BTW: I really appreciate your effort, because we can really use this.

So my personal wishlist proposal is that I would like to see a group handler. Similar like in Blender, where you can select several objects and put it in a group. When you select one or more of these groups, the objects are visible. If the group is not selected, it's invisible.

In Blender and other 3D apps this is called layers (forgot the name before so I had to look it up).

1.  I create a map with a leak (or defective portal) and save it  (name, for example: m1)
2.  dmap ,  console shows leak
3. when going back to DR for the pointfile, a message appears stating that there is no pointfile for this map
4. then I save the map with a new name (m2)
5. dmap again
6. back to DR: then there is a pointfile

Anyone has seen this problem as well and if so, is there a fix?

Add a button "Make efx file from info_locations".

When you click it, it creates an efx formatted file with all the in the map existing info_locations and safes it automatically in an efxs folder in your fm folder. So then you only have to add the relevant presets for all the info locations.

Maybe something for a Python script?

1. It's a well-tested and respected linear algebra library, which means we don't need to maintain our own code to perform already-solved problems like matrix multiplication.
2. It can potentially use SIMD instructions (SSE, AVX etc) to improve performance. I haven't yet looked into whether this happens automatically or whether we have to explicitly enable these optimisations.
3. It is header-only, so should not present any build issues on the various platforms.

Our Matrix4 class still exists but it is now just a syntactic wrapper around the Eigen implementation, and several methods which performed matrix maths manually have now been changed to forward directly to Eigen methods like inverse(), transpose() etc. Since Matrix4 is now well covered by unit tests, I am pretty confident that nothing is broken because of this change, although it's still possible of course.

@greebo Next time you pull from my master branch, you will need to do two things:

