jonri

The problem comes when the mouse leaves the window. For example, if you start dragging the 3D view to turn left and your mouse gets all the way to the left side of the window, you won't be able to keep turning left. In order to turn left infinitely, the mouse pointer has to get snapped back to give you room to keep moving the cursor left.

I came across this bug report on wxwidgets: https://github.com/wxWidgets/wxWidgets/issues/23778 The short of it is that GTK decided not to support mouse pointer warping on wayland. There may be some sort of workarounds by making direct wayland calls, but I'm not sure yet if that's something we could even do from our layer, or if it would have to happen within wxwidgets.

I gave it a try, and mine crashed with the same segfault the first time I tried. I've attempted to reproduce it while running under GDB and haven't gotten it to crash again yet. Each time I started it it up the same way without moving. I did a little source code snooping and the only places I found that would print out that particular message "Getting threadname failed" would be where Sys_GetThreadName is called to print out some information when a mutex is busy, deadlocked, or not locked when it should be; or also when a thread is destroyed. If I manage to catch a backtrace I'll share it here or on the bug tracker.

It's not specific to the flatpak version, it happens in my dev build on Arch linux too.

Would you mind checking the other windows listed on https://bugs.thedarkmod.com/view.php?id=6165 to see if they cause crashes as well?

Is this still true now that 2.11 is out with this feature? I've been wondering about whether this might open up the possibility to use larger models for things other than terrain, for example modeling a building at a time in Blender and then assembling them into a street in DR. I'll probably at least test it out someday...

I doubt it's something on our end, as we just tell flatpak that we need OpenGL support and it's supposed to figure out the rest. I'll see if I can read up on it a little though. Flatpak has many advantages, but storage space efficiency is not one of them.

I just updated the flatpak, so it should hit flathub in a little bit.

I've been trying to finish off a handful of projects and experiments I had started a while ago, and remembered that I ran into a roadblock. I was trying to build some custom entities with slightly complex behavior and had wanted to access a def_attach'd entity from the script on its parent object. These script functions sounded pretty close: scriptEvent entity getAttachment(string attName); Get the attached entity with the given attachment name Will be NULL if the name is invalid or if the entity no longer exists Spawnclasses responding to this event: idActor scriptEvent entity getAttachmentInd(float index); Get the attached entity at the given index. Will be NULL if the index is invalid or the entity no longer exists index: starts at 0 Spawnclasses responding to this event: idActor scriptEvent float getNumAttachments(); Return the number of attachments on an AI. Used to iterate through the attachments if desired. Spawnclasses responding to this event: idActor But as you can see, they only apply to idActors. I dug into the source code and found that the code that handles all 3 of these functions just calls into the idEntity base class to retrieve the attachment, and there does not appear to be anything specific to idActor with those. As such, I'm fairly certain that these script events could be moved to idEntity without breaking any existing usages (assuming script event inheritance works as expected). Are there any downsides to doing this? I can create a bugtracker entry and/or provide a patch if there are no objections.

Looks like it didn't help this mystery issue for me

I wonder if this explains https://bugs.thedarkmod.com/view.php?id=6165 which I was never able to get anywhere with. When I get a chance I'll make a build with that fix and see what happens.

DR uses wxGTK on Linux, so I'd expect anything that works for other GTK applications would do the trick. I'm not set up to try it myself, but it looks like you might try setting the GDK_BACKEND=x11 environment variable.

Can you convince it to run under xwayland? A proper fix is preferred, of course, but this might make it usable in the meantime.

Flatpak is updated and should show up on Flathub in a bit.

I created a bug tracker ticket for this issue: https://bugs.thedarkmod.com/view.php?id=6165 I made a build with debug symbols on my desktop, and oddly enough darkradiant exits entirely rather than crashing with a SIGTRAP when I try to debug it. I'll keep investigating...