QA Ticket Resolution Log #4 15 / 15 RESOLVED

Ticket #3 found that .gam rotations are authored in degrees and fixed the magnitude — but it derived the sign from the Z-mirror alone: a reflection flips a Y-rotation (S·Ry(θ)·S = Ry(−θ)), so it stored ry = −θ. That is only half the conversion. The original world is left-handed, and a left-handed rotation by +θ is the right-handed (GL) rotation by −θ — a second negation that cancels the first on the X and Y axes, leaving a single negation on Z. So the faithful import is rx, ry = +θ, rz = −θ.

Why did ticket #3's sign survive its own QA? Its three validation props were all sign-blind: a toolchest at 180° (−180° ≡ +180°), a phone booth at 180°, and a fan disc that is rotationally symmetric. The one asymmetric case (a 270° yokian door) reads "filled" from either facing because a door panel spans its opening both ways — so the shot was retaken and looked fine. This ticket finally supplied unambiguous arbiters: the mummy tomb is a one-sided 3D sarcophagus (at the wrong sign it turns edge-on, baring the dark recess) and the pirate ship must hang inside a fixed A-frame. Both lock to the authored angle only at +θ.

C3DOmtObj (FourCC 3OMT) authors two properties the engine had never parsed: OmtDatabase (a container, always objects.omt in JNBG) and OmtIndex (a 3DSh shape-chunk id). With no reader, every 3OMT instance fell through to the per-FourCC default — a faceted Sphere01 mesh that reporters across three levels all read as "a fan." The authored indices map cleanly onto the OMT shape table:

Level2a 3OMT bench01..06  OmtDatabase=objects.omt  OmtIndex=19  -> shape "bench04" (school desk)
Level3  3OMT rockship     OmtDatabase=objects.omt  OmtIndex=26  -> shape "rocketship"
Level3D 3OMT C3DOMTOBJ    OmtDatabase=objects.omt  OmtIndex=21  -> shape "block" (octasign banner)

C3DTree and C3DMovingTarget are both members of the C3DSprite family — every instance authors a SpriteDatabase=sprites.omt + SpriteIndex canvas, which is the object's visual. But the resolver checked its per-FourCC table first, where a 3TRE → tree01.glb mesh row (a Retroville trunk, applied to every tree including the level2a race cones) and a 3TAR → JNvsJN target sprite shadowed the authored data. The instances knew what they were all along — they author cone (41), shooting-stars (175) and martian (176).

The booth was exported (ticket #3) with its geometry localized to the mesh AABB centre — correct for static placements, which the engine translates by the centre offset. But an entity mesh is rotated about its own origin. The phone shape's authored origin sits ~83 units off its AABB centre in Z, so the authored 180° rotation swung the localized booth twice that distance — straight into the wall behind it.

The school/swing-door classes apply a per-instance authored PNGFile to whichever mesh source loads (ticket #3). When that source is a textured glb twin, its UVs are baked with the DX/glTF convention (the omt-gltf 1−v flip). A standalone PNG loaded with the engine's default (OpenGL, bottom-up) orientation then samples vertically inverted — so the doorretro lettering came out upside down.

Ticket #3 made every BLOCK*-prefixed placement an invisible collider — case-insensitively, to catch level1c's "Blocking01". That rule over-matched: level1's playground climbing toy is built from visible meshes literally named Blocks_Out and Blocks_In. Sweeping all 35 levels confirms those two are the only BLOCK-named meshes that carry real visible texture rather than being a bare collider (the fence-textured BLOCK_HOODFAR shells, for instance, are level-perimeter colliders whose visible counterpart is the chroma-keyed 2D_Trees foliage — they stay hidden).

The 3FLA FourCC is registered by C3DFlag (its registrar FUN_00419550 sits inside the class's code region per docs/_gam_classids.tsv) — the rooftop flag. The old row was a name-match to the freeform editor tag string "C3DFIRESTRATO" and bound firestrato.ASE, whose geometry is authored ~350 units off-origin; it rendered floating away from the pole, reading as "missing."

The engine hides any entity authoring InitiallyVisible=0 at boot (faithful — the original reveals them via scripting). But C3DKitty's own per-frame update force-enables its visibility while its task state is below the rescue threshold (10) — decomp C3DKitty.md — so the original shows the cat from frame one despite the authored flag. The engine's generic boot-hide didn't know about the class's override.

C3DOctapuke registers HIDEFAULT → octo.ase (the puke animation) and HISTOP → octostop.ase, both textured by octapuke1.png. The engine bound octo.ASE — but that morph-anim ASE carries zero texture UVs (the original keeps the base shape's UVs across morph frames). Drawn statically it sampled a single dark texel and rendered as a black silhouette.