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:
+30
-5
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user