OrbWeaver

You're free to distribute TDM yourself, in accordance with its license, along with a mission if desired (although I can't really see what you gain from doing so). But I think getting it onto a platform like GoG is going to face the same problem that Steam did: they want a legal entity who can sign off on the license status and take legal responsibility for the distribution (in other words, an entity who can get sued instead of GoG themselves if there is a copyright dispute).

GetMind()->GetState()->GetStr() == "Blinded" We use string comparisons to check AI states?

I liked the original T1/T2 flash bomb behaviour too, but I think a lot of players felt it was an exploit, because flashbombs were really intended as a tool to help you escape, not knock out an entire room full of guards in one go. Maybe I should try the Unofficial Patch. I consistently feel that the current game caters too much towards the "Original Thief was way too easy, MORE difficulty NOW!" crowd. I think it should also be accessible for people who want to experience the story and environments that mappers have created, without having to save and reload every 5 seconds because game difficulty has been turned up to 11.

Yes, that's just a func_static with a "model" key set to the entity name, which means it's brushwork converted to a func_static (so DR just renders the brushes). My guess is that DoomEdit does something specific when you "connect" a model and a light, which we're not doing in the same way. I thought that all that "connect" did was set a target key to point to another entity. Maybe it's supposed to have special handling for models and lights.

Correct. And I agree that the D3 way was much more intuitive, and allows the light to remain easily editable even after it has had a model attached. I never really understood the idea behind the TDM approach of starting with the model then attaching the light entities at runtime. I suppose it makes it possible to have more than one light source for a given model, but that would be a pretty bad idea from a performance perspective. We do now have the ability to preview the light entities (in the 3D renderer), which is a big improvement over having them appear as completely unlit models. Actually editing them, unfortunately, still requires a very clunky manual "set light_color on <attached>" approach, which is probably close to unusable without dedicated UI support.

Prefabs don't exist in the original Doom 3 or D3Edit as far as I know. But I don't understand what is the issue being reported. As far as I can see, creating a light entity and setting a "model" key works as expected, with the model becoming visible in the 2D and 3D views in addition to the light bounding box. I'm not sure what else is meant by "having a specified model for the lights". Perhaps vanilla D3 does this in some other way than by setting a "model" key.

Thanks for the report. I have bisected the problem to f99d1d5b417f043ee91b18cb3a79619bbdcac501 — Bounded::localAABB returns by value which was supposed to be a simple change to how a method returns its value but obviously I must have missed something when updating the various subclasses.

That's a pity, and rather an oversight in my opinion (although not very surprising, most of the licensing stuff wasn't really thought about very much until far too late in development). A couple of possible ways around it: Anything that came directly from vanilla Doom 3 would be covered by the id software license, which might be GPL for everything. In this case, the license cannot legally be changed by TDM and must be the original GPL license. For example, the func_static entity def has obvious references to "demonic" which suggests it is based on the original D3 definition. In many or most jurisdictions, purely functional elements which do not contain any creative or original content, or are needed for interoperability, are excluded from copyright protection altogether. This is how WINE is allowed to implement the Win32 API without permission from Microsoft, for example. This might make it possible to use certain entity definitions by stripping them down to the bare bones, and removing all original content such as documentation. Some entity definitions might not be as important as you think: atdm:entity_base, for example, only contains editor documentation for the various spawnargs (which could be re-written from scratch using original language, or just left out altogether).

DEF files are obviously code; I don't see how it makes any sense to have them under an "artistic" license. They are not simply aesthetic aspects of the game, they are functional elements, without which the game will not work. It makes even less sense to have some DEF files under GPL3 and others under CC. The only things which should be under a CC license are purely artistic elements like textures, models or sounds.

I would certainly be in favour of all DEF, MTR, SNDSHD and SCRIPT files being GPL3. Although these files may refer to artistic assets, they are not artwork themselves, but a form of code.

Oh, I was assuming we were talking about pre-compression of the images on disk. If it's just a case of dynamically compressing images at runtime which are known to be single-channel, then BC4 is a reasonable choice. I still suspect there will be very few cases where it is actually useful, though. Dynamic compression of specular maps will only be useful if the source images are uncompressed — re-compressing DXT1 to BC4 will be worse than uploading the DXT1 directly. I haven't been following the development of parallax maps so if there are a lot of new dynamically-generated or uncompressed images, perhaps enabling BC4 for these will be more of a win.

