See here for the pr Nex mentioned.
There's a couple of aspects in play in the above (which to be clear is not integrated):
- In the blueprint, setting
MaxRadius
(the distance to the target at which the beetle will explode) to a low number means the beetle will get closer to the target before firing, and presumably have a better chance of damaging other nearby enemies.
- Likewise in the bp, setting the distance at which the beetle tracks the target to be equal to
DamageRadius
(via math, MaxRadius * TrackingRadius = DamageRadius
) allows beetles to move closer to an automatically acquired target before exploding, instead of exploding immediately when the first enemy enters the tracking radius.
- In the script, there's a bit of logic that prevents beetles in motion from exploding when a unit that hasn't been deliberately targeted comes into range (this was the original feature request).
- Finally, in testing I also found that decreasing
MaxRadius
made beetles perform poorly when chasing moving units, doing the endless stop/start that I'm sure you're familiar with. The script adds a "tail chase" check that will artificially boosts MaxRadius
to be equal to DamageRadius
after one stop and start, which allows the beetle (speed 5) to catch anything slower than speed ~4.
@Nex, based on the above, the beetle should stutter step once, then explode on the next stopping event. Do you have a video of it continuing to chase with the tailchase script?
(Doing another thought pass on it now, the whole tailchase check may not be necessary, because against a stationary target the beetle won't start slowing down until it's close anyway.)
(Edit: it is, for some reason OnMotionHorzEventChange
is called almost immediately after a target comes into range, so the stutter step is required)