DelMar Internals: How Rocket Racing Actually Worked

A developer facing reverse engineering reference for the Rocket Racing Global Archive. Reverse engineering, datamining, and reconstruction by shrezee (this archive’s maintainer). Build: Fortnite 37.51 (5.7.0-46968237+++Fortnite+Release-37.51).

Companion to ROCKET_RACING_GLOBAL_ARCHIVE.md. The main file’s Section 5 documents Rocket Racing as a player feels it; this file documents it as the engine ran it. Where the main archive’s Section 8.5 sketches the internals from memory, this file is the full, citation per claim version.

0. What this is, and the honesty contract

Rocket Racing shipped December 8, 2023 as one of the three pillars of Fortnite’s “Big Bang” relaunch. Internally it was never called Rocket Racing: every file, plugin, playlist, and class carries the codename “DelMar” (after Del Mar, California). It is a bespoke, antigravity arcade racer: cars that drive on walls, ceilings, and through full loops, built by Epic (with Psyonix / Rocket League DNA) on a proprietary Chaos async physics vehicle, not on ChaosVehicles and not on the Battle Royale car code.

This document reconstructs how that vehicle worked, from three independent ground truth sources, each authoritative for a different layer, plus a web cross check for “does this match how it played”:

1. fmodel exports: the authoritative tuning values (DelMarVehicleConfig_60Hz.json and friends). These are numbers, not code.
2. The 37.51 SDK dump (Dumper7 CppSDK headers + Dumpspace JSONs): the authoritative types, offsets, and signatures. Layout, not behaviour.
3. Live Ghidra on the unpacked 37.51 image: the authoritative behaviour. The decompiled force laws. 7,255 DelMar functions were named; a subset were decompiled to the C in docs/decomp/.
4. Web cross check (patch notes, pro guides, Epic’s own UEFN device docs): not a ground truth source, but the check that a recovered value produces the behaviour players observed, and the way conflicts (Section 5) get surfaced.

The honesty contract

Every technical claim below carries a source citation (file:line, file:offset, or ghidra 0xADDR) and one of three status tags. This discipline is inherited directly from shrezee’s reconstruction docs: an honest “unrecovered” beats a confident guess.

Nothing in this file is guessed to look complete. The gaps are the point: they tell the next person exactly where to dig.

1. The core paradigm: Rocket Racing is a velocity redirect, not an arcade AddForce

This is the headline finding, and it reframes everything else.

Most arcade racers are Newtonian: throttle applies a forward force, friction and drag apply opposing forces, and the car’s velocity is whatever those forces integrate to. Rocket Racing does not work that way.

DelMar’s genuinely recovered core force law, the one function shrezee decompiled line by line and verified, is FUN_155da08c0. It is a per substep target speed velocity redirect / grip solver on the surface contact plane. Each physics substep, for the single rigid body that is the car, it:

1. READ    the body's current linear velocity  V           (FUN_14ba840c0)
2. NORMALIZE the contact/drive direction        D           (from the solve buffer; unit, or
              normalized, or a stored fallback vector)       [phys_155DA08C0_FUN_155da08c0.c:195-219]
3. ACQUIRE the surface normal                    N           (FUN_14b24bc20 = body-up from the
              orientation matrix; falls back to world-up      (0,0,1) only when no contact body)
                                                             [phys_155DA08C0_FUN_155da08c0.c:328-345]
4. REMOVE EXCESS / LATERAL velocity along D:
              speedAlong = dot(TargetVel, D);  vAlong = dot(V, D)
              if speedAlong < cfg+0x574 AND (cfg+0x578 < vAlong OR -speedAlong < vAlong):
                  ref    = min(vAlong, cfg+0x578); ref = min(ref, -speedAlong)
                  excess = vAlong - ref
                  if excess > eps:  V -= excess * D        [phys_155DA08C0_FUN_155da08c0.c:260-276]
5. RESCALE toward target speed (gated - all three must hold):
              dot(N, D)      > cfg+0x584
              dot(N, V/|V|)  > cfg+0x57c
              |V|            > cfg+0x580                    [phys_155DA08C0_FUN_155da08c0.c:346-351]
              ratio = |TargetVel| / |V|                     where |TargetVel| = length(sim[0x320..0x322])
              ratio = max(ratio, 1.0)                        <-- ACCELERATE-ONLY: never below 1
              scale = 1.0 + (ratio - 1.0) * cfg+0x588        <-- LERP toward target by the redirect GAIN
              V *= scale                                     (pure magnitude; DIRECTION PRESERVED)
                                                             [phys_155DA08C0_FUN_155da08c0.c:352-366]
6. WRITE   V back to the body                    (FUN_14ba9c2a0)   [:373]

Status: CONFIRMED · decompiled and verified line by line by shrezee; matches rr-dossier.md:6,107,110.

Reverified live against the 37.51 image, July 13, 2026. FUN_155da08c0 was redecompiled directly from the running Ghidra image and matches the above step for step: the contact normal fetch via FUN_14b24bc20 with the world up DAT_17b16f530 fallback, the grip clamp thresholds at cfg+0x574/578/57c/580/584, the redirect gain at cfg+0x588, the accelerate only rescale scale = 1.0 + (ratio − 1.0)·cfg[+0x588], the write back via FUN_14ba9c2a0, and the per substep vtable dispatch through slots +0x380 then +0x1038. The config resolver FUN_155db04a0 was also redecompiled: it returns the grip config object from simObj+0x1ef0 (via FUN_141ac1b60, gated by a validity bit), so the +0x574..+0x588 tunables live on that runtime physics config object. [ghidra 0x155da08c0, 0x155db04a0, live]

Three consequences fall out of this, and they define the entire feel of the mode:

(a) Wall and ceiling driving is native, not a special case. Grip is enforced by removing velocity along the contact direction D and expressing the rescale against the contact normal N (FUN_14b24bc20), with world up used only as a fallback when there is no contact body [phys_155DA08C0:328-345]. There is no world gravity “down” baked into the grip law. Drive on a ceiling and N simply points down out of the ceiling; the same code holds the car there. The car doesn’t fight gravity on a wall; the grip solver never referenced world gravity to begin with. [rr-dossier.md:61]

