Skip to content

An aircraft's speed above BrakeRate goes where its nose points - #36

Merged
CubeB merged 1 commit into
revivalfrom
23-brakerate-nose-reaim
Sep 11, 2026
Merged

CubeB merged 1 commit into
revivalfrom
23-brakerate-nose-reaim

Conversation

@HectorBailey

Copy link
Copy Markdown
Collaborator

Closes #23.

The decode, checked against the listing. 0x43D38E0x43D47D in the Steam/GOG v3.1 binary (same MD5 as the findings): hypot(vel.x, vel.z) compared with def+0x19A (brakerate) as floats; at or below, nothing. Above, vel.x and vel.z are each multiplied by brakerate/speed in 16.16, then excess = speed - brakerate is put through the sin and cos of the unit's heading word at unit+0x66 and added to vel.x and vel.z. vel.y is never read. That is exactly what §1's table says.

What changed.

  • applyBrakeRateNoseReaim(velocity, nose, brakeRate) in UnitBehaviorService_util, with the addresses in the comments.
  • computeNewAirUnitVelocity calls it after drag and before the profile, the original's order. That function serves the flying state and take-off.
  • Not applied to the attack run, the gunship ring or the dogfight, which have their own velocity functions and their own decoded geometry. Called out in the notes as the next pass.
  • docs/TOTALA-EXE.md §1 "Deliberately not ported" and the summary line at §88 updated.

Verified, with real FBI values from rev31.gp3 (ARMFIG 10/6/0.35/512, CORVAMP 12/7/0.35/620, ARMCA 6.9/1.5/0.06/90):

  • brakerate.test.cpp: at or below BrakeRate unchanged; excess goes along the nose (10 sideways with BrakeRate 6 becomes 6 across and 4 ahead); vertical untouched; never faster than it came in.
  • A ninety-degree turn driven the way updateUnitRotation and updateUnitSpeed drive it: the Freedom Fighter's worst crab drops from about 53° to under 15° and the Vamp's by more than half; the construction aircraft moves by under a degree, matching the earlier 0.00° bank measurement.
  • rwe_test: all 555 test cases pass (71500 assertions), Linux gcc-14 Debug, including the existing aircraft and bank tests whose fixtures the rule now touches.
  • Not play-tested in a running game here (the Linux run needs A chosen view refers to the caller's range, not a copy of it #17 first). The test drives the same two update functions the scene does.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PJCbwC9MGZnM6erMDKptun

The original's per-tick air movement has a brake step between drag and
the turn (0x43D38E-0x43D47D): if the horizontal speed is above the
unit's BrakeRate, the horizontal velocity is scaled down to BrakeRate
and the speed stripped off is added back along the heading. Vertical
velocity is left alone. It is why its aircraft barely crab. RWE had it
decoded and deliberately left out, because with only construction
aircraft measured, which never reach their BrakeRate of 1.5, it moved
nothing.

Measured with the shipped fighters it moves a great deal. A Freedom
Fighter (MaxVelocity 10, BrakeRate 6) or a Vamp (12, 7) put through a
ninety-degree turn crabbed by fifty to seventy degrees at the worst
point without it; with it the flight path stays within a few degrees
of the nose throughout. The construction aircraft is unchanged to
within a degree, as the earlier measurement said.

It runs in the flying state's velocity update, which take-off shares.
The attack run, the gunship ring and the dogfight steer their own
velocities and are left for their own pass.

Issue: #23

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJCbwC9MGZnM6erMDKptun
@CubeB
CubeB merged commit cc31a18 into revival Sep 11, 2026
5 checks passed
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.

Aircraft: the BrakeRate nose re-aim (0x43D38E)

2 participants