Cybran t2 mobile bomb AI
-
@FirstOneToDie
I can target a moving unit with a beetle and when it reaches the unit it explodes.
What I can see though, is that when the unit moves away from the beetle, the beetle doesn't really approach the target, but kinda lags behind out of range.
is this what you are experiencing? -
@nex yes, this is the case!
-
I don't believe this is (easily) fixable since it seems to be related to pathfinding, which is done in the engine.
@Jip might correct me on this. (I tested regular FAF, beta and clyfordv beetle PR on this behavior)
When giving your beetle a simple attack order on a moving unit it will constantly move to a point the units was just moments ago and then stop there for a few ticks. Even against slower units (like an ilshie here) it takes forever to catch up.
@FirstOneToDie
The problem can be alleviated by using an attack move order ahead of the target unit instead, this will cause the beetle to move to the target point at max speed and explode when something gets in range. -
It used to be that beetles had a higher engagement range so they could actually explode after catching up, but someone set that range to their explosion radius making them next to useless when not microed. Then I guess it was reverted to the tiny range under the assumption that they'll be shot at and killed anyway, again making them useless when not microed.
-
@mazornoob do you know where this is set?
I checked the blueprint for any changes that could affect this behaviour and couldn't find anything. -
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
MaxRadiusmade 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 boostsMaxRadiusto be equal toDamageRadiusafter 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
OnMotionHorzEventChangeis called almost immediately after a target comes into range, so the stutter step is required) - In the blueprint, setting
-
To elaborate further on what Nex said about pathfinding, the specific issue is that the meta "location to move into range" check is performed every couple of seconds or so. That's fine for units with longer ranges, but means short ranged units get tunnel vision and often need to re-check when they get to their "in range" position (potentially nodded to by the existence of the ominously named
Unit:MeleeWarpAdjacentToTarget). -
@clyf said in Cybran t2 mobile bomb AI:
Do you have a video of it continuing to chase with the tailchase script?
(How do you post videos on the forum? does this work for you?)
https://cdn.discordapp.com/attachments/1169425511932498051/1169425853256581191/chase.webm?ex=65555bb2&is=6542e6b2&hm=b27bbd012283c1277c42dfbd053fd1109e0771d30588bf4321ecb8c3ed0f2995&I checked out your PR and in the script it says something about improved tailchasing, still the beetle(speed 5) chasing the flare(speed 3.8) never catches up and stutter steps the whole way.
It works however if you attack move the beetle close enough to the enemy so it aquires the target itself.
-
Yeah that's a good spot.
What we're bumping up against is the stutter step effectively reduces the average speed of the beetle to somewhere around 4* (I tested it against the flare and speed 4 sera hovertank, it'll catch em eventually, but too long for any practical purposes).
We can artificially reduce the effect of that by bumping the acceleration multiplier up to ~20 (only when we're chasing, and set it back to normal as soon as we're not) which doesn't look bad and addresses the problem somewhat. But other than that I think we're out of luck.
*Actually, the average speed gets lower as target speed and distance decreases, because the beetle starts stuttering more and more.
-
How about this
-
@clyf
I'd always wondered what the Melee functions were created for. I thought that early on they had actual melee units that later on got cut. Didn't consider that it could have been for things like the firebeetle.
-
I haven't gotten the melee functions to work yet, so their nature is occluded from me. The concept seems a little hacky though, have to see how they look if I do ever get them working.
I added a
SetSpeedThroughGoaladjustment to the Beetle PR, and it improved tailchase performance by another major step (also had no idea aboutnavigatorsand what they did, some interesting possibilities there).Current issues:
- Performance against experimentals with large hitboxes is bad, because weapon targeting is generally evaluated to the center of the target. This is an issue with the stock beetle.
- No improvement for non-attack attacks (guard, patrol).
Adding another dummy weapon with a range significantly larger (~`10) than the current AOE (6.5) could help. Right now the main kamikaze weapon doesn't have a target until immediately prior to detonating, so it's no help with fudging our detonate radius. A dummy longer range detector could address that, both with large hitboxes and for letting the unit know if it has a target or is just on patrol.