(b) The car accelerates but the redirect never brakes. The ratio = max(ratio, 1.0) clamp means the rescale can only speed the car up toward its target, never slow it down. All deceleration must flow through elsewhere (lowering TargetVelocity, or the excess removal path in step 4), never through this integrator. shrezee flags this explicitly: “ACCELERATE-ONLY: ratio floored at 1 so it never brakes; deceleration must come from lowering targetSpeed, never here.” [rr-implementation-blueprint.md:41]. The dedicated brake path (value ~11818) was not located in the corpus; do not claim the brake law is reconstructed. [rr-implementation-blueprint.md:20]

(c) “Grip” is contact plane excess velocity removal, not downforce. What holds the car to the road/wall/ceiling is step 4 clamping the along contact velocity into a band, not a downward force pushing it onto the surface. Drift, boost, and wall stick are all built on this magnitude rescale + excess removal, not on downforce. [rr-implementation-blueprint.md:3,43-44]

The physics substrate

DelMar runs on the core Chaos async physics tick: not ChaosVehicles, not ChaosModularVehicle. UDelMarVehicleConfigs : UFortPhysicsVehicleConfigs is a proprietary spring physics vehicle on AFortAthenaSKVehicle, ticked per substep by a Chaos SimCallback and networked via UDelMarVehicleNetworkPhysicsComponent. The tick rate is set by ADelMarAsyncPhysicsTickMutator writing AsyncTickRate into FPhysicsSolverBase::AsyncDt; the config is “60Hz,” so AsyncDt = 1/60. The root and sole physics body is a single box collision primitive on the skeletal mesh component (zero friction / zero restitution physmat, LinearDamping = 0); the visible car mesh just follows it. Status: CONFIRMED [surface-locomotion.md:26-42; ghidra 15bb912e0, 14358f590].

The recovered per substep tick order

shrezee reconstructed the substep ordering from the physics thread dispatcher FUN_155dcca30 and the redirect FUN_155da08c0. EXACT = the velocity redirect core (Step 6) and the tick order itself; UNRECOVERED = most of the per corner appliers, which are vtable dispatched into stripped Chaos virtuals that Ghidra could not follow. [rr-implementation-blueprint.md:3-17]

The critical takeaway for a reimplementer: Steps 6 and 8 are the only two force laws recovered as decompiled logic. Everything else is either an accessor/state read (confirmed) or a reconstruction from values + SDK field order (inferred). The mode’s feel is dominated by Step 6.

2. Plugin architecture: the DelMar family

DelMar is not one plugin. It is a family folder under FortniteGame/Plugins/GameFeatures/DelMar/ holding the mode’s actual GameFeaturePlugins. Direct enumeration of the fmodel export root found 34 top level folders (the parallel type analysis classified 32 of them as 20 code bearing / 12 content only; the two folder difference is the shared Levels / VehiclesFrontend containers, folded differently, an honest counting note, not a discrepancy in substance).

Definitions. Code bearing = a dedicated native (or blueprint compiled) SDK package header was dumped for it (SDK\<Name>_classes.hpp). Content only = a .uplugin descriptor + a Content/ tree, but no dumped code module. KEY NUANCE: the native gameplay core (ADelMarVehicle, ADelMarRaceManager, the config structs, the physics) lives in DelMarCore (250 classes). DelMarGame is the blueprint/content layer built on top (RaceManager BP subclasses, the vehicle config data asset, level configs, data tables) and has no native module header of its own. Do not look for the physics in DelMarGame.

Why parsers report “empty” plugins: many of these folders (especially the Levels plugins) ship as descriptor only in the base install; the maps download on demand (see Section 6). A CUE4Parse style tool scanning the base install sees a .uplugin with no maps and reports it empty. That is expected, not a datamine failure.

3. Class & type architecture

3.1 The vehicle inheritance chain (a dossier correction)

shrezee’s SDK extraction corrects the dossier’s earlier approximate chain. The player car is exactly four Fort/Engine hops from AActor, and the vehicle branch splits off the character branch very early: it does not pass through any AFortVehicle or AFortPawn/AFGF_Character node.

UObject
└─ AActor                        Engine_classes.hpp:718          (: public UObject)
   └─ APawn                      Engine_classes.hpp:5258         (: public AActor)
      └─ AFortPhysicsPawn        FortniteGame_classes.hpp:2065   (alignas(0x10) : public APawn)   ← DIRECT off APawn
         └─ AFortAthenaVehicle   FortniteGame_classes.hpp:5175   (: public AFortPhysicsPawn)
            ├─ AFortAthenaSKVehicle  FortniteGame_classes.hpp:6652  (: public AFortAthenaVehicle)
            │  └─ ADelMarVehicle     DelMarCore_classes.hpp:948     (final : public AFortAthenaSKVehicle)
            │                                                        ← the player car, layout 0x2460..0x4150 (size 0x1CF0)
            └─ ADelMarGhostVehicle   DelMarCore_classes.hpp:4235    (final : public AFortAthenaVehicle)
                                                                     ← replay ghost, branches ONE level UP (no SK layer)

Status: CONFIRMED. Every node cited from a class declaration line in the 37.51 SDK headers. Note the correction: AFortPhysicsPawn derives directly from Engine’s APawn [FortniteGame_classes.hpp:2065], whereas the character branch is AFortPawn : AFGF_Character [FortniteGame_classes.hpp:9494]; the two split immediately below APawn. The replay ghost vehicle branches off AFortAthenaVehicle directly, skipping the skeletal mesh vehicle layer that the player car has.

AFortAthenaSKVehicle, AFortAthenaVehicle, and AFortPhysicsPawn are only emitted in FortniteGame_classes.hpp (the shared BR vehicle stack), not in the DelMar package: the DelMar car is a leaf on Fortnite’s existing Athena vehicle tree.

3.1a What each base layer actually holds (member content, for anyone reconstructing the car)

