Skip to content

Commit cf14728

Browse files
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

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

code/ship/ship.cpp

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8132,7 +8132,7 @@ void ship_chase_shield_energy_targets(ship *shipp, object *obj, float frametime)
81328132
shield_add_strength(obj, delta);
81338133
shipp->target_shields_delta -= delta;
81348134
} else if (shipp->target_shields_delta < 0.0f) {
8135-
if (delta < -shipp->target_shields_delta)
8135+
//if (delta > -shipp->target_shields_delta)
81368136
delta = -shipp->target_shields_delta;
81378137

81388138
shield_add_strength(obj, -delta);
@@ -8148,7 +8148,7 @@ void ship_chase_shield_energy_targets(ship *shipp, object *obj, float frametime)
81488148
shipp->weapon_energy += delta;
81498149
shipp->target_weapon_energy_delta -= delta;
81508150
} else if (shipp->target_weapon_energy_delta < 0.0f) {
8151-
if (delta < -shipp->target_weapon_energy_delta)
8151+
//if (delta > -shipp->target_weapon_energy_delta)
81528152
delta = -shipp->target_weapon_energy_delta;
81538153

81548154
shipp->weapon_energy -= delta;

0 commit comments

Comments
 (0)