Rapid-fire trigger_hurt

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.

A 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 delay to 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 trigger_hurt

"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…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s