The chain is only four hops, but the layers are wildly uneven in size, and ~94% of the mass is Fortnite game integration that has nothing to do with how the car drives. Knowing which members are the driving machine versus the game shell is what lets a clean UE reconstruction be faithful without dragging in half of Fortnite. Recovered by member level inspection of the 37.51 SDK headers:

• AFortPhysicsPawn : APawn: tiny (~3 members, layout 0x04D0..0x050C). The whole network predicted physics anchor: ReplicatedTransformReq (FVehicleTransformInfo @0x04D0), GravityMultiplier (float, Net/RepNotify @0x0508, the one movement relevant field), bUseNetPrediction:1 @0x050C; methods are pure replication glue (ServerMove(FReplicatedPhysicsPawnState), ClientUpdateStateSync, OnRep_GravityMultiplier).

• AFortAthenaVehicle : AFortPhysicsPawn: huge (~1,476 header lines, layout 0x0718..0x23C8). By member keyword the composition is ~75 Camera · 72 Seat · 41 Input · 30 Cosmetic · 24 Weapon · 18 Velocity · 16 Physics · 14 Passenger · 10 Wheel · 10 Collision · 10 Audio · 4 Gravity · 3 Movement plus horn/minigame/team restriction machinery. Only ~90 lines are the force model; the load bearing driving members are: bUseGravity:1 @0x0A32, bCanDriveOnIncline:1 @0x0A2E, bMoveStickAcceleratesVehicles:1 @0x0A50, bUseForceHeading:1 @0x0A2B, ForwardDrivingAntiGravityScaler @0x0FE8, FrontMassRatio/RearMassRatio @0x0D70/0x0D74, TopSpeedCurrentMultiplier/PushForceCurrentMultiplier @0x0CE8/0x0CEC, BrakeAboveTopSpeedDelta @0x10CC, ImpulseResponseMultiplier/ImpulseResponseZBias @0x13B0/0x13B4, and the velocity read back cache CachedSpeed/CachedLocalSpeed/CachedLocalVelocity @0x10E0/0x10E4/0x10E8. Everything else (seats, passengers, weapon mounts, camera modes, cosmetic components, horn) is game shell.

• AFortAthenaSKVehicle : AFortAthenaVehicle: small (~30 members, layout 0x23C8..0x2458). This layer is entirely 4 corner wheel VISUAL state: WheelOffset{FR,FL,BR,BL}, WheelOffsetLimit{F,B}, WheelOffsetLerpPerSecond{Up,Down}, AxleOffsetZ{,_B}, AxleCenter{F,B}, AxleRoll{F,B}, WheelRotation{FR,FL,BR,BL}, WheelRotationVelocity{…}, WheelSpin{…}, WheelSpinVelocity{…}, WheelSpinDampingPerSecond @0x2440, WheelFXSockets (TArray<FVehicleWheelFXSocketInfo>). It animates wheels; it is not part of the force law. (Its one method, GetModifiedDamageForActor, is BR combat, not racing.)

• ADelMarVehicle : AFortAthenaSKVehicle: the DelMar movement surface itself (layout 0x2460..0x4150, size 0x1CF0, 206 members): the FDelMarInputAction block (Throttle/Brake/Steer/Pitch/Roll/Yaw/Drift/Jump/KickFlip/Underthrust/Turbo/AirFreestyle/Strafe/AerialPitch @0x2560+), FFortAthenaVehicleInputState PendingDriverInputState @0x24E8, the GAS UDelMarVehicleMovementSet @0x27E8, UDelMarVehicleNetworkPhysicsComponent @0x27D8, TArray<FDelMarVehicleCachedContact> CachedContacts @0x2878, and the replicated ability state (Section 3.3). The actual force integration is not in this class’s own vtable; it runs on the Chaos sim object reached via vehicle+0x2458 (see Section 1).

Reconstruction implication. A clean UE port should mirror the hierarchy (physics pawn → athena vehicle → SK vehicle → car) and port the driving members above, but reconstruct the substrate as a single Chaos rigid body running the Section 1 velocity redirect, not attempt to port the seat/weapon/camera/cosmetic shell, which is both irrelevant to feel and unbuildable without the whole Fort ecosystem. (This is exactly the split used by the SursumGame VaeloraVehicle reconstruction: ASurmPhysicsPawn → ASurmAthenaVehicle → ASurmAthenaSKVehicle → AVaeloraVehicle, carrying these members with their offsets as provenance.)

3.2 The config container and the FDelMarVehicleConfig_* struct family

All tuning lives in UDelMarVehicleConfigs [DelMarCore_classes.hpp:7272], a container that aggregates 27 tuning sub structs by value (layout 0x0A68..0x2470; Drift is the largest single sub struct at 0x0718). The blueprint CDO DelMarVehicleConfig_60Hz stores per field deltas over this native container, which is why some fields (native defaults) are absent from the fmodel export and had to be recovered from the constructor via Ghidra.

The sub struct family, from DelMarCore_structs.hpp:

Status: CONFIRMED (SDK type declarations). Note FDelMarVehicleConfig_Strafe and FDelMarVehicleConfig_SelfDemolish are in the type layout but under surfaced in the 60Hz value export.

3.3 Replicated ability state

Runtime ability state is replicated through FDelMarVehicleReplicatedState [DelMarCore_structs.hpp:3174], a container of 15 per ability sub states, carried on UDelMarVehicleNetworkPhysicsComponent.ReplicatedState (0x0100, size 0x0290). The sub states share a small inheritance tree: a base FDelMarVehicleReplicatedState_Ability, a FDelMarVehicleReplicatedState_BonusSpeedAbility mid tier (for anything that contributes to the bonus speed accumulator), and per ability leaves.

Status: CONFIRMED [DelMarCore_structs.hpp:2987-3194]. The _Drive sub state carries LastAverageWheelWorldContactNormal (an FVector_NetQuantizeNormal): the surface the car is currently attached to, replicated so remote clients render wall/ceiling attachment correctly [DelMarCore_structs.hpp:3051-3059].

3.4 Other load bearing classes

4. The mechanics, by system

