OrbWeaver

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.