Add a flat threshold for the brain energy manager

[lL1l1]

Issue

Caused by #3699. When playing with mods that add extreme amounts of energy storage (T3 energy storage + multiple storage multiplier mods), an energy stall can disable your shields for minutes because they require 0.1% of the max storage to be full to activate, and energy storage can easily reach hundreds of millions while energy production remains rather tame in comparison.

Description of the proposed changes

Changes the trigger for when units are re-enabled to be based off available max storage. The ratio is still 0.1, but above 100k storage the ratio no longer increases.
If the amount of energy storage is passes over/under the threshold during an energy stall (when the energy ratio/flat amount is in effect), the ratio/flat trigger is switched to the other type.

Testing done on the proposed changes

Toggle the omnis in this set of units to control your energy amount.
First, deplete all energy to activate the new triggers.
Now you can add 20 storages and see that only 10k energy is needed to reactivate the shield.
You can also delete the storages while waiting for 10k energy and it will almost instantly reactivate due to the ratio making 500 energy the new trigger.

   CreateUnitAtMouse('xsb3104', 0,    0.85,   -3.73,  0.00000)
   CreateUnitAtMouse('xsb3104', 0,   -2.15,   -4.73,  0.00000)
   CreateUnitAtMouse('ual0301_ras', 0,   -0.28,    3.09,  0.00000)
   CreateUnitAtMouse('ual0301_ras', 0,   -3.28,    1.09,  0.00000)
   CreateUnitAtMouse('xsb4301', 0,    4.85,    4.27,  0.00000)

Additional context

• There is a 1 tick delay in reactivation due to energy trigger switching because it switches the trigger and then lets the trigger finish the rest. This simplifies the code but isn't a perfect solution.
• Optimize shield interactions v3 #3699 mentioned letting shields have enough energy for 1 tick. I considered tracking how much energy is required by the army and basing the threshold entirely off of that (fill storage until you can sustain all shields/radars for 1 second or 1 tick), but it seems a bit excessive right now.
• I noticed structures still consume energy while disabled due to energy stall, which is a bit counterintuitive and feels bad for gameplay, since you can toggle off the structure while it is already off to stop it from draining energy.

Checklist

• Changes are annotated, including comments where useful
• Changes are documented in the changelog for the next game version

[Garanas]

Love the additional annotations.

I think at this point it may be more interesting to have a thread check the economy status every tick instead of using the army stats triggers. The polling approach does not consume any noticeable resources, but it does significantly improve the readability of the code.

If we do that, we can also remove the need of some energy in your storage. We could just check both the storage and your economy. Combine that with the missile production fix of @4z0t in assembly and we can also expect less rapid fluctuations.

[lL1l1]

By economy do you mean the energy trend? What if you are in a mass + energy stall? What if we wanted to get rid of the energy-disabled shield energy drain?

About getting rid of the energy drain, it could be applied just like mass fabricators where they turn on gradually to avoid energy fluctuations. With more complexity, the brain could immediately turn on as many as the current energy trend can support.

[Garanas]

Of course there are exceptions, but nothing that a little debouncing can't fix.

My point was primarily about replacing the event-based system with a polling-based system. It's only polling a few numbers. Any other complexity (such as gradually enabling consumers) can be debounced and then applied.

The event-based system is a little undocumented, and if I am not mistaken then you can only have 1 active trigger per type. Which is a little error prone.

[lL1l1]

Just tested that multiple triggers per type works, they just need unique trigger names otherwise the triggers stop working.

I think the trigger system was designed for campaigns, looking at how the trigger manager is designed, so I agree it's fine to do polling in the future for some AI brain economy functions that run constantly in comparison and don't have to be mapper friendly.