Each system below gives the CONFIRMED values (fmodel / SDK / Ghidra ctor), the code status (recovered / inferred / unrecovered), and a how it plays one liner. All values are Fortnite 37.51. Physics values are in cm/s or cm/s² unless noted; see Section 5’s unit mismatch note before mapping any of these to the in game speedometer.

4.1 Base drive: throttle → target speed

DriveAccel is a torque vs speed ratio curve: full acceleration held to ratio 0.45, then a sharp falloff to 0 at ratio 1.0 (13 keys, linear) [...json:110-253]. Note the native base speed 7496 is the real number the target speed law scales; the BP raises the caps to 12000/6752 (BP wins over the native 9370/8440) [surface-locomotion.md:189-192].

• Code: the redirect (Section 1) is the confirmed integrator. How DriveAccel + TargetSpeedMaxAccelCurve accumulate into the target speed each substep is UNRECOVERED: the writer of the target vector (simObj+0x1900) is not in the 800 function corpus and has no Ghidra symbol [rr-implementation-blueprint.md:21,128].
• Plays: throttle alone settles the car at a base speed the UI shows as “not enough” (~600-700); the whole skill is keeping speed above it. The car is explicitly slower airborne than on the road; hugging the road is faster.

4.2 Steering

SteerAngleCurve maps speed → max steer angle, tightening as you go faster: (0,10°)(3000,10°)(4000,5.5°)(5000,3.0°)(6000,2.75°)(6500,2.5°), linear [...json:302-372]. AerialRotation.MinForwardSpeedForYawRotation = 1500 [...json:429]. Inversion is governed by MaxInvertedControlSteering (0x340) and MinCeilingSecondsToInvertControls (0x344) [DelMarCore_structs.hpp:2360-2407].

• Code: UNRECOVERED. The redirect preserves velocity direction, so steering is applied elsewhere and is not visible in FUN_155da08c0. Whether steering rotates the target vector, yaws the body via torque, or is a bicycle kinematic model is unconfirmed [rr-implementation-blueprint.md:22,129].
• Plays: A/D on PC; sharper turns feed stronger drift. The “Invert Steer Method” setting flips steering when upside down (fixed to persist in v28.10).

4.3 Drift (the largest config, 0x718)

Drift is a redirect of velocity toward facing model, not a torque skid. VelocityRedirectAngle curves exist in controlled / no steer / kickback / kickback-V2 variants (5-6 keys each) [...json:543-904].

• Code: FUN_155da08c0 IS the drift grip/redirect law, the same recovered core (Section 1). Drift raises the along contact velocity band (cfg+0x578), allowing more lateral slide. However, the drift time source of that reduced grip value is UNRECOVERED: the redirect reads a single config with no visible drift branch, and DriftConfig (configs+0x13B0) does not appear anywhere in the corpus. The torque tier selection law (in_dir 2 / no_steer 3 / not_in_dir 5 / change_dir 15 / with_kick 75), the rotation caps, controlled vs uncontrolled velocity handling, and slip angle derivation all live in the unreachable per corner applier [rr-implementation-blueprint.md:34-35,140-145]. Drift active state reads: sim(+0x2458) vtable slot for drift active, side (+0x3d0), slip (+0x3f0) [HandleDriftActivated 15e5e97c0.c:65].
• Plays: basic drift auto engages past a steer angle threshold; “Rocket Drift” is a held button (Shift/X/Square) for a bigger exit boost. Start the drift at the corner, re press mid corner to tighten.

4.4 Drift boost (exit boost economy)

BonusSpeedPercentageCurve (0,0)(0.63,0.9)(1,1); PotentialDriftBoostPercentageCurve (0,0)(0.25,0.45)(1,1); DriftBoostDurationCurve min 0.66 → 1.0 [...json:996-1124].

• Code: event/state surface only. UDelMarVehicleForceFeedbackComponent::OnDriftBoostActivated/Deactivated is haptics, not physics [docs/decomp/...15bd321e0.c]; drift bonus float reads at sim(+0x2458)+0x430. The impulse application force law is UNRECOVERED: how MaxBonusSpeed=2500 + the curves become a queued bonus is not decompiled [rr-implementation-blueprint.md:148].
• Plays: exiting a drift grants a boost that scales continuously with drift duration; you must straighten to receive it; hold too long and the boost arcs you into the outer wall. (v28.30: a new drift boost during an active one now always gives the full impulse.)

4.5 Turbo (3 charge boost economy)

• Code: charge economy structure CONFIRMED: TurboManager with Charges / ChargeCap=3 / ActiveSeconds=2; spend is Charges = clamp(Charges-1, 0, cap); activation is a ServerNotifyTurboActivated RPC that registers a DMFO_Max target speed modifier of 7681 for 2 s (it raises a floor, it does not stack +7681) plus a one shot impulse 1320 [rr-implementation-blueprint.md:67-68]. The exact application point/axis of the 1320 impulse is UNRECOVERED [rr-implementation-blueprint.md:149]. State reads: charges +0x560, active +0x588, IsInvulnerabilityActive +0x6d8.
• Plays: meter holds up to 3 charges (lightning icon); each activation costs a bar (Y/Triangle); each charge refills over ~60 s, faster while drifting; a short re press window gives a second turbo.

4.6 Startline boost (perfect start)

PercentageMaxBonusSpeedEarned is a symmetric timing curve peaking at release time 0 (±0.015 s plateau at 1.0, 0.4 at ±0.15, 0 at ±1.0) [...json:1367-1479].

• Code: state only: ADelMarVehicle.StartlineBoostData (FDelMarStartlineBoostData, Net RepNotify, 0x3C60) [DelMarCore_classes.hpp:1017]. HandleStartlineBoostActivated scales a percentage for UI only; the mapping from countdown timing to applied bonus speed and its decay is UNRECOVERED [rr-implementation-blueprint.md:150].
• Plays: time the launch to the final light for a graded % boost (perfect = 100%); the cadence changes each race, so read/hear it.

4.7 Jump (limited jet)

