Jump to content
The Dark Mod Forums

Skaruts

Member
  • Posts

    413
  • Joined

  • Last visited

  • Days Won

    7

Skaruts last won the day on February 6

Skaruts had the most liked content!

Reputation

178 Excellent

About Skaruts

  • Birthday 03/03/1981

Profile Information

  • Gender
    Male
  • Location
    In a dark corner behind you

Recent Profile Visitors

2187 profile views
  1. None of this is relevant, though. I will be switching OS and experimenting at some point, but I have other priorities to worry about in my life and no willingness to be adding that on top right now. Meanwhile, this is what I have to work with, and I'm trying to find out if there's a way I could still compile DR with it. @OrbWeaver I could use virtual box to run a linux distro, but could I compile to a windows executable from it? (I presume I can't.)
  2. I'd still be on XP if they hadn't dropped support. I didn't say anything to that effect. I just grew to hate having to keep switching OS due to their business model that keeps imposing that. Been doing that for nearly 30 years now. I don't expect Linux to be paradise. I just hope it's less infuriating than MS products. Either way, that's besides the point here.
  3. Unfortunately WSL is also for Windows 10, minimum. (This is why I'm going to switch to linux in the near future. I'm fed up with MS's bs and complications.)
  4. Couldn't compile. Seems my VS is also too outdated as well. I have 2019 at most, and I don't think I can install 2022 anymore.
  5. I'd like to be able to compile it, but I can't run VS to save my life at this point. Credentials gone stale (as always), and still being on Windows 7 is making it impossible to fix them (though it would be a nightmare anyway). So I need some other way, but I don't know enough about compiling C++ to know what to do. I tried with cmake, but it didn't compile. I got a whole bunch of errors just like this one: CMake Error at C:/CMake/share/cmake-3.29/Modules/FindPkgConfig.cmake:681 (message): pkg-config tool not found Call Stack (most recent call first): C:/CMake/share/cmake-3.29/Modules/FindPkgConfig.cmake:847 (_pkg_check_modules_internal) CMakeLists.txt:54 (pkg_check_modules)
  6. I took a look at DR 3.8 source code (not latest), and it seems to me it only ever checks for the fs_game and fs_game_base command line parameters.
  7. I was just giving this another go, and it seems neither fs_game nor fs_game_base set the actual engine's path. This is the problem I was having before. Looking at other game types in the drop down menu (in the Game Setup window), some of them show that fs_game sets the "Mod" (Mission ) and fs_game_base sets the "Mod Base", and not the "Engine Path". (fs_game is actually useful for Dark Mod mapping, though, for working on multiple projects. Thanks a lot for that. ) What I really need is to launch DR with an engine path (and no Mod or Mod Base at all). Is there a parameter to do that?
  8. I use hotkeys for filters, yes. If I had to access the menus every time I wanted to hide/unhide things I'd go insane. I wouldn't toggle them on/off nearly as much as I do, and my workflow would be slower and more limited. As an example, I very often toggle visportals on/off for adjustments, or func_statics for inspecting world geometry. And sometimes I have to turn off all filters so that I'm 100% sure I'm copying or moving geometry properly, without leaving behind hidden clips, triggers, visportals, nodraws, etc. And then I have to re-hide all the things I like to keep hidden. I don't know about your workflow, but 99% of the time, I keep collisions, shadows, sky, visportals, triggers, nodraws, and also caulks, all hidden and out of my way. With hotkeys I just press alt and a bunch of keys in succession, and it takes me seconds. With menus it would take a while. There's no way I could ever not use hotkeys. I'd go completely nuts. No, I'm saying they require more work than just simply creating a layer and putting stuff in it. And if you don't put a hotkey on it, it's also more work to use. I'm not saying you can't use them for that. I'm saying they're not the right tool for it. EDIT: Keep in mind that the example above is just one example. There's all sorts of things you might want to use that functionality I suggested for. And again, layers are map-specific. If you setup filters for layers (is that even really possible?), then your filters menu will grow, and become polluted with junk that only works on certain maps. And the more you do it, the worse it gets. Back when I could used that in Hammer, I always had quite a few layers per map that controlled visibility of specific groups of objects. When you can just go wild with it, you go wild with it.
  9. It's arguably quite a bit more work than just creating a layer and adding stuff to it. And then you'd have to also add it to a hotkey, to make it practical. Filters are good for things you want to keep as groups forever, not really for temporary or map-specific groups. One other problem with filters is that you can only have so many hotkeys. Any filters that aren't attached to hotkeys aren't practical to turn on/off, because you need to access the menu. (Ideally, filters and layers would be unified under the same system, because they are actually the very same thing. I went into this in more detail here. I'm not expecting that to be done in DR, though. It might be a lot of work. But I could be wrong.)
  10. I've been meaning to suggest this for months, but the previous improvements have already made Layers so nice to work with that I just got lazy about this. But there's a few things I think could still be improved. And personally, I would prioritize the first one below, if I had to pick one. I haven't been following DR's development, so I don't know if any of this is already done and ready for the next release. But in case it's not, here goes. 1- it would be nice to be able to right-click a layer in the Layers panel, and have all the options to add to layer and move to layer and remove from layer, right there. This would make it much easier and quicker to manage layers. And, I personally keep adding prefixes to layer names, so that they're sorted in the list below, so I can find them easier, because the list gets big and confusing. This improvement would remove the need to do that. It would even remove the need for using this list, I think. 2- It would also be nice to add a new layer directly as child of another layer, just by right-clicking the intended parent layer. Currently, you have to click the New button at the bottom, and then manually drag the layer to its intended parent. Or when clicking New, the new layer could be created as child of the selected one. 3- I've suggested this one before, but I don't know if it's doable or not. It's harder to explain and I think the benefits aren't very obvious. It would be nice to override the visibility of objects that are contained in multiple layers, by toggling one of those layers on/off. So the layer you toggle, overrides their visibility. So regardless of whether its objects are visible or not, hiding this layer, would hide all of its objects, and vice versa. This can be useful when you have certain objects in their respective layers, but then you'd like to have also have a way to toggle all of them on/off at a single click. And with this improvement you could add them to a separate layer, and then just use that layer to override their visibility whenever you needed. For example, to get the ceilings of a whole bunch of rooms out of the way all at once, so you could have a clear view of the rooms while you put in furniture or path nodes or something. Currently, objects are always visible if any of the layers that contain them is visible, so this kind of thing can't be done. (And to be honest, because of that, currently it seems to me that there's no point having objects in multiple layers.) This is also useful for grouping things for easy group-selections. Arguably, you can also use selection sets for that, but the way you create and delete them makes them more suitable for quick and dirty one-time grouping, rather than something a little more indefinite. The two approaches have different levels of control, which makes them appropriate for different use cases.
  11. I updated the mission to version 2. No major changes, but quite a few bug fixes, adjustments and stuff. https://www.mediafire.com/file/bg9crjsa020z9wg/sk_cooks.pk4/file @nbohr1more I presume you're the one I should notify to update the mission database?
  12. This mission strikes a special cord in me, as I've always been a huge fan of horror. But either I'm too dissensitized to monsters and demons, or not many games actually do a good job at it. Either way, I'm happy to say that this mission actually made me feel spooked or uneasy, hesitant to pick things up without looking behind me. At least for the first playthrough, this mission is nicely unpredictable. As far as I'm concerned, you're doing something fundamentally right. The atmosphere is also really good. It really ads to the tension, and to the sense of hostility of the whole place. Brilliant mission. Loved it a lot. Thanks.
  13. @grodenglaive I think random head turning might be plausible for specific characters, if they're supposed to be paranoid for some reason. But you should let the player know in advance that they're always looking over their shoulders. I don't know if Elsevier has any reasons to be paranoid, but it could be plausible in his case. It could even be one of the reasons why Astrid had a hard time seeing him insert the safe code. The doors thing, at least some interior doors were auto-closing too. I was specifically thinking of the dinning room doors when I wrote that. I think there were more auto-closing interior doors, though. Personally, my potato doesn't have any real issues with performance in this mission. Only on the outside the frame rates drop below 60 sometimes, but never enough to make any noticeable difference to the gameplay. That said, I wonder if you could use double visportals on the outside doors. That might help, as the inner portal should close more often, without needing to close the doors. I use double portals sometimes because of that. But it needs testing to know for sure whether it helps or not. (It also requires adjusting info_locationSeparators, as they can only touch one portal). Also, the big visportal in the water that separates the front yard from the spider area seems to be always open. I wonder if having two visportals in a V shape (from the top view) instead of that one, would help closing it. Or some similar configuration that doesn't interfere with the view from the watchtower.
  14. I'm having no issues blackjacking any of the AIs, including the anti-BJ helmet guard (still hits him), so I don't really know what's going on with that. Could be some bug in the game.
×
×
  • Create New...