One of the most obvious questions to ask of
trigger_hurt is “how do I make it attack faster?”. The current rate of once per second feels wrong for many sources of danger, and can cause issues in situations like a kill trigger in a void, where a backlog can build up if many monsters/players fall in at once. While some mods offer this as an enhancement, today we’ll see how to do it as an entity hack.
trigger_hurt attack cycle involves two functions:
hurt_touch inflicts the damage, turns off collision on the trigger, and sets a
think function 1 second into the future.
hurt_on is that
think function, which turns the collision back on for the trigger. The first function is an all-or-nothing deal, and the
nextthink delay is hard-coded, so there isn’t much we can do about that. The trick is to run
hurt_on ahead of schedule by a different means, so that the trigger resets faster than normal.
The simplest way forward is to create your
trigger_hurt and set a suitable
dmg value, then add the keys
"use" "hurt_on" and
"targetname" "fast_dmg". Create a
trigger_multiple with the same dimensions as the
trigger_hurt, give it
"target" "fast_dmg", and set both the
wait and the
0.1 (or whatever rate you want the
trigger_hurt to reset at). As simple as that.
If you’re after maximum carnage – like the void trigger in the preamble, you may want to minimise delay between activations as far as is possible, and make it work on multiple monsters as well as it does on players. For this, you really want an entirely different kind of entity to replace the
"classname" "InitTrigger" "touch" "door_blocked" "dmg" "666" "wait" "-1"
You don’t need a
trigger_multiple to go with this either, it does 666 damage every frame to everything it touches by itself. This makes it unfair to use as a hazard in a trap, because the rate of damage could be 7 times higher for one player than another, depending on their computer’s speed. But for instant kills there’s nothing better. The function
secret_blocked is an interesting alternative for the
touch function – it will produce a fixed delay similar to a standard
trigger_hurt, but the delay is half a second – twice as fast. If that’s the rate you wanted anyway then this is a simpler alternative to the first hack.
Going back to the first hack of the article, you might have realised that this trick doesn’t work to slow down a
trigger_hurt if you set the
delay on the
trigger_multiple more than 1 second into the future. The original
think function hasn’t been disabled by our hack, and it is the faster of the two which determines when the
trigger_hurt will next be active. Now, I doubt there is nearly as much demand for a
trigger_hurt which activates slower than the default, but it’s a good theoretical exercise, and one that will hopefully be explored in a follow-up post. Post a comment if you figure out a way faster than I do…