Only Jump.JumpVelocity = 2650 is in the export [...json:1128]. The SDK struct FDelMarVehicleConfig_Jump [DelMarCore_structs.hpp:1430] has 6 fields: MinJumpTime, MaxJumpTime, JumpVelocity, ForwardVelocity, PitchTorque, EndThrustForce. The other five values are not in the export.

• Code: UNRECOVERED. OnJumpActivated/OnVehicleLanded are haptic events only. The force law FUN_15baf07f0 timed out in Ghidra; whether 2650 is a velocity set or an impulse, and the tap vs hold gating, are unknown [rr-implementation-blueprint.md:30,155].
• Plays: hold to fly a limited time; tap in bursts to fly farther; landing recharges it; double/triple tap extends hang time over hazard zones.

4.8 Kickflip / air dodge (flip to attach)

• Code: UNRECOVERED. Input plumbing is confirmed (ADelMarVehicle.KickFlipAction at 0x2680; replay input bKickflip/bGroundedFlip) and the kickflip replicated sub state is confirmed (0x0190, size 0x60). But the torque/suction appliers FUN_141d91040/FUN_141d91070 timed out; the per substep combine order and the surface latch predicate (ray vs sweep, angle+distance+speed gating, the attach vs fall/death test) are not decompiled [rr-implementation-blueprint.md:31,156-158].
• Plays: Epic’s named ground→wall→ceiling transition (“basically flips the car over”); stick direction picks the surface; flipping toward a nonexistent ceiling = instant death (attach is gated by valid track geometry).

4.9 Air control (aerial pitch, diving for speed)

MaxPitchAdjustmentForwardSpeed = 5280 [...json:435]; UnderthrustTurnRate = 60, VerticalTurnRate = 30, MaxPitchVerticalDegreesFromWorldDown = 170, bAerialDivingBonusEnabled = true, MinAerialDivingBonusSpeed = -2250, AerialDivingBonusSpeedChangeRate = 6000, DecayRate = 3000 [...json:434-474].

• Code: UNRECOVERED (pitch/dive appliers timed out; candidates FUN_155da87f0/FUN_155d941b0) [rr-implementation-blueprint.md:32,162]. Input: AerialPitchAction (0x2728).
• Plays: nose up adds “wind resistance” to stay up longer; nose down dives faster to reach wall/ceiling boost pads; a downward dodge near the road preserves speed by cutting airtime.

4.10 Aerial rotation & air freestyle (flips/spins/air roll)

AirFreestyle.TorqueAccel = {X 27.5, Y 27.5, Z 9.1} (roll/pitch/yaw), TorqueDamping = {4.8, 4.8, 1.9} [...json:475-486]. AerialRotation: UnderthrustPitchDegrees 7.5, MaxRotationSpeed {4,4,9}, MinForwardSpeedForYawRotation 1500, LandingDetectionSeconds 0.25, LandingRotationAmplifier 3.0 [...json:422-433].

• Code: UNRECOVERED (player driven torque applier not located; distinct from the auto stabilizer). Input: AirFreestyleAction (0x26F8) [rr-implementation-blueprint.md:88-89,163].
• Plays: flips and air dodges fill the turbo meter; Air Roll (added v28.30) lets you hold a trigger + steer to spin midair.

4.11 Counter gravity / wall & ceiling driving: values recovered from the native ctor

This is the one place where a dossier top unknown was subsequently closed. The dossier ranked the per surface gravity scalars as UNKNOWN because the 60Hz export only surfaced the single scalar VehicleGravity = -2200 [...json:1549], and the FDelMarVehicleConfig_Gravity struct’s populated values were absent. shrezee then recovered them from the native constructor via Ghidra [surface-locomotion.md:84-104]:

• Code: surface relative attachment is CONFIRMED inside the redirect (Section 1): the contact normal comes from FUN_14b24bc20, world up only as a fallback [phys_155DA08C0:328-345]. But the classifier that tests the normal’s angle against 105°/135° to pick the ForceScale tier, the 4 wheel normal averaging + 35° variance gate + 3 wheel minimum, and the coyote time behaviour are all UNRECOVERED; only the cached result (vehicle+0xa30 bit1, via execCanAntigravityOnIncline @155dda8a0) is confirmed [rr-implementation-blueprint.md:24-26,134-137]. The counter gravity apply (gravity along −N scaled by the tier) is not in the on disk corpus; it lives in a stripped sim virtual reached via the vehicle+0x2458 vtable.
• Plays: the car sticks to walls, ceilings, and loops. The Creative device exposes a “Surface Counter Gravity Degree Threshold” (grounded sticking, 0°→180°) separate from a “Surface Latch Degree Threshold” (latching when flying into a surface).

4.12 Reattachment (surface re stick)

ReattachmentForceAmount = 5000, ReattachmentChannel = ECC_GameTraceChannel5; the force scalar curve is full to 0.2 s then a hard zero at 0.21 s (a short, strong pull) [...json:1181-1236]. SDK adds SurfaceTraceDistance (0x00) [DelMarCore_structs.hpp:2775].

• Code: UNRECOVERED: the trace + directed force application is not decompiled; the replicated sub state FDelMarVehicleReplicatedState_Reattachment (0x01F8) exists [rr-implementation-blueprint.md:97-98,168]. Likely shares code with suction (same channel).
• Plays: air dodge doubles as recovery: after falling off a surface, dodge toward a nearby wall/ceiling to reattach.

4.13 Underthrust (metered vertical/forward thrust)

UpwardAccel = 21000, MaxUpwardSpeed = 2750, MaxForwardSpeed = 5100, EndThrustForce = 1600, ForwardSpeedCap = 5700, MinUpwardAccel = 5500, LateralRelativeAccel = 5500 [...json:1501-1523]. The SDK models it as a fuel tank (StartingTankPercentage, MaxThrustSeconds, bReplenishTankOnLanding/OverTime, TankReplenishRatePerSecond) [DelMarCore_structs.hpp:2601-2623].

