OrbWeaver

The ASE importer has never been updated to work with the latest Blender (this is mentioned in the README). Both exporters should work, but the only importer which works is LWO.

The problem seems to be that the in-game key binding settings simply don't allow you to use modifier keys with other keys. If you try to change a binding to CTRL-A, you just get a binding for CTRL. The interface is treating modifiers like regular keys. Whether this is a limitation of the underlying game, or just a problem with the keybinding UI, I have no idea.

That isn't one of the scripts I maintain. Mine only deal with LWO and ASE, not MD5. Updating this script to work with Blender 4.2 and integrating it into the LWO/ASE add-on ought to be possible of course, but I don't know how much work is involved (and I know next to nothing about armature animation in either Blender or TDM/D3).

Thanks for confirming the latest version fixes the issue. Note that you can see all of the changes for a new package by viewing the changelog: $ zless /usr/share/doc/darkradiant/changelog.gz

"start_delay" rather gives the impression that it is leaving a period of silence before starting the sound. I'd suggest "loop_start x.xx" if you want a specific start point in seconds, or "loop_start random" to let the game choose a random position within the loop. I assume if the new property was applied to the actual shader in the .sndshd file, rather than as a spawnarg on an individual map entity, it would apply to existing missions without needing changes by the author.

From the description it seems the problem is that several nearby lights are flickering exactly in unison, presumably because they are all using the same sound shader to control the flickering (and the sound shaders all start playing at the same time). So it would seem the solutions are: Use a slightly different looping sound for each light (if available). Implement a feature in code whereby the looping sound shader can be started from a random position, rather than from the beginning of the loop.

Given that the same issue reproduces in a local debug build, I don't think the issue is specific to the PPA build. But you're certainly welcome to try the FlatPak version to see if it behaves differently.

I can reproduce the issue with the PPA version on Ubuntu 22.04. Unfortunately it does not reproduce in a local debug build. Actually it does, it's just that the assertion message only appears in the console after I changed the handler for wxWidgets assertions, due to repeated assertions from within the wxWidgets art provider which we cannot do anything to fix.

There's nothing wrong with suggesting an idea, and nothing needs to be deleted. Your idea isn't impossible, just more complicated than it might originally sound. It's entirely possible that someone else will come along with a different perspective, or a completely new possibility for implementing it that none of us have considered.

I believe the light gem is already using a much lower image size than that (possibly 16x16 if I recall correctly). But note that on modern graphics hardware, resolution only makes a modest difference to render time. The engine still has to calculate all of the renderable geometry, do culling to determine what is in view, send it to the graphics card, which then has to map textures onto surfaces and run the shaders to calculate lighting, etc, etc. So doing extra renders is not free, even if the output is a 1x1 image. I wonder how the "light level" of an object or area can be calculated without doing either a render, or something that is computationally equivalent to a render. This isn't a basic 1990s engine where you can just calculate distances to lights — we have fully animated, textured and projected lights with (possibly moving) shadows, where every pixel can vary its illumination from frame to frame. It might not even be an actual light entity providing the silhouette at all: the player could be standing in front of a bright part of the skybox, or a glowing particle effect, or a self-illuminated texture like a window or lava. Either you need to do a complete render to account for all of these (followed by an image processing step to calculate the silhouette), or you're going to end up with an extremely weak approximation which breaks down in so many situations that it actually feels less realistic than what we have at the moment.

Both. If the source texture is a compressed DDS with mipmaps, the game can load it directly into GPU memory. If it is an uncompressed TGA, the game will compress it and generate the mipmaps at runtime, which will have a performance cost (particularly if you have a large number of high-res textures). Once the texture upload is complete, there is no difference in terms of FPS. Keeping the textures as TGA while you are developing the mission is fine, but you should definitely convert them to DDS before releasing the final mission package. The correct formats to use are DXT1 for diffuse maps (without alpha), and BC5/RGTC for normal maps.

These portals sound a lot like the ones in (the original) PREY, which I believe was an id Tech 4 engine.

Thanks for testing. I don't rigorously re-test with every new Blender release because most Blender releases don't break the export scripts, although some do obviously (particularly when they make huge changes like removing the whole Autosmooth function). Yes, the scripts aren't particularly good at reporting errors unfortunately. I should probably fix that when I have time. By the way, it's LWO — LightWave Object — not IWO.

Yes, this has been discussed many, many times, and the "simple solutions" suggested are very rarely all that simple. Switching from a single visibility value, affected only by incident light, to a per-guard visibility value is not a small change. It has both performance implications — every single guard needs to render a line of sight to the player, every frame, with full lighting and texturing in order to calculate the visible silhouette — and player UI implications, because each of those individual per-guard visibilities needs to be communicated to the player in a useful way. Sparkles around the light gem is an interesting idea, but how meaningful will those sparkles be in practice? When a player is surrounded by many patrolling guards, will they be able to map each sparkle to a particular guard, and conclude "Oh yes, the helmeted guard to my left must be able to see my silhouette against the bright wall to my right"? It also raises believability questions of its own, since it's effectively providing the player with an automatic "guard radar" that communicates information about what others can see, which is not information that people would normally have access to. Still, if somebody can get a prototype working which is performant, intuitive and fun to play, I'm sure many players would be interested in trying it out.

Correct. The user still has to set the executable flag on the script using chmod +x, but once they've done that, the shell will run it as an executable if it has the interpreter specification line.