VanishedOne

According to this, the reason TDM mines don't have fire stims is that they're intended to be non-incendiary kinetic explosives: So where does this leave powder kegs: incendiary or non-incendiary? I've been trying to research gunpowder blasts, but while there are loads of sites explaining deflagration versus detonation, trying to find out about e.g. the possibility of secondary ignition caused by sparks from a powder blast has probably just got me on government watch lists. I did find a couple of assertions about fires arising from explosions: So I'm not certain black powder is non-incendiary (if you want an explanation for non-incendiary mines, maybe they use some form of high explosive). Anyway, powder kegs: with the current set-up they have a 'burn' phase prior to the actual explosion, perhaps implying the wooden keg has caught fire first, and hence that they chuck embers (def_debris) around as well. Do we want them setting flammable things on fire?

I remember being surprised when I noticed in DR's AI tab that lanternbots weren't KO-immune, but thinking it made some sense given the spindly look that they'd have some delicate external machinery that could be disabled with a precise whack. I'm not familiar with the workings of the soundprop defs, but at a glance the relevant ones seem to be sprgs_blackjack_hit_hard ("alert_factor" "0.55", "vol" "40") and sprgs_sword_hit_hard ("vol" "48"). So my guess is that as things stand the sword is noisier.

I've seen it said of the current core asset base that it tends towards the clean and unscuffed. Admittedly that was five years ago, prior to Springheel's outdoor modules with all the grime decals included.

Welcome to the 'people who've tried writing Pagan lines' club. :-P If this AI is meant to be 'poorly educated and rural', as quoted, then I like the animal/venery motifs, but I don't think he comes across as poorly educated. Bits like 'I do not fear your cowardly barbs' sound to me as though they're coming from someone who's trying to play the role of a heroic warrior out of literature, rather than someone who's authentically down-to-earth. 'Educated class pagan sympathiser' is a viable role of course, even one I find interesting, but a bit of a niche I'd have thought. Maybe not those exactly ('dark lady' makes me think of Shakespeare's sonnets), but I much prefer that approach to the number of times 'spirits' appear in the OP. The trouble with that kind of generic animism is that the stereotypes it fits are so broad, it can bring e.g. a North American Fallout 2 character to mind.

That reminds me of this problem: being able to frob e.g. light switches in the next room through the wall unless prevented by mapper precautions. Presumably the default frob trace behaviour is too firmly established to change, but I wonder whether entities could be given a spawnarg that disables frobbing them through solids.

Quake 4 assets reference 'meat hooks' that appear to involve binding a ragdoll to an animated entity, but I'm not certain of the workings, especially a line in the ragdoll's script that uses bindConstraint.

Necro'ing because I think I've got somewhere with this: The way the noose looks isn't ideal: I had to scale it in DR in the first place, since the original obviously wasn't designed to go with the AI necks, and before I set the noose nonsolid the ragdoll would twitch around for a bit and then settle without a nicely drooping look. So you might want to continue using Sotha's anim (especially if you want a swinging-in-wind effect like in PD2, which this method won't allow). If you'd like a hanged ragdoll, though, this seems viable. Basically you take the modified AF below, save it as af/guard_base_newskel_hanged.af, and give the ragdoll an "articulatedFigure" "guard_base_newskel_hanged" spawnarg. This causes the head to be bound to the world, so it stays in position, but the rest of the body still has ragdoll physics (I also made it solid to the player).

It looks as though Move To Position is for use with AI. The response effects are implemented via script functions, so you can find out what they do internally by looking at script/tdm_response_effects.script inside tdm_base01.pk4. effect_move_to_position_action() appears to invoke a script event called moveToPosition(), which according to http://wiki.thedarkmod.com/index.php?title=TDM_Script_Reference/2.06 is specific to the idAI spawnclass. (A touch confusingly, idMover has one called moveToPos().) Edit: on removing particles, I'm guessing these ones were spawned via the Spawn Particle effect? From a glance at the scripting there's no obvious way to get the name of the emitter it spawns, so depending on what you want to do, the best thing might be to place your own func_emitter and trigger it on/off as desired.

It just occurred to me: did your test map use delta1_fog by any chance? It has alpha explicitly set to 0.5 (values of 1 or less are treated as an instruction to use a 'default' fog distance of 500 units), which might explain why the shaderparm wasn't working.

I misremembered this somewhat; here's what it actually says: // If you replace the default internal fog projection image with your own // texture, make sure that the alpha starts at 0 in the center, reaches // 255 at the borders, and is generally radially symetrical. // The color channel can be left solid white, or it can have additional // color changes with position. I messed about with both RGB and alpha channels to no apparent effect. I think I tried the same on the falloff image too.

noFogBoundary stops foglights painting on the boundaries of their volumes, but they'll still paint on geometry inside the volume, so I'm pessimistic about its being a complete solution in this case. I'm not even sure whether id Tech 4 foglights work the way id intended to make them work: there's a Doom 3 file with a lengthy comment indicating they can be manipulated via the light texture's alpha channel, but my experiments got nowhere.

In the simplest case: frobbing already is a stim, so give the switch a response to STIM_FROB (that is, the Frob stim type). The catch here is that S/R alone doesn't give you a way to do one thing when a switch is frobbed 'on' and another when it's frobbed 'off'. The dining room in ITB has switches that fade the lights but I just used two switches.

http://www.sewerhistory.org/ - speaks for itself, really.

Just to check: will image functions like addNormals() still work on the compressed normal maps? (They don't work on DDS images.)

I see you found metaball.vfp. Apparently neither of these ARB shaders has ever been used in a released FM, then: (Though some FMs do pack versions of shaders in the HeatHaze family that presumably weren't yet in core when they were released.)