OrbWeaver

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.