The Ryzom Core .max corpus (ryzomcore_graphics, plus the workspace listings in ryzomcore_leveldesign) spans Max 3-era assets upgraded through Max 9 and finally exported through Max 2010. Twenty years of authoring produced a long tail of files with data that is defective, era-mismatched, or otherwise anomalous — nothing the pipeline can silently ignore without losing fidelity or, on the flip side, spending days chasing bugs on tool code that turns out to be correct against a broken input.
This page catalogs those files, in one place, so future sessions can look up "why does this file behave this way" without re-deriving it from pipeline_max_design.md's session-by-session narrative. Provenance is per-item — most entries reference the design-doc section that pinned the defect through corpus evidence; where a defect is stated without corpus evidence the item says so.
The catalog is organized by defect class, not by file name, because most files' defects fall into a small number of recurring shapes. A file may appear in more than one class.
"Defective" here covers three overlapping shapes:
.max file itself carries wrong or invalid data. The fix, if there is one, lives on the file side (an asset edit), not the tool side. pipeline_max may need to tolerate the input without crashing; it does not need to reproduce a defect the reference exporter also mishandled..max file has been edited since the reference .shape/.ig/.skel/.cmb snapshots in ~/pipeline_export were taken. The tool decodes today's bytes correctly; comparing against the era-frozen reference is the misleading operation. Fix: none needed on either side; the max file is authoritative per design-doc §9 T3 rules."Reference" below means the pre-built export in ~/pipeline_export (or ~/core4_data) that pipeline_max's T3 tier compares against. It is a snapshot of Max 2010 + the reference NeL plugin's output at some point in Ryzom Core's history — not a live evaluation of the current .max.
Cross-refs: PMD §NNw = pipeline_max_design.md section §NNw. MGF §L.N = max_geometry_formats.md Part L, subsection N.
zonematerial-converted-202_dy.maxTwo non-frozen RklPatch nodes (202_DY + a leftover copy 202_DY01), where the format admits exactly one per zone brick. pipeline_max_export_zone errors out; so does the original 3ds Max exporter. The existing reference .zone predates the copy, so an "export failure that matches the reference exporter's own refusal" is the correct behavior, not a bug. Fix: delete 202_DY01 from the .max file. Handled: zone_corpus.py DIFF_BUDGET carries this file. Provenance: PMD §10h "Budgeted deviations".
_puit_carre2/3" pattern) — fy_mairie.max and similarThe base EditableMesh has zero contributing faces (all deleted by the Edit Mesh modifier's MDELTA_CHUNK → 0x0170 deleted-vert bitfield), with the actual geometry created via 0x0130 created-vertex records + 0x0208 created-face records. Not defective per se — a normal Edit Mesh authoring workflow — but historically caused pipeline_max_export_ig and pipeline_max_export_cmb to see an empty world mesh (§10w's earlier decode note misread 0x0210 as created vertices; the correct decode is 0x0130 for verts, 0x0208/0x0210 for faces — see MGF §L.2). Fix: tool side, landed. Handled by pipeline_max_export_common/edit_mesh_mod.h.
Bipeds that carry the finger keytrack chunks (0x0067/0x006a per-arm) with nFingers==0 — no per-finger record follows the count. This is corner-case valid (a biped simply with no fingers); every non-empty-fingers corpus rig has at least 5 fingers × 3 links per side. Currently we handle it via the decode's own guard on nFingers. Fix: none needed. Provenance: PMD §10 "Biped structure records fully decoded".
Not a source defect — the format legitimately admits per-chunk width choice — but historically our roundtrip widened every chunk in a container to the outermost chunk's width, corrupting mixed streams (~15% of the wider corpus failed T1/T2 before the fix). The fix (per-chunk width tracking) is in IStorageObject::wasRead64BitChunk*. tr_mo_estrasson.max was the canonical fail case in the skel corpus. Fix: tool side, landed. Provenance: PMD §11 "Fixed 2026-07-05 mixed 32-/64-bit chunk headers".
Every *_fp.max first-person-hand file carries superclass 0x1190 ("Depth of Field (mental ray)"), a camera/render effect irrelevant to skeleton export. Historically this nlerror'd and aborted pipeline_max_export_skel outright on ~5% of the corpus. Fix: register it as a pass-through unknown like every other unimplemented superclass. Landed in CBuiltin::registerClasses. Provenance: PMD §11 "Fixed 2026-07-05 Superclass 0x1190".
.max)tr_mo_kami_warlord.max in the skeleton corpus is a git-LFS pointer, not the real file. Detected by the corpus drivers via the OLE-magic 8-byte header check (\xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1). No fix needed on the pipeline side; the driver skips them. Provenance: PMD §9 T1 skel-corpus note.
ge_hom_acc_gauntlet_kami.maxSingle corpus file with LOD_MRM=1 where our Physique-driven MRM build produces a post-MRM vertex buffer > NL3D_MESH_SKIN_MANAGER_MAXVERTICES=5000 (measured 6514) — the fixed size of the shared skin-manager VB that CMeshMRMSkinned is optimized to feed. CMeshMRMSkinned::isCompatible gates the input vertex count (642 verts here — comfortably under), but MRM growth at smoothing-group / material / bone boundaries can push the packed VB past the limit after the pre-check.
Root cause is downstream, not the assertion: the reference .shape for this file ships as CMeshMRMSkinned at 1461 post-MRM verts (~2.3× input growth, normal). Ours would land at 6514 (~10× input growth) if the assertion didn't stop us. The bulk of the difference is Physique-decode noise on our side — the current decoder returns 176 unresolved bone entries out of 926 total (~19%) and forces 50 vertices to root-only weight (Bip01, weight 1.0) as a ConvertToRigid approximation; those weight-set discontinuities become MRM vertex splits. See PMD §10z-quat / §10z-six / §M.3 — closing the Physique decode (locating the deformable cross-link record layout, replaying ConvertToRigid) is the same open item that gates skinned-shape byte-identity broadly.
Handling: pipeline_max_export_shape and plugin_max/nel_mesh_lib/export_mesh.cpp both check CMeshMRMSkinned::isRuntimeCompiled() after build(). When it's false they discard the CMeshMRMSkinned and surface an artist-facing message explaining the fix on the authoring side (set LOD_MRM=0 to export the mesh as plain CMesh with SkinWeights — which is what its two ship siblings ca_spaceship2 and ship_tank_karavan already do — or split the geometry so each part fits). NL3D::CMeshMRMSkinnedGeom::compileRunTime sets the flag via nlwarning; the invariant is enforced without an abort. Provenance: PMD (this session) — 2026-07-09 shape session.
Three .max files live under landscape/ligo/<eco>/max/ alongside the 1201 genuine zone bricks but are not picked up by the zone export, because their names don't match the ligo filename protocol the exporter (and the original nel_ligo_export.ms maxscript) keys on. They are valid OLE2 .max files on disk; they simply never match the zonematerial- / zonetransition- / zonespecial- token-count rule, so neither the reference pipeline nor the headless tool produces a .zone/.ligozone for them. Confirmed: no reference output exists for any of the three anywhere under ~/pipeline_export (only a stale .max.tag marker each, left by the build's tag protocol — the maxscript was invoked, ran the filterString ... "-" / tokenArray.count check, matched nothing, and exported nothing).
zonematerial-jungle-jungle-2.max (jungle) and zonematerial-solprimer-solprimer-03_dome.max (primes_racines): zonematerial- files whose cell name contains a dash, so filterString (getFilenameFile ...) "-" yields 4 tokens, not the required 3. nel_ligo_export.ms gates on tokenArray.count == 3 && tokenArray[1] == "zonematerial" (line 515), so these fall through with no export; the headless pipeline_max_export_zone uses the identical tokens.size() == 3 check (main.cpp) and warns "not a zonematerial/zonetransition/zonespecial file, nothing to do". Whether these are intended bricks with a mis-placed dash or leftovers is an authoring-side call this audit can't settle from the file alone; either way the authoring-side fix is to rename to the underscore convention every real corpus brick uses (e.g. zonematerial-solprimer-solprimer_03_dome, cf. solprimer-01_bagne_64_ah). Not a pipeline bug; the filter matches the reference exporter exactly.corrupted_moor_meta_goo.max (jungle): a dev file (confirmed by Kaetemi). Its name references zone content — "corrupted moor" is a zone, "goo" the goo biome — but it is not itself a shipped zone brick (no zone prefix), so it is filtered out by the prefix check and produces no .zone. Source-side dev leftover; fix is to remove it from the database (or move it out of the ligo export dir).The remaining 28 non-zone files in those directories — the material-<eco> and transition-<a>-<b> template files (e.g. material-desert = a single 25-patch RklPatch, transition-foret-jungle) — are not defective and must not be "fixed": they feed the ligo bank (processes/ligo/0_setup.py writes a LigoBankDir/LigoMaxSourceDirectory config over exactly this directory), a separate input to the ligo system, not the per-brick zone export the zone process targets. They likewise carry no .zone reference output (only a .max.tag). The corpus driver's zonematerial-/zonetransition-/zonespecial- filter is what keeps them correctly out of the zone export. Provenance: PMD §10h-bis coverage audit — 2026-07-09.
The ~/pipeline_export reference outputs were exported at a specific point in Ryzom Core's history. Since then, the source .max files have been edited — sometimes substantially. The pipeline decodes today's bytes; comparing against the frozen reference produces DIFFs that are NOT the tool's fault. Per PMD §9 T3 rules, the max file is authoritative.
_big/_small/_slim/_selle monster variants (biped) — rescaling anchor files, not editing leftoversCorrected framing (Kaetemi, 2026-07-08). These twin files are NOT stale post-reference edits; they are (or were) active game data used as rescaling reference points — the game engine consumes them to compute per-instance scale factors at runtime. Every base monster rig ships them as intentional companions.
Symptom in T3: 0x000f[1] thigh side offset (and other structural fields) in the .max file differs from the corresponding .skel reference by exactly the intended scale factor (×1.2 for _big, ×0.8 for _small, custom for saddled _selle variants). Historically classified under "reference-era mismatches" (design-doc §10, based on the observation that the base-rig subset matched the reference bit-exact while the scaled variants didn't); the corrected reading is that the scale delta is the file's purpose, not a drift.
Handling: our skel_corpus.py "era-matched" filter is really an "anchor-file filter" — it separates the intentionally-scaled variants from the base rig so per-file bit-match statistics on the base subset don't get diluted by the scale delta. Fix: none (max file authoritative). Also carries a _ref_scale shadow rig — a duplicate biped naming-suffixed for artist re-proportioning templating — that IS never exported and is excluded from missing-bone accounting; this one is genuine editing scaffolding, distinct from the _big/_small/_slim/_selle runtime anchors above. Provenance: PMD §10 "Reference-era mismatches" for the original observation; the "rescaling anchor" role established 2026-07-08 (this page).
Every ma/tr/zo/ca humanoid .skel reference carries fy-era figure params bit-identically. The per-race .max files were re-proportioned after the reference exports. Fix: none. Provenance: PMD §10 "Reference-era mismatches".
tr_mo_kitin_queen.max — the fresh-format outlierThe one corpus rig where 0x0115 (bodyType, formerly called FigureVersion) reads 0 (Skeleton, the biped.createNew default) rather than the corpus-standard 3 (Classic). Every apparent "outlier per role" in the biped error tables traces to this one file — R-arm drot outliers, 1.44 m finger bases, Bip02 residues.
Kaetemi's diagnosis: this rig was likely fixed up manually at some point after the reference exports (which would be exactly what rewrote its figure records in the fresh format and set 0x0115 = 0), and some kitin-queen assets crash 3ds Max, so its reference .skel may additionally come from a broken export. Either way: every queen mismatch is reference-era, not decode signal. Fresh-format decode rules were derived from the differential dataset (§10e), not the queen. Fix: none. Provenance: PMD §10 "The figure-version marker 0x0115" and §10p "0x0115 = bodyType".
The waterfall material files (~/core4_data/*_shapes/waterfall*.anim) use bExportTextureMatrix + StdUVGen U/V Offset controllers. Not defective — a normal texture-matrix scroll animation. Symptom: they carry the animated export flag as an On/Off controller (not a constant), so a naive nelInt read of the flag misses them. Fix: tool side, landed in SCENELIB::resolveNelBoolAt0. Provenance: PMD §10k "Texture-matrix (animated-material) export".
_marche_arriere and strafe biped anims — dynamicsType = 1 (Spline Dynamics)Sixty-four biped anim files carry 0x0012 (dynamicsType) = 1 ("Spline Dynamics", plain spline interpolation with no live balance solve) — almost entirely strafe animations, plus walk_to_idle, emote_drunk, and ca_hom_*marche_arriere. Corpus-consistent category (simple lateral/reverse locomotion where plain spline over live balance makes artistic sense). Not defective. Fix: none — dynamicsType doesn't affect our export decisions (we don't run live balance either way). Recorded so the field's role is documented. Provenance: PMD §10n "Twelfth: dynamicsType's only real corpus signal".
Corpus-wide result (2026-07-08, both pipeline_max_export_ig on 254 standalone ig sources and pipeline_max_export_cmb --ligo on 1231 ligo bricks): zero XRef reference errors observed — no unresolvable Windows→local path resolutions, no missing target nodes in any referenced .max, no malformed 0x0170 records, no recursion-depth blowouts, no missing streams in any XRef-target file. Every XRef in the corpus points to a real file at a real path, with the named target node present. This section is therefore about XRef quirks that are format-valid but categorically odd (nested chains, wrong-class sources), not about broken XRefs — the resolver would emit WARNING: xref: not an OLE compound file: ... / xref: cannot resolve '...' under db root '...' / xref: node '...' not found in ... / xref: no 0x0170 record on XRefObject / xref: incomplete 0x0170 record / xref: recursion depth exceeded / xref: missing streams in ... if any of those cases surfaced, and the corpus-wide sweep produces zero such warnings on either tool.
Distinguish this from ERROR: not an OLE compound file: ... (no xref: prefix) — that message comes from CStorageOleIn::open on the main input path the tool was launched with, not from XRef resolution of a referenced file. It fires when the driver passes a path that doesn't exist on disk (a stray probe pointing at landscape/ligo/desert/max/zonematerial-fond-ilot_4_mz.max when the file actually lives under landscape/ligo/lacustre/max/, for example) — a caller mistake, not a corpus defect. The corpus-driver harnesses (ig_corpus.py / ligo_ig_corpus.py / cmb_corpus.py) enumerate paths via os.listdir and never hit this class.
If a future session's corpus sweep DOES emit any of the WARNING: xref: ... classes above, add the offending file to a new §3.4 subsection here with the exact warning class and a diagnosis (missing file on disk vs. wrong DB root vs. malformed XRefObject in the source).
Files like zonematerial-fond-ilot_4_mz.max and the zonematerial-bassin-village_nb_0X.max family carry every collision node as an XRefObject pointing to a source .max whose own node is itself an XRef pointing to yet another file (e.g. fy_cn_module.max → fy_acc_ascenseur.max). The reference MaxScript detects this via if (classOf sourceObject == XRefObject) then FAIL — such XRefs are skipped by the pre-pass and fall through to later selection passes. pipeline_max_export_ig's XRef pre-pass replicates this rule (single-step source resolution, reject nested-XRef sources, gate on the {Geom, Helper, Light} superclass set). Fix: tool side, landed. Provenance: PMD §10w "Ligo maxscript ordering".
Some ligo files' XRef-resolved collision nodes point to a Box/Cylinder/Sphere parametric primitive (has old-style ParamBlock dimensions, no GeomBuffers) or an EditablePoly (has poly buffers, not tri buffers). pipeline_max_export_ig handles this via buildParametricMesh + poly triangulation; pipeline_max_export_cmb does NOT yet (they're ig-local, not shared). Symptom: cmb's extractNodeMesh returns "no GeomBuffers chunk". Handled: cmb downgrades this per-node failure to a warning + skip (drops that node, group's other nodes still ship). Fix: extract parametric + poly triangulation into pipeline_max_export_common when a shape-side use case joins. Provenance: PMD §10x "Ligo tier's 16 export failures".
The maxscript's XRef pre-pass gates on superclassOf sourceObject ∈ {Geom, Helper, Light}. Anything else (SplineShape, sClass=shape 0x40; other non-collision object classes) falls through to the per-category passes and lands later in $selection. Not defective — just a category mismatch. pipeline_max_export_ig replicates the gate; corpus example: fy_module_col_nb01's source resolves to a SplineShape and gets skipped. Provenance: PMD §10w "Kaetemi's Max 9 xref_resolvability probe".
Some files carry data whose interpretation depends on the history of the file — Max's own runtime state that got frozen when the file was last saved, not on any single bit in the format.
Biped anims where 0x006c[0..2] (figure-mode ComDisp) is zero and the COM's vertical channel is unkeyed evaluate to 0x006c (figure height). Same shape files where 0x006c[0..2] is nonzero evaluate to the current-position frame (0x0104[13] / 0x0260[5] + 0x0260[1] HeightCorrection). Whether a file lands in one bucket or the other depends on artist actions that don't leave a discriminator bit — closing without entering figure mode preserves the divergence; a single "toggle into Figure Mode and back out" heals it silently (exiting Figure Mode commits the figure state into the current-position family, regardless of whether the artist deliberately edited anything in figure mode). Fix: the tool honors the 0x006c[0..2] != 0 discriminator (empirically airtight over all four checkable reference files, and every other checked file); files that fall on the wrong side of that heuristic are the reference-era class (max file's current state != what was exported). Provenance: PMD §10o "The unkeyed COM is the current-position frame, not figure height".
Markers/dummies with authored negative scale (-0.8, -0.8, -1.17 or similar) reflect a rotation-decompose convention divergence between MAXScript's .rotationpart and our own decompMatrix on reflected TMs. box_arme_gauche, Babine/Bannane D, Box05-07, kami_guide_4's L toes are the corpus instances. Symptom: appears as ~28 prs:name-marker drot mismatches and 13 L finger bases in the biped decode. Fix: verify per case against the reference .skel (not the live-Max GT dump, which has its own separately-diagnosed divergence). Landed as-is; documented so it's not confused with the 28-file "PRS name markers not COM-parented" open item. Provenance: PMD §10e "Negative-scale (mirror-authored) markers" and §10l "prs:name-marker investigation".
0x0210 created-face records (map-1 texture-vertex faces)The Edit Mesh modifier serializes two kinds of created-face records: 0x0208 = base-topology (with srcTag, 24-byte stride) and 0x0210 = map-1 texture-vertex-face (no srcTag, 20-byte stride). They live in DIFFERENT vertex spaces. Historically we treated them as interchangeable and applied 0x0210 to the base mesh; the resulting edge-inconsistent topology CCollisionMeshBuild::link rejected outright. fy_hall_reunion.max was the canonical fail case. Fix: tool side, landed — the shared EDITMESH::applyEdits applies CreatedFacesA (base) only. Provenance: PMD §10x and MGF §L.2.
Files whose modifier stack contains mapext198m3.dlm ("Map extender plug-in — 3DSMax Team - UBI Soft Romania & Daniel Raviart", modifier class (0x2ec82081, 0x045a6271)) produce reference .shapes with garbage UVs. The reference NeL plugin doesn't implement the modifier and just leaks whatever memory happened to be there. Comparing our unmapped export against the reference's garbage is meaningless. Fix: bucket-report affected assets (mapext_assets.txt), route them outside the diff gate; either the modifier gets implemented properly (our output becomes better than the reference) or the assets stay excluded-with-reason. Provenance: PMD §9 T3 caveats and §10i "Map Extender bucketing".
Drop-in replacement plugin available (2026-07-10, PMD §10z-seize): nel/tools/3d/plugin_max/map_extender/ builds mapext198m3.dlm (Max 2010, VS2008/Wine plugin tree) — re-registers the Class_ID and replays the stored cache in ModifyObject, so these files view/collapse/export correctly in Max again. Validation: gen_mapext_plugin_validate.ms + mapext_plugin_check.py (Max-side run pending).
Headless cache decode LANDED (2026-07-10, §10z-quatorze / MGF Part P). Corpus survey of all 87 files / 164 mod-app instances answered the open question: the plugin object stores no projection settings (empty 0x39bf → 0x0100 everywhere; remaining non-empty siblings are universal ReferenceMaker/AppData chunks), and the map is stored flat in the LocalModData cache (0x2500 → 0x2512 → 0x03e8/0x03e9/0x03ea/0x03eb, channel in 0x03f3). UV values are UV-space (not XYZ); face counts match the mesh at the modifier's stack position on 160/164 applies. Shared library pipeline_max_export_common/map_extender_mod applies the cache as a replacing map channel in mesh_eval; the MAPEXT harness tag is kept because the reference .shape UVs remain garbage. 4 primes_racines sky domes refuse the apply (stale cache under a post-hoc Edit Mesh topology rewrite). Historical corroboration: the 2012 pipeline_max_rewrite_assets ReplaceMapExt mode (main.cpp:1129-1450) lifted the same 0x03e9/0x03eb into Unwrap UVW form — this session is that decode, productionized.
The affected source files (87 .max files, 118 exporting nodes — from the shape corpus's mapext_assets.txt report; nodes that don't export their own .shape — LOD slaves, lightmap-bucketed carriers — aren't listed, so the modifier-use warn count is higher, 165).
Per-node validation matrix (2026-07-10 end-of-session, ryzomcore 7d5778c5f; our export vs the per-project reference: byte-identical = raw bytes equal; FLOATEQ (full compare) = the full UNMASKED field walk passes at float-noise tier — for these the reference UVs are valid and match our recovered cache, i.e. the reference export evidently evaluated the plugin correctly for them; mapext-verified = passes --compare-mapext-mask (everything except UV values / vertex sets / index content — the reference UVs are the documented garbage); mapext-DIFF = fails even masked, note per node):
| Project | File | Node | Validation | Notes |
|---|---|---|---|---|
| common/characters | stuff/fyros/agents/actors/female/fy_hof_armor00.max |
fy_hof_armor00_armpad | mapext-verified | |
| common/characters | 〃 | fy_hof_armor00_bottes | mapext-verified | |
| common/characters | 〃 | fy_hof_armor00_gilet | mapext-verified | |
| common/characters | 〃 | fy_hof_armor00_hand | mapext-verified | |
| common/characters | 〃 | fy_hof_armor00_pantabottes | mapext-verified | |
| common/characters | stuff/fyros/agents/actors/female/fy_hof_caster01.max |
fy_hof_caster01_pantabottes | mapext-verified | |
| common/characters | stuff/fyros/agents/actors/male/fy_hom_armor00.max |
fy_hom_armor00_bottes | mapext-verified | |
| common/characters | 〃 | fy_hom_armor00_gilet | mapext-verified | |
| common/characters | 〃 | fy_hom_armor00_pantabottes | mapext-verified | |
| common/characters | stuff/fyros/agents/actors/male/fy_hom_caster01.max |
fy_hom_caster01_pantabottes | mapext-verified | |
| common/characters | stuff/generique/agents/actors/female/ge_hof_armor02.max |
ge_hof_armor02_gilet | byte-identical | |
| common/characters | 〃 | ge_hof_armor02_pantabottes | mapext-verified | |
| common/characters | stuff/generique/agents/actors/male/ge_hom_caster00.max |
ge_hom_caster00_pantabottes | mapext-verified | |
| common/characters | stuff/matis/agents/actors/female/ma_hof_armor01.max |
ma_hof_armor01_armpad | mapext-verified | |
| common/characters | 〃 | ma_hof_armor01_pantabottes | mapext-verified | |
| common/characters | stuff/matis/agents/actors/male/ma_hom_caster01.max |
ma_hom_caster01_pantabottes | mapext-verified | |
| common/characters | stuff/matis/agents/actors/visages/ma_hof_visage.max |
ma_hof_visage | mapext-verified | Morpher blend shapes — CMeshMRM class since the bsList landing (§10z-quinze) |
| common/characters | stuff/matis/agents/actors/visages/ma_hom_visage.max |
ma_hom_visage | mapext-verified | Morpher — same |
| common/characters | stuff/tryker/agents/actors/female/tr_hof_armor00.max |
tr_hof_armor00_bottes | mapext-verified | |
| common/characters | 〃 | tr_hof_armor00_gilet | mapext-verified | |
| common/characters | stuff/tryker/agents/actors/female/tr_hof_armor01.max |
tr_hof_armor01_armpad | mapext-verified | |
| common/characters | 〃 | tr_hof_armor01_bottes | mapext-verified | |
| common/characters | 〃 | tr_hof_armor01_gilet | mapext-verified | |
| common/characters | 〃 | tr_hof_armor01_pantabottes | mapext-verified | |
| common/characters | stuff/tryker/agents/actors/male/tr_hom_caster01.max |
tr_hom_caster01_pantabottes | mapext-verified | |
| common/characters | stuff/tryker/agents/actors/male/tr_hom_underwear.max |
tr_hom_underwear_hand | mapext-verified | |
| common/characters | stuff/tryker/agents/actors/visages/tr_hof_visage.max |
tr_hof_visage | mapext-verified | Morpher — same |
| common/characters | stuff/tryker/agents/actors/visages/tr_hom_cheveux_artistic02.max |
tr_hom_cheveux_artistic02 | mapext-verified | |
| common/characters | stuff/tryker/agents/actors/visages/tr_hom_visage.max |
tr_hom_visage | mapext-verified | Morpher — same |
| common/characters | stuff/zorai/agents/actors/female/zo_hof_armor01.max |
zo_hof_armor01_armpad | mapext-verified | |
| common/characters | stuff/zorai/agents/actors/male/zo_hom_armor00.max |
zo_hom_armor00_armpad | mapext-verified | |
| common/characters | 〃 | zo_hom_armor00_bottes | mapext-verified | |
| common/characters | 〃 | zo_hom_armor00_gilet | mapext-verified | |
| common/characters | 〃 | zo_hom_armor00_hand | mapext-verified | |
| common/characters | stuff/zorai/agents/actors/male/zo_hom_caster01_bottes_armor01.max |
zo_hom_caster01_bottes_armor01 | mapext-verified | |
| common/construction | stuff/generique/decors/constructions/gen_bt_atelier.max |
gen_bt_atelier_caisse | mapext-verified | |
| common/construction | stuff/generique/decors/constructions/gen_bt_auberge.max |
gen_bt_aub_ext | mapext-verified | |
| common/construction | stuff/generique/decors/constructions/gen_bt_comptoir.max |
gen_bt_comptoir_caisse | mapext-verified | |
| common/construction | stuff/generique/decors/constructions/gen_bt_drapeau_revendication.max |
gen_bt_drapeau_revendication | mapext-verified | |
| common/construction | stuff/generique/decors/constructions/gen_bt_tourgarde.max |
gen_bt_tour_portebas | mapext-verified | |
| common/construction | 〃 | gen_bt_tour_porteleft | mapext-verified | |
| common/construction | 〃 | gen_bt_tour_porteright | mapext-verified | |
| common/fauna | stuff/goo/agents/monsters/coureur/go_mo_c03.max |
go_mo_c03 | FLOATEQ (full compare) | was a bone-set mismatch until the rigid one-link fix; reference UVs valid |
| common/fauna | stuff/goo/agents/monsters/crustaces/go_mo_estrasson.max |
go_mo_estrasson | mapext-verified | |
| common/fauna | stuff/tryker/agents/monsters/cheval/c03/tr_mo_c03_boss.max |
tr_mo_c03_boss | mapext-verified | was "bones 12 vs 55" until the rigid one-link weight fix (§10z-quinze) |
| common/fauna | stuff/tryker/agents/monsters/chien/varinx/tr_mo_varinx_boss.max |
tr_mo_varinx_boss | mapext-verified | |
| common/fauna | stuff/tryker/agents/monsters/coureur/filin/tr_mo_filin_boss.max |
tr_mo_filin_boss | byte-identical | |
| common/fauna | stuff/tryker/agents/monsters/crustace/estrasson/tr_mo_estrasson.max |
tr_mo_estrasson | mapext-verified | |
| common/fauna | stuff/tryker/agents/monsters/kitin/kitimandib/tr_mo_kitimandib_boss.max |
tr_mo_kitimandib_boss | mapext-verified | |
| common/fauna | stuff/tryker/agents/monsters/ryzomien/kakty/tr_mo_kakty_boss.max |
tr_mo_kakty_boss | mapext-verified | |
| common/objects | stuff/caravan/agents/accessories/ca_wea_trooper_gun.max |
ca_wea_trooper_gun | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_acc_pick_o.max |
ge_acc_pick_o | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_hom_mission_reward_outpost_gauntlet.max |
ge_hom_mission_reward_outpost_gauntlet | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_kapo_pilon_o.max |
ge_kapo_pilon_o | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_kbij_marteau_o.max |
ge_kbij_marteau_o | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_kwj_ciseau_o.max |
ge_kwj_ciseau_o | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_carapace_b.max |
ge_mission_carapace_b | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_carapace_bull.max |
ge_mission_carapace_bull | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_entrepot.max |
object04 | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_feu_off.max |
ge_mission_feu_off | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_fortuna_wheel.max |
ge_mission_fortuna_wheel_ring | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_jarre.max |
ge_mission_jarre | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_karavan_acc_pick_a.max |
ge_mission_karavan_acc_pick_a | FLOATEQ (full compare) | reference UVs are VALID and match the recovered cache |
| common/objects | stuff/generique/agents/accessories/ge_mission_maison_ruine.max |
ge_mission_maison_ruine | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_mass_diam.max |
ge_mission_mass_diam | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_ossements_b.max |
ge_mission_ossements_b | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_outpost_infostele.max |
ge_mission_outpost_infostele | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_panneau.max |
ge_mission_panneau | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_pique_diam.max |
ge_mission_pique_diam | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_reward_karavan_bigshield.max |
ge_mission_reward_karavan_bigshield | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_ringate_teleport.max |
ge_mission_ringate_teleport | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_statue_jena_karavan.max |
ge_mission_statue_jena_karavan | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_stele.max |
ge_mission_stele | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_mission_stele_karavan.max |
ge_mission_stele_karavan | mapext-verified | |
| common/objects | stuff/generique/agents/accessories/ge_wea_fusarc.max |
ge_wea_fusarc | mapext-verified | |
| common/objects | stuff/matis/agents/accessories/ma_hof_acc_gauntlet.max |
ma_hof_acc_gauntlet | mapext-verified | |
| common/objects | stuff/matis/agents/accessories/ma_wea_batonspellcaster.max |
baton magie01 | FLOATEQ (full compare) | reference UVs are VALID and match the recovered cache |
| common/objects | stuff/zorai/agents/accessories/zo_hom_acc_gauntlet.max |
zo_hom_acc_gauntlet | mapext-DIFF | rdrpass count 7 vs 6 + skin-weight vert count 1384 vs 1569 — MRM-structural residual beyond the mask |
| common/outgame | stuff/outgame/appart_crea/ma_appart_outgame.max |
ma_appart_outgame | mapext-verified | |
| common/sfx | sfx/meshtoparticle/ma_fx_birds.max |
ma_fx_bird01 | mapext-verified | |
| common/sfx | sfx/meshtoparticle/tr_fx_birds.max |
tr_fx_bird01 | mapext-verified | |
| common/sky | sky_v2/max/de_sky_dome.max |
de_clouds_dome_altitude | mapext-verified | |
| common/sky | 〃 | de_clouds_dome_light | mapext-verified | |
| common/sky | sky_v2/max/fo_sky_dome.max |
fo_clouds_dome_altitude | mapext-verified | |
| common/sky | 〃 | fo_clouds_dome_light | mapext-verified | |
| common/sky | 〃 | fo_horizon_dome | mapext-verified | |
| common/sky | sky_v2/max/ju_sky_dome.max |
ju_clouds_dome_altitude | mapext-verified | |
| common/sky | 〃 | ju_clouds_dome_light | mapext-verified | |
| common/sky | sky_v2/max/la_sky_dome.max |
la_clouds_dome_altitude | mapext-verified | |
| common/sky | 〃 | la_clouds_dome_light | mapext-verified | |
| continents/bagne | stuff/primes_racines/sky_bagne/sky_primes_racines_bagne.max |
sky_primes_racines_bagne | FLOATEQ (full compare) | was a §10z-quatorze "stale cache" refusal — actually our Sphere-hemisphere defect; FLOATEQ since §10z-quinze |
| continents/fyros | stuff/fyros/decors/constructions/fy_cn_mairie/fy_cn_mairie01.max |
fy_cn_mairie_entree-a | mapext-verified | |
| continents/fyros | 〃 | fy_cn_mairie_entree-b | mapext-verified | |
| continents/fyros | 〃 | fy_cn_mairie_int | mapext-verified | |
| continents/fyros | stuff/fyros/decors/constructions/fy_cn_sheriff.max |
fy_bt_sheriff_modif_ok_inter_assistant | mapext-verified | |
| continents/fyros | 〃 | fy_bt_sheriff_modif_ok_inter_sherif | mapext-verified | |
| continents/fyros | stuff/fyros/decors/constructions/fy_cn_smokehouse.max |
fy_smoke_cage_elevateur | mapext-verified | |
| continents/fyros | stuff/fyros/decors/constructions/fy_panneau.max |
box01 | mapext-verified | |
| continents/indoors | stuff/fyros/decors/constructions/fy_cn_hall_reunion_vitrine/fy_hall_reunion.max |
halo_appart | mapext-verified | |
| continents/indoors | stuff/matis/decors/constructions/appart_joueur/ma_appart_joueur.max |
ma_appart_armoire | mapext-verified | |
| continents/indoors | 〃 | ma_appart_lit | mapext-verified | |
| continents/indoors | stuff/matis/decors/constructions/hall_vitrine_hall_reunion/ma_hall_vitrine_hall_reunion.max |
ma_int_hall_reunion | mapext-verified | |
| continents/indoors | 〃 | ma_plafonier_hall_vitrine | mapext-verified | |
| continents/indoors | 〃 | ma_stairs_hall_reunion | mapext-verified | |
| continents/matis | stuff/matis/decors/constructions/ma_mairie.max |
ma_mairie_couloir | mapext-verified | |
| continents/matis | stuff/matis/decors/constructions/ma_serre.max |
ma_serre_exterieur_couloir | mapext-verified | |
| continents/route_gouffre | stuff/primes_racines/sky_route_gouffre/sky_primes_racines_route_gouffre.max |
sky_primes_racines_route_gouffre | FLOATEQ (full compare) | same as bagne |
| continents/sources | stuff/primes_racines/sky_sources/sky_primes_racines_sources.max |
sky_primes_racines_sources | FLOATEQ (full compare) | same as bagne |
| continents/terre | stuff/primes_racines/sky_terre/sky_primes_racines_terre.max |
sky_primes_racines_terre | FLOATEQ (full compare) | same as bagne |
| continents/tryker | stuff/tryker/decors/constructions/tr_barge.max |
tr_barge_porte_int_left | mapext-verified | |
| continents/tryker | stuff/tryker/decors/constructions/tr_coffre.max |
coffre | mapext-verified | |
| ecosystems/desert | landscape/ligo/desert/max/zonematerial-converted-1_mz_city.max |
city_part08 | mapext-verified | |
| ecosystems/desert | 〃 | city_part50 | mapext-verified | |
| ecosystems/desert | 〃 | city_part63 | mapext-verified | |
| ecosystems/desert | 〃 | fy_bt_sheriff_plato_ext_fy_sheriff | mapext-verified | |
| ecosystems/desert | stuff/fyros/decors/vegetations/fy_s1_baobab_c.max |
fy_s1_baobab_c | mapext-DIFF | CMeshMultiLod materials 6 vs 7 — the slave-material merge class (§10y) |
| ecosystems/lacustre | landscape/ligo/lacustre/max/zonematerial-converted-203_dx.max |
tr_waterfall_03_a | FLOATEQ (full compare) | reference UVs are VALID and match the recovered cache |
| ecosystems/lacustre | stuff/tryker/decors/vegetations/tr_s3_aquabole_a.max |
tr_s3_aquabole_a | mapext-DIFF | CMeshMultiLod materials 4 vs 5 — same slave-material merge class |
Totals: 2 byte-identical + 8 FLOATEQ-full + 105 mapext-verified + 3 mapext-DIFF of 118 exporting nodes.
Provenance for the matrix: node list from mapext_assets.txt (shape corpus driver output; regenerate with any shape_corpus.py --t3 sweep — the report lands in the sweep's --out directory); validation statuses from pipeline_max_export_shape --compare / --compare-mapext-mask per node against the per-project ~/pipeline_export references. The 8 FLOATEQ-full rows are the interesting anomaly: their reference UVs are NOT garbage — the Max 2010 reference-export machine evidently loaded the plugin (or the stored cache) correctly for these — so the "reference UVs are garbage" rule is per-file, not universal; the mask stays because 105/118 references ARE garbage-UV.
These are individual files with a specific, still-unexplained divergence that doesn't fit any of the classes above and hasn't been pinned to a decodable rule.
Zo_bt_Hall_Conseil.max (cmb) — ~4.4-unit vertex offsetThe collision node is a plain EditableMesh with no modifier stack, parented directly to the scene root, TCB-rotation local controller with zero keys. Its whole mesh is offset from the reference by up to ~4.4 units at world coordinates ~20000 units from the origin, Y exactly preserved (X/Z diverge — consistent with an undiscovered rotation-about-Y discrepancy). Ruled out this session and prior: modifiers, object-offset, parent chain, the file's stored current-time, the rotation controller's own default-value chunk resolving to a real non-identity value, VS2008/x87 float precision (bit-for-bit identical between x64 and x87 builds — logic gap, not float noise). Open on its own separate terms. Provenance: PMD §10v and §10x.
FY_hall_reunion.cmb — one face-index remap + 16 created-vert positionsAfter the §10x Edit Mesh decode landed (0x0208/0x0210/0x0220 fully applied), the reference match jumped to 247/248 faces byte-identical + exact material distribution. The residuals:
TOPO_FACEMAP_CHUNK (0x2780) is the format concept; the modern MDELTA_CHUNK equivalent hasn't been identified in the corpus's 0x4000 sub-trees yet.0x2510 mod-context TM (checked: identity on this file). Suspected: an additional modifier stack element or an unhandled transform. Open.Provenance: PMD §10x open items.
Zo_bt_hall_Reunion_vitrine.cmb — 221/235 face diffs, 25 vert diffsSame class as FY_hall_reunion at larger scale — likely the same missing face-remap chunk plus a similar created-vert positioning issue. Solving the FY case should close this one automatically.
ship_tank_karavan_mort_idle — keyless-vertical outlierThe one corpus biped anim with a truly keyless vertical track. Its unkeyed COM height decodes to 0x0104[13] + 0x0260[1] (1.275 + 0.052 = 1.327) matching the reference exactly under the 0x006c[0..2] != 0 discriminator. Was formerly framed as "genuinely irreproducible" or "live physics"; §10o closed both readings — the value is just a decodable stored constant. Not open anymore. Provenance: PMD §10n through §10o.
The animation itself exports byte-identical (67/67 direct-ref match). The material's static user-texture-matrix value — the reference bakes the StdUVGen's static UV offset/scale/angle into it, we emit identity. This is ~48 bytes per animated material shape T3 gap. Decoding the StdUVGen static transform closes it. Provenance: PMD §10k "Still open".
~/biped_anim_dataset/, dataset2/, dataset3/, ~/biped_dataset/, ~/biped_regen/, ~/biped_vhtsrc_probe/, ~/biped_fields_probe/, ~/biped_anim_dataset*_gen.ms — Kaetemi-authored differential Max 9 datasets used to pin decode rules against ground-truth biped.getTransform dumps. Not corpus files, but referenced throughout PMD §10c-r as the tool for the biped-related decode work. See PMD §10 "Method note" for the discipline.~/decors_probe/manifest.txt — user-supplied Max 9 dump used to refute PMD's earlier "Mirror plane two stories down" hypothesis on TR_hall_reu_vitrine_decors (the plane values were fine; the real issue was the Edit Mesh 0x0130 created-verts decode, §10w). Referenced as the class of quick-turnaround probe that pins ambiguous format questions.~/prim_mesh_dataset/manifest.txt — user-supplied Max 9 dump that pinned Box/Plane/Cylinder/Sphere parametric-mesh topology + negative-dimension variants + Mirror-modifier cases. Used by pipeline_max_export_ig::buildParametricMesh. Ground-truth exact.fy_hom_emot_jump_time_at5432_max12345.max — user-supplied Kaetemi single-variable probe that pinned Config-stream 0x20b0 time-slider range (range end 12345, slider parked at 5432). Referenced in PMD §2c.fy_hom_emot_jump.max — generated by pipeline_max_export_anim --author-jump, the first WRITE consumer of the §10c decode. Ships as ~/fy_hom_emot_jump.max for Max 9 validation. Not a source file, but exercises the modify&save path fully. Provenance: PMD §10u.When a corpus file behaves oddly and doesn't fit any of the classes above:
~/pipeline_export's. Newer means the file was edited after the reference was exported — max file authoritative.--dump (or equivalent) and look for XRef WARN lines. Nested XRefs, unresolvable sources, and non-geometry XRef targets all have documented handling above.maxole.py on the file and look for unusual modifier ClassIDs. New modifier classes (0x40c7005e, 0x8ab36cc5, 0x8aad7d94 are noted-but-unnamed in PMD §10i) may need identification before their contribution to the mesh can be evaluated.~/build_vs2008_wine_pipeline) and re-measure. If the divergence is bit-for-bit identical between x64/SSE and x86/x87, it's a logic gap, not float noise — see PMD §2b's precedent.