Status & Open Work

Status & Open Work

This page mirrors the repo’s single status surface, docs/wime/TODO.md. Every genuinely open item gets one row here; the full evidence and paths-tried tables live in the raw notes.

Open items

ID	Status	Question (one line)
wime-iigs-tnof-songs-internals	open	On the Apple IIGS port, TNOF’s internal glyph-table layout and SONGS.RES’s per-song event-stream and 44-byte instrument-record field semantics are both undecoded. Each resource’s container and compression structure is fully confirmed — it’s the payloads that aren’t.
wime-elrond-scene-screen-untraced	open	Which screen draws Elrond? The “Council of Elrond / scene-event 0xF6” reading is refuted — 0xF6 is a generic “return to scene view” mode set from four unrelated sites — and his renderer is the already-documented general scene-figure routine, not a dedicated screen. A narrower gap replaced it: Elrond’s own conversation scene likely builds no sprite for him at all (his entity index fails the static-portrait routing test, so he falls through to the animated-FRML path, which fails silently because race 80 has no FRML). Not live-verified.
wime-frml-anim-balrog-undersegmentation	open	AAnims.res FRML #12 (Balrog) is confirmed a stationary encounter — it appears already in place for combat and never walks in — so the row’s missing walk content is by design, not a decode gap, and the weapon-behind-shoulder pose is the idle. Frame widths point at frame 2 or 3 (the two most contracted) with 0/1 and 4/5 as two outward swing arcs. The finer swing/death boundary is still not recovered, so it keeps falling back to the geometry heuristic.
wime-dosvga-frml-type-128-hobbits	open	DOS VGA BSCENE.RES LMRF #0 (hobbits, header type 0x80) and #19 (campfire, type 0x20) fall outside the decoder’s accepted type set (0/1/5) and silently decode to zero frames — hobbits are currently completely unrendered on DOS VGA. The race-0 animation-table trace, readable independently since that table lives in START.EXE, shows the same shift pattern as men and predicts 3 new frames.
wime-dosvga-wizard-frml-full-redraw	open	DOS VGA’s wizard FRML (BSCENE.RES LMRF #4) has zero frame-dimension matches against the Amiga’s — 18 of 19 frames disagree — reading as a full redraw at a different scale rather than the insert-and-shift pattern every other hero race shows. Not investigated beyond the dimension diff.
wime-frml-animation-outcome-semantics	deferred	What each scene-event code is called. Codes 2 (“confirmed/position-validated”), 3 (“battle in progress”), 5 (“ordinary-party encounter”) and 6 (“high-index special entity”) now each have a disassembly-traced condition, and entry 54’s trigger is found — two call sites in the scene-entry builder, both exclusively for the player’s own party. Only the user-facing names are unconfirmed, which is why it’s deferred: the classifier’s contract doesn’t depend on them.

Recently closed

Item	Result
wime-movement-state-inverted	A real, live engine bug in this project’s reimplementation, found while re-deriving an anomaly-list item. Re-tracing ProcessMovement byte-for-byte proved entity field +0x16 is 3 = camped/resting, 1 = actively moving — the inverse of what the code assumed. The transition into 3 fires the camp animation, into 1 fires walk.
Animation-VM entry points	A from-scratch jump-following decoder was run against all 16 animation rows two ways (a linear decode from offset 0, and a branch-exploring reachability walk): 253/256 landmark-alignment checks pass, 15 of 16 races clean, with Balrog the sole documented exception.
Event dispatch	Resolved as a non-issue. The two suspected jsr targets are both the message-display jump-table slot called from inside ProcessMovement, not a separate dispatch mechanism. The real dispatch call sites are fully traced.
AI route selection	Static only. An exhaustive negative search found zero writes to the route table and zero writes to entity+0x24 anywhere in either disassembly — route and queue assignment is baked into the shipped DATA hunk. Movement beyond that is the local greedy terrain scoring already documented.
Game end conditions	Exactly 4 trigger sites, each proven via the CSTR resource it fetches: the Ring reaching Barad-dûr (defeat), three or more of the five capital garrisons annihilated (defeat), the Ring reaching Mount Doom (victory), and entity 148 — the 9,500-orc host at Barad-dûr — annihilated (victory, previously undocumented). Named-character deaths are confirmed absent as an ending.
32-colour FRML recolouring	They are not recoloured. 5-bitplane FRMLs bypass the bitplane mode table and render against the fixed scene palette. Exactly one LoadRGB4 call exists in the whole binary (the scene fade-in), there are no SetRGB4/SetRGB4CM calls at all, and a live Copper-list dump shows no per-scanline colour writes between VPOS 0x29 and 0xF1.

Known inconsistency

The map grid’s row count differs between the format spec and the extraction pipeline: docs/wime/amiga/mmap-format.md documents 160×101 tiles with a 96-byte trailer, while the asset pipeline and the rendered map on The Map use 160×100. Both readings divide the same 16,256 decompressed bytes without residue (160×101 + 96, or 160×100 + 256), so the byte count alone doesn’t settle it. Treat the last row as unresolved.

Where to read the full evidence

• docs/wime/TODO.md — the single status surface.
• docs/wime/plan.md — the format-by-format status table.
• docs/wime/amiga/ and docs/wime/dosvga/ — the byte-level specs and disassembly citations.

The raw notes carry the full evidence, paths-tried tables, and corrections that this page summarises.