This behaviour is present in the current release. As aircraft already forget their current target after auto-resupply player expects them to forget all other orders as well. But they don't, instead go off executing order uninterrupted by forced resupply
As discussed previously (can't find where) it is not a good idea for units to wander around without player implicitly telling them so. It is painful to lose expensive air units to an anti-air weapon system when you aren't looking and didn't know that your units would decide to move into it. Technically players ordered it but it often isn't their intention
This is a feature per https://github.com/OpenRA/OpenRA/issues/16888#issuecomment-518798096. The previous fix in #16660, that changed the behavior to be more similar to what you're suggesting, was effectively reverted in #16721. Changing it again would mean breaking #14805.
Cancelling the current attack target but moving on to attack the next queued target seems like the least consistent and possibly least wanted of all the possible behaviours, IMO.
I agree. Imho the (most) intuitve options are:
The second option sounds like the more straight forward one to me, since it doesn't need to differentiate between explicit and implicit reload orders.
Cancelling the current attack target but moving on to attack the next queued target seems like the least consistent and possibly least wanted of all the possible behaviours, IMO.
ahem... https://github.com/OpenRA/OpenRA/pull/16721#issuecomment-507072886
I don鈥檛 see any contradiction between my two statements :P
Like @abcdefg30 says, the distinction comes from explicit vs implicit behaviour.
Don't drop the target but continue with the activity queue as usual (i.e. continue attacking the last target)
To clarify this option, it would mean that aircraft would no longer auto-resuply. What is a 馃憤 in my book.
It actually implies that they will RTB to reload, and then fly back to the thing it was attacking.
In that case we have 3 options
I didn't consider it as 3rd option to solving the "what to do after reloading" problem because, well, it does away with reloading. But in general I'd agree that removing automatic RTB would be an improvement.
The biggest issue with removing auto RTB is for players new to openra, first impressions, and possibly for a lot of casual players who do not want to use hotkeys. So we could add a per user option on if aircraft should automatically RTB on low ammo
Aircraft automatically returning to base to reload has always been part of C&C, the unit management and UI doesn't offer the depth of control to do anything different. Forcing players to manually try and select specific aircraft (those without ammo) out of a larger group to send back to base, without pausing the game, sounds excruciatingly painful.
It wouldn't be painful if aircraft skipped all queued attack orders whenever they ran out of ammo, it would be quite the opposite. If this behaviour was implemented then you could just queue a retreat path and a rearm order so when aircraft ran out of ammo in a large group they would separate automatically
We could also make empty ammo aircraft be considered as a different unit type. That way you wouldn't accidentally select empty aircaft with select by type command and would have a clear way to select empty aircraft. I suggested something simmilar for repairing here #17537
IMO the sensible/expected behaviour for the AbortOnResupply flag is to cancel the whole queue, so making FlyAttack do this before queuing ReturnToBase should be our first step.
We may then want to consider a second step that disables AbortOnResupply on RA's aircraft if there is a strong feeling that we do want to keep queued orders after reload there... but i'm not sure how I feel about this topic yet.
In case we go for the per user option then the it might be better to have aircraft not forget queued orders after auto-rtb as I assume people who complain about it not forgetting are the same ones who will just turn auto-rtb off
Forcing players to manually try and select specific aircraft (those without ammo) out of a larger group to send back to base, without pausing the game, sounds excruciatingly painful.
It is indeed the exact opposite: Because of aircraft automatically returning you either have to select aircraft without ammo out of your blob, or you will lose them when attacking since most of the time enemy AA is in direct line between the blob and your own base.
It is indeed the exact opposite: Because of aircraft automatically returning you either have to select aircraft without ammo out of your blob, or you will lose them when attacking since most of the time enemy AA is in direct line between the blob and your own base.
There has been an issue specifically about the question how the auto-rtb behaviour could be improved. I remember some keywords from the discussion but can not find it. It seems to be gone.
Appearently github deletes issues that had been owned by deleted accounts. This is not necessarily what a person intended when they have to delete their account. Even worse is that this also deletes what others have contributed to a discussion.
It is indeed the exact opposite
If you meant that aircraft without ammunition should ignore the player order and hover/circle at their current location, then this is just another point in the long "units that can't attack shouldn't move" discussion (#5507, #6624, etc). See those issues for discussion on why its not that simple.
It wouldn't be a big problem if empty aircraft ignored attack and attack move orders. They serve no purpose for the air fleet, unlike non-combat ground units
In any case, that is a distinct feature request from the regression presented in this issue. Lets not confuse the two here.
Most helpful comment
Aircraft automatically returning to base to reload has always been part of C&C, the unit management and UI doesn't offer the depth of control to do anything different. Forcing players to manually try and select specific aircraft (those without ammo) out of a larger group to send back to base, without pausing the game, sounds excruciatingly painful.