VanishedOne

Yes, Q4 and ET:QW both had their own implementations but D3 never did. (It appears from the leaked D3 demo that at one stage its parser was going to use the C preprocessor, or something like it. DECAL_MACRO is a leftover from that era but is no longer implemented in the same way; probably id never used the preprocessor for anything else and decided it wasn't worth it.) Someone did make this though: https://forums.thedarkmod.com/index.php?/topic/18843-material-generator-bash-script/

Speed potion assets (model and shop inventory icon, but no inventory shop icon) have existed since way back, much like the gas mine model for which Sotha made a def. The original plan was probably to implement it in a similar fashion to D3's powerup code (there's a comment "// TDM: leave this in for speed potions or something" in Player.cpp where most of the powerup code was stripped out). (By the way, the RoE version of the D3 gamecode has commented-out code for a "powerup_haste".) I made script-based implementations of speed and slow-fall potions a while back, initially very buggy ones once people started trying them out in various situations, though as far as I know all reported bugs are fixed.

Here's the earlier thread: According to this, LGS tried adding a 'Loud Room' property to Thief 2 but it ended up unused.

Cheers! If there's to be another patch, I'd just like to alert you to missing surfaces on the sides of this archway in the Plague Ward: (Seeing pyramid images everywhere is quite amusing if you've played Control, where an inverted black pyramid is the symbol of the mysterious Board residing on the Astral Plane...)

Does anything come up in the console afterwards? It should say something like "Wrote <filepath>".

There's the Inn Business approach - use the campaign system to run the same map multiple times, allowing for persistent items/variables - but it only works for a finite number of revisits. Having finished your masterpiece, I just wanted to ask about one room:

I think what I've got is the official release from the downloader, but after the briefing it dumps me at the console, having apparently tried to load an incorrect map name (startingmap.txt says movingday31, the files provided are movingday54). Edit: ah, I think I've found the problem. At some point I must have downloaded a prerelease version called movingday; the final version is called ptb0; therefore the earlier one didn't get overwritten. False alarm then, sorry.

I'm also getting a crash to desktop (Linux, TDM 2.10 final). It seems to happen after the game creates an autosave (the one called Desert). I'm playing on Normal so I can't comment on save rooms. Ordinary manual quicksaving is unaffected.

There's some vehicle-related code still in AFEntity.h/AFEntity.cpp (unlike the idAFEntity_ClawFourFingers class, which was stripped out of TDM), but I don't know whether it's in a working state; presumably it needs a suitably rigged MD5. I was thinking more of the bullet time feature (though some might consider it Dishonorable). I think that's what the timegroup stuff is for: https://github.com/TTimo/doom3.gpl/search?q=timegroup&type=

Another thing to be aware of is that the TDM gamecode (as opposed to the renderer) seems to have been built on top of the D3 SDK (before the whole engine went open source) and therefore not on the RoE gamecode. That's why the xray stuff didn't work properly before 2.10. So on top of what's been removed or altered, there are RoE features that never existed in TDM to begin with.

Here is what id's notes had to say about custom images in foglights. I could never get them to have any effect on the appearance, and have long suspected that that note is a relic from an earlier phase of development. id's D3 mappers seemed to like putting fogs in areas below/above the playable area, to give a sense you were walking over deep pits, so I think the vertical falloff may have been designed around that use case.

It isn't limited to transparent materials - see e.g. textures/darkmod/stone/flat/smooth/alabaster_opaque - but your second point is well made.

Materials can pass the depth buffer to a fragment shader as _currentDepth. (And _currentRender is a copy of the framebuffer.)

Apart from one which implements its 'camera' using a trigger brush. Edit: scratch that, I missed the word 'prepackaged'. As one of the people encouraging customisability, what I'm after is to avoid the present case in which assumptions down to the camera's spark particles are hard-coded. As I wrote on the tracker, I agree that it would be poor mission design if visually identical cameras had wildly divergent behaviour.