fabi/Syplheed-Reborn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re(flight): the linear factor is the CLOCK — 1.260 measured against 1.267

Browse Source 
Cleanest linear measurement: neutral throttle (HUD = CruisingVelocity 350), sticks
centred, 20 s of perfectly straight flight (displacement/path = 1.000):

  8 900 world units in 20.1 s -> 443.6 /s -> 1.267x the HUD's 350

And the game's own mission timer across a wall-clock interval:

  TIME 00:08.79 -> 00:46.97 = 38.18 s of game time in 30.29 s wall = 1.260

Same number. So the linear discrepancy is not a unit difference: the mission clock
runs ~1.26x faster than wall time under this emulator, and dividing world
displacement by WALL seconds inflates speed by exactly that. World units and
displayed speed share one unit; the definition velocities are per GAME second.

This supersedes the previous "world-unit vs displayed-speed" reading.

Left open (❔): settled turn rates measured 74.9/41.1 deg/s in wall time against
AV_PitchMinus_Min/Max 75/40, but the clock argument predicts ~94 for the first.
Either that agreement was luck inside a noisy sample (per-window rates spanned
61-96) or angular integration is frame-based where linear is time-based. The check
is to re-measure pitch and convert wall->game seconds with the clock ratio.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NptfmpjdpNCKEez6d2xvA9
This commit is contained in:
Claude (auto-RE)
2026-08-13 17:26:27 +00:00
parent 0cb81b6200
commit ae5f322c03
2 changed files with 92 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/re/flight-speed-law.md
View File

@@ -303,3 +303,42 @@ one of two moves: **let a held input vary** (the trigger's analogue range), or
**bring in an independent oracle** (the HUD, the definitions, a longer settle). The
wrong turn — the time base — came from explaining a number instead of first
measuring the same quantity a second, cleaner way.
---
# ✅ The linear factor IS the clock — measured against the game's own mission timer
The cleanest possible version of the linear measurement: neutral throttle (HUD reads
exactly `CruisingVelocity` 350), sticks centred, **20 s of perfectly straight flight**
(`straightness = displacement/path = 1.000`, so no manoeuvring contaminates it) —
[`tools/re-capture/cruise_ratio.py`](../../tools/re-capture/cruise_ratio.py):
```
displacement 8 900 world units in 20.1 s -> 443.6 /s
ratio vs the HUD's 350 -> 1.267
```
And the game's **own clock**, read off the HUD across a wall-clock interval:
```
mission TIME 00:08.79 -> 00:46.97 = 38.18 s of game time
wall clock = 30.29 s
ratio = 1.260
```
**1.260 against 1.267 — the same number.** So the linear "discrepancy" was never a
unit difference: **the mission clock runs ~1.26× faster than wall time under this
emulator**, and a speed derived by dividing world displacement by *wall* seconds is
inflated by exactly that. World units and the displayed speed share one unit, and a
reimplementation should take `CruisingVelocity`/`MaximumVelocity` at face value —
per **game** second.
This supersedes the previous section's "world-unit vs displayed-speed difference".
❔ **One thing does not fit, and is left open.** The settled turn rates measured
74.9 and 41.1 °/s *in wall time* against `AV_PitchMinus_{Min,Max}` 75/40 — but if
game time runs 1.26× fast, a 75 °/game-second cap should have read ~94 °/wall-second.
Either that agreement was luck inside a noisy sample (the per-window rates spanned
61–96), or angular integration is frame-based where linear is time-based. The check:
re-measure pitch and convert wall→game seconds with the clock ratio, expecting ~94
if the clock explanation is universal.