Openra: Units move forward on attack move even when their target is already in range

[Punsho]

This is just a single attack move order, I even added a weapon range circle to make this issue obvious

[matjaeck]

Attack-move means "move to that place and attack stuff meanwhile". I can't see a bug here. (the mentions of "issue description" and "expected behavior" are btw not only reserved for first-issue-posters")

[abcdefg30]

Yes, that is how it is currently implemented. (So yeah, kinda intentional.) We could still change it to scan for targets before moving.

[pchote]

The behaviour in the screenshot looks like the activity is forcing a move each time the attack activity ends. IMO this looks a bit buggy, although I guess it is more consistent with how turreted units behave.

[abcdefg30]

It is likely not the old activity ending but the new starting:
https://github.com/OpenRA/OpenRA/blob/bleed/OpenRA.Mods.Common/Activities/Move/AttackMoveActivity.cs#L39-L40

[matjaeck]

We could still change it to scan for targets before moving.

Agrred this is the more desireable behavior, but for OpenRA it might remove the last bits of micro involved (e.g. pressing stop from time to time).

[OpenOP2Admin]

We could still change it to scan for targets before moving.

Agrred this is the more desireable behavior, but for OpenRA it might remove the last bits of micro involved (e.g. pressing stop from time to time).

It wouldn't remove stop micro, because there is still movement between scans and fires I presume. You would still need to stop micro. It just means you will have less erroneous movement.

[matjaeck]

Fine

[KOYK]

All this time I thought it was a very bad bug of the engine, and that the units were un-responsive to the stop command. I hope this is fixedcorrected.

[matjaeck]

All this time I thought it was a very bad bug of the engine, and that the units were un-responsive to the stop command. I hope this is fixedcorrected.

They will still be unresponsive because they have to finish their moves from the subcell they started in to the corresponding subcell of the adjacent cell. This will actually reduce the incentive to fix this because "scan before move" in my opinion implies "only move when not found any enemies", so there are far less situations when stopping manually will be required, thus bug exposure is reduced.

[KOYK]

@matjaeck I dont think thats the case, look at the range cycle after the second attack by the tanya unit on the OP gif. The unit decided to move first and then scan for the next targets that where available in the same cell that was within range already, instead of scanning for all targets in the same cell first and then move, witch is what we want.

[matjaeck]

@matjaeck I dont think thats the case, look at the range cycle after the second attack by the tanya unit on the OP gif. The unit decided to move first and then scan for the next targets that where available in the same cell that was within range already, instead of scanning for all targets in the same cell first and then move, witch is what we want.

I might be misinterpreting this, but still hold the opinion that this is the wrong way to fix what is in my opinion the main thing OpenRA lacks to get substantially better: much finer grained unit movement control. I'm aware of the tanya-suicide-on-attack-move issue for years but have always thought that a) this behavior makes here a defensive/building sniping unit - which I like - and balances her broken mass-killing-autotargeting, b) would allow with subcell-move-control to micro her effectively by manually moving careful on subcell-level.

In general I believe that some level of artificial difficulty is what makes games interesting and that improvements are counterproductive at some point. I still can't comprehend how this would not remove the ability of one player to get a better result by ordering their units manually (e.g. stop attack-move) than the player who a-moves and let's the computer handle everything. If everyone else thinks this is the right thing to do then it's perfect and my intention to make aware of this concern/fantasy/whatever is achieved.

[KOYK]

Broken? thats tanya, it was and is what is supposed to be, it is not tanya's ability that is broken here, shes supposed to do what you describe, ie kill massive blobs of infantry, and the fact that she dies like that makes the defending player micro easy. actually the defending player dont need to micro at all, she just dies. So in essence this bug removes the need to micro in order to kill her.

And this bug does not only apply to tanya, this bug effects other infantry aswell and the end result is less micro for the defending player.

Doing good micro is one thing, but being forced on playing with a bad game mechanic and have to micro with that aswell, it is an entirely different thing.

[anjew175]

We could still change it to scan for targets before moving.

Agrred this is the more desireable behavior, but for OpenRA it might remove the last bits of micro involved (e.g. pressing stop from time to time).

The implication above is that this behaviour is the caused by the attackmoveactivity. Is tanya the only thing across the multitude of mods and personal projects using ORA that is or could be affected this way?
I don't think the balance of Tanya or lack of micro in the RA mod should warrant intentionally leaving undesirable behaviour in the engine. Issues of tanya being strong or a lack of micro should be addressed at the mod level not the engine level

[matjaeck]

Doing good micro is one thing, but being forced on playing with a bad game mechanic and have to micro with that aswell, it is an entirely different thing.

I don't think the balance of Tanya or lack of micro in the RA mod should warrant intentionally leaving undesirable behaviour in the engine.

Understood, sorry.