VanishedOne

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.

maskColor and maskAlpha are reasonably common when working with alpha masks: textures/darkmod/glass/clear for example. I've never seen a use for maskDepth though. Polygon offsets would probably be used more if they didn't break light interaction (one learns the hard way why setting DECAL_MACRO can be a bad idea); I basically associate privatePolygonOffset with D3-esque burnaway effects. Isn't the depth hack a particle thing from before sort particles? I have the impression that vertexColor is fairly rare because it needs a mesh with vertex colour data, and it's mainly used with inverseVer

I should think adding shader effects to the spyglass overlay would be done by adding a stage to the tdm_spyglass_overlay material to invoke a postprocess shader. You could look at water materials like textures/water_source/water_clear for an example of a stage calling a shader program.

I think blend modes with dedicated names tend (apart from blend none) to be pretty widely used and easy to learn: blend add for anything self-lit, blend filter for darkening effects like grime, blend blend as the basic choice for alpha blending. Other blend modes I'd consider more advanced, since you really need to know what the syntax means to work out how they interact with background colours: stuff like the blood decals that use blend gl_zero, gl_one_minus_src_color is quite non-obvious.

TDM flashbombs have no effect on undead, actually: supposedly the rationale is that undead don't physically see you (zombies hunt by scent), even though this makes no sense in a game with shadow- and line-of-sight-based stealth. The out-of-universe rationale is to make holy water more valuable. Even experienced mappers get caught out by this: The Rats Triumphant gives you some completely useless flashbombs. Flashbombs will harm the ghosts in my w.i.p. though.

It warms my heart to know that while half the world's hobby communities are engulfed in culture wars, there are still places where the high drama erupts over GUI design. On a more practical note: being able to add a background image to the preview might be useful for testing blend modes. It looks from the screenshot as though the list of stages has them identified by blend mode: maybe the currently selected stage could be highlighted in the right-hand textbox too, to make it easier to tell which blend add stage you're manipulating right now?

Base holy water damage is supposed to be 140, and health for a basic zombie is 150. Maybe something weird is going on with damage scaling, though I don't see where. Edit: I had an idea about this (presently untested): radius of the holy water stim: 24 units. Zombie's height: ~82 units. I don't see anything to make the stim test for intersection with the zombie's body instead of its origin; and an AI's origin is at its base... I think the stim is supposed to move downwards, like the water stim, but maybe it's missing if it's too far to the side, since the origin is at the (ahem) dead centr

Going a little offtopic here, but since you mentioned it: it seems from its script that holy water is less effective than you'd expect against multiple targets. // greebo: TODO: This won't cut it for holy stims damaging multiple undead if (stimSource.getIntKey("stim_already_fired") == 1) { //sys.println("Ignoring stim coming from " + stimSource.getName()); return; }

https://thief.fandom.com/wiki/Periscope_Eye https://thief.fandom.com/wiki/Watcher One option re. water arrows would be to invent a relay-type thingy for the power or alarm system: something like an antenna with lightning effects. If you see one near a camera, you can break the camera's connection to the alarm system for a bit. (Cf. how in T2 some turrets are autonomous, others rely on a nearby Watcher to alert them. It could also be used for other security devices, like in TDS's museum.)

The thing with the water arrow idea is, sitting in place watching areas is what a security camera does, so there isn't that big a difference between temporarily and permanently disabling one unless you need to traverse an area repeatedly. T2 Watchers are sometimes used like Bafford gate guards, to direct the flow of gameplay by making an ingress point impossible to stealth through. If they can be disabled with fairly common tools, that isn't really viable. Camera looking straight down a well lit corridor? Water arrow. Camera pointed directly at a valuable object? Water arrow. I'm not agai

It might be worth starting to think about turrets as well. I'm coming to think there just isn't a single optimum approach to camera vulnerabilities: making them vulnerable to various projectiles adds gameplay options but could mean nobody with a quiver of broadheads or water arrows will ever bother to hunt down the power switch, especially in areas where AI can't easily see a broken one. Fortunately, this is a problem with an established mapping solution:

This is going to be configurable for different camera types that might exist in future, yes? Given that the Wiki mentions necromancers' guardian skulls, and eyeball plants have been mentioned on the tracker... (Edit: also, the water arrow feature especially would be a nontrivial change to existing maps that use the cylindrical camera model.) Re. damage types: yes, we're hitting the limits of the Doom 3 way of handling damage again. You could try distinguishing projectile collisions from melee ones via clipmodel contents, perhaps.