1. Issue the git submodule update -i command (or GUI equivalent, if you're using one) to populate the external/eigen directory with the Eigen git repository.
2. Update include paths in the VS project so that external/eigen is added to the header file search paths.

Since it's already cross-platform and header-only, and the only current usage is with an existing class wrapper, I hope no other changes should be required on Windows.

I'm mainly using dark radiant for Doom 3 mapping, and it's working great, however sometimes just at random it would seem like the DR-feature for grouping adds (right click group) another brush or entity into the group. Not sure what triggers it, but I can come back to something, and the origin is suddenly half across the map because something else is included. So I'm running the risk of mistakenly removing or moving something without even noticing it, making me stare more at the origin than before as soon as I select something. At first, I was just sure I was the cause of it, like forgetting to unselect something, but it happens occasionally and now when I moved to a new computer it seems like the grouping is completely messed up. I made sure to move the entire dir of files where the .map file is, but I don't know, most groupings now are half done or include things half across the map.

I'm just curious if anyone else uses this feature extensively and have encountered or experienced anything similar? Just an observation.

This has wreaked havoc on my map (and I foolishly did not keep an emergency backup) so I'll have to reposition them manually unless I can figure out how to undo this. To make matters worse, it happened suddenly while I was saving some other changes and I didn't notice until later, and now I can't simply Ctrl+Z undo it.

I still have the origin data in the object properties, but I'm not sure why this happened, or how to revert it. Has this ever happened to anyone, and how badly screwed am I?

Whenever I click to 'View/New XY view' DR crashes. Same thing happens when I press L to set light properties. Just started using this editor, so far these are the only crashes I found. Anyone has the same issue and maybe a solution? I'm using Fedora 41, DR 3.9.0 Flatpak version. I've tried both Wayland and XORG

The package and build process was pretty straight-forward, minus MUSL libc not having an implementation of execinfo.h (nor a stub), so I needed to patch that out as well as most of the SegFaultHandler logic.

Otherwise, it runs and seems to work fine locally, which is exciting.

An issue I was not able to resolve, however, was getting all the tests in the testsuite to behave in our headless CI runners.

Here is the linked APKBUILD:  
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90369/diffs

I am unsure if there needs to be any packages defined in the checkdepends that are runtime dependencies for the checks, and I am unsure if wrapping the check in xvfb-run and vglrun is supported/tested against, or if there is a better way the team knows to test in headless.

Once I get this merged, I plan on building and packaging TheDarkMod itself, which I will likely seek guidance with.

Thanks!

I just setup a fresh out of the box, Windows 11 64bit laptop. I have downloaded all of the windows updates, installed TDM (which works) but when I downloaded DR 3.9.0 and ran it... I got the below error.

I tried uninstalling it, and tried the portable version with the same result. I couldn't see any .log files in the DR directory either. There's no error code, and Google doesn't help too much.

Greebo-wan-kenobi, you're my only hope!

(this is on a Win11 pc, although I usually work on Linux)

Also look at the greyed-out buttons. Is that normal?

This is just me being a bit curious. I've grown quite fond of DarkRadiant, so I tend to use it over the built-in d3-editor when mapping for Doom as well. However, there is one thing that doesn't work well, and It's when you have a specified model for the lights. So if you open up any map, you'll see the box with a question-mark instead. This is usually when there is special things going on like breakable lights etc. Is that just functionality that was never needed for the Darkmod/DarkRadiant or is there something else going on ? I tend to use d3-editor just for those special cases.

As far as entities go, I think I'm probably fine. I unpacked a few of TDM's .pk4 files and found the folder def with many .def files. I tried placing misc.def and tdm_base.def in there, to see if DR would load those entities after restarting, and it does but only if the game type is TDM. I'm probably fine with that, as it makes no difference, as far as I can tell. The Godot importer only cares about the contents of the .map file, which I know I can export in a few formats, so that should be fine (Q3 at least should work fine).

However, DR is not seeing my project's textures. I don't know if DR can work with .png files, but I brought in some .tga files from TDM for testing and DR doesn't see them either. So something is missing, but I don't know what it is.

I tried placing the textures in a textures folder at the project's root, but nothing happened. Although ideally I'd like to have the textures in root/assets/textures.

I haven't tried to use 3D models at all yet, so I'm in complete darkness about that. I wonder what formats DR supports, though. I usually work with .obj, which bypasses Godot's import weirdness.

Only downside I see is persisting too many open maps, in which case DarkRadiant may be slow when it starts up and use more resources, but since DR loads all assets in memory once I don't foresee this being slower than just opening one huge map that loads a ton of models and textures. I imagine standardizing undo / redo / autosave / other systems to recognize the map that's currently selected and be unique to it may be a little tricky but hopefully it's doable.

When I select the GUI Definition browser, I get a bunch of errors in the DarkRadiant log:

2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: -10
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 500
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 400
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: -10
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 500
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: ,
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: 400
2022-09-26 12:22:04 (57608) Unknown token encountered in GUI: rect-100
...

I searched for "rect-100" and found several in *.gui files. For example, book_bamberg_gothic_both_curl.gui has:

    windowDef rightPageBackground {
        WORLD_SCALE
        rect-100, -10, 500, 400
        background "guis/assets/readables/books/book_rightpage_curled_01"
        matcolor 1, 1, 1, 0
    }

Note, no space after "rect" and before the "-100"

I haven't been editing readables for a while, so I don't know when this started happening. I uninstalled and reinstalled DR 3.3.0; still have the problem. I ran tdm_installer to ensure my DM install was up to date (2.10). 

It must be something local to my configuration, because if this was happening to everyone we'd have heard about it by now. Does anyone have any ideas what is going on here?

For example: in this material, the grass bump appears everywhere so my dirt path has a grass bump pattern visible in it, which does not look good.

textures/darkmod/map_specific/grass4_dirt_01_blend
{
	qer_editorimage textures/darkmod/nature/grass/grass4_ed
	surftype15
	description "grass"

	{
		blend diffusemap
		map textures/darkmod/nature/grass/grass4
		vertexColor
	}
	{
		blend bumpmap
		map textures/darkmod/nature/grass/grass4_local
		vertexColor
	}
	{
		blend diffusemap
		map textures/darkmod/nature/dirt/dry_earth_muddy
		inverseVertexColor
	}
	{
		blend bumpmap
		map textures/darkmod/nature/dirt/dry_earth_muddy_local
		inverseVertexColor
	}
}

I've tried other textures with the same result. Note that this shader was made using the built in material editor in DR 3.8.

As you can see the grid in the 2d view is not visible and I have no idea how to present it. I've had previously DR installed where it did show.

os: Manjaro Linux xfce

Flatpack install

Have a pleasant mapping day.

Maybe I'm doing something wrong? But it should not crash at least.

Using DR 3.7.0 under Linux