Openra: On attack move auto-target scan radius beyond weapon range seems to be fully ignored

[Punsho]

It is a regression since the last release and it seems like an old bug. In default mods there are no units to reproduce it (maybe in d2k), In #17113 I added long auto-target range on a short ranged unit, it can be used to reproduce this bug. At the point it was merged the bug was already present.

It is a serious issue for Shattered Paradise as it has a few core melee units.

[GraionDilach]

In default mods there are no units to reproduce it (maybe in d2k),

Attack Dog? Ants? Visceroid?

[pchote]

This was an intentional change (see #16942) to fix #16940. We could introduce a flag on the AttackMove trait to allow mods like SP to restore the previous behaviour on just its melee units.

[pchote]

A more general fix would be to restore allowMove but then allow AttackMove to keep scanning for new targets and override the current attack activity if it finds something better (where the precise rule for "better" needs to be carefully defined - the opportunity targeting logic would be a good starting point but may not be sufficient).

[Punsho]

We could introduce a flag on the AttackMove trait to allow mods like SP to restore the previous behaviour on just its melee units

There might not be a need for it. IMO it would best to restore this behaviour on attack everything stance. Since unit's supposed to chase on it.

[pchote]

Do you have any thoughts on a direction here @tovl?

[tovl]

Alright, some thoughts:

• I think keeping attack-moving units from deviating from their paths works surprisingly well for the vast majority of units in the current release. I suspect most players do not appreciate their units wandering off more than necessary, so my advise is: don't fix things that aren't broken; the problem is with melee units (and others that need to have a longer auto-target range than their weapon range) so keep the fix tailored to the instances that need it.
• Guard is a different matter. guarding units should be able to move around to respond to threats within the guard radius. We could pass a boolean argument to AttackMoveActivity to toggle allowMove when called by GuardTarget.
• Riffing on your suggestion of overriding attack activities: For cases where we allow chasing, dropping the current attack activity when the current target is out of weapon range and other valid targets are in range seems sensible. That would prevent attack-moving units from defenselessly blundering into an obvious ambush while chasing a single enemy unit that has moved to the back-lines.
• This by itself only solves half the problem though; this would still mean units can be goaded way out of position. To solve this we need to limit the distance that units may move from the original path to chase an enemy. This is also important for guard: currently, guarding units will keep engaging the first enemy they encounter until either of them is dead; meanwhile, they 'forget' to stay close to the unit they where supposed to be guarding.
• I had already implemented a working proof-of-concept for the guard case some time ago. The basic idea: the auto-target range is overridden to be weapon range + guard range; The origin for the auto-target search is overridden to be the guarded target instead of the guarding unit itself; AttackMoveActivity cancels the attack activity whenever the unit steps outside of the guard range and requeues the Follow activity. My implementation needs more polish, but the basic idea works well—especially with area-guard.
• Attack-move for units with an auto-target range greater than their weapon range could be done in a similar fashion. In this case the attack-moving unit would drop their target when they move more than scanRadius minus weapon range from their initial path. It is more complex because the origin is not a single point, but that is nothing a bit of geometry can't solve. One possible gotcha: You have to measure from the _original_ move path, not the previous move path. Otherwise, units may still drift off if they encounter multiple enemies in a row.
• As an aside: I think it is interesting to note in this context that dogs aren't technically melee units because of the way LeapAttack works and so they are currently already capable of attack-moving (but all the abovementioned issues regarding out-of-position units still apply),

[Punsho]

That would prevent attack-moving units from defenselessly blundering into an obvious ambush while chasing a single enemy unit that has moved to the back-lines.

This by itself only solves half the problem though; this would still mean units can be goaded way out of position.

IMO if an opponent micros his units against yours you should need to micro as well to defend. It shouldn't be too automated, it is really a balancing thing

For cases where we allow chasing, dropping the current attack activity when the current target is out of weapon range and other valid targets are in range seems sensible.

I'm against allowing units to switch targets on their own. It just isn't behaviour one would expect, if players want to their units to retarget they can and do issue a stop order

[pchote]

I'm against allowing units to switch targets on their own. It just isn't behaviour one would expect, if players want to their units to retarget they can and do issue a stop order

This is obvious for standard attack orders, but I don't understand how this could be expected for attack move...?

[Punsho]

If you see your unit attacking an enemy unit you expect it to continue attacking it. How one would differentiate between an explicit attack order and an attack order generated by attack move? Another colour? Seems cumbersome

[pchote]

From above:

the opportunity targeting logic would be a good starting point but may not be sufficient

All the feedback on opportunity fire has been positive, and that works the same way as the proposal here.

[anjew175]

How one would differentiate between an explicit attack order and an attack order generated by attack move? Another colour? Seems cumbersome

The user should be able to tell since they gave the order

[Punsho]

The user should be able to tell since they gave the order

It is best to design such features with the idea that the player has litelly no memory and only acts on what he sees. It will result in a much more comfortable game. With features that are much more easilly discoverable and less likelly to be called bugs

[anjew175]

It is best to design such features with the idea that the player has litelly no memory and only acts on what he sees. It will result in a much more comfortable game

Not if they are sitting there wondering what this colour line could mean. I think it’s better to keep the lines simple so our memory deficient players can have an easier time. Red denotes an attack regardless of its functionality, even guard displayed a red line when attacking (although the behaviour was bugged from memory). Personally I think it’s quite easy to tell the difference between attack and attack move as it is since attack move can only target the ground, normal attacks are generally on specific units unless ordered to attack ground. Attack and attack move have always used the red line despite being functionally quite different, personally I don’t see the need to implement a different coloured line

And I think it makes complete sense to drop units out of range on attack move since the primary objective should be the moving, attacking units along the way but not following them across the map.

[pchote]

This appears to be turning into a can of worms, so dropping from the milestone.

[Punsho]

And I think it makes complete sense to drop units out of range on attack move since the primary objective should be the moving, attacking units along the way but not following them across the map.

It currently works that way, the talk is mostly about melee units, units with higher scan radius than weapon range. In their case they should not retarget if their targets come out of weapon range. And their primary objective is to chace and kill, unless specifically a standard move order is given or stance is changed

Not if they are sitting there wondering what this colour line could mean.

It's supposed to make you wonder, when you know that it is different you will start looking for differences.

I think it’s better to keep the lines simple so our memory deficient players can have an easier time.

Who are these memory deficient players? In my post above I meant making it simple for the mind, not making one need to memorise every action for it to make sence in the future

Red denotes an attack regardless of its functionality, even guard displayed a red line when attacking (although the behaviour was bugged from memory). Personally I think it’s quite easy to tell the difference between attack and attack move as it is since attack move can only target the ground, normal attacks are generally on specific units unless ordered to attack ground. Attack and attack move have always used the red line despite being functionally quite different, personally I don’t see the need to implement a different

Attack move and guard orders are displayed in orange. If a unit is attack moving and he encounters an enemy a red line is drawn from him to the target. NOT to the ground