• Code: UNRECOVERED: OnUnderthrustActivated/Deactivated are haptics; the applier timed out. Input: UnderthrustAction (0x2698). Getters ActiveDuration/PercentageTankRemaining at vtable +0x640/+0x638 [rr-implementation-blueprint.md:85-86,161].
• Plays: a real named mechanic with its own VFX and quests (“Use Total Underthrust Percentage”), giving metered vertical/forward lift while airborne.

4.14 Drafting (slipstream)

MinSpeedToStartDrafting = 3000, NumSecondsToActivateDrafting = 0.5, NumSecondsToMaxBonusSpeed = 2.0, MaxBonusSpeed = 1000, NumSpeedRemovalSeconds = 1.0, LineOfSightChannel = ECC_Vehicle; MaxBonusSpeedPercentageCurve is a single key (0, 1.0) [...json:504-531].

• Code: UNRECOVERED: the replicated sub state FDelMarVehicleReplicatedState_Drafting (0x00F0, a BonusSpeed ability) exists; no force application function was located [rr-implementation-blueprint.md:94-95,169].
• Plays: sit in the slipstream directly behind a car for a speed increase/slingshot that also fills the boost bar; it works even on walls and upside down.

4.15 Rubberbanding (catch up)

MaxBonusSpeedLostPerSecond = 500, MaxBonusSpeedGainedPerSecond = 250, MaxSpeed = 7770; MaxBonusSpeed is a race position(0..1) → bonus curve up to +1500 for last place: (0→0)(0.375→500)(0.75→1250)(1.0→1500) [...json:1238-1365].

• Code: state fields on the vehicle (DistanceToPack (0x2548), RaceStatusSpeedModifier (0x2550) [DelMarCore_classes.hpp:956,958]) and a GAS BonusSpeed attribute (0x90) with OnRep [DelMarCore_classes.hpp:7354-7364]. The +1500 registers as an additive AddTargetSpeedAdjustment folded into the bonus accumulator (Step 4). The application law is UNRECOVERED; the per position curve mapping beyond the +1500 max is an evidence gap [rr-implementation-blueprint.md:103-104,151].
• Plays: slight catch up: cars out of the lead gain small boosts (largely via drafting), so players perform better out of first.

4.16 Suspension (bespoke 4 corner)

BodySetup_SportsCar (both axles symmetric): FrontAxle.TranslateX 136.55 / BackAxle −136.55, TranslateY −73.418, TranslateZ 51.9535, WheelRadius 40.098, RestDistanceZ 70; Suspension.MaxRaise 8.019, MaxDrop 38.475, Stiffness 210, DampingCompression 12.6, DampingRelaxation 20.16 [BodySetup_SportsCar.json:10-20]. The entire axle + suspension config block is byte for byte identical between BodySetup_SportsCar and BodySetup_SUV (the two files differ only in their Name and Package header lines), so the two body archetypes have no handling difference whatsoever [BodySetup_SUV.json - block diff]. SpringCollisionChannel = ECC_GameTraceChannel5 [...json:1530]. VehicleMass = 731.6113 [ghidra 0x15BD02EAA].

• Code: the per contact/suspension constraint setup is recovered: FUN_15bd1c9f0 iterates contacts (stride 0x48), computes a projected constraint force scale·dir·(dir·V), and stores each into the 0x70 stride CachedContacts buffer at vehicle+0x2878 [phys_15BD1C9F0_FUN_15bd1c9f0.c:63-88]. The 4 corner state (FR/FL/BR/BL WheelOffset/Rotation/Spin) is at AFortAthenaSKVehicle+0x23C8 [FortniteGame_classes.hpp:6655-6681]. The spring solve itself is inlined in Chaos / lives in UVehicleSimSuspensionComponent (VFT @173a22eb0) and is UNRECOVERED; the standard form F = k·(rest − compression) − c·compressionVel is a reconstruction, not byte perfect [rr-implementation-blueprint.md:27,138].
• Plays: the web is silent on suspension numbers (a coverage gap, not a conflict); only the general grounded arcade feel is described.

4.17 Collision (wall redirect & target speed reduction)

MinSpeedForTargetSpeedReduction = 10, WallTargetRedirectPercent = 0.7 [...json:92], MinAerialDemolitionSpeed = 4000, ContactNormalToVehicleRightThresholdDegrees = 15, TrackTraceChannel = ECC_GameTraceChannel5 [...json:34-95]. SpeedReductionPercentageCurve (impact angle → reduction): 0°→0.03, 15°→0.05, 90°→0.10 [...json:36-91]. All damage is disabled (noncombat) [...json:1542-1548].

• Code: UNRECOVERED as a dedicated function; the wall redirect feeds the same core: the reduced target speed is written into sim[0x320] and consumed by FUN_155da08c0. OnVehicleHitWall is camera shake only (cosmetic) [rr-implementation-blueprint.md:100-101,170]. The exact wall tangent projection (keep 0.7 of the tangent, discard the into wall component) is inferred from values.
• Plays: collisions were made “less severe” in v28.10 and kept tuned; cars can ricochet off walls (a device toggle) distinct from latching.

4.18 Auto upright / orientation stabilization

AutoUpright: RotationTorque 500.0, RotationDamping 20.0, MinActiveSeconds 0.2, MinDegreesFromVehicleUpThreshold 50.0 [...json:498-503].

• Code: CONFIRMED structure. FUN_155dd4eb0 is a per substep PD controller: reference up = surface normal near a surface else world up; proportional restore via body slot +0x8e8; Gram-Schmidt orthonormalize; angular torque from two axis error terms via slot +0x8f8 [phys FUN_155dd4eb0; rr-implementation-blueprint.md:14,79-80]. Which gain set applies (AutoUpright 500/20 vs AutoAerialRotation {25,25,80}) is unmapped because the physics thread config offsets (+0x610/+0x614) are a repacked struct that does not line up with the SDK layout.
• Plays: keeps the box from tumbling: torques the car toward surface up when it tilts past ~50°.

5. Conflicts & unit mismatches

These are the doc’s integrity backbone. Carried from the dossier [rr-dossier.md:93-102]; each is a place where two ground truth sources disagree or cannot be reconciled without a missing piece. They are documented, not resolved by guess.

