Nothing here changes what a tool computes; it changes where tools look.
- tools/re-capture: 33 censuses globbed /work/sylph_extract, a path that has
existed nowhere since /work became a clone, so they matched nothing and
printed empty results. They now resolve the disc through a new disc.py
from $SYLPHEED_DISC and exit loudly without it (the #44 fix, generalised).
Nine scripts that imported siblings from the retired Reborn checkout or an
old session scratchpad now import from their own directory. unitgroup.py
only needs the variable when --pak is not given.
- sylpheed-xex: the loader only ever uses the XEX2 retail key. The dead
devkit key and a doc comment claiming a devkit fallback that does not
exist are gone; Project Sylpheed is a retail XEX2, so no XEX1 key either.
- sylpheed-viewer: real_font_rasterizes looked for /tmp/sylph_extract and so
always skipped. It reads $SYLPHEED_DISC now, and passes against the disc.
- Comments and docs that named xenia-rs, the Reborn repository or /work/*.pe
as places to look now name sylpheed.db, Canary's ppc_context.h and the
flat .pe; docs/re/README.md no longer says the native Canary build does not
run.
Historical records keep their original paths: findings that were measured
against /work/xenia-rs/sylpheed.db still say so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
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.
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.
