Skip to content

Measure afterburner cooldowns on the mission clock - #7895

Open
BTawaifi wants to merge 1 commit into
scp-fs2open:masterfrom
BTawaifi:feature/afterburner-mission-clock
Open

BTawaifi wants to merge 1 commit into
scp-fs2open:masterfrom
BTawaifi:feature/afterburner-mission-clock

Conversation

@BTawaifi

Copy link
Copy Markdown

Split out of #7874; as suggested there, this applies in all modes, not only headless runs.

+Aburn Cooldown Time and the player's 1.3 s afterburner re-engage delay were timed with timer_get_milliseconds(), the real clock. Under time compression a cooldown therefore lasted longer in mission time than the table says, and it kept running while the game was paused. The cooldown was added in 2020 (23f8062) and reused the retail re-engage check's real-clock now; the rest of afterburner.cpp already uses mission timestamps.

Both delays now use mission timestamps. The mission clock does not run outside missions and can be near zero when a session's first mission starts, so the "last stopped" and "last started" times start out invalid instead of 0; no delay applies before the afterburner has been used.

Behaviour change: only under time compression or a pause. At 1x the delays are unchanged.

Testing: a ship with +Aburn Cooldown Time: 4 and an AI "afterburn hard" goal, windowed, gap from each afterburner stop to the next engage, in mission time:

1x 4x time compression
before 4.00 s 16.00 s
after 4.00 s 4.00 s

The ship afterburns within 3 s of mission start, so the first mission does not start in cooldown. Builds alone on this branch.

afterburners_start()/afterburners_stop() timed the +Aburn Cooldown Time delay and
the player's 1.3 s re-engage delay with timer_get_milliseconds(), the real
clock. Under time compression a cooldown therefore lasted longer in mission
time than the table says, and it kept running while the game was paused. The
cooldown was added in 2020 and reused the retail re-engage check's real-clock
"now"; the rest of the file (ABURN_DECAY_TIME, the sound timers) already uses
mission timestamps.

Both delays now use the mission clock. The mission clock does not run outside
missions, so it can still be near zero when the first mission of a session
starts; the "last stopped" and "last started" times therefore start out
invalid instead of 0, so that no delay is in effect before the afterburner has
been used.

Without time compression or pausing, the delays behave as before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant