434 Commits

Author	SHA1	Message	Date
Sylpheed RE agent	93e9b185ea	re(ui): the rest fallback fires on 2 elements, and "last keyframe" wins there ... Scored candidate rest-pose rules by rendering and correlating instead of arguing, and both results correct something I had published. First, the exposure. The guessing fallback is reached only by an element that is plateau-less AND multi-keyframe -- a single-keyframe element short-circuits at `match len { 1 => first }`. Per screen: title (4) 24 elements 2 plateau-less 0 reach the fallback main menu (5) 16 5 0 EXTRAS (6) 18 5 0 publisher splash (10) 3 2 1 developer splash (11) 7 2 1 So on the three screens the port cares most about, rest() never guesses. That is why three different rules render builds 4/5/6 to identical correlations -- the code is unreachable there, which I nearly read as "the choice does not matter". Second, where it does fire, the last keyframe is markedly better: publisher splash dwell +0.9600 last +0.9982 maxalpha +0.9600 developer splash dwell +0.9643 last +0.9758 maxalpha +0.9643 That refutes my own earlier refutation. I had killed the last-keyframe rule by arguing it makes palogo_anima_eff invisible while its two siblings stay lit, which looked like an artefact. The capture says otherwise: making it invisible is what improves the match. The sibling symmetry was my expectation, not evidence. Caveat kept in front: both captures are single frames of a transient animation, so this fixes which pose matches THOSE frames, not which is canonically at rest. Default unchanged -- better on both screens where it fires and identical on the other three, but it would move 2 305 elements disc-wide on two measurements. Reachable via SYLPHEED_REST_RULE=last. Also confirmed: all 195 zero-scale rest poses are inside the corrected 2 305 ambiguous population; none is a single-keyframe element. METHOD: score a rule where it can differ, or you measure nothing; and an argument from symmetry is a prediction, not a refutation.	2026-08-29 04:20:27 +00:00
Sylpheed RE agent	0265da31a1	re(ui): refute my own fix for rest(), and correct the defect rate by 65% ... Two corrections from one experiment. A keyframe group is entry -> hold -> exit, and the exit ends invisible: on the five port screens the final keyframe is invisible for 21/24 (title), 8/16 (main menu), 12/18 (EXTRAS), 2/3 and 6/7 (splashes). So the screen as seen is the HOLD, which is why rest_plateau is the right primary rule and why "rest = last keyframe" would empty every screen. That suggested a fix: an element with no hold has no representative pose, so draw nothing rather than guess an endpoint. Tested through compose's visible mask and correlated against the live captures: title +0.9500 -> +0.6839 -0.2661 main menu +0.9460 -> +0.9037 -0.0423 EXTRAS +0.9440 -> +0.9094 -0.0346 Refuted on all three, and the reason invalidates a number I published. An element with a SINGLE keyframe has no adjacent pair, so the plateau test marks it plateau-less -- but its one pose is unambiguously its rest. Suppressing those removes backgrounds and full-screen layers, which is the title's -0.27. no plateau (as published) 3 807 (24.57 %) ... single-keyframe 1 502 trivially at rest, not a guess genuinely ambiguous 2 305 (14.88 %) So rest() guesses for 2 305 elements, not 3 807 -- the figure I gave the port overstated the defect by 65%. Corrected in HANDOFF and the page. METHOD: a predicate over adjacent PAIRS silently misclassifies a one-element list; and acting on a claim is a better test of it than re-reading it -- this flaw survived a census, a write-up and a handoff row, and died the moment the rule was used to change a rendering.	2026-08-29 04:15:58 +00:00
Sylpheed RE agent	714a26769d	re(ui): premultiplied alpha refuted for bit 0x02; parking the field ... A per-sprite premultiplied-vs-straight-alpha flag would matter a lot to a port and has a sharp static signature: premultiplied means RGB <= A everywhere. Over the 170 decoded GP_TITLE textures that pair to a flag word: bit SET n= 61 mean %(RGB>A) 55.52 median 52.52 bit clear n=109 mean %(RGB>A) 33.66 median 30.17 Premultiplied requires ~0% for the flagged group. Both groups are far from it and the flagged group violates MORE -- the opposite of the hypothesis. Refuted. What remains is a weak association: flagged sprites carry more bright-RGB/low-alpha pixels, which is what glow art looks like. But the best single threshold classifies 76.5% against a 64.1% base rate -- a 12-point lift with badly overlapping distributions. A tendency, not a rule, and reported with its base rate so it cannot read as more. Noted for whoever returns: "0x02 selects an additive blend" was refuted by blending those sprites additively and finding every measure worse against the capture -- but that ran through a title render since fixed twice (rest_plateau, and the 8AX background the composer drops). The refutation may well stand; it was measured through a renderer with known other errors, so it is worth one re-run if blit ever gains additive blending. Parking the field. Four candidate meanings are dead -- additive blend, eff name in both directions, transient element, premultiplied alpha -- none produced a positive account, and the bit blocks nothing: the port's screens composite at 0.947 correlation against a capture without it. The negative space and the sound attribution method (child order, not size) are written down so a later attempt starts here. METHOD: report a classifier's lift over its base rate; and park a field after N failed hypotheses, saying what was eliminated.	2026-08-29 03:23:40 +00:00
Sylpheed RE agent	489ea12759	re(ui): the eff-name implication for bit 0x02 is refuted disc-wide ... Last iteration I killed the biconditional and reported that the one-way reading survived: all 10 bit-set sprites on GP_TITLE build 4 are eff names, so "bit set => eff name". Checked over the disc, that is false. sprites with a resolvable preceding name 14 709 bit SET & name has 'eff' 2 338 bit SET & name lacks 'eff' 2 657 <-- counterexamples bit clear & name has 'eff' 1 399 bit clear & name lacks 'eff' 8 315 P(eff | set) = 0.468 P(eff | clear) = 0.144 The implication fails more often than it holds. What survives is an association -- 3.3x enrichment -- and build 4's 10/10 was a local naming habit in an 18-element bundle, not a format rule. The counterexamples are the useful part: pv_loading_ring0, pv_loading_light0-3, pv_loading_line, px_bunk_line, px_top_extra. Rings, glows, lights, thin lines -- effect-like artwork that does not carry the eff naming convention. Consistent with the bit marking effect sprites by authoring intent rather than by name, which is a description and not a decode, and is labelled as such. Names here come from the string immediately preceding each T8aD, validated 17/18 on build 4 against the RATC child order; the single mismatch is the known pteff04.t32 -> registered as 8AX case, so this is the element (opt) name rather than the sprite's registered name. That mismatch is itself an independent confirmation of the 8AX finding, reached from the opposite direction. METHOD: a pattern perfect on one screen can be near-chance on the disc; and when an association survives a refuted implication, the counterexamples are the finding.	2026-08-29 03:20:24 +00:00
Sylpheed RE agent	5f701db588	re(ui): kill two candidate meanings for the T8aD 0x02 bit, and fix attribution ... The bit at +0x04 was recorded as a real field with its meaning "not diagnosed", noting ptlogo_back2eff is 0x8830 "despite its name". That note rested on a size match -- and its size is ambiguous, which is the trap this corpus already records. First, a sound attribution. T8aD headers appear in the bundle in RATC CHILD ORDER, verified on GP_TITLE build 4 against an independent property -- each header's decoded dimensions versus the dimensions the named child should have: 18 of 18 match, 0 mismatches. Two of those eighteen share a size (ptlogo_back2eff and ptlogo_back2eff5, both 1133x280), so a size-keyed lookup cannot separate them; ordering can. Index 12 is back2eff5 (0x8832, bit set), index 14 is back2eff (0x8830, bit clear). The documented counterexample is real and correctly attributed -- now on evidence. Two candidate meanings tested and refuted: bit <=> name contains "eff" REFUTED: ptlogo_back2eff is an eff name with the bit clear. All 10 bit-set sprites are eff names, so the implication holds one way only. bit <=> the element is transient REFUTED: pteff03/pteff03a carry the bit and run to t=250, ramping to a=255 and holding. Up close, the exception pair differs in two header words: +0x04 0x8832/0x8830 and +0x08 0x8083/0x8081 -- layer keys 32899 and 32897. They are NOT duplicates: their alpha summaries agree to one decimal (4.5% opaque, 86.7% clear, mean 19.3) but a pixel compare gives max abs diff 21. Two renditions of one image at one size, which is why the summaries were not trusted. Still not diagnosed, and said so -- but the search space is two smaller and the attribution beneath it is now sound. METHOD: T8aD headers sit in child order, use that not the size; and identical summary statistics are not identical data.	2026-08-29 03:14:40 +00:00
Sylpheed RE agent	421c61a517	re(ui): close the gamma chain from canary's defaults -- the game writes a ramp ... Continues the previous iteration, where the game was measured calling VdGetCurrentDisplayGamma at video init. The remaining link -- does it then WRITE the ramp -- is a GPU register operation (XE_GPU_REG_DC_LUT_RW_INDEX in CommandProcessor::WriteRegister), unlogged and invisible to kernel logging. Two facts from the source close it without instrumenting. 1. The swap-path gamma stage is a PURE LUT. apply_gamma_table.xesli is the whole transform: index by input*255, fetch from a 256-entry ramp buffer, output. No sRGB encode, no second transfer function. 2. The table DEFAULTS TO IDENTITY. CommandProcessor::Initialize fills it with value = i * 0x3FF / 0xFF, and its own comment says the linear default is "what games set when starting with the sRGB (return value 1) VdGetCurrentDisplayGamma". An unwritten ramp is a no-op. So the only transform is a LUT, the LUT is identity unless written, the game queries the display gamma at init, and the capture differs from our composite by gamma 1.34-1.49 -- which identity cannot produce. The guest wrote a non-identity ramp. Labelled an inference, with its weak joint named: it assumes our composite reproduces the PRE-RAMP framebuffer, which it does not exactly. What carries it is the shape -- a systematic ~1.4 fitted on flat patches across three screens is not a compositor bug. The obvious alternative, a fixed sRGB stage in the presenter, fits neither direction: an encode (^0.45) brightens and we measured darkening; a decode (^2.2) darkens far more than 1.4. Direct observation remains available and cheap, and needs the emulator only to boot: a GPU trace records gamma ramps as their own command type, or one log line at the DC_LUT register write would settle it outright. Not done. METHOD: a default value is evidence; and name the weak joint of an inference in the same breath as the conclusion.	2026-08-29 02:53:45 +00:00
Sylpheed RE agent	c6ce000002	re(ui): the game does query the display gamma -- measured, with its control ... Last iteration's corrected experiment, run. Boot with --log_mask=12 --log_level=3 (Kernel logging on, Cpu/Gpu off), which changes nothing about the output and so cannot perturb the capture harness the way the gamma-cvar experiment would have. VdGetCurrentDisplayGamma is called once, at video init: d> VdGetSystemCommandBuffer(701CF830, 701CF804) d> VdGetCurrentDisplayGamma(701CE1F8(00000000), 701CE1F0(0)) d> VdSetDisplayMode(40000000) d> VdGetCurrentDisplayInformation(701CF110) The control is in the same log: 359 VdRetrainEDRAM and 358 VdGetSystemCommandBuffer lines, so an absent call would have been visible. Per the export's own comment the returned type is "used in D3D SetGammaRamp/SetPWLGamma" -- the game asks the question a ramp-builder asks, at the moment one would ask it. Still open, and stated: whether it then WRITES the ramp, and whether the measured gamma 1.34-1.49 is that ramp. The write is a GPU register operation (DC_LUT), invisible to kernel logging; a GPU trace records gamma ramps as a command type (TraceWriter::WriteGammaRamp), which is where to look next. Worth its own METHOD line: this had been parked behind "needs the emulator to reach a menu" for several iterations, and it needed the emulator only to BOOT -- video init happens in the first seconds. A blocker that stops one experiment does not stop every experiment in the same area.	2026-08-29 02:51:32 +00:00
Sylpheed RE agent	93b0a6b20f	re(ui): the gamma confound is refuted from source -- canary applies none of its own ... I had parked the tone-curve finding behind "this may be the emulator, not the game: canary applies kernel_display_gamma_type = 2 (BT.709) on output", with a planned run setting it to 0 and re-fitting. Reading the source kills both the confound and the experiment. VdGetCurrentDisplayGamma_entry is a kStub GETTER the guest calls (xboxkrnl_video.cc). Its own comment: "Used in D3D SetGammaRamp/ SetPWLGamma to adjust the ramp for the display." The cvar is a value REPORTED TO THE GAME, which then builds its own ramp. Canary's role is downstream: the guest writes DC_LUT, command_processor.cc reads it into gamma_ramp_256_entry_table_, and the swap path applies it via swap_apply_gamma_pipeline_layout with apply_gamma_table.ps / apply_gamma_pwl.ps compiled in. So there is no emulator-side BT.709 post-process to subtract, and any gamma in a captured frame is a ramp the game installed. What is NOT established, and the reach is stated: that this game installs a ramp at all, or that the measured 1.34-1.49 is it. The run logs cannot say -- kernel exports log at Debug and this harness masks Kernel logging (log_mask = 13, per boot_menu.sh's own comment), so their silence is guaranteed regardless of what the game did. The planned experiment was wrong in design: changing the cvar changes what the GUEST is told and therefore which ramp the GAME builds, so it could never isolate a stage that does not exist -- and it perturbs the capture harness, since skip_intro classifies movie-vs-static on an absolute rmse threshold that a brighter frame biases. The right run changes nothing about the output: LOG_MASK=12 LOG_LEVEL=3 and look for the call and the DC_LUT writes. Also for the port: the ramp depends on the display type the game is told, and canary hard-codes TV/BT.709 where hardware uses a console setting. So this is a display profile, not a fixed property of the game. METHOD: read what a cvar does before building an experiment around it; and an absence in a log is only evidence if the log would have shown it.	2026-08-29 02:44:30 +00:00
Sylpheed RE agent	3490fba9e3	re(ui): settle 8AX vs ptbase statically -- the game draws the full-res one ... I had parked this as "needs a per-draw capture recording texture base addresses". It did not. 8AX (1280x720) and ptbase (640x360 at 200%) are the SAME artwork at two resolutions, which is exactly why comparing either against a capture is inconclusive -- and why comparing their DIFFERENCE is not. Compute 8AX - upscale(ptbase), the detail only 8AX has, and ask whether the capture contains it. Both candidates are first mapped into the capture's tone domain with the measured gamma; without that the residual is dominated by the tone difference and the test is blind. main menu corr +0.0475 controls +0.0032 shift, -0.0075 flip 68% of ceiling title corr +0.0634 controls +0.0095 shift, +0.0086 flip 68% of ceiling Two independent screens, both at 68% of the theoretical ceiling (sd of the 8AX-only detail over sd of the capture residual), 7-15x their matched controls. The controls preserve spatial correlation and destroy only alignment, so they are what "no signal" looks like. So the recommendation changes: resolve the name and draw 8AX at 1:1. Upscaling ptbase 2x is wrong, not merely softer. Still do not draw both -- an opaque layer over an identical one costs fill and hides later changes, and ptbase's element is the one carrying the keyframes, so a consumer needs its timing with 8AX's pixels. Also recorded and withdrawn: a cruder pixel-pair test gave 0.00-0.72 for upscales, 0.98 native and 1.01 for the capture -- apparently decisive. Additive noise raises both terms of that ratio equally and drives any value toward 1; fitting a noise term, both "native + noise" and "bilinear + noise" reproduce the observed numbers. The conclusion is right, that test does not establish it, and it is in REFUTED because the number looks conclusive and is not. Not shown: whether ptbase is also drawn underneath. 8AX is ~86% opaque and carries the same art, so it would hide it either way.	2026-08-29 02:40:53 +00:00
Sylpheed RE agent	aaaa08b164	docs: the UI decode's own evidence images were unreachable -- 11 links repaired ... The brief's rule is to commit reference data beside the finding so the port can be built without a disc. Nothing had ever checked that the docs' cited artifacts actually exist. doc_link_check.py walks every markdown file under docs/, resolves each relative link, and reports targets that are missing -- and separately targets that resolve to a ZERO-BYTE file, which looks fine in any listing. links resolving 1038 -> 1049 missing targets 16 -> 5 empty targets 0 -> 0 +11 resolving and -11 missing against 11 edits: the counts pair, which is the confirmation the pass did what it claimed and touched nothing else. Two of the sixteen were the evidence for the UI layout decode itself. structures/ui-rat-layout.md is what the port is built on, and its two figures -- backing "the tutorial PAUSE menu rebuilds pixel-accurately from its sprites" and "the same method reproduces the main menu" -- were written as captures/ui-layout/... from a file in structures/, one directory too shallow. The headline evidence for the decode could not be opened from its own document. Eleven links had the wrong relative depth with the target present. Each was rewritten only where exactly one candidate path resolved, so nothing was guessed; the first pass left three alone because equivalent spellings (captures/../captures/x) failed to collapse, and a second pass normalised them. Five remain genuinely absent and are left rather than invented: two point at MEMORY.md outside the repo, one at a header in the separate xenia-canary-native tree, and two name documents that were never written (weapon-datasheet-runtime.md, canary-build-verified-env-confound.md). None is port-relevant. A missing document is a different problem from a bad path and is not something a link fix should paper over.	2026-08-29 02:34:16 +00:00
Sylpheed RE agent	7373035868	re: the port was still being told SE audio is undecodable -- it is not ... A resolve-check on HANDOFF's own rows. Q8 read "SE audio is undecodable from the disc -- no XACT container exists anywhere". menu-audio-cues.md retracted exactly that ("### Retracting 'cannot be extracted'") and locates three cues in Static.slb that decode to PCM: d-pad move 0x1ec0 (4 packets), (B) back 0x0ec0 (2), (A) confirm 0x5d6c0 (6), all mono 48 kHz. The retraction landed in docs/re/ and the page the port reads kept the superseded text -- the fourth time in this corpus. Writing the rule down has not worked, so there is a tool now. handoff_lint.py flags every HANDOFF line making a strong negative claim that links a doc containing retraction language. First run: found the Q8 row, plus one benign false positive (Q3 links a doc whose retraction is about a sprite count, not about the tie-break -- checked, and HANDOFF repeats none of the retracted figures). The lint also caught its own bug first: it reported existing docs as missing because it joined a guessed repo root, so it now resolves links relative to the file as markdown does. Separately, EXTRAS's paint-order risk narrows twice more. Of its 15 tied pairs only 2 overlap, and of those, ptloop01 x ptloop02 are loop* animations compose skips by default -- so exactly ONE tie can be drawn: ptframe3 x ptframe4, overlapping 102x132 px. Against live-extras.png that contested region correlates +0.9622, better than the whole frame (+0.9440) and inside the range of regions where order cannot matter (+0.8502 / +0.9903). Consistent with our order, not proof: correlation cannot see a swap between locally similar art. 15 -> 2 -> 1 -> consistent is now the whole paint-order risk on the five screens, and HANDOFF says so.	2026-08-29 02:31:37 +00:00
Sylpheed RE agent	f7f9b555f6	re(ui): the paint-order tie-break is undecodable from the bundle ... Q3 was delivered as "decoded: a u16 layer key at +0x0A". The audit last iteration showed the key does not fully order a screen -- elements sharing a key are tied, and on the title that tie-break decides two total occlusions. This searches for what breaks the tie, and closes it as a negative with reach. The game paints the five tied ptlogo_back2eff glows in the order eff1, eff2, eff5, eff3, eff4. Three static structures were searched: 1. The declaration table. Entries 14-18 are byte-identical apart from the pivot, which is only half the sprite's own size. 2. The T8aD headers. All five carry identical +0x04 (0x8832) and identical +0x08/+0x0A (32899, the key itself), differing only in position and tile count. Searched exhaustively -- every offset 0x00-0x7f, u8/u16/u32, ascending and descending: fields sorting to the MEASURED order: 0 fields sorting to the DECLARATION order (control): 64 The control is the point: 64 fields can be found that reproduce a known ordering, so the scan finds ordering fields when they exist. It finds none for the order the game uses. 3. The RATC child order -- a genuinely different permutation on other screens -- gives eff1..eff5 here, declaration order again. All three static orderings give eff1..eff5; the game gives eff1,2,5,3,4. That agrees with ui-screen-runtime's conclusion from the other direction: the game builds a reordered child list at load time and paints that. Q3 now reads honestly: the layer key is decoded and orders 4 of the 5 measured bundles exactly; the tie-break within a key is undecodable, and a consumer must use a measured order or accept declaration index as an arbitrary stand-in. The port's exposure remains 2 overlapping tied pairs on EXTRAS. METHOD: an exhaustive field search needs a positive control, or "found nothing" is worthless.	2026-08-29 02:26:19 +00:00
Sylpheed RE agent	ba47bdebe8	re(ui): measure the paint-order hedge -- exact on 4 of 5, and bound the rest ... `compose` claimed the derived paint order "reproduces both measured orders up to ties". That sentence was never measured and was stale by one: there are three measured orders, not two. examples/paint_order_audit.rs checks it. main menu (entries 5, 8) derived == measured 0 inverted pairs developer splash (11, 14) derived == measured 0 inverted pairs title (entry 4) DIFFERS 8, all same-key ties So the claim holds and the exception is entirely ties -- but two of those ties are total occlusions, not near-misses. The tied family is the five ptlogo_back2eff glows (key 32899); back2eff5 is 1133x280 and FULLY CONTAINS back2eff3 (82,824 px^2 = 100% of the smaller) and back2eff4 (152,047 px^2 = 100%). Derived paints it on top of two glows it entirely covers; the game paints it underneath. A tie-break by declaration index can therefore be wrong by a whole layer. The title itself is unaffected -- it has a measured order. The port's actual exposure, per screen: title, main menu and developer splash all use MEASURED orders; the publisher splash is derived but has ZERO ties, so it is fully determined; EXTRAS is derived with 15 tied pairs of which only 2 OVERLAP. Two element pairs on one screen is the whole risk, and that is what HANDOFF now says -- not the raw 15, which would have overstated it 7x. Reach stated: this compares the derived order against orders measured from the game, not an independent derivation, so where no measured order exists only the tie exposure can be checked. Overlap uses pivot*2 as the element size at its resting placement. Stale comment in compose corrected. METHOD: a hedge in a code comment is an unmeasured claim; and count the cases that can bite, not the ones that match the pattern.	2026-08-29 02:22:01 +00:00
Sylpheed RE agent	ee73de50be	re(ui): put a number on the render-vs-capture tone difference ... Closes an observation I left dangling last iteration ("the capture is ~4x darker than the render") and puts a figure on the ❔ INDEX's texture row already carried: exact gamma/sRGB fidelity untested because a hue comparison cannot see it. Geometry first: cross-correlating the main-menu capture against our render over +/-6 px puts the best alignment at exactly dy=0 dx=0, correlation 0.9466. Only the tone differs. Two methods failed before one worked, and both failures are recorded. Three dark patches gave "4x darker" -- the whole-frame best linear scale is 0.914, so three patches from one region are not a transfer curve. A pixel-wise fit over 854,685 pixels then produced a NON-MONOTONIC transfer (render 96-127 mapping brighter than render 128-159) with mean abs error 10-14 for every candidate model. That is edge misalignment, not a tone curve: at correlation 0.947 a bright pixel routinely lands on a dark one. Flat patches fix it -- 16x16 blocks with std < 8 in BOTH images, a threshold chosen from the counts (0/83/404/1055/1788 at std<3/5/8/12/20): main menu 404 patches gamma 1.491 err 0.28 (best linear 0.276, 0.34) EXTRAS 382 patches gamma 1.493 err 0.22 (best linear 0.273, 0.28) title 506 patches gamma 1.338 err 1.08 (best linear 0.842, 9.02) Reach, stated because it is narrow: those patches span only render values ~0-60, where gamma and a plain scale are nearly indistinguishable -- the two menus decide nothing (0.28 vs 0.34, 0.22 vs 0.28) and only the title separates them. Nothing constrains midtones or highlights. The held-out control FAILED TO DISCRIMINATE and is reported as such: the splash's 2918 flat patches are pure black (render 0-4), so every model scores ~0.00. That is a test with no power, not corroboration. Confound left open: this compares our composite to what canary DISPLAYS, and canary applies kernel_display_gamma_type = 2 (BT.709). The exponent may be its output stage. The discriminating run -- set it to 0, recapture, refit -- needs one emulator session reaching the main menu and was not done. Classified measured, not decoded; HANDOFF says plainly that a port applying it is authoring.	2026-08-29 01:05:25 +00:00
Sylpheed RE agent	2b4ec20f00	re(ui): a full-screen element is dropped on three port screens -- do not "fix" it ... Audited what `screen render` silently omits on the port's five screens, since an element the game draws but we skip is the one defect class the port agent has actually hit. Everything is accounted for -- kind & 0x4 ghost instances, .prm primitives, loop* animations -- except pteff04.t32 on the title and pteff05.t32 on both menus. Those are kind 0x0, one keyframe, rest a=255, pivot (640,360): full-screen and opaque. Cause: the element declares pteff05.t32, but the T8aD behind its `opt ` link is registered under the name 8AX, so build.sprites.get() misses and compose hits a silent continue. Bytes at 0x0e2035 of GP_TITLE entry 5: opt ... 70 74 65 66 66 30 35 2e 74 33 32 00 38 41 58 54 38 61 44 p t e f f 0 5 . t 3 2 \0 8 A X T 8 a D 8AX is 1280x720 and present in all six title-family bundles; it is a sprite in builds 4/5/6 and never an element. It does not currently show, and that is the useful half. ptbase.t32 is 640x360 drawn at 200% and carries THE SAME ARTWORK: its 2x upscale differs from 8AX by mean abs diff 2.05 (max 80), and our rendered background is pixel-identical to 8AX in every patch sampled. So resolving the name and drawing it in addition would double-draw an opaque full-screen layer -- invisible as a doubling, which is worse than a visible bug. Written into HANDOFF as a do-not-do. The free win, offered and not taken: use 8AX at 1:1 and drop ptbase instead of upscaling a half-res copy. That is a rendering choice and ptbase's element carries the keyframes, so it is the port's call. Not established: which of the two the game actually draws. Both carry the same art, so pixels cannot separate them; it needs a per-draw capture recording texture base addresses, since the two differ in size.	2026-08-29 01:00:36 +00:00
Sylpheed RE agent	6d246c7a97	re(ui): finish the top-level rotation census; record the JP-capture blocker ... Two threads had converged on needing one capture this container cannot take, so this iteration records that and finishes something reachable. BLOCKED, written into MISSION.md rather than worked around: Q1's keyframe time association and the rest() rule for plateau-less elements both now hinge on a running capture of GP_TITLE build 7, the Japanese title. The console language is not settable here -- user_language appears only as DECLARE_int32 at four call sites with no DEFINE anywhere in the tree, and it is absent from the registered cvars in xenia-canary.config.toml. There is no flag to pass, and guessing one is specifically unsafe: run-canary's own header records that xenia calls ShowSimpleMessageBox from ParseLaunchArguments before logging starts, so a bad flag blocks forever with an empty log. Rebuilding canary to add the cvar would be improvising around the blocker; it needs a human decision. Neither question blocks the five menu screens. FINISHED: the disc-wide top-level rotation count, left running four iterations ago as a shell loop over `screen info --geometry` that never completed (it decodes every texture per build). Walking the placement region directly takes seconds. top-level elements with a keyframe group 15 493 carrying a non-zero rotation 2 152 (13.89 %) Both controls pass: GP_TITLE build 4 reports 0 (its rotations are the nested ptloop records) and GP_DIALOG build 0 reports the expected two. The control earned its place -- the first version indexed the pak with a `screen list` BUILD number and got 0 for a screen that has two, because GP_DIALOG build 0 is entry 2. GP_TITLE maps 1:1, which is how the assumption survived. METHOD line added. Two free corroborations of the rotation decode. The rotated population is dominated by tactical-map ship icons -- pbb_destroyer 444, pbr_destroyer 402, pbr_fighter 276 -- i.e. markers rotated to heading, the single largest use of the field on the disc. And GP_TITLE entry 7's Japanese wordmark pieces settle from ALTERNATING tilts: ptlogo3a r = 0, -14, -4, -1, 0, ... ptlogo3b r = 0, +14, +4, +1, 0, ... ptlogo3c r = 0, -14, -4, -1, 0, ... Same magnitudes, opposite signs, all decaying to upright. A misread field does not produce that.	2026-08-28 23:46:54 +00:00
Sylpheed RE agent	b973d8cde3	re(ui): scale 0 means collapsed, not "unset" -- stop drawing it full size ... blit() and fill_quad() both opened with let sx_pct = if kf.scale_x == 0 { 100 } else { kf.scale_x }; so an element whose pose is collapsed to nothing rendered at FULL SIZE. I first described this as "a 1-pixel sliver", reading the .max(1) in the size arithmetic two lines below -- the guard above it meant .max(1) never saw a zero. Read the whole function, not the lines you went looking for. Control run before the change: if 0 meant "unset", something on the disc would use it throughout. Nothing does. elements with a keyframe group 15 493 at least one keyframe at scale 0 2 166 EVERY keyframe at scale 0 0 zero is a transient the element grows out of 1 762 ptlogo_eff3.t32 runs 0% -> 200%. An "unset" marker no element ever uses throughout is not a marker. Both functions now return without drawing when either scale is 0. Reach: 24 of 24 renders byte-identical across GP_TITLE (all 16 builds), GP_PAUSE_MENU and GP_OPTIONS -- additive on every screen the port needs. 195 elements have a guessed rest pose at scale 0 and 126 of those have a non-zero alpha, so the old code painted them; all 126 are in GP_READY_ROOM.pak, which S1 already declared a no-go. They are tactical-map sprites at sx=0/sy=100, mid-horizontal-wipe, that the coercion drew full-width. So: a real correctness fix with no visible effect on the menu port. Suite green, 122 passed / 0 failed across 3 suites at commit time.	2026-08-28 23:38:37 +00:00
Sylpheed RE agent	c2c69b02be	re(ui): size the rest() guess disc-wide, and refute my own proposed fix ... Follows up the defect found last iteration: rest()'s dwell fallback is guessing whenever it runs. Two things were open -- how big it is, and whether "rest = the last keyframe" is the fix. Both are now answered, and the second is answered no. plateau_census.py walks the placement regions directly instead of going through `screen info --geometry`, which decodes every texture and cannot do a disc-wide pass in reasonable time. Its control reproduces GP_TITLE build 7's three fallback elements and names ptlogo_eff3.t32 among them before counting anything. elements with a keyframe group 15 493 no plateau -> rest pose is guessed 3 807 (24.57 %) ... current rule returns invisible 1 711 (44.9 %) ... current rule returns scale=0 195 ( 5.1 %) the two candidate rules agree 1 911 (50.2 %) 195 elements get a rest pose with scale 0%, which is not a pose. And disc-wide the choice of rule is not cosmetic: the candidates agree half the time. But the port's exposure is one element. Across main menu, EXTRAS, title and the developer splash, 14 elements are plateau-less and the two rules agree on 13. The single disagreement is palogo_anima_eff.t32. And "last keyframe" loses there, on a control that needed no new capture: the splash carries three sibling glows with identical structure and identical times -- palogo_gamearts_eff 15:a=0 30:a=255 45:a=255 -:a=0 plateau -> visible palogo_seta_eff 15:a=0 30:a=255 45:a=255 -:a=0 plateau -> visible palogo_anima_eff 15:a=0 30:a=255 45:a=212 -:a=0 no plateau -- differing in one byte. "Last keyframe" makes anima alone invisible while its two siblings stay lit. The capture agrees weakly: box-mean ratios capture/render are gamearts 0.717, seta 0.723, anima 0.772, and a glow we drew that the game does not would put anima below its siblings, not above. So the defect is measured and the fix is still undecided. Nothing in the decoder changed.	2026-08-28 23:23:55 +00:00
Sylpheed RE agent	b947fa8e8e	re(ui): withdraw the render evidence -- rest()'s dwell fallback is unsound ... Last iteration I reported a 13.1% render change in GP_TITLE build 7 as evidence AGAINST the keyframe-time shift, arguing that language twins should match in brightness. Withdrawn. Localising the diff to an element shows it is not about the time association at all. The element is ptlogo_eff3.t32, a transient bloom: 46: (98,42) 100%,100% a=0 61: (108,72) 0%,0% a=0 103: (108,72) 200%,200% a=255 r=80 -: (108,72) 0%,0% a=0 r=150 No two adjacent poses are equal, so there is no plateau, and rest() falls through to its longest-dwell fallback. The longest gap is 61->103, during which the sprite grows from nothing to 200% at full alpha and then collapses. The rule returns whichever end of that movement the indexing lands on: the invisible frame as decoded, the 200% peak shifted. An 896x389 sprite at 200% is larger than the screen, which accounts for the entire 13.1% and the entire 4.9-unit luminance gap. I was comparing a heuristic against itself. The defect generalises, and structurally. A dwell gap is time spent interpolating FROM pose k TO pose k+1; neither pose is held during it unless the two are equal -- which is a plateau, and the plateau path has already returned by then. So the fallback is guaranteed to be guessing every time it is reached, under any reading of the times. Every element with no two adjacent identical poses has a guessed rest pose, in our renderer and in anything built from it. Consequences: the case FOR the shift (26x on the hold:fade-out ratio) is no longer opposed by render evidence -- 10 of 11 builds byte-identical, the 11th differing only through this heuristic. It is still not adopted, now because it flips this element to the visibly wrong answer, so the shift and a decision about plateau-less elements must land together, and neither half has a capture to verify against. Default-mode suite green (122 passed, 0 failed across 3 suites so far).	2026-08-28 23:10:41 +00:00
Sylpheed RE agent	f11fde51e5	re(ui): rotation is not nested-only, and the pivot-anchored scale is measured ... Two corrections and one new confirmation, all from finishing the sweep I left running last iteration. Refuted, by my own sweep, within the hour: "rotation appears to live only in nested .rat leaf records". That held for GP_TITLE, GP_BUNK and GP_CHALLENGE -- the three archives the sweep had reached when I wrote it -- and fails on GP_DIALOG and GP_DEBRIEFING_PILOTLOG, which rotate top-level elements. Scoping the claim made it cheap to withdraw, but the sentence should have waited for the sweep. Those top-level cases are the best evidence on the disc, and they show up in `screen info --geometry` without a hex dump. GP_DIALOG build 0: pceff03/pceff04 ramp r = 90 -> 30 -> 10 -> 3 -> 0 while alpha ramps 0 -> 255 and they slide into place -- a swing-in settling upright. Build 6: pzeff02 ramps 43 -> 61 -> 75 -> 90 while scaling 112% -> 200% and fading to 0 -- a spin-out. Rows committed as reference data. New: the pivot-anchored scale term in blit, kf.x - pivot*(scale-100)/100, was implemented and reasoned about but never measured, because every element previously examined sits at 100% scale where the term is exactly zero. The ptloop pair scale 600% and 800%, where it is worth 450 and 630 px. Formula predicts centre y = 360.0 for both; capture measures 359.1 and 360.0. Top-left anchoring predicts 810 and 990. Horizontally it makes t-from-position agree with t-from-alpha to 0.33 / 0.65 units against ~8 without it. That agreement does NOT prove linear interpolation -- both fields were inverted through the same linear map, so a shared easing curve cancels. It shows position and alpha ride one shared parameter. Recorded as such. The disc-wide sweep is still running; the count is incomplete, the existence is settled.	2026-08-28 22:46:44 +00:00
Sylpheed RE agent	67fa1a1b0b	re(ui): decode keyframe +12 as screen-plane rotation in degrees ... The rotated quads on the title screen come from the keyframe block after all. The earlier negative -- "every GP_TITLE build 4 element has all three angle words at zero" -- read the right bytes over too small a region: it walked the top-level declaration table, and the rotated elements are the nested leaf records ptloop01.rat / ptloop02.rat. Confirmed against the framebuffer rather than against our own renderer. The two records declare +12 = 30 and -45; the GPU capture submits their quads at +30.26 and -45.28 degrees -- magnitude and sign, two different values. Corroborated by shape in GP_BUNK 117ca14f, where +12 ramps 0 -> 360 with position, scale and alpha constant: a spin in place. Identifying which draw it was needed edge lengths, not bounding boxes: 400x1076 and 400x1444 against pteff03/pteff03a 399x180 at the elements' two different declared scales, 600% (1080) and 800% (1440). The same test names three known-positives in the capture (ptlogo1, ptcopyright, ptbtn00), so it passes its own control. Keyframe gains rotation_deg plus unknown_4/unknown_8, carried rather than dropped. NOT rendered -- ui_layout::blit is axis-aligned only, so the reference renderer and the port will both draw these upright until a rotating blit exists. The census tool ships with the trap that broke its first version: nested RATC blobs are not 4-byte aligned, so an aligned scan found 0/3 of its own control blocks and missed 16 341 blocks. Disc-wide +12 is non-zero in 14.50 % of 83 862 blocks. sylpheed-formats tests, SYLPHEED_DISC set: 131 passed, 0 failed across the 6 suites finished at commit time; the run had not yet completed.	2026-08-28 22:42:00 +00:00
Sylpheed RE agent	5d02d5cd60	re: additive blending refuted, the swoosh is not displaced, and the ... residual is smaller than I said Testing the candidate I raised last iteration rather than carrying it. Blending bit-0x02 sprites additively moves every measure the wrong way -- whole-frame mean diff +0.55 to +1.04, swoosh-band mean +1.83 to +3.98, band edge-correlation 0.6971 down to 0.5578. So the bit is real and independent but does not select an additive blend. I reverted the experiment and kept the word as T8adImage::flags, documented and not acted on; the render is byte-identical to before. Second refutation: the swoosh is not displaced. Shifting the band over plus or minus 80 by 8 pixels peaks sharply at zero, 0.7342, falling to 0.22 at 24 px. So the pivot story is dead twice over -- inert at scale 100, and no displacement to explain anyway. And I have restated the residual, because earlier sections overstated it. The +16 to +34 band tiles I quoted were measured WITHOUT --primitives. With the dim drawn the band's average is nearly right at +1.83; what is wrong is its structure, tiles running -38.6 then +33.8 and cancelling. Six candidates eliminated now and none confirmed. One caveat I owe the port agent about the capture I gave them: it is at t=4.0s, roughly 174 keyframe units into a screen whose elements have keyframes out to t=600. I judged "settled" from mean luminance, which cannot see a thin sprite still moving. It is settled for the bulk of the screen and not proven settled for every element -- which is a live alternative explanation for a structural difference in exactly the band the sweeps cross. METHOD: cargo build passing does not mean cargo test compiles. Adding the field built the library in 1.48s and broke two test-only struct literals; cargo test failed with exit 101.	2026-08-28 22:00:55 +00:00
Sylpheed RE agent	e0d02dce71	re: a candidate blend flag -- T8aD header +0x04, bit 0x02 ... Continuing the swoosh. Last iteration ended with "the next step is finding where a blend mode would be encoded, and I do not know the format carries one". It does carry a candidate. The kind field is not it -- the swoosh sprites are kind 0x0, the same as ordinary ones. But the T8aD header word at +0x04 splits the title's sprites exactly along effect versus normal: pteff01, pteff03a, ptlogo_back2eff1..5 and both ptlogoall_eff are 0x8832, while ptlogo1, ptlogo2, ptlogo_tm, ptbase2, ptlogo_back2 and ptcopyright are 0x8830. One bit, 0x02. Disc-wide it behaves like a real flag rather than an artefact: 19216 sprites, 18 distinct values, bit 0x02 set in 27.1 percent, and it toggles against otherwise identical words -- 0x8830 against 0x8832, 0x0830 against 0x0832, 0x0810 against 0x0812, 0x0030 against 0x0032. Marked as correlation and not decode, because nothing here shows the bit MEANS additive. The one thing that makes it more than a guess is ptlogo_back2eff, which carries 0x8830 despite having eff in its name -- so the split is the field's and not my pattern-matching on names. The test is to blend bit-0x02 sprites additively and re-correlate the title against the plate-free capture. METHOD gets the trap that cost the first attempt: searching for a sprite's name and taking the next T8aD returns the SAME header for every sprite, because the names all live together in the declaration table. It failed its own control at once -- different sprites reporting identical dimensions -- and the fix was to match on width and height instead of on proximity.	2026-08-28 21:46:18 +00:00
Sylpheed RE agent	5414db34bf	re: the rest() fix gets its disc-wide check, and one question back to the ... port agent Closing the two things I flagged as unconfirmed when I committed the fix. The unit gate is green: cargo test -p sylpheed-formats with SYLPHEED_DISC set gives 131 passed, 0 failed across six binaries including the disc-gated ones. The earlier background run that produced an empty log had died with SIGTERM, which is why it looked like nothing happened. And the disc-wide check the classification requires. Reimplementing both rules over every RATC bundle on the disc -- 2859 bundles, 13991 elements with at least two keyframes -- the fix moves rest for 30 elements, which is 0.21 percent. Four go invisible to visible. Zero go visible to invisible, which is the safety property I wanted and did not have when I committed. The four are ptframe1 and ptframe2 in GP_TITLE entries 5 and 8, the same pair once per language. That surfaces a discrepancy worth handing back rather than smoothing over. On the English main menu exactly TWO elements satisfy the port agent's pose-equality condition, not six, so their six must span the whole twelve-screen export. That fits their own observation that the timeline and rest differ in exactly one region, the bounding box of ptframe1 and ptframe2 and nothing else. But if any of their other four have a TRANSPARENT trailing run, my alpha rule leaves them alone deliberately -- that exclusion is what protects PAUSE -- so I have asked which screens they are on and whether a capture shows any of them drawn. If one is, the alpha rule is incomplete and needs a third discriminator.	2026-08-28 21:24:42 +00:00
Sylpheed RE agent	4bc970688f	re: rest() fixed -- a trailing keyframe run is the hold when it is ... VISIBLE, not when its pose repeats The port agent's report was right about the defect and about which elements it hits, and its proposed condition does not survive the case the exclusion was written for. Their test -- the final untimed keyframe has the same pose as the last timed one -- is also true of pgptitle.rat, whose trailing run is two identical transparent frames. Adopting it would erase the word PAUSE again, which a committed capture disproves. What separates the two is alpha: an exit fades the element out so its last keyframe is transparent, while an element with no exit ends on the pose you can see. So rest_plateau now accepts a trailing run exactly when it is visible. Verified against a capture rather than against another renderer, which is the point their own report made: ptframe1's rest moves from (620,108) t=16 to (440,108) t=62; the changed pixels are 10082 in a bounding box of x 440-839, y 108-577, which is exactly the 400x470 at (440,108) they predicted; and correlation against main-menu-oracle.png over that region improves from 0.9596 to 0.9748. The PAUSE wordmark is unchanged across all three pause builds. This also closes a question ui-paint-order-key.md has carried for a while, that ptframe1 and ptframe2 rest at alpha 0 while the capture shows the menu frame plainly. One trap cost most of this iteration and goes in METHOD: CARGO_TARGET_DIR is redirected in this container, so ./target/debug/sylpheed-cli is hours stale and every render I made against it was old code. Byte-identical before and after reads as "no effect" when it actually means "you ran the old binary". The full disc-gated test suite was still executing when this was committed; the verification above is artifact-based.	2026-08-28 21:19:00 +00:00
Sylpheed RE agent	ed4e5c7b37	re: build 4 captured without the plate, and keyframe groups hold rather ... than loop The port agent ranked a plate-free capture of build 4 above any further static RE, so that came first. B from the main menu returns to the title and the plate fades in a beat later, which opens a clean window. Recorded at 20 fps from the press: the art appears at 1.10 s, builds in to 3.70 s, sits settled and unobstructed until 5.00 s, and the plate arrives at 5.10 s -- the band jumps from 282 to 3755 bright pixels. Committed the frame at 4.0 s as the reference for the cyan glow slab they report drawing and the game not having. Their other sub-question -- whether a keyframe group loops or holds -- falls out of the decoded sweeps plus a measurement I already had, and the two agree. ptloop01's final keyframe parks pteff03.t32 at x=1521 and ptloop02's parks pteff03a.t32 at x=-839, both off-screen on a 1280-wide design; and over 18 s of settled title the centre tiles sit at sd <= 0.01 when a looping group would recross the screen every 7.5 s. So groups HOLD at the last keyframe. The loop*.rat name is misleading. Also recorded, in the corpus rather than only in their report: the rest_plateau bug, with their exact identifying condition -- the final untimed keyframe has the same pose as the last timed one -- the six elements it misses on main_menu, and the bracket it drops. That closes an open question ui-paint-order-key.md has carried for a while about ptframe1 and ptframe2 resting at alpha 0 while the capture shows the frame plainly. Same two elements, same cause. Not fixed yet; the change is in ui_layout's rest(). And a METHOD line I would not have written myself: two renderers agreeing is not evidence the field is right. Their composite and screen render matched to 3/255 on main_menu and both omitted two elements the game draws, because both read one field through one decoder.	2026-08-28 21:05:35 +00:00
Sylpheed RE agent	1b95001feb	re: the last keyframe time is the chunk terminator -- observed, not ... assumed Continuing the pulse's cycle length, which I had called a structural limit of the format. It is, and now I can show it rather than assert it. Dumping past what I thought was the final keyframe found an EIGHTH block: fade 0x00ffffff at the same position, so the glow returns to fully transparent and the pulse is a closed cycle rather than a one-shot ramp. That is worth having on its own -- the port knows the animation ends where it starts. And the eighth block's time slot contains the four bytes "end ", the record's ASCII terminator. So the corpus's rule that a group's last block has no time of its own holds here in a second form: not the next group's element index, but the chunk terminator. The value does not exist. That goes into ui-rat-layout.md, because it generalises beyond this record. The measured 2.3 s would need a final step of about 33 units. I have written that number down explicitly labelled as fitted to the measurement rather than read from the file, so nobody later re-derives it as a decode. One thing I had half-assumed and can now rule out: the word at +0x004 is not a keyframe count. It reads 60 here with 8 keyframes and 30 in the loop records with 3. Unknown, and marked so.	2026-08-28 21:02:14 +00:00
Sylpheed RE agent	b302558d26	re: the developer splash renders -- screen 1 of 5 finally has a composite ... Two pages of this corpus disagreed. MISSION says the splash "is the RATC screen, which already renders"; ui-paint-order-key.md says it "cannot be rendered by screen render at all". Running the tool both ways settles it. screen list --all shows all 16 GP_TITLE entries instead of 12, and the four the default listing drops are the splash, each half shipped twice: entries 10 and 13 are the white SQUARE ENIX publisher logo, entries 11 and 14 the GAME ARTS / SETA / studio anima developer logos. Entry 11's seven elements are the three logos, their three _eff glows and the palogo_eff0.prm backdrop -- exactly the composition ui-paint-order-key.md had measured for the splash without being able to draw it. So the "cannot be rendered" line is wrong and is corrected in place. What is true is narrower and worth keeping: the splash is invisible to the DEFAULT listing because is_build wants a .rat child, so anyone who does not pass --all concludes it is missing. That goes in METHOD -- a default filter can hide a whole screen and the corpus will record it as absent. The payoff is for the port rather than for the RE: the first of the five screens now has a reference composite, which it did not have. Marked amber on one point -- there is no framebuffer capture of the splash in this repo, so the match to the running game is by description against the milestone-1 notes, not by pixels.	2026-08-28 20:29:33 +00:00
Sylpheed RE agent	86e52b01d0	re: the menu's music is BGM_103 -- found by accident while chasing Q6, ... confirmed three ways Chasing where the event code comes from, sub_821C5580 turned out to do two things worth having. For Q6 it arms the outer gate: li r11,3 ; stw r11,16(r28) is exactly the value sub_821C7850 tests before dispatching, which answers the "what does this+16 == 3 gate on" question I left open last iteration. It then passes r5 = [r27+4], an event read out of a structure, so the vocabulary is still not enumerable. Of the four callers of sub_821C7850, three pass constants -- 0, 0 and 5 -- and this one does not. The accident is a few instructions earlier: li r5, 1103 into a sound-play call. 1103 is a BGM cue id, BGM_103. That closes a residual I had written off as undecodable: which bank the menu plays. The cue table genuinely cannot say, since its BGM entries are numeric -- but the code can, and it checks out three independent ways. The census says BGM_103.slb is two waves of 3876864 and 3930112 bytes; the XMA probe at the main menu saw two stereo streams of 3876864 and 3930112 bytes. Byte for byte on both. That also corrects me. bgm-two-stems.md said those observed sizes matched no bank's declared waves and inferred the decoder gets a window rather than a whole wave. Wrong on both counts -- I had checked only the BGM_0xx rows of the census because that was the block on screen. METHOD gets it: check a measurement against the whole reference set, not the part you happened to be reading.	2026-08-28 20:10:41 +00:00
Sylpheed RE agent	0d7199bc22	re: the UI sound effects ARE extractable -- retracting "cannot be ... extracted", and the tool was in the build all along Two iterations ago I closed Q8 by declaring the SE audio undecodable: Static.slb has no wave boundaries, there is no XACT container anywhere, and I said the index "exists only at runtime" as though that put it out of reach. The disc half of that stands. The conclusion did not. This build of Canary carries a cvar called xma_param_probe, added by this project, whose own comment says it logs each XMA stream's parameters and head bytes so raw sound.pak entries can be matched to real decode params. It has been sitting in the startup CONFIG DUMP of every log I have read this session. Run with it, driving the main menu: a d-pad move spawns a new mono 48 kHz stream of 4 packets / 8192 bytes, and B spawns a different one of 2 packets / 4096 bytes. Searching their logged head bytes in Static.slb finds each at exactly one offset -- 0x1ec0 and 0x0ec0 -- and the two are contiguous, 0x0ec0 + 4096 = 0x1ec0. So the bank is a packed run of whole 2048-byte packets with no delimiters, which is precisely why the seek scan found nothing: there is nothing to find. A wave is (offset, packet count) and nothing else. That splits Q8's binding cleanly. Event -> WAVE is now measured: the port can have the audio. Event -> cue NAME is still a name match on the authors' identifiers, and the page says so. The same run settled something for Q10 too. Sitting on the main menu, TWO stereo 48 kHz streams were decoding simultaneously. bgm-two-stems.md said that observation was what it needed and that this container could not make it; it can, and a music bank's two waves are now measured as simultaneous rather than only inferred. METHOD gets the general lesson, because it cost two iterations: check what instrumentation the local build already has before declaring a question blocked on tooling.	2026-08-28 19:30:03 +00:00
Sylpheed RE agent	2c4005795b	port: audit the handoff -- four stale statements, a broken link, and the ... residue in one place Every MISSION row is answered, so this iteration checked the deliverable itself rather than opening new scope: an answer that is not reachable from HANDOFF.md has not been delivered, and I have been editing that page by surgical replacement for a dozen iterations. Four things were wrong or stale: - the Q5 row still said initial focus was 2x TUTORIAL, 1x NEW GAME while its own bullet said four boots -- I updated the body last time and not the row; - the Q2 bullet still described the other four main-menu destinations as "likely by name -- an inference, not a measurement", which Q4 has since MEASURED, and it listed GP_MISSION_SELECT as a main-menu destination when MISSION SELECT lives under EXTRAS; - the Q1 bullet claimed that if the game presents at 60 Hz "nothing else on this page changes". That is now false: Q7's declared fade-in lengths are keyframe-derived and would halve. The same bullet also missed that the transition capture is a SECOND independent measurement supporting 1 unit = 1/60 s -- the quad is declared black for 12 units, 0.20 s under the conversion, and the capture measured the plateau at 0.17-0.23 s. Recorded as corroboration, not proof, because the plateau spans two screens' fades and cannot separate them; - bgm-two-stems.md linked ../port/MISSION.md from inside structures/, which resolves nowhere. Also named the two videos actually in scope, since "3.3 GB of video, two files are in scope" is not much use without the filenames. And added a What Is Still Open section. With every row green the residue was scattered across eight pages; it is now one table with why each item is stuck. Two entries share a single unblocker -- an emulator whose audio path can be observed -- and they are the only ones that would change a port decision.	2026-08-28 19:02:49 +00:00
Sylpheed RE agent	b3c8632006	re: a music bank is two stems that play together -- not intro+loop, and ... not something to concatenate Q10, and it starts by withdrawing the question's own premise. BGM_001 is not three sub-waves of 10 KB / 4.47 MB / 4.67 MB: the 10 KB is the bank header. A bank is exactly TWO waves, and across all 32 BGM banks on the disc the two always have the SAME duration -- equal to 0.01 s over lengths from 37 s to 277 s. That alone kills intro+loop and kills two halves of one piece, both of which require unequal lengths. Four banks appear to break the rule and do not: BGM_106-109 are the known leading-region straddle, and the giveaway is that the entry named BGM_107.slb contains BANK id=1108. The seek packet counts pin each join exactly, so they realign to the same two-equal-waves shape rather than being dropped as noise. That trap goes in METHOD. Then the roles, by decoding both waves to PCM. They are sample-synchronous: transient-envelope correlation searched over +/-5 s peaks at lag +0.00 s, and both waves stop at the same millisecond, 167.663 s. Two stems of one performance, meant to sound at once. Wave 1 is quieter, has almost no bass and is far more L/R-decorrelated, which reads as a surround-rear pair or a second intensity layer -- I cannot separate those two from the file, and say so: ChannelMask is 0x0002 on both, and this game's channel metadata is already documented as meaningless. Two things the port needs that are NOT on the disc, both marked as authored: the track is not a seamless loop (BGM_001 fades out and is followed by 6.15 s of silence, no loop-point field found), and nothing names which bank the menu plays -- all 32 BGM cues are numeric.	2026-08-28 18:13:10 +00:00
Sylpheed RE agent	bebdb18a02	re: Q3 was already answered in docs/re -- deliver it, and test it on EXTRAS ... The handoff had Q3 as "runtime-solved only". It is not: the layer key at +0x0A of the T8aD sprite header, stable-sorted, is a file-derivable paint order, already checked against five measured orders and already driving the compositor for every build on the disc. That answer had simply never reached the page the port agent reads. The new evidence is EXTRAS -- the first screen composited from the rule alone and scored against a framebuffer capture the rule had never seen. 0.9620 at zero shift, against a same-tooling control of 0.9657 on the screen the rule was fitted to. Written down with its limit rather than its headline: align_to_capture correlates edges, and a paint-order change moves blends, not edges, by =<45/255 on a few per cent of pixels. So the score is evidence for placement and only CONSISTENT with the order. The sharp A/B needs a rebuild and is named in the doc instead of being claimed.	2026-08-28 17:39:29 +00:00
Sylpheed RE agent	306a8a5661	viewer: open the whole sound bank, not just the voice half ... The library enumerator kept only names containing VOICE or \Briefing\, and read eng\sounds.tbl unconditionally. So the Explorer could reach 4382 of the 9519 banks in sound.pak: no music, no jingles, no sound effects, and no Japanese voice at all -- roughly half the disc's audio had no route to the UI. `slb::list_audio_entries` now returns every named bank with the category its path implies (Music / Jingles / Sound effects / Radio / Dialogue / Movie voice / Briefing). `list_voice_clips` is that, restricted to the spoken categories, so its existing test still guards the old behaviour. The 36 root banks carry no language component and appear whichever table is read; the window gets an English/Japanese switch that re-reads the other sounds.tbl, since the table name IS the selector. Two defects the decode found, both recorded in docs/re/structures/sound-pak-contents.md: * `Static.slb` -- the SFX bank -- declares 616768 bytes more than sound.p04 holds. Not our extraction: p04 matches the ISO's own directory record, and a sweep of every pak on the disc finds this one entry over-running and no other. It is the highest-offset entry, so its comp_size is an allocation size. A short read is now allowed for the tail entry ONLY; any other overrun stays an error, because clamping it would hide real damage behind a half-decoded asset. The bank went from unreadable to 514 s of audio. * the left-channel downmix was applied to everything. Right for voice (mono content however stored), wrong for music (a real stereo mix, half of it discarded). The caller now decides from the category. 35 of the 36 shared banks decode; JNGL_001 does not, and says so in the player instead of the panel silently closing. Its payload is not a whole number of XMA1 packets from any known data offset, so it is likely not a plain headerless stream -- written up rather than papered over. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 16:28:20 +02:00
Sylpheed RE agent	03ece95c06	Merge branch 'auto/idxd-unnamed-keys' ... # Conflicts: # docs/re/INDEX.md	2026-08-28 15:27:51 +02:00
Sylpheed RE agent	8124b85fc7	Merge branch 'auto/regn-reader' ... # Conflicts: # docs/re/BACKLOG.md # docs/re/INDEX.md # docs/re/structures/regn-map-grid.md # tools/re-capture/regn_decode.py	2026-08-28 15:26:35 +02:00
Sylpheed RE agent	245b73243b	Merge branch 'auto/isl-builtins-26-28-29' ... # Conflicts: # docs/re/INDEX.md # tools/re-capture/isl.py	2026-08-28 15:24:55 +02:00
Sylpheed RE agent	0ace5db7c7	re: the 95 BASE_INFO screens partitioned - BASE_INFO discriminates screen-config from table-read ... Item (a): mine the screen population found last iteration. Resolving every one's key list via the string-xref join over its own body gives 298 distinct keys and a three-way split: 95 = 9 corpus-known + 48 new with a readable key list + 38 bare, where "bare" means BASE_INFO and nothing else. The bare 38 are the honest limit of the instrument - a screen whose only catalogued string is BASE_INFO cannot be named this way. The control turned the finding into a law. Only 9 of the 19 loaders the corpus documents appear among the 95, and which nine is not arbitrary. The nine that reference BASE_INFO all read a SCREEN's own configuration: debriefing, career, save, medals, evaluation list, gamma, POINT_RANKING, CLEAR_TIME_RANKING, hangar. The ten that do not all read a DATA TABLE: unit definitions, weapon datasheet, AIParams, stage settings, chatter, PlayerParams, ControlTweak, the PG* HUD roster, material slots, and the leaderboard. 9/9 and 10/10, both off-diagonals empty. The leaderboard falling on the table side is a check rather than an exception - its own doc records that all 18 of its names are tables.pak names, so it is a table reader that happens to paint a screen. That exclusion is what last commit's "universal screen marker" claim was missing. 48 new screens are named by their most distinctive keys, including the title screen (sub_821C4EB0: TITLE_SCREEN/TITLE_MENU/LOADING), the ready room (sub_821D6D28: SCRIPT_ID/SCRIPT_PATH, confirmed independently by its own error string silph::GamePart_ReadyRoom::Impl::PrepareScript), movie subtitles, the three menu modes STANDARD/EXTRA/TUTORIAL, the speaker window, loadout and gallery views, mission select, and an equip screen carrying the game's own typo EQUIIP_LIMITATION. One caution worth recording: a high key count is not a rich screen. The two 27-key entries sub_82297550 and sub_822A2F00 resolve to pure coordinate pairs (1080,163 / 734,502 / 1164,403) - a layout table, not configuration. Read the values before trusting the rank. Still open: the 38 bare screens, and whether the EX_ in EX_MENU_DISABLE_SKIP and EX_LETTERS is the same EXTRA mode word as +184. All seventeen artefacts byte-identical.	2026-08-28 11:58:51 +00:00
Sylpheed RE agent	80406ce3e4	re: the RTTI route is dead - BASE_INFO enumerates 95 screens instead ... Item (a): can the vtable scan name the corpus's anonymous classes? The route I proposed last turn - "the RTTI behind those two anon classes" - does not exist. Of all 1150 catalogued vtables, 1150 carry an ANON_ class name, 0 have rtti_present set, and 0 have a non-empty base_classes_json. Not one named class, not one RTTI flag, not one base-class edge in the whole table. Withdrawn as unrunnable; the ANON_Class_XXXXXXXX labels are synthesised, not recovered. The sibling methods cannot name a class either: slots 0, 2, 3 and 4 of both EX_ classes reference zero strings. Every naming datum sits in slot 1, the method the corpus already had. Re-verified at the true addresses (0x820A9760 and 0x820A9350) that sub_822814D8 and sub_8227A3A0 are each slot 1 uniquely, and sub_82286BC8 is in no vtable. What the shape DID give: both classes are 5-slot with an exactly-88-byte slot 0. 83 vtables have 5 slots, 16 also have the 88-byte slot 0, 13 of those have a catalogued slot 1, and 10 build a key list. Ranked by key count the two known screens sit at the top and the rest name themselves - a medals screen (MEDALS/ACHIEVED_MEDALS/NEW_MEDAL), an evaluation list (EVALUATION_LIST plus eval_%02d_eval / eval_%02d_points), the gamma screen (GAMMA_RGB/GAMMA_WB), POINT_RANKING, CLEAR_TIME_RANKING, and three bare ones. POINT_RANKING and CLEAR_TIME_RANKING being two separate screens is a direct lead for the open item "which challenge stage is which leaderboard mode": the leaderboard is ranked two ways and each way has its own class. But the obvious follow-on claim - that BASE_INFO marks this family - is false, and the control says so. BASE_INFO is a single string at 0x820A20EC referenced by 95 functions: 10 inside the family, 85 outside, including sub_82286BC8 (the save screen, in no vtable at all) and sub_822AE628 (the hangar loader). So the direction inverts: BASE_INFO is the universal first key of every screen key list, a 95-function population, while the 5-slot/88-byte shape is only a weak filter that catches 10 of them plus 6 non-screens. Enumerate screens by BASE_INFO, not by vtable shape. All seventeen artefacts byte-identical.	2026-08-28 11:41:52 +00:00
Sylpheed RE agent	141a65cb4a	re: the ind_call damage is bounded - no corpus claim was contaminated ... The protective sweep after last commit's refutation. The question was which existing claims the ind_call cross product voids. Answer: none of the ones the corpus makes. Every caller-count claim in the corpus verifies against call edges, with zero ind_call contamination: title-crash-stl-tree sub_82457780 "one caller" call=1 ind_call=0 isl-trigger-queue sub_8226EAB8 "16 callers" call=16 ind_call=0 isl-coroutine-spawner sub_822737C8 "seven callers" call=7 ind_call=0 challenge-mission-gate 0x82175110 "22 callers" call=22 ind_call=0 4 of 4 exact, and not one of the four carries a single ind_call edge. There is a structural reason for that rather than luck. Partitioning the two target populations: 1710 targets have ind_call edges, 12170 have call edges, 103 have BOTH, 1607 are ind_call-only, 12067 are call-only. And all 1710 ind_call targets are vtable entries - 1710 of 1710, zero partials - against a control where only 273 of the 12170 call targets are. So ind_call fires only on virtual methods, and 1607 of them have no direct caller at all, which is exactly why the two EX_ screens came back empty on call and flooded on ind_call. The residual risk is narrow and nameable: the 103 targets carrying both kinds, where a caller count taken without a kind filter would be inflated by about 633. Everywhere else the two populations are disjoint, so a call-based count is safe and an ind_call-based one is meaningless. Rule for future work: always filter kind='call'; and when a function has no call edges, that is a fact about it - it is a virtual method - not a gap to be filled from ind_call. All seventeen artefacts byte-identical.	2026-08-28 11:24:14 +00:00
Sylpheed RE agent	749567e835	re: the +184 writer is blocked - and xrefs.ind_call is a CROSS PRODUCT, not a call graph ... Chasing what supplies the EX_ mode word. Two routes, both measured to have no power, plus one structural fact that did come out. The offset route is dead. stw ..., 184(rN) occurs 301 times in the image, lwz from +184 occurs 351 times, and 115 functions touch both +144 and +184. +184 is an ordinary small offset shared by many unrelated classes - the same shape the corpus already recorded as failing three times. Nothing narrows to a writer. The bigger result is an instrument refutation with corpus-wide reach. Asking xrefs for the callers of the two screens returns 633 sources for EACH, and the two lists are IDENTICAL, which cannot be right. Measuring the relation itself: ind_call rows 1827297 distinct targets 1710 distinct sources 6992 targets with EXACTLY 633 sources 236 236 different functions sharing an identical source count is the signature of an unresolved-indirect-call cross product, not of a call graph. Any reading that treats an ind_call edge as "X calls Y" is void, here and anywhere else in the corpus it may have been used. The control shows the other kinds are sound: sub_82286BC8 has exactly one caller, kind call. And both EX_ screens have ZERO non-ind_call edges - they are reached only through function pointers, which is why the direct graph is empty for them. What did come out: scanning the entries of all 1150 catalogued vtables in the flat .pe, both EX_ screens are slot 1 of their own class - sub_822814D8 in ANON_Class_271D5F25 and sub_8227A3A0 in ANON_Class_CAA8AD62 - while sub_82286BC8 is in no catalogued vtable at all. So the 2/0/0/1 partition from the previous commit reflects a structural difference rather than a coincidence: the two screens that select on the mode word are vtable methods of their own classes and the one that does not select is not a vtable method. Still not settled: what writes +184. Both the offset sweep and the call graph are exhausted for it. A route with actual power would be the RTTI behind those two anonymous classes, or a runtime watch on the field - not another static offset search. All seventeen artefacts byte-identical.	2026-08-28 11:08:18 +00:00
Sylpheed RE agent	35a35f753f	re: the EX_ selection is shown - a mode word at +184 tested against 3 ... result-screens.md left this explicitly open: "the selection has not been shown". It is shown now. Both screens that reference EX_ names carry the same five-instruction idiom immediately before the choice - sub_822814D8 at 0x822815b4 and sub_8227A3A0 at 0x8227a408: lwz r11, 4(rX) the owning object lwz r11, 184(r11) a mode word at +184 addi r11, r11, -3 cntlzw r11, r11 rlwinm r11, r11, 27, 31, 31 r11 = 1 iff [+184] == 3 cmpli cr6, 0, r11, 0x0 bc 12, 4*cr6+eq, <plain> not 3 -> STAGE_RESULT / OVERVIEW else -> EX_STAGE_RESULT / EX_OVERVIEW cntlzw of zero is 32, and rotating left 27 lifts bit 5 into bit 31, so the sequence is a branchless equals-3 test. The equal-to-zero branch takes the plain name, so EX_ is chosen exactly when the word is 3. A partition over the three key-list loaders the corpus already names: loads +184 does not references EX_ names 2 0 does not 0 1 sub_822814D8 and sub_8227A3A0 both load it; sub_82286BC8, which references no EX_ name, has no +184 access at all. Both off-diagonal cells are empty. 3 is the game's own EXTRA. challenge-mission-gate already established the vocabulary for this constant at a three-way switch: == 3 is EXTRA, == 5 or 6 is CHALLENGE, otherwise FILE. So the prefix reads literally - EX_ is the EXTRA variant. That REFINES the doc's tentative reading rather than confirming it. The section proposed "EX_ = the challenge-mission debriefing" by analogy with _EXn on asset names; the measured constant is EXTRA, which in the game's own three-way vocabulary is a DIFFERENT kind from CHALLENGE (5/6). Boundary of what was measured: the EXTRA = 3 constant is established at +144 of the stage-loader class, while the word tested here is at +184 of [object + 4]. Same constant and the same EX/EXTRA naming, but two different offsets in what may be two different objects - that the two fields are the same field is NOT shown, only that both compare a mode word against 3. All seventeen artefacts byte-identical.	2026-08-28 10:51:16 +00:00
Sylpheed RE agent	33671c5086	re: wep_85 is the ONLY declared-but-unshipped asset; the package gaps are unused numbers ... The obvious follow-up to last commit's wep_85 finding: the weapon packages number 00 to 84 with 26 holes, so are those holes cut weapons too? Partitioning every number 00-85 by package-present x named-anywhere-in-the-parsed-pak-data: named in data not named package present 59 0 package absent 1 26 59 + 0 + 1 + 26 = 86, the numbers 00 through 85. The 26 gaps are simply unused numbers, not unshipped weapons - nothing in the data names them at all. The one occupied cell is the one already known: wep_85, named 16 times, with no package. It is an isolated cut, not a pattern, which refutes the natural expectation that finding one cut weapon means finding a family of them. The other zero is worth as much: 0 shipped packages are never named. Every rou_f001_wep_NN.xpr on the disc is referenced by the data, so the package set and the weapon vocabulary agree in both directions but for that single entry. Running the identical test on the craft family gives a clean negative. Every rou_f### number appearing inside an .xpr against every number named in the parsed data: 16 in both, 0 named-but-unshipped, 0 shipped-but-unnamed. The 16 are f001-f004, f101, f102, f104-f106, f201, f202, f301-f303, f401, f402 - the hundreds digit groups them into five families with holes inside each (no f103, no f203). No craft was cut. So across both families the disc ships exactly what it declares, with the single exception of that one weapon. All seventeen artefacts byte-identical.	2026-08-28 10:33:41 +00:00
Sylpheed RE agent	7ba415fbae	re: the last 9 effects are genuinely unshipped; wep_85 accounts for two ... EF_IDX_ proved that prefixes exist, so the residual deserved the same treatment across every package rather than one. Censusing prefixes over all 36 effect-carrying .xpr gives seven in use: EF_IDX_ 223 names mdl_ 45 EF_IDX_mdl_ 45 VolumeLine_ 10 GN_ 10 GN__ 6 bare the rest Testing all nine unlocated names against all seven prefixes: 0 of 9 resolve. That zero has force where the earlier disc-wide zero did not, and for the stated reason - the control shows each prefix genuinely carries names the same search reads (223, 45, 45, 10, 10, 6), so the instrument demonstrably works on the population it is being asked about. The nine are bound by a datasheet field and shipped in no package. Two of them turn out to belong to one cut asset. eff_m010_wep_85 and eff_m011_wep_85 name a weapon, and the weapon is real in the data: Weapon_DSaber_P_wep_85_Beam with 24 uses, its Shell_, WeaponCannonName_ and WeaponShellName_ siblings, and GameModel_eff_m010_wep_85 / _m011_ declaring the two effects. But the weapon packages stop at 84 - hidden/resource3d/ holds 59 rou_f001_wep_NN.xpr files numbering 00 to 84 with gaps, and no wep_85. So wep_85 is a declared-but-unshipped weapon and its two effects go missing with it. This does not contradict "every weapon is placed - 131 = 105+22+0+4". That partition is declared x MOUNTED IN A LOADOUT, which is a different question from whether a package ships. Seven remain with no account: eff_e0044, eff_f0002, eff_f0002_barn, eff_h308, eff_j002_e01, eff_j002_e02, eff_n0071. The .xpr route is now exhausted for them under every prefix the disc uses; a different container or a runtime generator is what is left. All seventeen artefacts byte-identical.	2026-08-28 10:17:20 +00:00
Sylpheed RE agent	23a6cfd979	re: the EF_IDX_ prefix - ptc_pack has 727 names, and the map reaches 128 of 137 ... Censusing ptc_pack's own naming vocabulary turned up a third variant of the prefix trap, and this one had been corrupting a number the corpus carried. 268 of ptc_pack's names do not start with eff_ at all. They start with EF_IDX_, as in EF_IDX_eff_d001_f. A regex anchored at eff_ chops that prefix off and merges distinct names, which is exactly where the earlier figure of 532 came from. Enumerating maximal [A-Za-z0-9_] runs gives 727. The two earlier traps were a STORED name being longer (rot_n001_break) and a BOUND name being a prefix (eff_f0002 inside eff_f0002_barnhaze); this is the third - a prefix the pattern cannot see at all, because its anchor sits in the middle of the real name. Looking each bound name up bare AND under EF_IDX_ resolves 25 of the 34 that were unlocated. The map is now 128 of 137, and the residual is 9, small enough to print: eff_e0044, eff_f0002, eff_f0002_barn, eff_h308, eff_j002_e01, eff_j002_e02, eff_m010_wep_85, eff_m011_wep_85, eff_n0071. All 17 eff_l### are among the recovered. This withdraws my own previous correction. I had recorded Base.xpr (53) as holding more bound effects than ptc_pack (46), and struck out "ptc_pack is the effect library". With the prefixed keys counted ptc_pack holds 71 - it IS the larger library, and the 46 was an undercount from the same truncating pattern. Two shared libraries remains right; which one is bigger does not. The suffix vocabulary: 106 distinct tokens over the 727 names - IDX 223 (the prefix above), _f 137, _e 119, _root 87, _col 54, _mdl 45, _break 43, _ring 38, _ALL 17, _haze 14, _thunder 10. That census counts ALL tokens rather than trailing ones, which is precisely how the EF_IDX_ PREFIX surfaced inside what I had first labelled a suffix list - the mislabel found the bug. Testing the structural candidates the way _hangar was tested, does the suffixed name have a bare parent: _ALL 17 names 17 of 17 _root 87 64 of 87 _break 30 15 of 30 _e 74 0 of 74 _f 61 0 of 61 _root is strictly terminal - 87 of 87, and it never appears mid-name. The compound shapes put it outermost: _e_root 19, _f_root 18, _break_root 13, bare _root 30. So the order is <stem>_[<faction>|<break>]_root and _root reads as a hierarchy marker rather than a variant - though 64 of 87 having a bare parent means it is not simply the parent of an existing node, and _break at 15 of 30 is likewise not a plain destroyed-twin-of-everything. _e/_f never have a bare parent, 0 of 135. That is independent asset-side confirmation of the faction law: an effect is authored per faction and there is no faction-neutral original for either side to derive from. effect-homes.txt changes 5/30 and every line pairs: five values changed (103->128, 34->9, ptc_pack 46->71 and its sort position, the residual header, 3-digit 80->105 of 110) plus 25 pure deletions, exactly the 25 recovered names. All are 3-digit, so the 4-digit line is unchanged at 23 of 27. The other sixteen artefacts are byte-identical.	2026-08-28 10:01:53 +00:00
Sylpheed RE agent	aa478d9444	re: the faction law generalises - 564 of 564, four fields, all six paks ... The previous commit measured _e/_f on one pak and only through the effect binders. Widening the sweep to EVERY string field of every unit object in ALL SIX GP_MAIN_GAME_* paks: value _e value _f UN_e### 198 0 UN_f### 0 366 564 of 564 agree and the mismatch residual is empty. The law is not confined to one field either - it holds separately, at 100%, in each of four: LowerHPFxModel 252 of 252 ShieldHitEffectName 210 of 210 ShieldRecoverEffectName 84 of 84 ExplosionFxModel 18 of 18 The two shield fields were not in the earlier measurement at all, so the law reaches further than the *FxModel family that suggested it. Scope stated exactly, because "general" would overclaim: this is a law about EFFECTS, not about assets in general. The sweep covered every field, and every _e/_f-suffixed value a unit binds turns out to live in those four effect fields. No model, motion or SE value carries the suffix at all, so the faction pairing is NOT shown for those kinds - there was simply nothing to test. UN_n### (TTRL) binds no _e/_f value in any of the six paks: 12 objects, = 2 users, with nothing on either side. That confirms over the whole population what was only a single-pak observation before. Also corrects the ID grammar and reconciles a count. The earlier section reported 42 + 26 + 2 = 70 unit objects using a regex that required UN_<letter>###_<FACTION>_; the looser UN_<letter>###_ finds 71. The extra one is UN_e910_core_ADAN_GeneratorCore, which inserts a sub-kind token BEFORE the faction tag. So the grammar is UN_<letter>###_[<subkind>_]<FACTION>_<name>, and both counts were right for their own pattern. All seventeen artefacts byte-identical.	2026-08-28 09:44:20 +00:00
Sylpheed RE agent	1265512880	re: _e/_f on an effect name is the binding unit's FACTION (94 of 94) ... Chasing the 17 unlocated eff_l### turned up their shape first: they come in _e/_f PAIRS - eff_l101_e + eff_l101_f, and the same for l102, l104, l105, l106, l201, plus _e-only l010/l011/l107/l108 and _f-only l002. Partitioning every eff_<letter><digits>_<e|f> binding by the ID letter of the OWNING unit (one GP_MAIN_GAME_* pak = one user): effect _e effect _f UN_e### 33 0 UN_f### 0 61 94 of 94 agree and both off-diagonal cells are empty. The control reads the factions straight off the IDs: UN_e### -> ADAN (42 objects), UN_f### -> TCAF (26), UN_n### -> TTRL (2, tutorial, binding neither). So an effect ending _e belongs to an ADAN ship and one ending _f to a TCAF ship - the same visual is authored twice, once per faction, which is exactly why eff_l### arrives in pairs. What the 34 unlocated ARE is now also clear, even though where they live is not. They are one job, not a scatter: Generic binds 32 of the 34, Explosion 19, Shell 9, Level_0 and Weapon 2 each. The binder fields rank LowerHPFxModel 252, HitFxModel 144, then JetFxModel_00N and AfterBurnerFxModel_00N. They sit in the six GP_MAIN_GAME_* paks at 130 bindings each plus 32 in DefTables.pak. Since LowerHPFxModel is the damaged-ship effect, the residual is largely the per-faction battle-damage and hit visuals. None of the 34 is a record name and only one is a field name, so they are asset references. Stated plainly: they remain unlocated AS ASSETS. Knowing the family and its naming law does not say where the geometry lives - the .xpr route is exhausted for them and the parsed pak payloads hold references, not meshes. Also fixes a defect in the artefact shipped last commit. effect-homes.txt came back with two equal-count lines swapped: Counter.most_common() breaks ties by insertion order, so the package listing was not deterministic. Now sorted by (-count, name) and verified to regenerate byte-identical twice running. This is the corpus's own rule - any map built by iterating a set or Counter needs sorted() - and the new tool had violated it. The other sixteen artefacts are byte-identical; effect-homes.txt changes only in the tie-break ordering of the five 1-count rows, with every line pairing.	2026-08-28 09:28:39 +00:00
Sylpheed RE agent	e72f0f14be	re: the effect->package map, 103 of 137 - and eff_f0002 was a substring artefact ... Enumerating eff_* names per .xpr across all 166 packages and matching the bound names EXACTLY gives a real home for 103 of the 137, up from the 71 ptc_pack alone accounted for. Only 36 packages carry an effect name at all, and two dominate: Base.xpr 53 ptc_pack.xpr 46 Stage_S28.xpr 2 five rou_f001_wep_NN.xpr 1 each So there are TWO shared effect libraries, not one - and ptc_pack.xpr is the only *_pack bundle on the disc, so no third shared library is hiding. By digit-width: 3-digit 80 resolved of 110, 4-digit 23 of 27. The previous iteration's split survives and sharpens - the four-digit series really does live outside ptc_pack (that zero stands), and now we can say where: Base.xpr. Correction to the previous commit. It reported eff_f0002 and eff_f0002_barn as present in Base.xpr. Both were SUBSTRING artefacts: what the file actually holds is eff_f0002_barnhaze, one longer resource name that grep -l eff_f0002 and grep -l eff_f0002_barn each match inside. Neither bound name is there. This is the corpus's own paid-for prefix lesson arriving from the other direction - last time it was rot_n001 vs rot_n001_break with the stored name longer; here the BOUND name was the prefix. The new map is exact-keyed and does not have this failure mode, so the earlier positive is withdrawn. 34 names remain unlocated, dominated by a family the last pass did not single out: eff_l### with 17 of the 34, then h 4, s 4, j 2, m 2, t 1, and four four-digit names - eff_e0044, eff_f0002, eff_f0002_barn, eff_n0071. Scope note worth keeping: the j 22 / t 14 clustering reported last time was the residual against ptc_pack ALONE; against all packages those families are largely accounted for and l is what is left. Both numbers are right for their own population, which is exactly why a residual has to say what it was measured against. New artefact with its regenerator: tools/re-capture/effect_homes.py -> docs/re/data/effect-homes.txt, which lists all 34 by name. All sixteen existing artefacts byte-identical.	2026-08-28 09:12:15 +00:00
Sylpheed RE agent	7e9d1437c0	re: effects split into two families by digit-width; ptc_pack.xpr holds one ... The open question was how an effect mesh is reached at all, after last iteration's .xpr byte search was refuted by its own control. The corpus already held the pointer: xbg7-mesh names ptc_pack.xpr, a 20 MB shared particle package in hidden/resource3d/. It lists 532 distinct eff_* resources - 527 three-digit, 3 four-digit, 2 unnumbered. Joining it against the 137 effect names the datasheets actually bind: in ptc_pack not 3-digit 71 39 4-digit 0 27 Zero of the 27 four-digit names resolve in ptc_pack, and that series is a closed three-letter set: e (10), f (12), n (5). Since eff_e0033 was found in Base.xpr, the reading is two effect families - a shared three-digit particle library in ptc_pack.xpr, and a four-digit series that lives in the per-model and base packages instead. The instrument passes its own control this time, which is the difference from last iteration. The same kind of byte search demonstrably reads names out of this file - 532 of them - so a zero WITHIN ptc_pack is meaningful in a way the earlier disc-wide zero was not. Among the 39 three-digit misses the letters cluster hard - j 22, t 14, m 2, h 1 - and ptc_pack contains just one j name against 149 m and 81 s, so eff_j### is a third grouping that is almost entirely elsewhere. Not closed: 66 of the 137 bound effects still have no located home, eff_n0071 among them. But the route is now real and has a number on it, and the next step is the eff_j### family and the four-digit series rather than another disc-wide grep. All sixteen artefacts byte-identical.	2026-08-28 08:55:41 +00:00
Sylpheed RE agent	dd542c23a4	re: the unit family is the only schema on the disc; an .xpr search cannot prove absence ... Two exhaustive probes agree on the same 15 records. The six Shift-JIS type words occur in the six GP_MAIN_GAME_* paks and nowhere else, and a disc-wide sweep of every parsed record name for a wildcard shape (???, *, ###, NNN, <...>) returns 7 distinct names - exactly the seven already in the schema: Turret_???, Hatch_???, Bridge_???, Thruster_???, ShieldGenerator_???, Versatile_???, NS_*, each x6. So the weapon datasheet, the arsenal item and StageResource ship NO schema; the unit datasheet is the only structure the disc describes to itself. Wildcard field names are confined to the schema records too - NozzleSpec_???, NozzleFrame_???, CannonFrame_???, MuzzleFrame_???. No untyped gaps either. The full residual is 30 slots and every one holds a sample value rather than a missing type: 28 booleans spelled Yes, plus Generic.ID = Ship_ and Generic.Type = Vessel. The booleans follow one pattern - the six destructible part types each carry the same four-boolean core (IsDestructible, IsInvolved, IsRadarVisible, IsShielded), Turret_??? adds IsAuto, Generic carries only IsDestructible, and NS_* has its own pair AttenuationAlpha / AttenuationVolume. 28 + 2 = 30; 7 fully-typed records + 8 with examples = 15. The third result is a refutation of my own instrument. Testing the four genuinely-undeclared effects against the 166 .xpr packages put eff_f0002 and eff_f0002_barn in Base.xpr and found nothing for eff_e0044 or eff_h308 - but the control kills the negative: eff_n0071, which we measured LIVE as an Explosion record's ExplosionFxModel, also returns nothing from the same search. A known-live name the test cannot find means the test has no power here. Only the positive half counts: eff_f0002/_barn do ship. Nothing follows about eff_e0044 or eff_h308, and the earlier "no mesh" remarks about eff_e0058/_e0059/_e0060 are weaker than written - absent from a byte search over .xpr is not absent from the disc. How an effect mesh is actually reached is now the open question, since eff_n0071 is not a plain name string in any of the 166 packages. All sixteen artefacts byte-identical.	2026-08-28 08:38:26 +00:00