Commit cf14728
committed
Avoid silly behavior when transferring almost-nonexistent energy.
This is a bit complicated to explain, so stick with me.
When transferring energy from shields to weapons (or vice versa), the values modified are the so-called "target deltas" rather than directly modifying the shield strength or weapon energy values. The ship_chase_shield_energy_targets() function carries out actually meeting these targets without exceeding a change of ETS_RECHARGE_RATE percent per second. At least, that's what it's supposed to do, and obviously works that way when the target delta is positive.
When the target delta is negative, however, a logic error with the conditional meant to limit the rate of change instead functions backwards; if the amount of desired change exceeds the per-frame limit, the amount of change is set to the total desired change, and if the amount of desired change is smaller than the per-frame limit, than the amount of change is the per-frame limit (even though that's more than the amount that's supposed to be drained).
Since the target delta is modified by the amount by which the value changed, this leads to an interesting consequence whereby the "extra" amount taken away is added back in the next frame... which has another interesting side-effect if the "extra" drain tried to reduce shields below 0. Namely, the shield code doesn't let it, while ship_chase_shield_energy_targets() remains blissfully unaware that the actual change was smaller than requested. So on the next frame, you spontaneously get some fraction of a percent of your shields back. Which, naturally, you can then transfer energy from to your weapons ad infinitum; the amount is small, but you can continually transfer it, so you're getting weapon energy out of nowhere.
Now, straight-up fixing the logic error would be a major retail balance change; if transferring energy from your shields to your weapons only gradually reduced your shields, instead of taking a huge chunk at the start, it would be a much safer option. Therefore, the only non-balance-changing fix is to just remove the broken conditional entirely (so that it always drains the full amount instantaneously, regardless of how big or small it is).
I've left the fixed conditional commented out so that somebody, when we're not in a feature freeze, can add an AI profile or mod table flag to restore the check, allowing for slow energy transfers.1 parent c5278e2 commit cf14728
1 file changed
+2
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
8132 | 8132 | | |
8133 | 8133 | | |
8134 | 8134 | | |
8135 | | - | |
| 8135 | + | |
8136 | 8136 | | |
8137 | 8137 | | |
8138 | 8138 | | |
| |||
8148 | 8148 | | |
8149 | 8149 | | |
8150 | 8150 | | |
8151 | | - | |
| 8151 | + | |
8152 | 8152 | | |
8153 | 8153 | | |
8154 | 8154 | | |
| |||
0 commit comments