1. Speed units (turbo). Web says each turbo is “+150” to a “900” max on the UI speedometer, but Turbo.TargetSpeedModifier.Value = 7681 / InitialImpulseForce = 1320 are cm/s scale physics units. The 600-700 base / 900 max UI numbers cannot be mapped to config cm/s without a UI↔cm/s scale factor, which no source provides.
2. Speed units (base cruise). Web “600-700” settle speed vs config MaxBaseForwardSpeed 7496 / ForwardMaxSpeed 12000. Different unit systems; the base cruise number is not a directly readable config field.
3. Aerial demolition threshold. Patch note says air demo min raised to “400 KPH” (v28.30); config Collision.MinAerialDemolitionSpeed = 4000. 400 KPH ≈ 11111 cm/s, matching neither 4000 nor 12000 cleanly; unit ambiguity unresolved.
4. Startline timing method. Gamerant: hold accelerate “right before the fourth circle lights”; earlygame: “the moment the green light appears.” The symmetric PercentageMaxBonusSpeedEarned curve (±0.015 s plateau at time 0) is consistent with “at the green” but does not settle the dispute.
5. Flip input combo. Gamerant describes three simultaneous inputs (jump + drift + stick); ggrecon/Epic docs describe a single “Air Dodge” button + direction. The exec chain shows one HandleKickflip entry, but the triggering input combo is not confirmed from decomp.
6. Gravity struct. An fmodel export note claimed “no separate Gravity struct: gravity is the single scalar VehicleGravity=-2200,” but the SDK shows FDelMarVehicleConfig_Gravity with per surface scalars. Reconciled (Section 4.11): the struct exists in the type layout and the 60Hz export simply didn’t surface its populated values; shrezee later recovered them from the native constructor via Ghidra. This conflict is now closed.
7. Drift tiers. Web uniformly reports drift boost as continuous with hold duration (no Mario Kart color tiers); config/SDK instead show a structured controlled vs uncontrolled model with distinct kickback/kickback-V2 redirect curves. Not a hard conflict, but web’s “continuous” framing understates the internal branching.
8. Double turbo window. Web reports a “1-2 second” re press bonus window; config Turbo.BonusZones=[{Start 0.8, End 2.0}] plausibly is this, but the mapping is a community estimate, not confirmed.

6. Top unknowns (ranked)

The honest frontier: what a reimplementer or the next dataminer should attack first. Carried and updated from [rr-dossier.md:104-117] and the blueprint’s GAPS block [rr-implementation-blueprint.md:127-173].

1. Speed unit mapping (blocks exact feel match): the conversion between config cm/s values (ForwardMaxSpeed 12000, MaxAccelSpeed 7144, TargetSpeedModifier 7681) and the UI speedometer (base 600-700, max 900). Without this factor every “does it feel right” check is ungrounded. No source gives it.
2. Drift boost force law: how MaxDriftBoostRatio 1.66 / MaxBonusSpeed 2500 + the curves are applied as an impulse. Only values, the haptic event, and the +0x430 state read are known; the applying code is UNRECOVERED.
3. Core drive integrator (target vector writer): the redirect (Step 6) is recovered, but the routine that turns throttle + DriveAccel + TargetSpeedMaxAccel into the target vector (simObj+0x1900) is not in the corpus and has no Ghidra symbol. This also hides the deceleration/brake path (value ~11818 unlocated).
4. Steer application: the max angle vs speed curve is known; how steer angle becomes heading change / yaw torque (and the inversion logic) is UNRECOVERED.
5. Kickflip / flip to attach law: rich values, but the torque/suction appliers timed out and the surface latch geometric predicate (raycast vs sweep, angle+distance+speed gating, attach vs death) is unrecovered.
6. Grip config field names: the redirect reads tunables at cfg+0x574..+0x588 (redirect gain at +0x588); these physics thread offsets are not yet mapped to named fmodel/SDK fields, so their numeric values are unconfirmed. +0x588 (the master approach fraction) must currently be hand tuned. (Partial progress, July 2026: the config object itself was confirmed live (FUN_155db04a0 resolves it from simObj+0x1ef0 via FUN_141ac1b60), but the return type of FUN_141ac1b60, needed to name the fields, is still unresolved. Discovering it via search_functions_by_name/xrefs is blocked by the Ghidra MCP’s 5 s read timeout on enumeration calls; a raised timeout or the function’s address would close this.)
7. Turbo impulse semantics: exactly how TargetSpeedModifier 7681 raises the cap and how the 1320 impulse is applied (axis, decay over MaxActiveTimeSeconds 2.0) is not decompiled.
8. Air control / diving bonus, underthrust, air freestyle laws: values known, all appliers timed out.
9. Reattachment & latch geometry: ReattachmentForceAmount 5000 over a 0.2 s window is known; the attach vs fall trace predicate and the post attach gravity reorientation rate are undocumented and undecompiled.
10. Jump struct completeness: 5 of the 6 FDelMarVehicleConfig_Jump values are absent from the export.
11. Drafting & rubberbanding application: values complete; neither force application path is decompiled.

Recently closed: the per surface gravity scalars (Section 4.11) were a dossier top unknown until shrezee recovered them from the native constructor: a worked example of the honest gap discipline paying off when a second evidence lane (Ghidra ctor) reaches what the first (fmodel export) could not.

7. Level delivery & preservation

(Expands the main archive’s Section 8.5. Firsthand datamine: shrezee.)

Three umap anatomy. Every track is built as three .umap files: TrackName.umap, TrackName_CYN_OOB.umap, and TrackName_SFX.umap: the main geometry, the canyon/out of bounds shell, and the sound FX layer. The split is consistent with all RR levels using level streaming and World Partition.

The plugin naming rule = playlist availability. A track’s plugin name encodes which playlists it ships in: competitive tracks (Racing + Ranked + Speed Run) use a DelMar + Codename plugin (e.g. DelMarApollo = Tilted Turnpike); Speed Run exclusive tracks use the bare Codename plugin, no prefix (e.g. Apollo = Tilted Turns, Snap = Pleasant Detour). The community’s “Apollo2 / Snap2” labels name real tracks but not real plugins; the second track just lives in the bare codename plugin. Full detail + the full circle rationale in the main archive’s Section 8.4.

