OrbWeaver

I'm not sure how the web site works these days — is it Git based? I do actually have a little GitLab CI script in my repo (https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/.gitlab-ci.yml?ref_type=heads), which just generates the manual HTML using asciidoctor then puts the resulting page into the public directory, but I can't remember what URL the content appears at (if it still appears anywhere). Presumably if all of the website content was in the repo, such a CI script could deploy the whole thing rather than just the user manual, and the darkradiant.net domain could be pointed at it. But I don't know if maintaining a website by making commits into the same repo as the source code is actually a good practice or not.

Blender 2.79 is eight years old at this point. The only scripts available back then were the ASE and LWO exporters, which can still be downloaded from the corresponding branch. There's a partially working import script for ASE available in the latest branch (which only imports geometry, not materials or vertex colors), but the chances of it working with an ancient version of Blender are very low, given how much the Python API changes between major releases.

EDIT: Never mind, I've already wasted enough of my life arguing on the internet.

Presumably he didn't delete them because he didn't actually know he was going to die before being able to release them, and keeping the beta process going was potentially useful to get feedback before release. I'd interpret "no archiving as-is" as a pretty unambiguous desire not to have them remain available for download, even in beta state.

A hypothetical system to allow the team to recommend or promote certain missions, without making them "official", might be a reasonable way to help new users. Or even allow the best missions to be voted for by players and given some kind of rating in the in-game downloader (although that requires server infrastructure to receive and count the votes).

Don't mean to be rude, but did you read the thread you linked to? It pretty clearly states (1) the hash is for the self-update process, and isn't intended for manual checking, and (2) if you do want to check it yourself, you can use the command line tool b2sum (on my Debian system this is installed by default as part of the coreutils package, so I assume it is available on xUbuntu as well). The hash has nothing to do with security. If you don't trust the installer you downloaded from the official website, you also shouldn't trust anything you read on that site, including hashes. Anyone who can compromise the installer can compromise anything else on the website. Using a hash to confirm a download is only useful if the hash comes from a separate, more trustworthy source than the download (e.g. downloading an Ubuntu ISO from a random mirror, but looking at the official Ubuntu website to get the correct hash).

And we know exactly how well it works out when tech-illiterate lawmakers start dictating the functions of technology they don't understand. "We don't care about this physics shit! We passed a law that requires you to provide faster-than-light travel and you nerds better figure out how to make it happen!" I don't even understand what these petitioners are asking for. Do they want a law that compels providers of online games to keep the servers running forever (even if the company goes bust)? Provide a refund if the servers have to be switched off (even if the company has already gone bust, and has no money to pay for it)? Implement an offline mode for games like WoW where it makes no sense? Or just never provide online games in the first place? No matter what they're asking for, I'm pretty sure what they're actually going to get (if the law is passed) is games publishers simply not selling into the EU/UK market at all. Just like the web sites which are now blocking UK visitors because the dumb fucks who passed the "Online Safety Act" mistakenly believed they had the power to regulate the entire internet.

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".