From 855aadf52359102c223c19bfe441bf34a2c12e6e Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Tue, 13 Oct 2026 18:07:04 +0200 Subject: [PATCH] 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. --- docs/formats/core-data-regions.md | 52 +++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index f5f1889..3f5255e 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -1385,6 +1385,58 @@ So: the four-value claim was right, my retraction of it was wrong, and the retraction was made on a number from the same contaminated set. A retraction is not automatically better than the claim it retracts; it needs its own bounds. +## The located `0xf6` terminator is inside the last packet (2026-10-11) + +**Range measured:** every tie LOD block on the disc, 2,177 blocks. + +**Method:** 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.** The error is not a multiple of 16, so it is not +a length error: a packet ending exactly at the terminator would give a +quadword-aligned difference. The `0xf6 00` pair therefore sits *inside* the last +packet's data, 2 to 16 bytes before its end. + +Two readings fit: either the terminator was located too early, or the last +packet's length over-predicts by an amount that isn't a multiple of 16. The +first is likelier, and the test asserts the measurement rather than the +reading. What still holds either way: the lengths are right for every record +but the last (12,927 of 12,927 record pairs), and the block *starts* are +RAM-confirmed. The block *extent* is what is short. + +**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 it walked to *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: `payload` and `padding` under-report, so anything computed from them +is correspondingly short. + +### Two candidate fixes, both measured and neither clean (2026-10-11) + +**Range measured:** every tie LOD block, 2,169 blocks with a known last packet. + +**Candidate 1: the first `0xf6 00` at or after the last known packet's end.** +Fails. 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 whose length is unknown and therefore sit after the last known end. +The scan lands inside those. + +**Candidate 2: the block's data ends at a long zero run.** Fails. Walking +forward from the last known packet's end to the first run of 8+ zero bytes, the +byte preceding the run is not dominated by `0xf6` (2, 4, 1, 64, 3, 32, 19 ... +across 2,169 blocks) and the runs themselves are mostly 8-31 bytes. The zero +padding after a block is short and irregular, so run length does not +discriminate the block's end. + +Recorded as negative results because both are the obvious thing to try next +and both are dead ends. 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. + ### Corrected header, over all 2,177 blocks +0x00 count multiple of 16 on all; 42 distinct; never zero