But aren't heightmaps only used by the heightmap() expression, which generates a new normal map? If the heightmap isn't directly rendered by a shader on the GPU, there's no benefit in using DDS compression. I suppose there's no harm in supporting BC4 if it's easy to implement, but I doubt it's going to make much of a difference. How many actual black-and-white images are there? Specular maps aren't needed for most materials, they can be lower resolution than the diffuse and normal maps, and they're not necessarily monochrome. And wouldn't you need special handling in the shader to duplicate the single channel into all three RGB channels for BC4 images (but not do this for full-color images)? Update: I just did a test with GIMP, and a DXT1 and a BC4 image are exactly the same size. So using BC4 doesn't achieve anything in terms of file size. What it gives you is smoother gradients for image types which are necessarily single-channel (e.g. heightmaps).

It's all theoretically possible of course, it's just a question of whether/when somebody will have the time to look into it.

"3Dc", "BC5", "RGTC", "ATI2" are texture compression equivalents of "panther", "puma", "cougar" and "mountain lion": all different names for the same thing. The article is correct, but you need to look carefully at the wording: "Each channel uses the same compression technique as DXT5 alpha". DXT5 has smooth alpha but blocky RGB, that's why vanilla D3 swapped the red and alpha channels for normal maps (so at least the red channel would be smooth, even though the green channel would still be blocky). The idea behind BC5 is to use the same technique for both red and green channels, while leaving out the blue entirely (because it contains no additional information in a normal map, and can be reconstructed in the shader). This gives an effective compression ratio of 50% compared to the uncompressed image, without introducing the blocky artifacts of DXT1/3/5 normal maps.

DXT5 for normal maps is obsolete. Both game and DR support BC5 (RGTC) normal maps, which are better quality and more efficient than DXT5 for this purpose. I fully agree with this. Having to maintain two separate trees mirroring each other is an awkward hold-over from vanilla D3. It would be so much more ergonomic to just dump DDS files into the main textures tree along with TGAs or any other format. Unfortunately when I looked at the code to see if this could be improved, it seemed very non-trivial because of the way that the scanning of the DDS tree was bound up with the compression code.

If we're going for completeness, it might be worth mentioning: TGA doesn't have to be uncompressed, it can use RLE compression (which can give better compression ratio than DXT for very smooth or low-detail images with large solid areas). PNG has variable compression, but is always lossless. Ogg Vorbis also has variable compression, but is lossy, with lower bitrates giving worse quality sound. Should not be used for repeated editing due to generation loss.

Things that would be worth including are things that are non-obvious, for example: What license are individual missions released under? Are mappers required to use the same Creative Commons license as the mod itself, or can they choose a different, possibly more restrictive license (up to and including "All rights reserved")? If it's a restrictive license, they at least need to grant TDM the right to store and distribute the mission for download, but they don't necessarily need to grant rights to end users to edit the content or re-use it for other purposes. How should the license be communicated? Is there a need for a mandatory LICENSE file in the mission package? Can a mission author revoke their mission, and ask the team to remove it from the server, or is the right to publish irrevocable? Are there any restrictions on mission sizes? Do foreign language missions have to include an English version as well, or can they be foreign-language only? If a third party believes their copyright has been infringed by a mission, what is the process for making a complaint? Who should they contact and how?

Ah, so the concern is that if we don't explicitly forbid illegal content, a mapper might include it, then argue in court that the TDM team was complicit because we didn't tell them up front that such content was forbidden? Maybe that's a valid concern; it's certainly not one I can dismiss out of hand without legal advice. But in that case, I still don't think there is any benefit in listing specific types of illegal content. The relevant ToS could be made much simpler, e.g. Similarly, we don't need separate items for "unauthorised copyrighted music", "unauthorised copyrighted game assets" etc. These are all covered by "content which infringes third party copyrights".

This seems like a solution in search of a problem. Where are all these mission authors submitting deliberately broken missions, missions containing child porn or missions promoting Nazism? Why do we need a list of rules stating the blindingly obvious, such as "illegal content won't be hosted by TDM"? Why do we need to tell people that we won't host their revenge porn or pirated game ISOs? And why do we need to standard tedious litany of virtue-signalling about vague, subjective concepts like "sexism" and "inflammatory viewpoints"? I understand why corporations need to do this to keep their HR departments and "diversity consultants" happy, but this is a volunteer project. I don't see any need for any of this. All missions in the TDM archive are hosted at the discretion of TDM administrators. This has always been the case. We don't need to spell things out with an explicit (but inevitably incomplete) list of rules which are all either obvious, vague and meaningless, or completely irrelevant in practice.

That should be fairly straightforward to implement; it sounds rather like what DR was doing before the change to treat bumpmaps as implicit separators. Are we certain that there are no materials using [B,D,D] to share a single bumpmap between two blended diffusemaps, since it looks like they might be handled differently now? This might have been something that only vanilla D3 used, perhaps to share a model's renderBump bumpmap with blended/painted diffusemaps.

https://www.darkradiant.net/userguide/#_customising_the_grid_appearance

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