Every VTV on the roster page, resolved by id

The page listed 34 of the 38 vehicles in the resource file. The four
missing were community variants, and I had written down that they shared
another vehicle's mapping streams. They do not - they have their own, of 17
to 33 records. The decoder just could not find them.

Streams are stored as resources named plainly L4 and Thrustmaster, so
nothing in a stream says whose it is. The old decoder guessed by taking the
nearest preceding vehicle name in the file, which works while vehicles are
laid out one after another and fails quietly when they are not: it lost vole
outright and mis-attributed four blkr variants.

The file answers exactly if asked properly. A vehicle's ControlsMappings
List holds the resource ids of its two streams. Ids are not quite positional
- this file leaves 53 and 56 unassigned - so the directory walk is aligned
against RPL4TOOL -l, skipping the ids the listing marks Not Used. That gives
1077 ids with zero size mismatches, and every stream lands on its owner.
Subsystem names now come from each vehicle's own Stream of N Subsystems,
checked against the count in its header instead of being pattern-matched out
of the bytes.

Nothing already verified moved: lepton, dark, blkspk and neut decode exactly
as they did when checked against the 4.10 retail file, blkspk still putting
its third booster on the thumb-high in preset 4 and dark still spending
preset 5's HORN slot on its second demo pack.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-08-07 10:11:00 -05:00
co-authored by Claude Opus 5
parent b3ed7bc141
commit 17bbcb2049
2 changed files with 82 additions and 21 deletions
+30 -5
View File
@@ -214,7 +214,7 @@ resource by name: `"L4"` for the pod RIO, `"Thrustmaster"` for the stick
appear six times with six different targets.
**Every VTV in `assets/RP411/RPL4.RES` ships a full six-preset table, for
both the RIO and the Thrustmaster** — 34 of them as of the resource file
both the RIO and the Thrustmaster** — 38 of them as of the resource file
promoted from the airlock archive (see §8). Decoded, the *lepton* (two
boosters, one chute, unarmed) reads:
@@ -369,7 +369,32 @@ simply been renamed out of reach. `disk` remains the one genuine orphan: a
panel layout with no vehicle behind it in any resource file, and no entry in
the console's own config either.
Four of the eight community variants have a `ControlsMappings List` but no
mapping streams of their own; they reference another vehicle's by resource
id, so they carry no preset table of their own and are absent from the
roster page.
### Reading the file by id rather than by proximity
Every vehicle in the file has its own mapping streams — 38 of them, all on
the roster page. An earlier pass claimed four of the community variants
shared another vehicle's streams; that was wrong, and worth recording
because of *why*.
Streams are stored as resources named plainly `L4` and `Thrustmaster`, so
nothing in the stream itself says which vehicle it belongs to. The first
decoder guessed: it took the nearest preceding vehicle name in the file.
That works while vehicles are laid out one after another, and quietly fails
when they are not — it lost `vole` outright and mis-attributed four of the
`blkr` variants, whose streams simply do not sit where the guess expected.
The file answers the question exactly, if asked properly. A vehicle's
`ControlsMappings List of 2 elements` holds the **resource ids** of its two
streams. Resolving an id needs the id table, and ids are not quite
positional — this file leaves 53 and 56 unassigned, and the listing marks
them `Not Used`, so a plain walk of the directory drifts by two from there
on. Aligning the walk against `RPL4TOOL -l`, skipping the unassigned ids,
gives an exact id→resource map: 1077 ids with **zero** size mismatches.
Subsystem names come the same way, from each vehicle's own
`Stream of N Subsystems`, checked against the count in its header rather
than pattern-matched out of the bytes.
The lesson is the ordinary one: the format had an explicit answer, and the
first decoder inferred one from layout instead. Everything the guess got
right, it got right by luck of ordering.