OrbWeaver

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.