bugfix: Jets now defer attack, force attack, attack move and guard commands while reloading

[Stubbjax]

Fixes #197

This change adjusts jet aircraft behaviour so that attack, force attack, attack move and guard commands given while the aircraft is reloading are deferred until reloading is complete.

Demonstration

DEFER.mp4

[GOLDFISH132]

Sounds great. But what if you are airforce and a player is sending a technical to your base and the raptor is 3 bullets in reloading which would be enough to kill the technical, would it still need to be fully reloaded before leaving the airfield when commanding it to direct attack?

Making it so guard mode and attack move would make the planes fully reload, but with a direct attack it should cancel the reload after at least 1 bullet is reloaded so the players can fast micro it when needed.

[Stubbjax]

Sounds great. But what if you are airforce and a player is sending a technical to your base and the raptor is 3 bullets in reloading which would be enough to kill the technical, would it still need to be fully reloaded before leaving the airfield when commanding it to direct attack?

Yes. The Raptor would need to wait an extra 1s to reload the other half of the clip. This is a very low time cost in comparison to a full takeoff and landing which is roughly 14s (and that's if the jet is returned immediately). However, most importantly, reloading can be aborted by simply giving a move order first.

Making it so guard mode and attack move would make the planes fully reload, but with a direct attack it should cancel the reload after at least 1 bullet is reloaded so the players can fast micro it when needed.

I originally thought the same. However, the primary source of frustration is when dealing with groups of jets. It's a lot easier to ensure a single plane has reloaded when commanding it individually. The main issue is that when you have a group selected - especially across several airfields - it becomes difficult to ensure all planes have reloaded. A common example is when a group of MiGs are fully loaded but 1 MiG is not, and the firestorm is lost if the group is prematurely given an attack command.

I imagine most players would prefer to be looking at the battlefield / targets and issuing attack orders without having to scroll back to look at their airfields to see if reloading has completed, which is tedious, time consuming, and unskillful. Given your example is a very niche situation (that the player can still control), I would suggest this change is a fair compromise and the benefits greatly outweigh any negatives.

Here is another example, where if the Raptor had deferred the attack command until it had reloaded, the Quad Cannon would be dead. You can make the argument either way.

NO_RELOAD.mp4

So these are the options:

1. Leave this change intact. All commands that require ammo are consistently deferred until fully reloaded. Players can learn to give a move command first if they want to prematurely attack, though this behaviour might not be very intuitive.

2. Allow attacking to immediately cancel reloading. Players have more immediate control, but this comes at a price. If 4 MiGs are selected and only 3 have reloaded, the firestorm is lost. If 2 Raptors are selected and only 1 has reloaded, the Quad Cannon survives, etc. Players can learn to give a guard command first to ensure reloading occurs before attacking, though this behaviour might not be very intuitive either. Players still have to maintain awareness of their jets' reload status.

3. Allow force-attacking to immediately cancel reloading. This is more intentional and less likely to result in undesirable take offs in most cases (other than e.g. firing Auroras on shrouded targets or leading approaching enemies), but it would likely be less frustrating than option 2 at the cost of reduced visibility.

4. Leave the behaviour unchanged.

[DrGoldFish1]

Okey thank you for the very detailed explaination.
And it does indeed sound like you have it all figured out.
Now I fully understand what this change is and does and it does makes a lot of sense thank you.

Cant wait to see this in action.Good job.

[xezon]

It is a bit unintuitive that plain move commands would cancel the reload while other commands do not. Anything we can do about that?

[Stubbjax]

It is a bit unintuitive that plain move commands would cancel the reload while other commands do not. Anything we can do about that?

Is this not consistent with behaviour when in flight and out of ammo? Attack, guard, attack move, etc. all result in the jet immediately returning to the airfield, whereas a move command will not.

[tintinhamans]

Is this not consistent with behaviour when in flight and out of ammo? Attack, guard, attack move, etc. all result in the jet immediately returning to the airfield, whereas a move command will not.

I guess the difference between that situation is that in order to be able to execute an attack command when it is out of ammo it logically has to reload (returning to the airfield) in order to execute the command.

Maybe this should be an option that the user can decide, maybe in-game with a command button per jet, maybe as a global setting.

[Skyaero42]

Yes. The Raptor would need to wait an extra 1s to reload the other half of the clip. This is a very low time cost in comparison to a full takeoff and landing which is roughly 14s (and that's if the jet is returned immediately). However, most importantly, reloading can be aborted by simply giving a move order first.

This is a balance/mechanics change that imho would need verification within the community first.

[Stubbjax]

I guess the difference between that situation is that in order to be able to execute an attack command when it is out of ammo it logically has to reload (returning to the airfield) in order to execute the command.

The point is that if the existing behaviour is already intuitive then it should be easy enough to intuit the reload behaviour as it follows the same pattern.

In 1.04, when a jet is landing or taxiing to its parking space, it defers all commands until it has fully reloaded. Is this behaviour intuitive? Or is it expected that the jet immediately takes off again without having fully reloaded? Should commands be deferred when landing / taxiing if we have ammo?

Anyway, the proposal might be easier to visualise:

The change is essentially just an extension of the landing / taxiing state to the reloading state - but with movement allowed so as to still leave the player with some agency. In an ideal world, it would probably make the most sense for move commands to be always executed immediately.

Maybe this should be an option that the user can decide, maybe in-game with a command button per jet, maybe as a global setting.

I think that would overcomplicate things and be counterintuitive to most players.

This is a balance/mechanics change that imho would need verification within the community first.

This is really more of a usability change. The same behaviour can be achieved in 1.04 but with a higher degree of difficulty and frustration. I'd say fixing undesirable behaviour in order to streamline / improve player experiences and by extension lowering the influence of such behaviour on match outcomes is always beneficial.

[OmarAglan]

I don't exactly hate this change, but why not make it optional? Maybe add a way for the user to choose between methods, like an ini option in a future PR, so this one doesn't go out of scope. That's just my opinion on it.

[Stubbjax]

I don't exactly hate this change, but why not make it optional? Maybe add a way for the user to choose between methods, like an ini option in a future PR, so this one doesn't go out of scope. That's just my opinion on it.

There are several reasons why adding an option should not be taken lightly:

1. It increases code complexity, potential for bugs and makes logic harder to maintain, test and understand. We've already seen this with the alternate mouse setup option.
2. Adding options that modify behaviour on a per-player basis complicates the game state by introducing more variables and making it harder for players to predict outcomes and properly strategise.
3. Where do you draw the line? Do we want an option for jet behaviour when landing / taxiing? For behaviour when airborne? For behaviour when reloading? For which commands are deferred during each state? For whether auto-retaliate overrides this behaviour? For whether to also wait for full health before takeoff? For whether to return after firing only part of a clip? For whether to return after idling for 10 seconds? It gets out of hand very quickly and the game loses its structure.
4. And in the case of this change, it is a highly beneficial quality of life improvement that is unlikely to opted out of, which would make such an option rather redundant.

[OmarAglan]

I don't exactly hate this change, but why not make it optional? Maybe add a way for the user to choose between methods, like an ini option in a future PR, so this one doesn't go out of scope. That's just my opinion on it.

There are several reasons why adding an option should not be taken lightly:

1. It increases code complexity, potential for bugs and makes logic harder to maintain, test and understand. We've already seen this with the alternate mouse setup option.
2. Adding options that modify behaviour on a per-player basis complicates the game state by introducing more variables and making it harder for players to predict outcomes and properly strategise.
3. Where do you draw the line? Do we want an option for jet behaviour when landing / taxiing? For behaviour when airborne? For behaviour when reloading? For which commands are deferred during each state? For whether auto-retaliate overrides this behaviour? For whether to also wait for full health before takeoff? For whether to return after firing only part of a clip? For whether to return after idling for 10 seconds? It gets out of hand very quickly and the game loses its structure.
4. And in the case of this change, it is a highly beneficial quality of life improvement that is unlikely to opted out of, which would make such an option rather redundant.

I do understand, then it's ok, keep up the good work and thank you for your effort.

[xezon]

I agree that for the majority of players this change is very welcome. Players generally want their planes in the air with full ammo. Preferring a plane with no ammo or half ammo to take off does happen, for example when trying to safe planes from approaching Bomber, and if that can be still done with the move command, then no functionality is lost.