tweak: Defer offensive commands for parked jets without ammo

[Stubbjax]

This is a supplemental / preliminary change to #1757 and modifies jet behaviour so that offensive commands such as attack and guard are deferred when parked with no ammo. This aligns the behaviour a bit more with the in-flight logic, in which command behaviour is dependent on whether the jet has ammo.

The change essentially expands the command deferral window until the jet has reloaded at least one shot. This can be considered an objective improvement to the game as it ensures offensive commands do not end up launching jets without any ammo.

It should be noted that this rule is not consistently applied to all states, and jets that are issued a command during landing and taxiing states will always defer the respective command until fully reloaded, regardless of existing ammo status.

Demonstration 1

A Raptor with no ammo defers its attack until it is fully reloaded

DEFER_EMPTY_1.mp4

Demonstration 2

Attack and guard commands are deferred with no ammo, but immediately performed when partially reloaded

DEFER_EMPTY_2.mp4

[xezon]

In Demonstration 1, why is one of the Raptors not attacking when he has his first rocket reloaded?

[Stubbjax]

In Demonstration 1, why is one of the Raptors not attacking when he has his first rocket reloaded?

What do you mean? The demonstration aligns with the described behaviour. An attack command given while the jet is out of ammo will result in the command's deferral until fully reloaded.

[xezon]

Ok. It was confusing me. In Demonstration 1 I expected the plane to start flying with 1 bullet loaded, because in Demonstration 2 planes do start flying with 1 bullet loaded too. The inconsistency in behavior depending on landing state makes it unintuitive. It would be good if we can design it in a way that is intuitive to understand and consistent to execute.

Before diving into implementation details, how about we create a Design Issue Report, layout the status quo design and then gather a list of potential design improvements and look at their pros and cons to understand what would be the most desirable design?

[Stubbjax]

Ok. It was confusing me. In Demonstration 1 I expected the plane to start flying with 1 bullet loaded, because in Demonstration 2 planes do start flying with 1 bullet loaded too. The inconsistency in behavior depending on landing state makes it unintuitive. It would be good if we can design it in a way that is intuitive to understand and consistent to execute.

Is retail behaviour confusing?

RETAIL.mp4

It is worth studying the diagram in the PR description. Landing or taxiing jets with partial or no ammo will also defer attacks until fully reloaded, rather than launching with partial ammo. This change is more consistent with existing behaviour. As a simple rule: All offensive commands that are deferred will be deferred until the jet is fully reloaded. If we change this rule for the short duration that the jet is parked and without ammo, then we will be introducing yet another behavioural branch and inconsistency.

When given an attack command, a jet will either commence takeoff or fully reload. Here are some flow charts to highlight what this change does:

• Retail flow chart
• This change flow chart

Before diving into implementation details, how about we create a Design Issue Report, layout the status quo design and then gather a list of potential design improvements and look at their pros and cons to understand what would be the most desirable design?

I've already considered such and laid out several diagrams and flow charts in #1757. I've created this intermediate PR as it is an objective improvement that does not need any design input. Any further deviation in design can use this change as a baseline.

In addition, I've had a look at the work that it would take to have jets launch after reloading one shot, and have determined that it will add significant complexity to the state machine. We'd have to keep track of whether an offensive command was issued during that small window of being parked with no ammo to then go into a 'launch with only one ammo' state, otherwise it'll always launch with full ammo. See ALLOW_INTERRUPT_AND_RESUME_OF_CUR_STATE_FOR_RELOAD.

[xezon]

Thank you for the flow chart. I understand now and you are right this is an objective improvement.

[xezon]

How did you determine that these are all the command that are needed here? There also is a AICMD_ATTACKFOLLOW_WAYPOINT_PATH and it is not obvious whether that needs covering as well.

[Stubbjax]

I wanted to match the same values as commandRequiresAmmo and isGuardCommand from #1757.

I had originally added the waypoint path values but I ultimately deemed them unnecessary as they're scripted events and such events typically involve carefully managed specific behaviours. I'm happy to add them back if you think it's worthwhile adding them anyway.

[xezon]

How did you conclude they are scripted events? Wouldn't all AI command be subject to use in scripted events?