On demand delivery (and the “empty plugin” illusion). The base game install contains no Rocket Racing level content. The .umaps that once lived under DelMar/Levels were removed from the install, leaving descriptor only plugin folders, which is exactly what a CUE4Parse style parser detects and reports as “empty” (a plugin descriptor with no maps). Each track instead downloads on demand the first time it is played, arriving as a four file bundle (.pak, .ucas, .utoc, .sig) under %LOCALAPPDATA%/FortniteGame/InstalledBundles/PersistentDownloadDir. Those bundles are encrypted with the game’s main AES key.

Preservation implication (time critical). Archiving RR levels means capturing the InstalledBundles downloads per track, before the October 2026 shutdown. Once the servers stop serving the bundles, the levels are gone even for players with the game still installed. Dumping the public fortnite-api.com/v1/playlists endpoint (which still exposes the full Playlist_DelMar_<codename> naming scheme, including the unreleased Challenge/Death Race/Tutorial playlists) is the cheap companion capture.

On the .usmap and property export. DelMar .uassets need a matching .usmap (mappings file) to deserialize typed properties; without one, fmodel/CUE4Parse read package structure but not values. A property level export did succeed on an earlier build (July 7, 2026, the source of several TrackSelectV2 property dumps), while a reattempt on the current build was blocked by a missing .usmap; where a value here is cited from raw structure or SDK layout rather than a clean JSON dump, that is why.

8. Reproduction methodology: how shrezee did it, so others can extend it

This reconstruction is reproducible. The method, in the order it was applied:

1. Live Ghidra on the unpacked 37.51 image (behaviour). The primary behavioural source. The unpacked Fortnite 37.51 executable was loaded into Ghidra and 7,255 DelMar functions were named. The working rule: decompile the impl, not the exec*/OnRep_* thunk. The thunks are UFunction/replication glue; the logic is one hop past them. From there, follow calls and xrefs for inlined logic. The vehicle call stack to walk is AFortPhysicsPawn → AFortAthenaVehicle → ADelMarVehicle. This is how the core redirect FUN_155da08c0 was recovered line by line, and how the native constructor gravity/drive values (Section 4.11) were read off constructor store instructions at their exact addresses (0x15BD03073, etc.). ~800+ functions were decompiled to C under docs/decomp/ (the phys_* files are the physics core). The honest limit of this lane: vtable dispatched per corner appliers (the vehicle+0x2458 sim vtable and UVehicleSimSuspensionComponent VFT @173a22eb0) and several force law functions (jump, kickflip, suction, underthrust) timed out or were unreachable, which is why those mechanics are marked UNRECOVERED rather than guessed.

2. fmodel value export (tuning numbers). All tunable values were exported with fmodel (built on CUE4Parse) to JSON, chiefly DelMarVehicleConfig_60Hz.json (the BP CDO storing per field deltas over the native container) and BodySetup_SportsCar.json / BodySetup_SUV.json. Where a value was absent from the export (a native default not overridden by the BP), it was recovered from the constructor in lane 1; the two lanes are complementary, and the seams between them are documented (e.g. native MaxBaseForwardSpeed 7496 vs BP override ForwardMaxSpeed 12000).

3. The 37.51 SDK dump (types / offsets / signatures). A Dumper7 CppSDK (*_classes.hpp / *_structs.hpp: human readable layout, offset+size, no values) plus the Dumpspace JSONs (StructsInfo, ClassesInfo, FunctionsInfo, EnumsInfo, 40-115 MB; always grep/offset targeted, never full read) and the IDAMappings/*.idmap. This lane gives the inheritance chain (Section 3.1), the config struct family (Section 3.2), and the replicated state layout (Section 3.3), and it anchors every Ghidra offset to a named field where the layouts line up.

4. Web cross check (does it match how it played). Patch notes, pro/creator guides, speedrun.com technique writeups, and Epic’s own UEFN device documentation were used to confirm that a recovered value produces the observed behaviour, and to surface conflicts (Section 5) where the community’s numbers and the config’s units cannot be reconciled.

5. The three way discipline. The master dossier (rr-dossier.md) is 3 way cross checked (web + fmodel + Ghidra + SDK); the per mechanic spec (surface-locomotion.md) splits every field into CONFIRMED value vs PENDING recovery; and the implementation blueprint (rr-implementation-blueprint.md) reconstructs the per substep tick from disassembly while rigorously separating EXACT (byte recovered) from UNRECOVERED. Every unrecovered law is a flagged evidence gap, never a filled guess: “No values were guessed; every unrecovered law is flagged above rather than filled.” [rr-implementation-blueprint.md:37]

Extending it. The clearest next steps are all in lane 1: with a responsive Ghidra session, dump the vehicle+0x2458 sim vtable (esp. the +0x380 / +0x1038 per corner apply slots and the integrate forces slot) and the UVehicleSimSuspensionComponent VFT, then decompile 0x15baf07f0 (jump), 0x141d91040/0x141d91070 (kickflip + suction), and the drive update function that writes simObj+0x1900 before the redirect. Those closures would resolve top unknowns #2, #3, #5, #7, and the suspension/counter gravity appliers.

Tooling (ShrezesUverse). shrezee’s public tooling that operationalizes this work: UEFN_RocketRacing_TrackConverter (revalidates broken/delisted RR community tracks so they load again in UEFN) and UEFN-Rocket-Racing-Asset-Pack (the full DelMar content surfaced in UEFN, published July 1, 2026). See the main archive Section 7.2 / Section 21.7 for details.

9. How this maps to the main archive

Compiled for the Rocket Racing Global Archive. Reverse engineering, datamining, and reconstruction: shrezee. Build Fortnite 37.51. Every technical claim carries a source and a CONFIRMED / INFERRED / UNRECOVERED status; the gaps are documented deliberately, in shrezee’s “gaps marked, not filled” discipline, for a mode Epic deletes in October 2026.