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