feat: Add option to bypass initial upgraded special power reload time

[Stubbjax]

This change adds a HasInitialReloadTime field to the SpecialAbility module. When assigned a value of NO, the special power does not have to await its ReloadTime when it is first enabled.

Usage:

Behavior = SpecialAbility ModuleTag_X
  HasInitialReloadTime = NO
End

Before

The Helix's Napalm Bomb must always await its 10-second reload time after the upgrade completes

BEFORE.mp4

After

With HasInitialReloadTime = NO, the Helix's Napalm Bomb can be used as soon as the upgrade completes

AFTER.mp4

[xezon]

If StartsPaused = YES was removed from Behavior = SpecialAbility, would a reload also occur on unit creation? If yes, then maybe the new flag should be part of Behavior = SpecialAbility (or SpecialPower, or SpecialAbilityUpdate) ?

[Caball009]

This would change the behavior between retail / older versions and newer versions given an INI file that has this new field, correct? Is this desirable without any macro around it?

[xezon]

Can add RETAIL_COMPATIBLE_CRC yes.

[Stubbjax]

If StartsPaused = YES was removed from Behavior = SpecialAbility, would a reload also occur on unit creation? If yes, then maybe the new flag should be part of Behavior = SpecialAbility (or SpecialPower, or SpecialAbilityUpdate) ?

If StartsPaused = NO then the ability is available without requiring the upgrade.

This would change the behavior between retail / older versions and newer versions given an INI file that has this new field, correct? Is this desirable without any macro around it?

In what situation? If a retail build tries to use this field then the client will crash.

[Caball009]

In what situation? If a retail build tries to use this field then the client will crash.

Using two local instances, one without this change and one with it, there could be a mismatch, correct?

[Stubbjax]

In what situation? If a retail build tries to use this field then the client will crash.

Using two local instances, one without this change and one with it, there could be a mismatch, correct?

Is that not the case for any other deviation in INI data between two clients?

[Caball009]

The INI file(s) would be the same for both instances, so it's not like any other deviation in the INI data.

[Stubbjax]

The INI file(s) would be the same for both instances, so it's not like any other deviation in the INI data.

So the INI is the same but the build is different?

[Caball009]

The INI file(s) would be the same for both instances, so it's not like any other deviation in the INI data.

So the INI is the same but the build is different?

Yes.

There would be a discrepancy how the INI file is interpreted between the different builds. I don't think it's a good idea to do that without a retail compatibility macro and perhaps a new macro.

[Caball009]

I think we've dealt with a similar situation before: link.

[xezon]

If StartsPaused = NO then the ability is available without requiring the upgrade.

Yes, and will that reload after unit creation or not? Player builds Helix, clicks it: does it need to reload the Bomb first or can it be used straight away?

[Stubbjax]

If StartsPaused = NO then the ability is available without requiring the upgrade.

Yes, and will that reload after unit creation or not? Player builds Helix, clicks it: does it need to reload the Bomb first or can it be used straight away?

That's a good point. I have moved the field to the SpecialAbility module so that we can apply this behaviour via non-upgrade paths. This means we can use the field to remove the initial reload time from non-upgrade abilities like Black Lotus's Cash Hack.