Skaruts

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.

Actually I think I found what's causing issues with my textures: DR changes the texture's Horizontal and Vertical Shift when a face gets slanted. E.g., my test door is facing -Y and sitting flat on the ground, which is at 0 in Z, so the v-shift is 0. When I move the bottom vertices of the door 8 units forward, and then re-fit the texture, the v-shift turns to 4 (3.97241). If I do the same but backward, the v-shift turns to 90.7035. But these values depends on the distance the face is from the world origin, and sometimes if I move the top vertices instead, the values don't change. I can't make sense of it... The other editors don't do this, so the plugin's import code doesn't account for it. Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it.

I'm not using the Quake 3 engine, I'm using the Godot engine. The results seem ok, except when faces are slanted, but I'm not sure why it happens. I'm trying to find out. I don't know anything about the Q3 engine, so I'm not the one to say what's correct and what isn't about the map format. When I said "correct", I just meant that it's the same value that is displayed in the editor. But there are differences between the Q3 format from DR and from other editors I've tested, like TrenchBroom and NetRadiant Custom. They keep the texture values as they are in the editor. One other difference is that DR exports entity brushes with coordinates relative to the `origin` spawnarg, for example. Though DR is also the only editor that enforces the `origin` spawnarg. (I know there are two Q3 formats, and I'm using the equivalent one on all editors.) I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

So..., texture issues are being the only road block I'm having so far in trying to use DR with Godot, but I'm not exactly sure why yet. However, I've noticed when exporting maps in quake3 format, that the texture values don't match the ones in the editor. This is the door face in the map file: hs vs rot hscale vscale ( 24 64 0 ) ( -24 64 96 ) ( 24 64 96 ) darkmod/door/wood/board_brown_nails_hinge 64 256 -180 -0.375 -0.375 0 0 0 The horizontal shift is the only correct value. Is this a bug?

Someone else wrote that in the OP, I just edited the source link into it. There's not going to be any voices.

Switching systems is a longer term time and effort investment than a way to compile a program. Especially because I am willing to invest some time learning linux. Mint, probably. I don't have any strong preferences, I just want something reliable and low maintenance, where I can focus on work.

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.)

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.

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.)

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.

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)

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.

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?

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.

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.)

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.

Thank you.

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?

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.

@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.

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.

@The Black Arrow

Just finished playing this mission on Expert. Took me a little while, but I actually managed to ghost it (with a few suspicions). The spider can be dealt with without incurring any penalties for ghosting. I love the aesthetics. The house looks gorgeous, and the whole outdoor areas are gorgeous as well. The lobby area -- or whatever it's called -- is quite tough for ghosting, I would say. I had never played an assassination mission, so to me it was interesting to have improvise. I presumed the guard outside would hear me stabbing the guy to death, and I also presumed he wouldn't die with a single blow (I later confirmed that). So I decided to... My only issues with the mission, were: That's about it. Lovely mission.

It very much is. I've been goofing around in DR for a decade, on and off, and about two years ago I said to myself "that's it, I'm gonna actually make a mission for once". (And then about a year ago I started making this one.) So yea, my drive to do this hasn't dwindled, it has only gotten stronger. I've always loved making maps for games, and I still very much do. If I told you, I'd have to kill you. I actually wanted to make that book readable, and have some kind of interesting recipes in there, but I just couldn't think of anything... If I ever think of something, I'll do that.

@lowenz @chakkmanit's not a bug, it's a helmet that protects against blackjacking. From the wiki: blackjacking: That's why the bj doesn't rise. Though if it still doesn't hit the guard, then that's a bug, I suppose. I think the game lacks a proper way to inform players about these helmets. The Training Mission doesn't include any guards with protective helmets, so currently the wiki is the only place one could learn about them... In my opinion, the "low back" can be deceiving. The guard in the screenshot doesn't have it, and some guards have it but can still be blackjacked.