OrbWeaver

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.

I don't know of any system on which your Python script could just be invoked as "dmpak". Mac and Linux will not remove file extensions because there is no such concept; the extension is just part of the name and there is no equivalent of ".exe" to indicate an executable file. As far as I know Windows will not run a Python script by just typing the file name without an extension, but I don't develop on Windows so I could be out of date. The interpreter line has nothing to do with Python or the Python version. It is there to indicate to the shell what command to run in order to parse your script. Without that line the shell will have no idea that your script is a Python 3 script, and the Python 3 interpreter will never even be started. The interpreter line is not needed if you always start the script explicitly with "python3 dmpak.py"; it's only there to allow you to run the script directly as an executable from the shell. Well it's up to you. If you don't care about syntax highlighting randomly highlighting some of your variables in a different color (or you don't use an editor/IDE with highlighting at all), and you don't ever intend to call the conflicting function, I guess it doesn't matter (and it won't cause a Python error in this case). But note that a public member variable is very far from a "small ephemeral scope", since it could be referred to by any amount of downstream code which uses the class. Maybe, but the resulting code will be larger, more complicated and bug-prone if you needlessly re-invent the wheel, so the effort of learning argparse is hardly wasted. Getting a simple ArgParser up and running is a few lines; far fewer than the dozens of lines you already have to manually parse arguments, split strings, write out a large help text (which needs to be manually kept in sync with the actual arguments), etc. The only time I wouldn't use argparse is if the script is so simple it's just taking a single argument, e.g. "process.py /path/to/inputfile". But your script is already way past that level of complexity. I'm not sure what you think is "hidden" — the Python semantics are very clear, a non-empty sequence is True and an empty sequence is False. But you're right that it is just a stylistic issue, and some people do think that "len(seq) == 0" is clearer in expressing intent. Just remember that the performance considerations do exist, although in your case the size of the sequence is small so it is unlikely to make a difference (it's more of an issue of you have a list of a million points and you want to check that it's empty after processing each point, or something like that). Another advantage of "if not x:" is that it will also correctly handle the case where x is None, whereas "len(None)" will cause an immediate crash. Again, probably not an issue in your case but it's something to be aware of.

.

A few initial observations of the code: The README says you can just run the script as a command ("dmpak .") however this won't work on Mac or Linux. In order for it to work the script needs to start with an interpreter specification line like #!/usr/bin/env python3 and the script needs to be made executable by the user with chmod +x dmpak.py. After this the user can run it as ./dmpak.py but it needs both the "./" and the file extension. Instead of using functions like os.path.join you should use the new PathLib module. class Task: type = "" arg = "" def __init__(self, type, arg=""): self.type = type if arg: self.arg = arg You have defined class variables type and arg which serve no obvious purpose, and are shared with all instances of the class (equivalent to static member variables in C++). Python does not require instance variables to be declared in the class body (and there is no way to do so), so if these are just intended to be instance variables, you should remove the class variable assignments and just assign the instance variables in the __init__ method directly. Also note that type is a built-in function in Python and generally should not be used as a variable name. i = 0 while i < argc: string = argv[i] ... i += 1 This is how a loop would be written in FORTRAN or C, but is not idiomatic Python. It would be more usual (and much shorter) to write it like this: for string in argv: ... process string However, you shouldn't write your own CLI argument parsing function at all, instead you should use the argparse module which will parse the arguments, detect errors and generate the help text for you automatically. if len(tasks) == 0 and fm_path != "": add_task(PACK_FILES) Do not use len just to test if a list is empty, it is inefficient (as it must iterate over the whole list just to count the items). Instead, use the fact that an empty sequence is false, with: if fm_path and not tasks: ... As the above code shows, you can do the same with strings, since a string is a type of sequence.

Is it using the 7zip module just to create a better-compressed ZIP, or is it actually creating a 7z-formatted file using the LZMA algorithm? If it's an actual 7z file, will the game actually load it? The packaging section on the wiki suggests that only ZIP format is supported (although it could be out of date).

Not only is caulk not rendered, but it doesn't even generate renderable triangles at all. You can texture a wall with caulk, go into game and enable r_showTris and you will see no triangles at all for the caulked wall. At least that was the case the last time I tested. Perhaps the behaviour has changed with the numerous renderer optimisations that have happened since then.

In general, medieval fantasy-style worlds don't incorporate much real-world technology, while hi-tech worlds tend not to use magic. I suspect the main reason for this is that magic and technology have a lot of overlap in what they can achieve, and it wouldn't be obvious why you would need both. If you have artillery you don't need a fireball spell, whereas if you can read people's minds with magic you don't need advanced brain scanners. Some works do have both, but they have to consider carefully how to combine them. Harry Potter largely keeps the magic and muggle worlds separate, whereas the Rivers of London series makes magic users extremely rare while also making magic itself extremely damaging to technology (your iPhone will catch fire if you cast too many spells near it). There's no reason why a mapper cannot introduce some explosives or firearms into a mission if it makes narrative sense. I believe one of the T2X missions did this.

It's nowhere near as easy as you think, and there's no way in hell you can do it in bash. Sure, you can try something really simple and obvious like grepping for the material name and then grepping for the word "diffusemap" and hoping for the best, but it won't work. Materials and other declarations are complicated. They have a large number of keywords which can appear in an arbitrary order, they have nested blocks, they have math expressions, they have quoted strings and comments (including multi-line C-style comments) which might themselves contain keywords or even entire commented-out definitions. I actually started writing a new material parser in Rust, with the intention of creating a command line tool which could answer queries like "Get me the path to the diffusemap for material textures/common/blah" so it could be used as a back-end for the Blender import/export scripts. I started out by trying simple text searches and quickly realised that it wouldn't work. In order to parse anything you have to parse everything. That project has been going on for over two years and it still doesn't parse all of the TDM materials (and that's just materials — it doesn't even touch skins, model defs or any other kind of decls which you will need to parse if you want to determine the complete set of assets used by a map).

The renderer is now fixed in DarkRadiant to give the same results as the engine, provided the stages in the MTR are correctly sorted. This finally answered the question of why the sorting matters: we need to choose a particular material stage to be the "delimiter" between interaction passes, otherwise there is no way to correctly handle both blending between two completely different textures sets (B1, D1, B2, D2) and sharing a bumpmap between two blended diffusemaps (B1, D1, D2). There's no particular reason why the delimiter has to be the bump map, but I assume the D3 devs chose this approach because sharing a bump map between two diffuse maps is more useful than sharing a diffuse map between two bump maps.

I'm certainly in favour of new syntax if it makes things clearer or more flexible. We might consider something like POV-Ray's nested block approach, e.g. Blend between two materials: interaction { diffusemap textures/first_d bumpmap textures/first_local vertexColor } interaction { diffusemap textures/second_d bumpmap textures/second_local inverseVertexColor } Shared bumpmap, two diffusemaps: interaction { bumpmap textures/bump_local diffusemap { map textures/first_d vertexColor } diffusemap { map textures/second_d inverseVertexColor } }

Well I guess you learn something new every day. The blending works correctly in the engine if you put the bumpmaps before the diffusemaps in the MTR. It is also the order that KatsBits tutorial example is using, although he doesn't mention that it's a requirement. I guess we can consider this a documentation issue rather than an engine coding issue (it still needs fixing in DR though).

I was referring in this case to the order of stages in the MTR declaration. I don't think there is any requirement for the bumpmap to appear first in the MTR, is there? I certainly haven't seen any mention of this requirement in the texture guidelines, and most of our materials have the diffusemap first. I'm still confused as to which part of the rendering code cares about the ordering. Is it simply that the engine passes around arrays or vectors (rather than structs with named fields), and it needs to assume that images[0] is always the bump map?

I have wondered that myself, but I always assumed the purpose was to allow individual stages to be given different transforms, e.g. you can have the diffusemap twice as large as the bumpmap, or give it different RGB scaling or whatever. If the D/B/S maps were all part of a single stage declaration this wouldn't be possible without different syntax (e.g. nested sub-stages). That's perfectly fine, as long as the "packets" themselves are kept whole. If the material stages are {D1, B1, D2, B2} and the engine sorts this into {B1, D1} {B2, D2} then there is no problem, but what DarkRadiant (and maybe the engine) is currently doing is sorting the original list into {B1, B2, D1, D2}, then reconstructing the triplets at render time as {B1, <black>} {B2, <black>} {B2, D1} {B2, D2} which is obviously wrong and gives rise to the observed behaviour of only the second bumpmap appearing on a vertex-blended model. Maybe our sort code is fundamentally sound, but it needs to happen within triplets, not on the whole list of parsed material stages? But then within a triplet, each material has a specific purpose and is assigned to a dedicated shader uniform, so I'm not sure if the order has any effect.