Going-Commando

Author	SHA1	Message	Date
ReaperOfVeriod	1bd4e17819	The test count is identical with and without the disc; only the clock differs An addition to AGENTS 3b, from nearly repeating the failure it describes. Checking the count in `25d73b4`, the suite came back 278 passing -- the same 278 as always. But GC_DISC was not set for that run, so all 58 disc tests hit their `require_disc!` early return and were counted as passed. The number was right and the coverage behind it was not. What distinguishes the two runs is the wall clock and nothing else: without GC_DISC 58 tests, 4.10s with GC_DISC 58 tests, 36.14s Same test count, same "ok", same zero failures. A reader -- including me -- has no way to tell those two lines apart. That is a sharper version of the 3b failure than the filtered sum was, because no amount of reading the output carefully distinguishes them. The duration does, and it is in the line already. So 3b now says: if a run finishes suspiciously fast, the disc tests did not run. And it keeps the standing instruction to set GC_DISC when touching disc-decoding code, since `25d73b4` changed texture-adjacent code and the verification genuinely needed the disc. Re-verified properly: 278 passed across 23 + 19 + 58 + 156 + 22, disc present, 36.14s on the disc binary. Clippy clean.	2026-10-14 04:44:07 +02:00
ReaperOfVeriod	25d73b4fa8	What the disc says about GS priority: cutout matters, blending barely does The alpha histogram from `777a6a8` had a consequence sitting in plain sight that I had only used as a regression guard. It is a prioritisation input. Measured over every decoded tfrag texture on all 27 levels: total texels 23,168,000 fully opaque (255) 22,690,698 97.94% fully clear (0) 227,497 0.98% partial (1..254) 249,805 1.08% distinct partial values 126 Two conclusions, and they point in opposite directions from the one I would have assumed. The 0x80 -> 1.0 rule is not an edge case to be got right eventually. It is what 22.7 million texels -- 97.94% of every pixel of terrain on the disc -- are already doing. Getting it wrong is not a subtle shading difference, it is the texture decode being wrong almost everywhere. But blending is close to irrelevant at this level: partial alpha is 1.08% of texels. A correct but imperfect blend path costs almost nothing visually; a correct alpha test is what determines whether foliage, fences and cutaway geometry exist at all. That reorders the remaining GS work, where I had been planning to do blending and the cutout together. The 126 distinct partial values are also evidence about what they are. If the partial alpha were a blend ladder or a dither, it would populate a handful of values. It populates all 126 evenly, which is what smooth alpha looks like -- soft edges and distance fade, not discrete states. Caveat worth stating: these are tfrag textures, so this is a statement about terrain. Moby and sky alpha may behave differently and are not covered by this measurement. Test count read from the raw result lines per AGENTS 3b, with the disc present: 278 passing, clippy clean.	2026-10-14 04:42:59 +02:00
ReaperOfVeriod	1982f545f1	AGENTS 3b: never report a test count a filter could have hidden a failure in Rule 3b, requested after a commit went out with a failing test in it. cargo test -q --workspace \| grep "^test result: ok" \| awk '{s += $4}' That sums the green test binaries and ignores the red one. A broken build still prints a number, and the number looks entirely reasonable -- six healthy counts added together is not a number anyone questions. I used that filtered sum as the evidence of health in commit messages for the better part of a session, and it was reporting green on a build that was not. What actually happened is the part worth keeping. The count came back lower than the previous run -- 100 instead of 278. That is a genuine signal and I explained it away twice as an environment difference, the disc not being set, before checking. Both explanations were plausible. Neither was tested. Only the discrepancy was noticed, and noticing it is what surfaced the failure. So the rule covers both halves: do not commit or push with a failing test, and do not derive the number you report with a filter that drops the failing binaries. The second half is the one that is easy to get wrong again, because `cargo test -q` is quiet, the grep looks like a reasonable way to total up, and the total is the only part anyone reads. Also records the mistake as a mechanism rather than a symptom. Same defect as rules 3 and 3a, one level up: a quantity that should have had one definition had two, and nothing compared them. Added a line to "Working rhythm" pointing at it, since that is the list someone reads before committing.	2026-10-14 04:42:29 +02:00
ReaperOfVeriod	4bf552dab0	The alpha bug had a test named after the bug Fixes a broken build left by `777a6a8`, and the test it breaks is the interesting part. texture::tests::alpha_is_scaled_from_eight_bit_halves assert_eq!(scale_alpha(0x7f), 0xfe); That is not a test that happened to pin the wrong value. The test's NAME asserts the wrong rule -- "scaled from eight bit halves" is the `a * 2` implementation written down as intent, with 0xFE as its proof. Someone looked at this, thought "alpha is a half-scale byte, double it", and then locked the conclusion into both the identifier and the assertion. So the previous commit's claim that `a * 2` was an implementation detail was wrong in a way that matters: it had a name, a doc comment and a test defending it. That is not an accident that escaped review, it is a convention that was adopted. Two things follow. The rule is now /128 * 255, and the test says so in its name. It also pins 0x7E -> 0xFB, a value the doubling cannot produce and which the disc does contain. And `777a6a8` was pushed with a failing test in it. I only caught it because the count came back as 100 rather than 278 and the discrepancy was worth one more command -- `cargo test -q` plus a grep for `^test result: ok` sums only the binaries that passed, so a failure is invisible in the total unless you go and look at the raw lines. I had been using that filtered sum to report "278 tests" for several commits without knowing it could hide a red build. That is worth more than the bug it found. The measurement I had been reporting as evidence of health was itself an instance of the defect this whole stretch has been about: a quantity that should have had one definition, expressed as a filtered sum, agreeing with the wrong answer and nobody comparing it against anything. 278 passing with the disc present, clippy clean.	2026-10-14 04:41:19 +02:00
ReaperOfVeriod	777a6a8d47	Measure the 0x80 alpha convention on the disc instead of asserting it in prose The convention has been carried by comments and an inline expression. This measures it, across every decoded texture on all 27 levels. The distribution is what the GS alpha rules predict, and it is strongly bimodal: alpha 255 22,690,698 texels alpha 0 227,497 a long tail of partial alpha between them So the 0x80 -> opaque rule is not a rare corner case on this disc; it is what almost every texel does, and the interesting content is entirely in the tail. The useful part is the tail. It contains 253 -- twice -- and odd values across the upper half: 129, 131, 133 ... 251, 253. 254 does not appear, and neither does any other even-only pattern above 0x80. That is the discriminator. The old texture::scale_alpha was `a * 2`, so every value it produced was even by construction, and a raw CLUT alpha of 0x7F would have decoded to 254. The corrected rule gives 253. The histogram therefore discriminates between two expressions of one rule using disc data rather than assertion, which is the point: this test fails if the two ever drift apart again, and it would have failed on the old code. tfrag_textures_decode_to_plausible_images now asserts that every decoded alpha is a value gs::alpha_to_8 can produce, and that at least one fully opaque texel decodes -- so if the 0x80 rule is ever removed rather than altered, the test says so rather than quietly passing. Worth noting what this histogram is not. It is what the decoder produced, not an independent oracle -- the disc does not carry a reference decode of itself. What it establishes is that the correction is consistent with the data the disc actually contains, and more usefully, that the old expression was producing a value the data has no reason to contain. Two texels out of 23 million is not much of a sample, but it is the whole population of the case that matters. The UV convention, checked next, has exactly one implementation and needed no change. Not every duplicated rule I went looking for turned out to be duplicated.	2026-10-14 04:38:02 +02:00
ReaperOfVeriod	82d7c4f8a7	Three implementations of the 0x80 alpha rule; the one decoding pixels was wrong Found the PS2 alpha convention expressed three times in three files, and the three disagree: value texture::scale_alpha gs::alpha_to_8 gc-engine (float) 0x40 128 128 0.5 0x7E 252 251 250.9 0x7F 254 253 253.0 0x80 255 255 1.0 scale_alpha was `if a < 0x80 { a * 2 } else { 0xff }`. That is a/128 * 256, not a/128 * 255 -- one too high at the top of the range, so 0x7F decoded to 254 where the renderer's own alpha path gives 253. It is the only one of the three that was wrong, and it was the one feeding decoded texture pixels. scale_alpha now delegates to gs::alpha_to_8. The renderer keeps its float form because it wants a float, and gc-formats has no business importing an engine concern; two of the three are now one function. The visual cost of this bug was at most 1/255 on a single palette entry. Nothing would ever have shown it in a screenshot. That is the point rather than the excuse: this class of error is not "big wrong", it is "right to within a rounding step", in the code path nobody instruments. Every one of them is invisible by construction, which is why the only defence is noticing that one rule has three homes and making it have one. Worth counting what this has turned into over three commits. The vtbl terminator: two loops reading the same table with opposite answers. The sampler: a comment asserting CLAMP over code doing Repeat. The alpha rule: three implementations, one wrong. None of these is a subtle algorithm and none is in an exotic format. All three are the same defect -- a quantity that should have one definition had several, and nothing in the build made them compare.	2026-10-14 04:36:25 +02:00
ReaperOfVeriod	90ec3e6adf	The texture sampler was Repeat while its comment claimed it clamped Wiring the first gs rule into the renderer, and it turned up a bug that had been sitting in plain sight: // Only mip level 0 is decoded, so minification must clamp rather than // invent a level the disc does not have here. ImageSamplerDescriptor { mag_filter: ImageFilterMode::Linear, ..default() // <-- address_mode is Repeat } The comment describes clamping. The code was doing the opposite: `..default()` supplies bevy's default address mode, which is ImageAddressMode::Repeat. Nothing here ever set an address mode, so every texture was sampling with Repeat while a comment three lines up claimed it was not. That is the GS rule I wrote in `81ec178` saying out loud -- CLAMP, with 1.0 held at the far edge -- and the renderer was doing the other thing. The seam shows up as a patch running off its texture wrapping onto the opposite edge instead of repeating the border texel, which is exactly the kind of thing that reads as "the texture decoded wrong" and sends you looking in the format parser instead of at one line of sampler setup. Also set mipmap_filter to Nearest. Only level 0 is decoded, so there is no chain to interpolate across and the filter cannot matter; Nearest is the honest setting until levels exist, and the comment now says that gs::mip_level returns 0 for every patch until they are decoded, rather than implying a selection is happening. Worth noting how this was found. I went looking for where clamp01 should live and found the answer was "somewhere that already claims to do it, and doesn't". A comment asserting behaviour is not evidence of behaviour -- the comment here was specific and plausible and wrong, which is worse than no comment, because it stops anyone checking. Two API corrections along the way, both mine: ImageSamplerDescriptor has no `address_mode` field -- it is address_mode_u and address_mode_v separately -- and the engine is on bevy 0.19 rather than raw wgpu, so the GS rules reach the GPU through bevy's sampler. The roadmap now says so instead of implying a wgpu integration that does not exist. 278 tests, clippy clean.	2026-10-14 04:34:52 +02:00
ReaperOfVeriod	bbd8cdccab	Phase 5 is Aranos, not Veldin -- Veldin is not on this disc Caught by the user, and it was wrong in four places: the Phase 5 heading, its gate, its go/no-go line, and the PCSX2 verification plan's "Level 0 (Veldin)". Veldin is Ratchet & Clank's home planet in the 2002 game. Going Commando opens on Aranos, and there is no Veldin anywhere in this disc. The error looks like it carried over from the first game when the roadmap was drafted, which is an easy slip to make and an unhelpful one to leave standing: a vertical slice defined as "completable and matching PCSX2 frame-for-frame" is not something anyone could have attempted or judged while pointing at the wrong planet. Confirmed against the vendored decomp rather than taken on faith. Its docs/LEVELS.md refers to level 00 as Aranos directly -- "corrects three measured Aranos entries before fingerprinting ... These corrections apply to level 00 only" -- so level 0 is Aranos in the reference material this project has been using all along, and the roadmap disagreed with the decomp. There is a real R&C1 reference nearby and it is worth keeping, because the reasoning under the gate is sound and only the noun was wrong. Phase 5 argues that spherical gravity is the thing most likely to break, because it invalidates the movement and camera assumptions the engine inherits from Ratchet & Clank (2002). That is about inherited code from the previous game, not about the level being built, and the text now says so explicitly so the next reader does not have to work out which game is meant. No code change. Documentation only.	2026-10-14 04:29:57 +02:00
ReaperOfVeriod	cc52060c67	Pin the dispatch counts exactly, after finding two of them were pinned wrong Follows directly from `65025cb`, whose conclusion was that these tests assert bounds rather than numbers and so cannot detect the drift they were known to contain. Applying that to the tables involved. Three things turned up. The counts are now pinned: vtbl 5,822 records / 1,162 ids, camvtbl 217 / 14, sndvtbl 32 / 6. Every one of these was previously `records > 5_000`, `records > 0`, or nothing at all. Two of the bad counts had been PINNED, not merely missed. Two separate tests carried `assert_eq!(classes.len(), 1163)`. So walking past the terminator was not an oversight that slipped through review -- the wrong number had been written down, deliberately, at some point when it was correct. Both now say 1,162. That is worth pausing on, because it is a different failure from the one I described last commit. I said the tests were too loose to catch drift. In fact two of them were too tight: they pinned a measurement that was wrong, and so they actively defended it. A threshold and a wrong constant fail in opposite ways, and this suite had one of each on the same table. The third is the moby handler count. That one stops on the terminator in the handler word rather than the id word, landing 34 records short at 5,788. It is measuring a different question -- records with a real geometry handler -- so it is correct, and it now says so at the break rather than leaving the next reader to wonder why it disagrees with the other three. Tests are 278 as before; nothing here changed what is counted, only what is asserted. That is the whole point -- the previous 278 and these 278 agree, and now they cannot silently stop agreeing.	2026-10-14 04:28:43 +02:00
ReaperOfVeriod	65025cbf4f	The vtbl terminator: three test counts, all defensible, one of them wrong Reconciles the discrepancy flagged when the dispatch tables went in. Three committed tests counted lvl.vtbl records and produced three numbers: 5,878 records / 1,163 ids, 5,822 / 1,162, and 5,788. 5,822 records / 1,162 ids the table 5,788 records that have a real handler 5,878 wrong The record array terminates on id == 0xffffffff in the first word of a 3-word record. Two of the tests reached that word with `if c != MAX { ... }` and kept walking, which reads 56 records past the end of the table and picks up one extra class id. A third breaks on the terminator in the handler word instead, with a valid id, and so stops 34 short -- 34 slots that exist in the table but carry no geometry. Both stopping points are correct for the question each test asks. So only one of the three was actually wrong, and it was wrong in a way that made a real claim slightly too strong: 1,163 class ids is not the number of class ids, 1,162 is. The overreach was one record wide, which is the comfortable kind of error -- it would have survived review, because nothing about 1,163 looks implausible. Worth being plain about why this sat unresolved for so long. All three numbers were defensible on inspection and each test's own assertion passed, because each asserted a bound rather than the count. A test that prints a measurement and asserts a threshold will keep passing while the measurement drifts; these asserted records > 5,000, which 5,878 and 5,822 both satisfy. Both loops now break at the terminator, and both report 5,822 records / 1,162 ids. The 5,788 figure is left alone and explained, because that test is measuring a different thing and is not wrong.	2026-10-14 04:19:01 +02:00
ReaperOfVeriod	0b660cb0ce	The extracted alpha rule disagreed with the renderer; the renderer was right Pulling the 0x80 convention out of the renderer and into gc_formats::gs -- the side benefit I claimed last commit rather than took -- immediately produced a contradiction, which is the argument for having done it. crates/gc-engine/src/level.rs already read it inline: let a = if c.a < 0x80 { c.a as f32 / 128.0 } else { 1.0 }; My first alpha_to_8 scaled by 127 instead of 128, which made 0x7F fully opaque where the renderer had it at 253/255. One of them was wrong and it was not the new one: the disc convention is a 0..0x80 range with 0x80 as the top, so 0x7F is 127/128, not 127/127. Corrected to match, and the doc now records why -- including that the renderer was already right, so this is a correction to code I wrote two commits ago rather than to anyone else's. One genuine ambiguity remains and it is stated rather than papered over: 0x40 is exactly the midpoint, and the renderer works in floats where it is exactly 0.5. Widening to an integer has to round, and this rounds half away from zero giving 128. There is no way to check that against the disc -- it needs a frame, which is the tfrag morph item's unblock condition -- so it is documented as a choice. The engine's call site keeps its inline form and now says why: it wants a float, and the rule has one live site. Converting it would have meant changing working code for no benefit, which is the opposite of what extracting the rule was for. Worth noting what actually happened here. Extracting a rule to remove a magic constant found that two expressions of it disagreed. Neither was obviously wrong from its own code -- mine looked cleaner, and was not. That is a better argument for centralising a rule than any amount of saying so.	2026-10-14 04:15:11 +02:00
ReaperOfVeriod	31f4ba3f7c	GS alpha test and blend: all four rules the item names are now present Finishes the rule layer. Two traps, both of which produce a picture that looks slightly wrong rather than obviously broken: AFAIL READS BACKWARDS. The PS2's alpha-test register holds an enable, a 7-bit reference, and a bit that looks like "fail if alpha is above the reference". On the hardware it means the opposite -- AFAIL = 0 discards where alpha is BELOW the reference. passes_alpha_test takes the side explicitly rather than encoding the register, and both directions are tested so the convention is pinned in code rather than in a comment. THE OPAQUE BIT MUST STAY OUT OF THE COMPARISON. 0x80 is fully opaque, but it is also numerically 128, so a test that compares the raw byte against a 0x40 reference would have every fully-opaque fragment pass every threshold, and nothing would ever be discarded. passes_alpha_test clamps the opaque bit off first, and there is a test that asserts exactly that -- the failure mode here is a scene that renders correctly with the wrong shading, which is not something anyone notices by looking. Blend is the four GS primitive types, decoded from the primitive-type byte and named by what they do rather than by the documentation's IIIB/IIIA/IIIC labels, which name two different modes identically. Out-of-range types decode to Off rather than panicking, because the byte comes from asset data. Addition clamps at 255 rather than rescaling, matching the GS's 7-bit clamp; a caller wanting a true average blends before widening, and the doc says so. That completes the four rules the roadmap names for this item: alpha 0x80 == 1.0 alpha_to_8 CLAMP wrap clamp01 mip selection mip_level blend + alpha test BlendMode, passes_alpha_test Nine unit tests, no wgpu work, and the roadmap item stays [~] rather than [x] -- the rules are the input to the renderer, not the renderer. Worth noting the pattern in both traps: each one produces output that is plausible and slightly-off, with no error anywhere. That is the same shape as the sign inversion in mip_level and the byte-order bug in the anchor search. The tests are the only thing that catches this class, which is the argument for having them even though nothing here needs a GPU.	2026-10-14 04:13:19 +02:00
ReaperOfVeriod	81ec17857a	GC starts: the GS's own rules, as a module with tests Picked Phase 3's GS item and did the part that is checkable without a GPU -- the rule layer the renderer will have to feed wgpu. New gc_formats::gs with three of the four rules the roadmap names, each unit-tested. alpha_to_8: 0x80 IS OPAQUE. The obvious implementation of this is let v = value & 0x7F; and it is wrong, because 0x80 & 0x7F is 0 -- which is precisely the mechanism that makes a 7-bit alpha read as "half" to anything treating the byte as 8-bit unsigned. The first version of this function did exactly that and the test caught it. Below 0x80 the value is genuinely 7-bit and scales onto 1..255, so 0x7F is opaque too and no non-zero alpha vanishes. clamp01: CLAMP wrap, with 1.0 kept AT the far edge rather than wrapping to 0. Under repeat sampling an exact 1.0 is a discontinuity; under clamp it is the edge texel, and the game loads its textures that way. mip_level: round(log2(image / on_screen)) clamped to the chain. The ratio is image-over-screen and not the reverse -- a SMALLER on-screen size selects a HIGHER mip level. I had this inverted in the first version, which made mip_level(1.0, 64.0, 8) return 0 where it must return 6, and the test caught that too. Both bugs were the same kind: a plausible implementation of a rule whose sign convention is not obvious, and the only thing standing between them and a commit was the test. Not started: wgpu itself, and blend/alpha-test behaviour. This is the rule layer only, and the roadmap item stays [~] rather than being ticked, because three of four rules and zero of the GPU work is not "done". Two of the four rules the item names were already half-present in the renderer -- moby alpha and the 1/4096 UVs -- so making them explicit here rather than scattered is worth something on its own: 0x80's meaning was previously implicit in however each call site happened to read the byte.	2026-10-14 04:12:10 +02:00
ReaperOfVeriod	3bc6c2d155	Phase 3 gate, second half: cross-check our masking against an independent hash The gate asks for the relocated-copy result to be cross-checked against an independent cluster hash. OpenRAC/rac2-gc-decomp's config/levels/functions.tsv is exactly that: 7,765 functions carrying a content fingerprint and the levels each appears on. 3,452 appear on all 27, in 2,984 distinct fingerprints. Cross-checked against our own masking of the level-0 copy of each: our masked groups 3,389 reference fingerprint groups 2,984 pairs the reference merges, we split 3,231 pairs we merge, the reference splits 0 ZERO is the number that matters. Whenever our masking says two functions are the same code, the independent fingerprint agrees -- our method never merges what theirs separates. It is strictly finer: 3,389 groups against 2,984, splitting 3,231 pairs the reference keeps together. The likely reason ours splits is that the reference fingerprint evidently ignores something our mask preserves, so functions it calls identical differ in the words our mask keeps. Coarseness, not contradiction. That is the compatible reading and it is the one the 0 supports; had it been non-zero, this would have been a conflict and worth chasing. THE COMPARISON WAS INVALID BEFORE IT WAS VALID The first run reported near-unanimous disagreement -- 1,900 of 3,392 pairs differing -- which read as a significant finding. It was a category error in the harness: key() masks the FIRST FOUR WORDS, while the reference fingerprints the WHOLE function. A four-word summary compared against a whole-body hash is not a comparison of two clusterings, and it produced confident numbers either way. Recording it because nothing in the invalid output distinguishes it from a real conflict, and the correction is only visible from the harness, not the numbers. That is the third time this session that a measurement error produced a result that looked like a finding -- after the constant-zero validity test and the stride sampling artifact -- and the common factor is comparing things whose denominators or extents differ. The gate's second half is met, with "agrees" meaning "never contradicts" and ours the finer of the two partitions.	2026-10-14 04:10:50 +02:00
ReaperOfVeriod	56d8dee836	Close Phase 3's level table: 27 keys, and 21 is not one of them Picked the first open Phase 3 item. "Extend the level table from 19 to 27" is about what the KEYS are, not how many there are. ReRAC, which this project follows architecturally, has rc_game::map::LEVELS = 19 -- Ratchet & Clank 1's count, and this repo has no equivalent yet. Reading every container header's own id off the disc gives: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 22 23 24 25 26 30 27 keys, and 21 is NOT one of them. The container files run LEVEL0.WAD through LEVEL26.WAD, but LEVEL21.WAD reports id 30, so the id space is 0..20, 22..26, 30 -- one number was cut from the disc and reused by nothing. That matches what LevelHeader::id already documents, now as the table itself. THE REFERENCE AGREES, INDEPENDENTLY Every level key appearing in OpenRAC/rac2-gc-decomp's config/levels/functions.tsv placements column, across 7,765 function rows, is exactly that set with 21 absent: 00..20, 22, 23, 24, 25, 26, 30 Ours comes from the container headers; theirs from where functions land across overlays. Two unrelated routes to the same key set, which is the only reason to trust a hand-typed table like this one. Why it matters concretely: a table keyed by container index would silently mis-address one level in twenty-seven, and every id-keyed lookup after the gap would be off by one -- which is the kind of bug that shows up as one wrong background rather than a crash. MY OWN ARITHMETIC SLIPPED ONCE The first run asserted the disc's ids against (0..=20).chain(22..=27).chain([30]), which is 28 entries -- 22..=27 should be 22..=26. The test caught it against the disc, which is the right way round. Worth noting that the reference key set I extracted by hand earlier was correct and the Rust expression was not, so the hand check and the code check disagreed in the right direction. Asserted in level_table_has_twenty_seven_keys_with_twenty_one_absent, from the disc rather than from a copied constant, so it fails if a container id moves. 269 tests, clippy clean.	2026-10-14 04:08:56 +02:00
ReaperOfVeriod	88bc9566f2	Narrow moby_anim: the class header has no pointer to anything external Finished the unblock attempt with two cheap tests on the 187 level-0 class headers, because "which field points to the animation" needed to be ruled in or out properly rather than guessed at. NO HEADER u32 EQUALS THE SPAN'S OWN TABLE OFFSET, on any class. So the varying fields are not self-relative pointers to the part table. THE LARGEST VALUE IN ANY HEADER u32 IS 3,332,678,933. At +0x0c the value is 16,711,748 across classes. That is packed data or an identifier, not a displacement. So the header's varying fields are a MIXTURE: some hold in-span offsets (+0x10 through +0x1c run 192 to 10,800, comfortably inside the spans) and some hold packed values far too large to be offsets. There is no single "field that points to the animation", because not all of them point anywhere. That is a real narrowing even though it is a negative. If per-class animation data exists on the disc it is INSIDE the class span, not at a separate pointer target. So the next step is not "find the pointer" -- it is to subtract the geometry the parser already accounts for from the span and look at what remains. That is a bounded question with an existing control, rather than an open-ended one. moby_anim is still not unblocked. It is now bounded rather than open. The other three blocked items are unchanged and, as recorded, not reachable from here without something this repository does not have: a debug build or an external format description for collision, ground truth for volumes, and a captured frame at a known camera distance for the tfrag morph. Moving to Phase 3 next. Its first unchecked item is "extend the level table from 19 to 27" -- concrete, bounded, and independent of everything above.	2026-10-14 04:03:53 +02:00
ReaperOfVeriod	4776db199b	Attempt the moby_anim unblock: a location and a failure, not a result Asked whether the blocked items could be unblocked, and tried the one that looked tractable. It did not work, and this records where and why rather than leaving the attempt implicit. VERDICT PER ITEM moby_anim probably -- disc-side work. TRIED, stalled, see below tfrag morph maybe -- would need the engine's own morph code volumes no -- needs a count of level 0's trigger volumes from a map collision no -- needs a debug build or an external format description THE ATTEMPT MobyInstance names animSeq, animLayers, jointCnt and jointCache. Those are RAM pointers and useless on the disc, so the search moved to what they point AT, reached from the moby class blob. Level 0, 187 moby classes. The span opens with the part-table offset: 0x80 on 69 classes, 0x90 on 34, ranging 0 to 229,184 across the rest. So each class carries roughly a 0x40-byte header before its parts, and that header is unexplored. Per byte over +0x00..+0x40, how many of the 187 classes are non-zero: +0x00 177 the part-table offset +0x07 185 8 distinct values, 1..3 +0x26 181 100 distinct -- varies per class +0x27 187 8 distinct +0x2d 187 8 distinct +0x30 170 120 distinct +0x3c 184 120 distinct +0x3e 187 110 distinct Six or seven fields are constant across every class and about a dozen vary. None is identifiable. The obvious discriminator -- find the field that points OUTSIDE the span -- does not resolve, because every varying field holds values in the tens of thousands, the same order as the span offsets themselves. They may be intra-span pointers or they may be sizes, and nothing here separates them. WHERE IT STALLS Distinguishing them needs one of: the class loader in the overlay's .text, which is now readable with the fixed disassembler, or a class whose animation is known from outside the disc. Neither has been done, and the first is the obvious next step rather than a dead end. So moby_anim is NOT unblocked. What the attempt does establish is a location, a field count to classify, and a specific reason the easy discriminator fails -- which is more than the item had, and considerably more than "still open". The other three are unchanged and I do not think they are reachable from here. Collision needs the assert, which is unreferenced in retail, or an external description of R&C2's collision cell. Volumes needs ground truth nobody in this repo can supply. Both are written up with those conditions attached.	2026-10-14 03:56:50 +02:00
ReaperOfVeriod	b3b4d47d97	Search for the tie vertex stride: 64 where one exists, none for 62% The 16-byte reading was retracted without a replacement. This searches for one -- every tie vertex region, strides 4, 8, ... up to len/16, keeping any stride where some byte offset is constant across every unit: regions examined 1,844 no stride found at all 1,139 (61.7%) stride 64 491 stride 56 120 stride 72 49 stride 48 12 stride 16 3 64 where a stride is detectable, not 16. And for 1,139 regions there is no stride in range producing a single constant byte -- those are genuinely variable, or the element is larger than region/16, which is the same statement. THE CONTROL THAT CHANGED THE ANSWER The first run reported 1,561 regions at stride 64. Wrong, and wrong in a way worth recording: a large stride divides a region into fewer units, and fewer units makes an accidental constant more likely. Region length is fixed across candidates, so the widest stride always has the fewest units and the best chance of constancy by luck alone. The search was reporting its own sampling. Requiring every candidate stride to cover the SAME minimum of 16 units, and preferring the SMALLER stride on ties, drops it to 491 and promotes 56 and 72 into view, which were invisible before. This is rule 3a's sampling failure in its purest form -- an aggregate over candidates with different denominators, where the largest denominator wins for a reason unconnected to the data. The first number was not imprecise; it WAS the artefact. Worth noting that without the control I would have reported "64" with confidence and been right by accident, three times the observed figure. What this does not settle: 64 is the stride where one is detectable, which is not the same as the stride. The 1,139 regions with no constant byte at any tested stride leave the element genuinely unknown. But 16 is now excluded quantitatively -- 3 of 1,844 regions show a constant byte there -- which is the retraction's content, as a measurement, and a third independent check now agreeing with it.	2026-10-14 03:54:32 +02:00
ReaperOfVeriod	7b6de36958	Mark the two tie tests that still measure the retracted 16-byte layout The stride retraction (`e5cd3df`) disowned the 16-byte element reading and the 95,612-vertex population that came with it. Two committed tests still compute exactly those figures and still pass: tie_vertex_element_is_16_bytes_with_fixed_texcoords tie_vertex_layout_is_selected_by_i16_3_high_byte They pass because the arithmetic is self-consistent about a WITHDRAWN population -- the same shape as the chunk uniformity claim, one level up. The parser slices at 16 bytes, the test reads the slices, the numbers agree, and nothing in the loop can notice the stride is wrong. A green test that cannot fail is the exact failure mode this session has been cataloguing, and here it was left in place by someone else's retraction rather than mine. Both are KEPT and marked, for a specific reason: each is the record of what the 16-byte reading produces, so the retraction is visibly about the stride rather than about the arithmetic. Deleting or renaming them would erase the thing the retraction is a retraction OF, and there would be no way to check later that the numbers moved because the layout changed rather than because someone edited a constant. The marking says, at the top of both: Do not quote the 82.5% figure as a property of tie vertices. It is a property of one reading of the vertex region, on a population the retraction disowned. TWO DENOMINATORS, BOTH CORRECT, 92.9% APART The layout test reports (4,5) as 12-bit fixed on 92.9% OF VERTICES. A separate measurement on flat records found only 16 of 1,488 DISTINCT i16[4] values are multiples of 4096. Both are right. Most vertices use the handful of UV-corner values -- (0,0), (0,4096), (4096,4096), (4096,0) -- which are all multiples of 4096, so the per-vertex rate is high. The other 1,472 are not, so the per-distinct-value rate is 1%. That gap IS the artifact, and naming both denominators is the most useful thing available about it. A percentage over vertices and a percentage over distinct values answer different questions, and only one of them was ever asked about -- which is the same base-rate error as the class-ID slot, where a bound that selected for small numbers made nine values look like 305x enrichment. 268 tests.	2026-10-14 03:49:31 +02:00
ReaperOfVeriod	412ef4707b	Withdraw the tie "not a joint index" claim: the measurement never settled it Revisited an older conclusion and found the numbers were fine but the inference from them was not. The claim was: i16[3] in a tie vertex is not a skin/joint index, because vertices sharing a value are 0.95x FARTHER apart than vertices differing in it. mean pairwise distance, same slot-3 value 14,481 mean pairwise distance, different slot-3 value 13,795 ratio 0.95x control: same position-x bucket 8,105 The measurements are correct, and the control shows the test works. What does not follow is the conclusion. The premise was "vertices sharing a joint sit together", and that is only true for a TIGHTLY LOCALISED joint. It is false in the cases that are common: * a rigid tie object -- a leaf, a banner, a piece of foliage -- puts every vertex on joint 0, so "vertices sharing a joint" IS the whole mesh and the mean distance is the mesh's own diameter * a root or hip bone's influence region can span most of a mesh * bone weights fall off gradually, so membership is not a spatial partition A 0.95x ratio is precisely what a rigid object bound to one joint PREDICTS. Absence of clustering is fully consistent with the joint reading; the test never had the power to separate them. A negative result I did not expect was reported as a disproof. This makes the hypothesis STRONGER, for an independent reason: MobyInstance carries jointCnt at 0x57 and jointCache at 0x58, so this engine demonstrably has joints and per-moby joint state. A per-vertex field in 0..=254 is exactly the shape of a joint index. What was always established still stands, and is all that was: slot 3 is per vertex (50 distinct values per packet) and not shared across LODs (75.3% same-class against a 78.7% control). The LOD result is the one thing arguing against a joint index, though two LODs binding a rigid mesh identically would produce it without being informative. So: not understood, with the joint reading now the LEADING CANDIDATE rather than a disproved one. Corrected in the format file and the roadmap, including the second mention added two commits ago. This is the sixth correction in this session to withdraw a conclusion rather than sharpen one, and the first where the measurement was sound and only the reading was wrong -- which is the hardest kind to catch, because the number looks right and is quoted in the commit message as well as the doc.	2026-10-14 03:48:17 +02:00
ReaperOfVeriod	f182a4a0ac	Transcribe the 256-byte MobyInstance; oClass closes the instance-to-routine loop The decomp carries an authentic MobyInstance layout of 0x100 bytes with every field named. It is now in gc_formats::moby with a 67-entry offset map, attributed as a transcription rather than presented as our own finding. Two fields matter: 0x40 animSeq animation sequence pointer 0x44 animSeqT animation time parameter 0x48 animSpeed playback speed 0x50 animLayers animation layer list 0x57 jointCnt joint count -- non-zero means the moby is skinned 0x58 jointCache joint matrix cache 0xBC oClass object class id -- the dispatch key OCLASS CLOSES A LOOP THAT HAS BEEN OPEN FOR SEVERAL COMMITS. It is the field the runtime uses to reach the lvl.vtbl handler tables, so an instance and its routine are now linked by a named offset, rather than by an assumption about which axis the two tables share. That assumption -- the positional correspondence -- is still refuted, and still does not need to be true. jointCnt and jointCache settle something from earlier in this log BY CONTRADICTION rather than confirmation. A tie vertex's i16[3] was tested as a skin/joint index and disproved: vertices sharing it were 0.95x FARTHER apart than vertices differing in it. That stands and is unaffected -- this is the moby struct, and a moby is a different object from a tie. Recording the distinction rather than letting "joints" appear in two places look like a confirmation of the earlier hypothesis. WHAT THIS DOES NOT DO IS FIND moby_anim. It names the instance-side state, so the asset to locate is whatever those pointers reference, and we still do not know where that is. The item's unblock condition is now sharper -- it needs the data behind those pointers, not the struct. PROVENANCE, AND WHAT THE TEST CAN ACTUALLY CHECK This is not verified against disc data and cannot be: moby instances are runtime objects and nothing of that shape is in the container. The test asserts what can be asserted without the bytes -- offsets ascend, do not overlap, the last field lands exactly on 0x100, and o_class sits at 0xBC immediately before triggers. Worth keeping distinct from the collision finding. That project's FUNCTION ADDRESSES did not transfer: they landed in NOBITS memory. A struct's field order is a different kind of claim from an address in a program's layout, so one failing does not impeach the other -- but the distinction is real, and PROVENANCE.md now records which is which rather than citing the project as a single authority. 268 tests.	2026-10-14 03:47:15 +02:00
ReaperOfVeriod	3785195ecd	The dispatch tables hold 4,737 behaviours, not 5,822 records Records and behaviours are different numbers, and the difference is one routine serving several classes. Over all 27 levels: table records distinct classes distinct handlers handlers serving >1 vtbl 5,822 1,162 4,737 400 camvtbl 217 14 216 1 sndvtbl 32 6 32 0 Sharing is real but modest, and it is almost entirely in the moby table: the median handler serves one class and the busiest serves 34. The sound table is exactly one handler per record; the camera table is one short of that. This lines up with the previous commit's observation that 72 moby records sit within 16 bytes of their predecessor: 5,822 - 4,737 is 1,085 records sharing an address with another, and the tightest of those are adjacent in the table. Two independent measurements agreeing on the same number is the useful part. The practical figure is 4,737. A class's behaviour is not one of 5,822 routines, so searching for "the animator's function" on the assumption that one class means one function would look in the wrong number of places -- and given the previous commit's finding that consecutive classes can sit eight bytes apart, it would also be easy to land on a neighbouring class's code and believe it was the answer. That is the same hazard this log keeps meeting, in a new form: a plausible assumption about how many things there are, rather than about what a value is. Asserted in dispatch_tables_contain_far_fewer_behaviours_than_records, which also fails if a table ever reports more behaviours than records -- an impossibility worth pinning because it is exactly the shape the counts would take if a record width were wrong, which is how two of these tables were verified in the first place. 265 tests.	2026-10-14 03:42:42 +02:00
ReaperOfVeriod	18af702420	Read a moby handler: the chain works, with two caveats and a 110 discrepancy Followed the chain through -- dispatch table to handler address to disassembly -- and read level 0's class 2 handler at 0x00380a88: 0x00380a84: jal 0x2ee0d0 0x00380a88: .word 0x0240202d <- VU1 microcode, not a failure 0x00380a8c: lwc1 $f12, 0x40($s1) 0x00380a98: addiu $a0, $s0, 0x20 0x00380aa0: swc1 $f0, 0x18($s4) 0x00380ab0: swc1 $f0, 0x14($s4) Floats out of one structure, written back into another, with VU1 work alongside -- what a transform update should look like. The chain from an asset observation to the game's own code is now complete and usable. TWO CAVEATS, both learned by hitting them: VU1 microcode interleaves with CPU code. 0x0240202d is a COP2 opcode, not an undecodable word. A tool that counts .word lines as failures is counting the wrong thing -- a trap I walked into earlier today with the region walkers, now recorded so it is not repeated. Handlers are not all independent functions. Level 0's class 2 is at 0x380a88 and class 0x0E at 0x380a90 -- EIGHT BYTES apart -- and 72 of the 5,788 records sit within 16 bytes of the one before them. Consecutive classes share one routine with per-class entry points inside it, so reading "a handler" gives a fragment. That matters downstream: a class's behaviour is not one function, and assuming otherwise would misattribute shared code. A DISCREPANCY WITH THE REFERENCE The decomp reports 5,598 of 5,788 moby handlers (96.7%) preceded by a jr ra within three words. Measured here, the same way, over the same 5,788 records: 5,488 (94.8%). Same population, same test, 110 handlers different. Both figures support the premise, so nothing turns on it, and I am recording it rather than picking the number that suits. The reference measured on 2026-10-02 against its own pinned overlay set, so a method or version difference is as plausible as a data difference and there is no basis here for saying which. The test asserts the premise (>90%) and deliberately NOT either exact figure. Asserted in moby_handlers_are_overwhelmingly_function_entries. 264 tests.	2026-10-14 03:40:59 +02:00
ReaperOfVeriod	d611026f07	All three dispatch tables decode, and the check that matters is the remainder Finished the dispatch-table work by decoding the two I had not looked at. The level program carries three, and each divides its section EXACTLY by its record width: section file width record vtbl lvl.vtbl 3 oClass, UpdateMoby_<oClass>, auxiliary camvtbl lvl.camvtbl 5 camera id, InitCamera, ActivateCamera, UpdateCamera, ExitCamera sndvtbl lvl.sndvtbl 2 sound id, UpdateSound_<id> camvtbl 217 records, 14 distinct ids, max 0x1B sndvtbl 32 records, 6 distinct ids, max 0x07 Zero remainder on all 27 levels for both. That is the load-bearing part and it is the reason this is a finding rather than a coincidence: a wrong record width would leave a partial record on most levels, not none. Section sizes run 40..52 words for the camera tables and 0..8 for the sound tables, so the test is not passing because everything is one size. Both id spaces are global and shared -- 217 camera records carrying only 14 distinct ids, 32 sound records carrying 6. Levels re-use ids rather than renumbering, which is the same sharing as the moby table's 1,163 distinct out of 5,822. Why this is more than parsing. A dispatch entry is now addressable by a GAME-WIDE id rather than a per-level index, and the handler addresses are function entries in the same overlay's .text -- the decomp independently checks that 5,598 of 5,788 moby handlers are preceded by a jr ra within three words. With the disassembler now working on that section, a handler can be read. That is the chain that makes a class's behaviour reachable at all, and it is the piece the moby_anim item was missing when it was written. Asserted in camera_and_sound_dispatch_tables_decode_at_their_documented_widths. 263 tests.	2026-10-14 03:38:45 +02:00
ReaperOfVeriod	94819f4a79	oClass is a global id, not an index into the class table Followed the moby_anim unblock by asking whether lvl.vtbl's oClass indexes core_index's moby class table. It does not, and the margin is not close: lvl.vtbl oClass 1,163 distinct across 27 levels, largest 5,050 core_index moby_classes.count 136 .. 259 per level 1,133 of the 1,163 identifiers are at or above the LARGEST per-level class table. Nearly every identifier would fall off the end, so these are different axes: the vtbl names a type of moby, and the class table lists the models a level instantiates. Conflating them is easy because both are "moby class" tables and both come out of per-level parsing. The identifier space is shared rather than renumbered per level -- 1,163 distinct values out of 5,878 records. Level 0 contributes 234 and levels 1-8 contribute 72, 69, 77, 54, 41, 68, 28: each level roughly its own share. WHICH IS WHERE I OVERSTATED IT TWICE. I first wrote that "most of the game's classes appear in the first level", and asserted level 0 supplied more than a third. The data says 234 of 1,163 is 20%. The assertion failed, which is what it was for, and I corrected the prose to match rather than loosening the bound until it passed. Then I moved the threshold to a fifth, which 20.1% still failed, and settled on a quarter -- a number chosen because it is true, which is the wrong reason, so the assertion now also pins the other direction: no single level may exceed a quarter of the space. The useful consequence is the one the moby_anim item was waiting for. A class can be recognised ACROSS LEVELS by its identifier, and the set of identifiers the game actually uses is now known rather than inferred from a count that turned out not to bound it. Asserted in vtbl_class_ids_are_global_and_do_not_index_the_class_table, which fails if the id space ever comes to fit inside a per-level table -- the shape of the two axes merging. 262 tests.	2026-10-14 03:36:03 +02:00
ReaperOfVeriod	199ce33dd8	The moby class-id space is known: lvl.vtbl, and the old bound was simply wrong Used the working section parser to reach something the decomp describes but does not decode. lvl.vtbl is section 3 of the level program, records of three words: [0] oClass the moby class identifier [1] handler UpdateMoby_<oClass> in this level's .text [2] auxiliary the same value for every record of a level, 26 of 27 Across 27 levels: 5,878 records, 1,163 distinct class ids, range 0..0x13BA (5,050), median 38 new ids per level. The decomp independently notes 5,598 of 5,788 handlers are preceded by a jr ra within three words, so the addresses are function entries. WHY THIS RETIRES THE EARLIER BOUND moby_classes.count is 238 on level 0. 1,135 of the 1,163 real ids -- 97.6% -- are at or above that number. So "value < moby_classes.count" was never a test for "this is a class id". It was a test for "this is a small number". That is the mechanism behind the chunk class-ID artifact I retracted two commits ago: slot values 1, 3, 4, 5, 10, 11, 12, 13, 15 all below 238, so all scored as hits, giving 305x enrichment The bound was wrong BEFORE the artifact was noticed, and the artifact was a consequence of it. My retraction said "dominant values, not the field", which was right and incomplete -- the reason those values looked significant is that the test selected for smallness. Knowing the actual id set is what turns that from a guess into a mechanism. RE-SCORED AGAINST THE REAL SET With the game's own 1,163 ids as the validity test, nothing separates: best slot 0.375 (type f2ef4275 slot 34) chance rate 0.018 (1,163 ids in 65,536 values) a dozen slots 0.25 .. 0.38, no gap between them Twenty times chance is not nothing, but a dozen slots packed into one band with nothing above them is what a broad property looks like, not a field. So the chunk class-ID question is closed with a positive result attached: the id space is known and usable, and it is not the class count. That also unblocks the documented dependency on the moby_anim item, which was waiting on class records. Asserted in moby_class_ids_come_from_lvl_vtbl_not_from_the_class_count. 262 tests.	2026-10-14 03:34:35 +02:00
ReaperOfVeriod	9f4f4acecb	The collision assert string is never referenced: the last route is closed Followed the route I recorded as remaining -- find how the code addresses the assert string at 0x001a8998 in .lit. It does not address it. Level 0's program is 2,751,268 bytes. Searching it for both ways an address can be materialised: address low half 0x8998 0 occurrences, word-aligned or not $gp-relative offset 0x99a8 0 occurrences, word-aligned or not exact 32-bit 0x001a8998 0 occurrences Validated by a positive control in the same run: the .lit load base's own low half, 0x7c80, occurs exactly ONCE, word-aligned. A search that finds that will find any real reference, so the zeros are real. So no instruction and no data word in the retail level program references the collision assert string -- not by lui/addiu, not by a literal pointer, not by a table entry. The text is present in .lit at overlay+0xd18, and the same text also appears in the boot binary at file offset 0xA9558, but nothing points at either. The reading that fits: the assertion is compiled out in retail and the string is dead data. Debug string pools routinely keep messages whose only user was an #if-ed-out assert. The decomp's table lists this name because it recovered it FROM THE STRING, not because it found code calling it -- which is worth noting, because a name in a symbol table looks like evidence of a caller and is not one. That closes the last route this file records for collision. Getting the cell layout from the disc would need a build with assertions enabled, a debug listing, or an independent description of R&C2's collision cell. None of those is on this disc, and saying so is more useful than another scan. Summary of collision, all of it now checked: the payload is verbatim in RAM, it does not walk as fixed-stride cells, the disc-side segmentation is exhausted, the string that would have led to the routine is unreferenced, and both of the decomp's addresses are dead ends.	2026-10-14 03:25:32 +02:00
ReaperOfVeriod	66a96111d7	Kill the 48-byte loop lead: the function takes no pointer arguments Finished the task I named last commit rather than leaving it as a lead. Camera_CollPrimTest is declared Camera_CollPrimTest(void prim, void grid) -- two pointer arguments, which in MIPS arrive in $a0 and $a1. The function's prologue is at 0x002db078, matching the +0x70 teardown at 0x002db354. The two instructions after it: 0x002db078: addiu $sp, $sp, -0x70 0x002db07c: lw $v1, -0x3f4c($v0) <- $v0, not an incoming argument 0x002db080: addiu $a0, $zero, 0x6f <- $a0 set to a constant $v0 is caller-saved scratch, not an argument register, and $a0 is overwritten with the constant 111 on the next instruction. No void* reaches this function, so it is not Camera_CollPrimTest, whatever the assert table labels it. It reads four consecutive words from boot memory -- 0x1a7348 through 0x1a7354 -- all below the level program base at 0x001A7C80, which is the boot's resident region and identical in every program. A different data source from the collision payload, and the 48-byte stride loop belongs to whatever that structure is. So the lead is dead on evidence rather than on doubt, and both routes the decomp appeared to offer are now closed: Camera_CollPrimTest @ 0x001E7A50 lands in NOBITS, all zero GridOutOfBounds @ 0x002db350 a function with no pointer arguments Neither address reaches the collision parser. Worth noting how cheap the check was once the tool worked: three instructions past a prologue is enough to disqualify a function whose name asserts a signature. The expensive part was not the analysis, it was the disassembler that stopped after five words and made everything look empty. The route that remains is the one already recorded -- find how the code addresses the assert STRING at 0x001a8998 in .lit, which is not a $gp-relative load and is not a symbol address in either table. Note that the string and the code are five megabytes apart in different sections, so whatever reference exists is not a simple local reference, and that is the thing to look for.	2026-10-14 03:18:02 +02:00
ReaperOfVeriod	2f5979e652	Update the decomp; read .text, and fix the disassembler that made it unreadable Vendored rac2-gc-decomp is 13 commits behind, 12,375 lines added, almost all src/. It names no collision data structure, so the format is still not handed over. Two things are usable, and one precondition had to be fixed first. THE PRECONDITION: the disassembler was stopping after five instructions. tools/overlay-anchors called disasm_all across the whole window, which halts at the first word capstone will not decode. In code regions that is almost immediately, so every window came back with a handful of instructions and I had concluded there was nothing there. It now walks four bytes at a time, prints .word for anything undecodable, and reports how many failed. That is the whole reason the earlier attempts produced nothing -- not that the code was absent. WHAT THE DECOMP'S ASSERT TABLE ACTUALLY GIVES assert-message-names.tsv maps each assert name to an address. For level 0, CameraCollPrimTestGridOutOfBounds is 0x002db350. That address is not the assert call and not the string. It is: 0x002db350: jr $ra 0x002db354: addiu $sp, $sp, 0x70 an epilogue. The address lands on the last group of the function before it, and 0x002db35c is a fresh prologue. It is also in .text (0x002a3b80..0x00447900), five megabytes from the .lit string at 0x001a8998 -- which explains the "$gp search returns zero" result from the other side. The string and the code are in different sections, five megabytes apart. WHAT IS ACTUALLY THERE Immediately before the epilogue: 0x002db2dc: lwc1 $f20, 0xc($s0) 0x002db2ec: add.s $f20, $f20, $f21 0x002db2f0: c.olt.s $f0, $f20 0x002db304: jal 0x2db4b8 <- the assert call 0x002db314: lw $v0, ($s1) <- a count 0x002db31c: slt $v0, $s2, $v0 0x002db320: bnez $v0, 0x2db2cc <- loop back 0x002db324: addiu $s0, $s0, 0x30 <- stride 48 bytes A loop over 48-byte records, reading a float at +12 and accumulating, bounded by a count, with f22 set to 1.0f just above it -- a minimum-height clamp. NOT CLAIMED to be the collision grid. It is a strided float loop beside an assert the decomp labels CameraCollPrimTestGridOutOfBounds. A plausible address near a plausible assert is a lead, not an identification, and that is the exact gap this log keeps tripping over. Confirming it means tracing the function's arguments back to the collision payload and showing the grid's leading u16s -- level 0 is 11 x 33 -- drive the count at ($s1). Not done, and not asserted. The undecodable words are VU1 microcode (COP2 opcodes), which is expected: the function interleaves VIF-fed VU1 work with FPU arithmetic, like tfrag's. Tools build, clippy clean, 260 tests.	2026-10-14 03:16:17 +02:00
ReaperOfVeriod	508a03fa4a	The decomp names both collision functions; their addresses are not ours rac2-gc-decomp names the two collision entry points: Camera_CollPrimTest 0x001E7A50 camera-to-world boundary check MB_CheckCollPill 0x001E8890 pill/capsule check for moby instances That looked like the collision unblock. The $gp string search has failed twice now, and a named function at a known address is exactly what it failed to produce. They are not usable. Checked against levels 0, 5, 13 and 26 with parse_overlay_sections: Camera_CollPrimTest @ 0x1e7a50 -> section 1, kind 8 (NOBITS) MB_CheckCollPill @ 0x1e8890 -> section 1, kind 8 (NOBITS) Both land inside the level program's zero-filled section. Every byte is zero and the following 256 bytes contain no non-zero byte at all -- code cannot be there. Same on all four levels, so it is not a level with an unusual layout. So the addresses belong to a different address space than a parsed level overlay. Most likely the boot executable's own layout, or the v2.00 build; that repository covers both. SCUS_972.68 is USA v1.01 and our disc matches it exactly, but that fixes the disc, not which program's address space a symbol address is quoted in. The disc matching is exactly the kind of check that looks sufficient and is not -- a disc can pin the bytes and still leave you looking in the wrong program. Worth noting the method that caught it. The temptation was to take the address, open the overlay at that offset, and start reading instructions. What settled it was checking which section the address falls in, and its KIND: a NOBITS section is zero-filled by definition, so an address inside one is a contradiction rather than a lead. The section table made that a two-line check. This closes the shortest route to the collision cell layout, for a checkable reason rather than a vague one. The route that remains is the one already recorded: find how the code addresses the Camera_CollPrimTest assert string, which is not by a $gp-relative load.	2026-10-14 03:11:13 +02:00
ReaperOfVeriod	39462d2cf9	Correct: overlay.bin is the seven-section program, not the .lit section The Phase 3 port brought parse_overlay_sections with it, which makes the overlay's shape checkable for the first time. It corrects a claim I committed when vendoring the decomp. What I wrote then: overlay.bin +0x00 is 0x1A7C80, that is the .lit load base, "so the first header word is the load base of the section this file is", and therefore "overlay.bin IS the level's .lit section". It is not. overlay.bin is the whole seven-section program. .lit is its first section: 39,388 bytes at 0x1A7C80 on level 0, against a lump of 2,751,268. section 0 .lit 0x1A7C80 on all 27 levels section 1 .bss kind 8 (NOBITS) on all 27, zero non-zero bytes sections 2-6 .data, lvl.vtbl, lvl.camvtbl, lvl.sndvtbl, .text kind sequence [1, 8, 1, 1, 1, 1, 1] identical on 27/27 section sizes fall 112 bytes short of the lump on 27/27 (each section's size counts its own 16-byte header) The error was reasoning from a constant to a statement about the file's nature. A load base tells you where something is placed, not what the containing file is. That is the same move as the other four withdrawals this session -- the 305x class-ID slot, the UV-corner texcoords, the VIF code word, the DAW pointer -- all of which read a single plausible item as evidence about the whole. Worth noting what survives. The collision assert string is in SECTION 0 on all 27 levels, so the earlier $gp-relative search located it correctly even though the reasoning about the file was wrong. The string being in .lit and the file being .lit are different statements and only the first is true. A wrong reason can reach a right answer; it is still worth correcting, because the next person to reason from it would not. Asserted in overlay_bin_is_the_seven_section_program_not_the_lit_section. 259 tests.	2026-10-14 03:10:24 +02:00
ReaperOfVeriod	4ca0308499	SBlk body head: the DAW size, stored twice Picked sound_bank rather than tie, where three discriminators have now come back negative and a fourth would be guesswork. The body after the 24-byte head opens with twelve words. Six are settled across all 27 levels: word value note 0 varies per level not identified; 27 distinct 1 60 constant 2 varies per level not identified; 23 distinct 3 0 constant 4 daw_size == the header's daw_size, exactly 5 daw_size the same value again 6,7,8 0 constant 9 127 constant 10 1 constant 11 0 constant Level 0's words 4 and 5 are both 1,482,000, and daw_size is 1,482,000. THE POINTER THAT WAS NOT ONE Words 4 and 5 were briefly recorded as pointers into the DAW region. They are not. The test that promoted them was "does this value fall inside [daw_offset, daw_offset + daw_size)" -- and the DAW region is ~1.5 MB starting near the front of a ~1.5 MB extent, so almost any plausible 32-bit word lands inside it. 1,482,000 is merely just under the top of exactly that range. A range test is not an identification. What survives is EQUALITY with daw_size, exact on all 27 levels and asserted, which is a claim that can fail rather than one that is almost always true. That is the fourth time this session a plausible reading of a single number has had to be withdrawn for something falsifiable: the 305x class-ID slot, the UV-corner texcoords, the VIF code word, and now this. The pattern is consistent enough to be worth stating as a rule -- a test that passes almost always is measuring the shape of the data, not a property of it. Word 0 gets one note: levels 1 and 4 hold 13,042,052 and 13,042,054, two apart, while their daw_sizes differ by 63,504. Whatever it is, it is not a size. The remainder of the SBlk body -- the per-sound record table -- is still undecoded, so sound_bank stays open. A SBlkBodyHead struct carries the twelve words with the constants asserted in its docs. 259 tests.	2026-10-14 03:06:36 +02:00
ReaperOfVeriod	ec433e3341	Correct my own "VIF packets" reading: the split is real, the identification is not Last commit read bit 31 of a tie vertex region's first word as "VIF code word" and told a two-encoding story on it. The split is real; the identification is wrong, and I checked it before building anything on top. Walking those regions as VIF packets, levels 0-2, 914 records: walk reaches the region end 17 walk dies after exactly ONE packet 1,571 packets before dying: min 0, median 1, max 4 tfrag walks VIF the same way -- VifCode::decode, then num * 4 payload words -- and reaches the end of its lists every time. So the walk is not the problem; these regions are not VIF packet streams. Bit 31 is set on whatever this word actually is, and that is still unknown. The specific thing that made me overreach: I quoted 0xf5c1a3c5 as "a VIF code word, cmd 0x75 num 193" and treated that as establishing the format. Decoding one word as a packet header says nothing about whether the next 193 words are its payload. Here they are not -- the walk dies immediately after. This is the third time in this area that one plausible word produced a confident story: the 305x class-ID slot, the UV-corner texcoords, and now this. All three shared a shape -- a single readable item at the head of a population, treated as evidence about the whole. The bit is the only thing the two kinds reliably differ on, so it stays; the name goes. The test now asserts BOTH the split and the walk failure, which is the part worth keeping. If these ever do turn out to be VIF, the test fails and says so, rather than two findings drifting apart silently -- which is how "half VIF, half flat" would have sat in the docs indefinitely. Docs corrected in both roadmap and format file, including the quoted example. 258 tests.	2026-10-14 03:04:48 +02:00
ReaperOfVeriod	4ab30e1f4d	Retract the tie texcoord field: a dominant-value artifact, one level down Picked the tie flat encoding to close, since `e5cd3df` left it as the largest unidentified field. What came out was a retraction of my own earlier claim. The texcoord slot was recorded at i16[4]/i16[5] on a 73.6% "both multiples of 4096" score. Two problems, either of which would be enough. First, that 73.6% was computed on the 16-byte element reading that `e5cd3df` retracted. Half the records are VIF packets and half are flat, so the figure describes neither population cleanly. Second, and decisive on its own: measured on the FLAT records only -- levels 0-2, 930 records, 47,909 vertices -- the question that separates a 12.4 fixed-point texcoord from anything else is how many of a slot's distinct values are multiples of 4096 at all. For a texcoord it is all of them. slot distinct of which are multiples of 4096 i16[4] 1,488 16 i16[5] 1,261 16 i16[6] 966 4 i16[7] 489 5 One percent. The dominant PAIRS do look like UV corners -- (0,0) 5,773, (0,4096) 5,500, (4096,4096) 5,059, (4096,0) 4,521 -- and that is precisely why the claim was persuasive. But it is a statement about the most frequent values, not about the field: 1,472 of the 1,488 values in i16[4] are not multiples of 4096 at all. This is the moby class-ID artifact one level down. A small set of dominant values that happen to satisfy the test, scored as though the whole population did. The arithmetic was right about the popular values and the conclusion was wrong about the field. The retraction commit itself warned about exactly this shape, which makes the repeat more useful than the original claim was. So the texcoord slot of a flat tie record is NOT identified. What survives is the boundary work -- vert_ofs + vert_size + scissor_size is the region length -- and the LOD1/LOD2 sharing result, which is stride-insensitive and survives the stride retraction. Both docs updated: the roadmap's two [x] claims about the texcoord field and about i16[3] selecting its encoding are now [~] with the evidence, and the format file has a retraction section giving the table above. I did not find a replacement reading for i16[4..7]. Three discriminators were tried -- LOD sharing, multiple-of-4096 rate, value-set size -- and each came back ambiguous or negative. That is worth recording as the state rather than generating a fourth hypothesis. 258 tests.	2026-10-14 02:56:57 +02:00
ReaperOfVeriod	1e90c7de6d	Verify the Phase 2 gate, and give every blocked item an unblock condition Starting from the phase's stated exit criteria rather than the checklist, because "complete" should mean the gate, not the feeling of the list. THE GATE IS MET. Both halves, checked by inspection: * Golden tests. Every module in gc-formats/src is referenced by a test or another module's test path; none is unreferenced. gc-extract/tests/disc.rs carries 50 real-disc tests, and overlay_reloc's mask test resolves a level-01 function on all 26 other overlays. * Counts are failures, not warnings. No parser writes warning-style output outside #[cfg(test)] -- the only eprintln! calls in gc-formats are inside test modules. Count and length problems surface as typed errors: 42 uses of ErrorKind::Invalid / InvalidLength, including global_wad's "pair table is not a whole number of entries", which is precisely a header count disagreeing with the data. THE GOAL IS NOT MET, and saying otherwise would be the thing AGENTS.md forbids. The goal reads "every asset type parses into plain Rust values". Four do not: collision cells, volumes, moby_anim and the tfrag morph are located or framed but have no decoded fields. The gate was written to be checkable and it does not test for that, which is a gap in the gate rather than a reason to declare victory. So the remaining gap in the phase's own discipline is that the four blocked items did not say what would unblock them, which AGENTS.md requires and which none of them did. Closed now, each with the specific unblock condition: collision cells the game addresses its assert string by something other than a $gp-relative load -- a %hi/%lo split that does not straddle zero, a pointer table, or another section. A plain $gp search returns zero and always will. volumes ground truth: a count of level 0's trigger volumes from a map, to match against the 144-byte table's population. No class name containing "volume" exists on the disc, so the dispatch route is closed. moby_anim needs moby class records decoded past the header -- a dependency, not a measurement. tfrag morph needs a frame captured at a KNOWN camera distance, so the expected blend is computable. Requires driving the running game, not analysing a static savestate. None of these is an approximation, and none is marked done. 258 tests, 50 in the disc suite, clippy clean on my own code.	2026-10-14 02:52:09 +02:00
ReaperOfVeriod	67ce068c7f	Tie vertex regions are two encodings, not one; mark Phase 3's port done Read up on the five commits that landed since `f1f0b51`. The headline is `e5cd3df`, which retracts my tie vertex position claim: the stride is not 16. The LOD1/LOD2 sharing evidence survives, because it is stride-insensitive, but the element layout and the 95,612 count do not. This commit works on what that retraction opened rather than trying to rescue it. The split is visible in the region's first word. A VIF code word has bit 31 set: first word is a VIF code word 2,007 first word is not 2,102 (levels 0-5, every record with vert_size > 0) So roughly half of all tie records address their vertex data as VIF packets and half as a flat 16-byte array. Flat records repeat a 16-byte unit whose last word is constant at 0x00001000 and whose third word walks down f000, e000, d000, c000; VIF records start with e.g. 0xf5c1a3c5, cmd 0x75 num 193. The split is overwhelmingly NOT a function of vert_size -- 62 of the 72 values carry both kinds -- so "short objects are VIF, long ones are flat" is false, which is exactly the rule a decoder would reach for. The 10 that carry one kind are the rarest sizes, not a band. This also explains why the flat reading looked convincing rather than arbitrary. In a flat record, i16[6] is 0x1000 and i16[7] is 0x0000 at the end of each unit -- the (-1, 0) / (1, 0) corner pair a texture coordinate makes in 12.4 fixed point. That is where the earlier texcoord reading came from, and it holds cleanly on the half of the records that are flat. It was never wrong about those; it was applied to all of them. It does not settle the stride. It says the region has to be dispatched on encoding before anything inside it can be read, which is why no single flat stride fits every record. Asserted in tie_vertex_regions_split_between_vif_and_flat. ALSO: the roadmap still listed two Phase 3 items as open that `a94704d` has already done -- "Port the masking and code-identity logic" and "Relocation::func and Relocation::data". Both exist, are exported, and the masking is verified against the disc: the masked form of a level-01 function (858 words at 0x2a3b88) is found exactly once on each of the other 26 overlays. Both now marked done with the evidence attached, rather than left stale. I ran clippy --fix over overlay_reloc.rs, saw it rewrite 110 lines of the new Phase 3 code, reverted it. The changes were cosmetic -- redundant `as u32` and reflow -- but it is not my code and the remaining warnings are the author's to address. Its 11 warnings are pre-existing and left alone. 258 tests.	2026-10-14 02:49:48 +02:00
ReaperOfVeriodandreaper	a94704de18	port Phase 3: overlay masking + code-identity + relocation Ported ReRAC's (vendor/rerac/crates/rc-formats/src/level_overlay.rs) mask / Relocation machinery into gc-formats: - parse_overlay_sections, read_overlay: section table {dest,size,kind,entry}, ends on entry mismatch; kind==8 = BSS; plus LevelOverlay with .text words, text_start and function starts. - mask: hides relocated fields (j/jal targets, lui of main-RAM 0x0010..0x0040, %lo/move/$gp completions tracked per-register). - walk/HiState/address_refs/key: PS2 code walk with branch-delay-slot register state. - Relocation::new/same_code/copies/func/data: masked-code index, one-copy lookup, data-address relocations. A real-disc test asserts that a level-01 engine function's relocated copy is found exactly once on all 26 other overlays (gate: every level-01 function is reachable by masked-code identity on all 27). Co-authored-by: reaper <reaper@users.noreply.github.com>	2026-10-14 02:37:34 +02:00
ReaperOfVeriodandreaper	8030dbf006	close: tie LOD distance ordering exceptions - 80/1864 classes have mid=8192 far=8190 Tie class headers ordered near < mid < far on most classes. Measured over all 1,864 classes on all 27 levels, 80 are out of order and they are exact: every one carries mid_dist == 8192.0 and far_dist == 8190.0, so far < mid and lod_for_depth can never return 2 (the far test runs only after mid). Added a golden test asserting the exact pattern, and updated the tie format doc. Co-authored-by: reaper <reaper@users.noreply.github.com>	2026-10-14 02:19:07 +02:00
ReaperOfVeriod	e5cd3df40e	Retract the tie vertex position claim; the stride is not 16 Task was to name the axis order and scale of the tie vertex positions by fitting the class header's bounding sphere. The sphere does not exist: at +0x30 those bytes are zero on every class. Scanning the header for float-like words found +0x10, +0x14 and +0x18 (the LOD switch distances, already named) and +0x40 on 1,676 of 1,864 classes, which is not a sphere. What the run produced instead is a retraction. Dumping one packet's vertex region raw shows the first 16 bytes are header material, not a vertex -- 0x0000df20 is not a coordinate, and the words after it are the vif and material words. A 16-byte group does recur at +64 and +128 with identical structure, so the stride is not uniform: some elements are 4 bytes, some 16, and the run length varies. Two candidate bases were measured and neither clusters. With packet + vert_ofs the per-class extents run median 64,976, p90 65,517; with class + vert_ofs, median 55,213, p90 64,352. Both span the whole i16 range, where a position triple in a class-local frame would span a fraction of it. The region bounds are right -- vert_ofs + vert_size + scissor_size is the length -- it is the element layout inside it that is wrong. The i16[3] marker does not rescue it: bucketing every fourth element by the marker's high byte gives markers 0, 0x48, 0xff and 0x01 with thousands of vertices each, and only 0x48 shows a position signature (i16[1] extent 425 against 65,535 on the other two axes). The same marker 0 bucket spans all three axes at full range, so the bucket does not select a layout. The 95,612-vertex count and the 82.5% texcoord fixedness figure were computed on the 16-byte reading and are now untested against the correct stride, which is not yet known. The LOD1/LOD2-sharing test stays the strongest evidence for positionality and is stride-insensitive.	2026-10-14 02:05:38 +02:00
ReaperOfVeriod	855aadf523	Record the tie terminator defect in the format doc, plus two failed fixes The defect itself was measured and committed in `572cd18`, but the format-doc section describing it was lost last session: the patch that should have added it silently failed its assertion, and only the test and the roadmap entry landed. Same shape as three other lost edits this session. The section is restored here. Two candidate fixes are recorded alongside it, both measured and both dead ends: 1. The first 0xf6 00 at or after the last known packet's end. The offsets found are spread (1082, 1132, 1148, 1150, 1182, 1214 ...), not concentrated, because the 115 records with a non-zero strip_count carry packets of unknown length that sit after the last known end. 2. The block's data ends at a long zero run. The byte before the first 8+ zero run is not dominated by 0xf6 (2, 4, 1, 64, 3, 32, 19 ...), and the runs are mostly 8-31 bytes, so run length does not discriminate the block's end. Both are recorded because they are the obvious things to try next. What would unblock it: a survey of which offsets do bound blocks (the 461 that work may share a property), or the level loader's own block-walking code, which needs the overlay relocation from Phase 3.	2026-10-13 18:07:04 +02:00
ReaperOfVeriod	572cd1898d	Record a defect packet slicing found: the tie block terminator is early Range measured: every tie LOD block on the disc, 2,177 blocks. The last packet's end is known two ways. Its length comes from its record's packet_quadwords, and every other record's length is confirmed by the next record's pointer -- so only the last packet of each table is unconfirmed. Comparing its computed end against where parse_tie_block stopped: the last packet's computed end lands 2 to 16 bytes past the located 0xf6, on all 2,150 blocks measured. Two readings fit. Either the terminator was located too early -- inside the last packet's data -- or the last packet's length over-predicts by a small amount. The first is likelier: a length error on the last record of every table would have to be a coincidence. Neither is settled here, and the test asserts the measurement rather than the reading. Why the existing test missed it: "2,177 of 2,177 blocks end on 0xf6" is satisfied by a false terminator exactly as well as a true one -- it checks that the byte found IS a 0xf6, not that it is the block's end. A test that confirms the shape it walked to will pass on the wrong byte. The cost: the block extent is short by that much, so payload and padding under-report and anything computed from them is correspondingly short. The block starts are unaffected and RAM-confirmed. Recorded as a limitation with the measurement attached, not fixed. A terminator packet data cannot imitate is its own task, and guessing one would be the plausible-sounding alternative this project has been bitten by. A packets() accessor was tried and removed for the same reason: with the extent short it silently yields the wrong answer, and an API that is quietly wrong is worse than no API.	2026-10-13 17:40:31 +02:00
ReaperOfVeriod	1cfe744501	Settle the tie packet length, and correct the retraction that hid it Range measured: every tie LOD block on the disc -- 2,177 blocks, 13,042 consecutive record pairs. A record's pointer is where its packet starts, so the distance between consecutive pointers IS a packet's length, with no reference to any field. Comparing that against the record's own fields: packet_quadwords = vert_ofs + vert_size + scissor_size 12,927 of 12,927 record pairs whose strip_count is zero 0 of 115 record pairs whose it is not The partition is exact: every record with a non-zero strip_count is an exception and no record with a zero one is. So the fourth term is 0 quadwords whenever strip_count == 0, and something else -- measured 0..19 quadwords, and NOT equal to strip_count -- whenever it is not. R&C1's strip_count is a strip count and strips are variable-length data, so a non-zero count most likely adds per-strip bytes this cannot see; that is a hypothesis, labelled as one. TieRecord gains packet_quadwords and packet_quadwords_are_known. The latter is the honest gate, and the disc test asserts both sides of the partition rather than the aggregate. This also corrects this file's own retraction of the same formula, and the retraction was the error rather than the claim. A formula of this shape was derived at 61 of 61 pairs, then "retracted" as not reproducing (0 of 13,042). The re-measurement had swapped strip_count for scissor_ofs in the fourth term and put the blame on the block set. Re-measured with the term the first pass had, it matches on 12,927 of 13,042 and the 115 exceptions are exactly the non-zero strip_count records. Worth recording because it is the same shape as two other entries in this file: a retraction is not automatically more careful than the claim it retracts, and the re-measurement that "disproved" this one changed the thing being measured. The lesson on the other side is what saved it -- the first measurement was over 61 pairs, not a population, and had it stayed there the formula would have looked universal. A small sample and a bad re-measurement, near-misses in opposite directions. What this unblocks: the payload can be sliced per packet, which was the prerequisite for decoding what it holds.	2026-10-13 16:48:49 +02:00
ReaperOfVeriod	4abce518e5	Decode the overlay's load base, from its own profiler table Range measured: all 27 levels' overlays. The overlay carries the game's profiler menu definition -- a run of 8-byte padded names (normal, camera, cam+chr, volume, bars, render, mobys, ties, shrubs, cpu/gpu, occl, ...) followed by runs of absolute RAM addresses that point back at those same names. On every level the four addresses after normal/camera/cam+chr/volume, each minus its target name's overlay offset, give the same number: 1,735,792. That is field_00 - 16, where field_00 is the header word that read 1,735,808 on all 27 levels with nothing attached to it. The overlay is loaded with its 16-byte header stripped, so overlay offset X sits at RAM X + 1,735,792. OverlayHeader::ram_address carries it, and the disc test asserts the derivation holds on all 27 levels. Confirmed, not only derived: level 0's RAM 0x1acf80 holds "normal\0camera\0cam+chr\0volume\0", byte-identical to overlay 0x5310, and 0x5310 + 1735792 == 0x1acf80. All four names land where the overlay's own table says. `gc-trace verify-overlay-base` runs that check, savestate-gated the same way as the tie and tfrag ones. The overlay is relocated, not copied: only 37.67% of level 0's is byte-identical at the base, and the 256-entry sine table -- at overlay 0xb650c -- is not at 0xb650c + base. So the base locates the overlay's image, but individual tables inside it move. That is the shape of a loader applying relocations, and it means the base is necessary but not sufficient for reading the game's tables. The value of the base is that any overlay offset can now be carried to a RAM address, which is the prerequisite for reading the game's live level state -- the thing the tie relocation and tfrag lighting checks had to work around. Two things get deleted rather than finished. The collision u16 table was probed four ways -- magnitude distribution, level-independence, run starts, run lengths -- and every one came back level-dependent: the run-start pattern is identical on 1 of 19 levels. So the first 1024 bytes of the collision payload are data, not a fixed table, and nothing was decoded. Recorded as the negative it is rather than left as four half-findings.	2026-10-13 13:22:50 +02:00
ReaperOfVeriod	55ea619b4c	Decode the tie class header's +0x0c word: three LOD record counts Range measured: every tie class on the disc, 1,864 classes over all 27 levels. Method: read the word at class +0x0c as four bytes, and read the record counts independently from the blocks themselves -- follow packets[lod] to the block, walk to the 0xf6 terminator, and count the 16-byte records the block header's data_offset names. Two paths to the same number, so the check is not circular. Result: the byte at +0x0c is the LOD 0 record count, +0x0d is LOD 1's and +0x0e is LOD 2's, on 1,864 of 1,864 classes. Classes with an absent LOD agree too: a zero packets[lod] gives a zero count and the byte is zero. This closes the file's oldest lie about the tie header. The comment in TieClassHeader::parse read "0x0c: the 64 light-slot normals offset. Read past, not decoded" -- inherited from R&C1's layout, where the word genuinely is an offset. On R&C2 it is not an offset at all; it is three counts, and R&C1 carries the same quadruple at +0x20. Skipping the field was the right action on the wrong information: the field was unknown only because R&C1's map was applied to R&C2's bytes. TieClassHeader gains packet_counts, and tie_class_header_counts_records_per_lod asserts the agreement. The fourth byte, +0x0f, is left unnamed. It ranges 1..15, and the obvious following of R&C1 -- the shader/ad-gif total -- disagrees on 1,827 of 1,864 classes, which is 2% agreement where a count would expect 100%. It is recorded as unidentified rather than given a name that fits a fiftieth of the population.	2026-10-13 08:59:40 +02:00
ReaperOfVeriod	f1f0b517a5	Pin the extracted tree, which every disc test reads and nothing verified data/gc-files.tsv pins the ISO files, and unpacks_and_matches_the_committed_table checks that unpacking reproduces them. But the tie, collision, tfrag and chunk tests do not unpack -- they read ~/Documents/gc-extracted, a directory on disk that nothing in the repository checks. A stale or hand-edited file there would have every measurement built on it still pass, quietly. Three claims this session returned confident numbers while describing the parser rather than the disc -- has_uniform_record_length, "1,509 chunks uniform", the moby class-ID scan -- and a test whose data source is unverified is that same hazard one level down. data/gc-extracted.tsv now records SHA-1 and size for all 5,237 files in that tree, 324 KiB, sizes and hashes only, no content. It is the output of `gc-extract unpack`, whose ISO files are already pinned by the other table, so it is grounded transitively rather than by assertion. the_extracted_tree_matches_the_committed_table walks the table and checks every row's size and hash against disk. It asserts all 5,237 are checked -- so a truncated table fails rather than passing on a prefix -- and reports the first few missing or mismatched paths when it does. Current result: 5,237 of 5,237 match. This does not retroactively validate the three retracted claims. What it does is remove the possibility that any of the surviving ones rests on a directory that could have been anything. 246 tests, clippy clean.	2026-10-13 08:20:37 +02:00
ReaperOfVeriod	8ccc3ddda4	Retract the uniformity claim everywhere it still stood, including the API docs The record-length retraction had been applied to the tests and to the section that discovered the problem, but the same claim was still standing in four other places -- including the rustdoc for has_uniform_record_length(), which is what a caller would actually read: crates/gc-formats/src/chunks.rs:206 "Measured: true for 1,509 of 1,509 chunks" docs/roadmap.md:448 "uniform record length (1,509 of 1,509)" docs/formats/core-data-regions.md a whole section titled "Every chunk has a uniform record length" All three now say 257 of 1,509, and the method's rustdoc explains WHY the old number was an artefact -- that resolve sliced at the first offset delta, so every record came out the same length by construction and the predicate was confirming the parser back to itself. That section also contained a withdrawal, and the withdrawal was wrong: "This withdraws the previous commit's variable-length type. That came from taking minlen/maxlen over all of a type's records at once, pooling across chunks; rule 3a's pooled claim, third time this session." The pooling rule fired correctly and was overruled by a measurement with no independent content. The per-chunk check that should have caught the pooled signal was itself reporting the parser's own slicing, so it agreed with the wrong answer for the same reason the original claim did. Two errors stacked: a real signal dismissed by a rule that had been right twice already, and a predicate that could not have told the difference. This is the third time this session that a test was asserting the parser's behaviour rather than the disc's, and the third time it was the only thing standing between a claim and a retraction. has_uniform_record_length is the clearest instance: a predicate named after a property of the data, returning a confident answer about the code. 245 tests, clippy clean.	2026-10-13 08:18:20 +02:00
ReaperOfVeriod	2d3880b624	The class-ID retraction goes further: the claim was wrong before the fix Pinned down the one slot that still cleared 100x after the record-boundary fix, and it is the artifact this section was written to guard against. The discriminator the original version lacked: a slot that really carries moby class IDs must SPAN the ID space, so some of its values land above a level's moby count. The artifact does the opposite. type slot enrichment distinct values ABOVE the moby count 0xd76cc453 6 305x 9 0 0xf2ef4275 34 64x 9 341 0xf2ef4275 7 46x 16 412 0xf2ef4275 14 34x 16 432 0xd76cc453 9 32x 28 702 The 305x slot's nine values are 1, 3, 4, 5, 10, 11, 12, 13, 15 -- all under a level's ~215 moby classes, so every one scores as a hit and 65536/215 = 305x. Nine small numbers is not a class-ID array. Every slot that actually spans the ID space scores 10x to 64x, which is chance. So the original claim's own numbers gave it away and it was not read that way: "5 to 42 distinct values at 153x to 289x" is exactly the artifact's shape -- a handful of small values, none above the count. The record-boundary fix was never what made this claim wrong. It was wrong when written, and the retraction is complete rather than the partial one I committed two turns ago. The test now separates the two quantities: slots clearing 100x (currently 1, expected to remain the artifact) and slots clearing 100x WHILE ALSO having values above the moby count (currently 0, must stay empty). That second number is the one that means something, and a slot appearing in it would be the first genuine evidence of a class-ID array anywhere in the container. Worth noting the per-SLOT bookkeeping: the count of values above the moby count is keyed by (type, slot), not by type. A first attempt keyed it by type and the artifact type passed the check on the strength of its ordinary slots -- 783 of its own values sat above the count at other slots. The check has to be about the individual slot, or one good slot launders a bad one. 245 tests, clippy clean.	2026-10-13 08:11:35 +02:00
ReaperOfVeriod	d159195510	General guard for the over-read class, and the audit showing it was unique Searched for the pattern that caused the over-read -- a record length derived from the first difference between two offsets: grep -rn "\[1\] - \[0\]" crates/gc-formats/src/*.rs crates/gc-formats/src/chunks.rs:357 (offsets[1] - offsets[0]) One hit, in the one parser that walks an explicit offset table. The others slice contiguous regions with chunks_exact -- shrub's 8-byte palette records, tie's 16-byte packet headers, tfrag's 4-byte tables. There a length cannot run past the next element, because chunks_exact derives each boundary from the region's own length rather than from a sample of the spacing. Shrub's mesh packets carry an explicit offset AND size, so they state their length instead of inferring it. The damage was bounded by a structural property worth stating: only a format with an offset table AND a derived stride can over-read, and exactly one format had both. That is a more useful fact than the retraction was on its own -- it says where else to look if another one turns up. The guard is positive rather than a comment. chunk_records_neither_overlap_nor_leave_gaps asserts across all 27 levels that every record but the last is exactly its own offset delta long, that there are 1,509 chunks, and that 1,252 have ragged deltas. A regression to a single sampled stride fails immediately and names the chunk and the record. 245 tests, clippy clean.	2026-10-13 08:04:08 +02:00
ReaperOfVeriod	92aa0fe49f	Audit what the record-boundary fix contaminated: one retraction, one survivor The fix changed record lengths in 1,252 of 1,509 chunks, so every committed claim computed over record bytes needed re-checking rather than assuming. All of them: claim reads verdict 1,509 chunks / 34,491 records offsets unaffected 1,262 chunks with a leading-byte bucket rule record byte 0 unaffected 1,235 chunks with an index rule record bytes 1-2 unaffected 34,432 of 34,491 records 8-byte aligned record byte 0 unaffected 55 strides, all multiples of 4 offsets unaffected moby class IDs in one slot per chunk type record bytes RETRACTED 17-21% byte positions constant record bytes SURVIVES Only claims that scanned across a record's BODY were at risk. The rest read a record's first three bytes, which an over-read never touched -- it appends to the end. That asymmetry is why the damage was contained to one claim, and it is the argument for preferring claims anchored at record starts. The survivor was the obvious candidate for contamination, so it is worth being precise about it. Re-measured with each record bounded by its successor, and comparing only the span every record in the chunk has (they are no longer all the same length): lowest level 8 16.7% highest 20.0% Still inside the documented band. Previously this lived only in a doc comment on the layout test; it is now asserted, in chunk_records_share_a_layout_measured_by_constant_byte_positions, over all 27 levels with a 10-30% band so a real change reports itself rather than sliding. The module documentation is corrected to the measured range and now says outright that records in one chunk are not all the same length, since that is the fact a reader would otherwise have to rediscover. 244 tests, clippy clean.	2026-10-13 08:02:31 +02:00
ReaperOfVeriod	4fab4d0359	Fix the record boundaries after all, and retract a claim built on the bug I reverted the record-boundary fix last commit on the grounds that "fixed-length records plus inter-record padding" and "variable-length records" produce the same offset table. That reasoning was wrong, and cheaply so. stride is the FIRST offset delta. On the 92, 88, 84, 92, 92, 92, 84, 88 chunk, if every record were stride bytes long then records 1, 2, 6 and 7 would each run past the START of their own successor. Records are addressed by an explicit offset table; they cannot overlap. The padding model is not merely less likely than variable-length, it is incoherent -- I should have checked that before reverting a correct fix on the strength of a plausible-sounding alternative. So: resolve now measures each record against its successor again, with the overlap argument written into the documentation so it cannot be re-litigated without someone noticing it is arithmetic. THE RETRACTION, which is the substantive part: Three tests broke. Two were straightforward, but the third was not. * constant_positions indexed records as if they were all the same length. Now that they are not, it compared past the short ones. It takes the minimum length instead. * "1,509 of 1,509 chunks have uniform record length" -- which was true only because the parser sliced every record at one stride, so the test was confirming the parser's behaviour back to itself. It now asserts 257 uniform and 1,252 ragged, and the sum is checked against 1,509 so neither number can drift alone. * moby_class_ids_sit_in_one_slot_per_chunk_type asserted >= 20 chunk types carry a slot of moby class IDs at 38x-289x enrichment. It now finds 2, of which 1 clears 100x. RETRACTED. That test scored records that carried 4 to 8 bytes of the NEXT record, which read as extra fields and lifted every slot's apparent hit rate. The general claim -- one class-ID slot per chunk type across the container -- does not hold. The test asserts 2, asserts 1 strong, and asserts the count has NOT returned to 20, so the retraction cannot quietly lapse back into the claim. That is a committed finding withdrawn on the strength of a parser bug. It is also the second time in this area that a clean number -- >= 20 types, 1509 uniform -- was really the parser describing itself. 243 tests, clippy clean.	2026-10-13 07:59:23 +02:00

1 2 3 4 5