maddo/Crusader_Decomp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Pseudocode decompialtion improvements and docs

Browse source
This commit is contained in:
MaddoScientisto 2026-03-26 22:10:48 +01:00
commit 589bfc31ef
1898 changed files with 60634 additions and 6597 deletions
Download patch file Download diff file Expand all files Collapse all files

5
plan-mid.md
View file

@ -54,6 +54,7 @@ Detailed completed analysis belongs in the files under `docs/`, not in this plan
- The USECODE tooling lane now also has a first full readable corpus export: `tools/export_usecode_pseudocode.py` writes `977` current pseudocode bodies into `USECODE/EUSECODE_extracted/pseudocode`, and the first focused read of that corpus now shows `JELYHACK::use` / `JELYH2::use` as tiny shared `set_info(0x0207) -> process_exclude -> return` stubs rather than hidden active event cores.
- The USECODE tooling lane now also has two new follow-up notes grounded in the exported corpus: `docs/usecode-tool-improvement-plan.md` turns the Pentagram/`crusader-disasm` comparison into a concrete parser roadmap, and `docs/usecode-alarmhat-analysis.md` records the current best evidence-backed read of `ALARMHAT::equip` as a frame-driven local alarm-state controller that equips nearby `shape 0x04D0` helper objects in different modes.
- The USECODE tooling lane now also has a broader equipment-event note: `docs/usecode-equipment-system.md` records live binary proof that `Item_Equip` / `Item_Unequip` are real generic usecode event dispatchers gated by owner-row capability masks (`0x400` / `0x800`), and that the exported corpus currently contains `77` `equip` bodies plus `50` `unequip` bodies spread across actor, turret, alarm, conveyor, camera, and hazard classes. Current best read is `surviving Ultima-style event vocabulary generalized into activation/setup/state-change semantics`, not yet `fully proven paper-doll RPG gear subsystem`.
- The USECODE tooling lane now also has its first implemented readability follow-through from that improvement list: `tools/poc_crusader_usecode_parser.py` and `tools/export_usecode_pseudocode.py` now regenerate the full `977`-body corpus with one verified wrapper alias seed (`FREE.waitNTimerTicks` for `0A0C:0032`), class-name-aware target rendering (`FREE.slot_21`, `BLASTPAC.slot_20`, `TRIGGER.slot_20`, etc.), first-pass selector decoding that upgrades the simpler alarm/trigger `loopscr` runs into `for ... in nearby_items(shape=..., origin=...)` / `for ... in nearby_items(family=..., origin=...)` loops, and a second readable selector-family fallback that collapses raw `loopscr 0x42` runs into `selector_0x42(arg0=..., arg1=..., arg2=..., origin=...)` annotations or `for ... in selector_0x42(...)` loops where the control flow is simple enough.
- The USECODE/VM lane now also has a verified generic masked-context creation hub (`000d:463a`) plus two concrete sequencer-internal consumer blocks (`000d:208b`, `000d:21ed`) built directly on `entity_vm_context_create_from_slot_index`.
- The USECODE/VM lane now also has first caller-role evidence outside the older seg021 wrapper island: the new seg004 callers keep masks `0x8000:0x0007` and `0x2000:0x0015` in gameplay-side materialization lanes, while the newly named seg006 helpers now separate one extra-word masked lane with a real local class-state transition fallback (`0x0008:0x0030`) from a guarded `0x0010:0x0008` materializer that simply returns `0` on miss after readiness checks.
- The USECODE/VM lane now also has a wider verified higher-slot wrapper ladder: the `0005` island reaches slot ordinals `0x10..0x14`, slot `0x12` is a zero-extra-word lane, slots `0x11/0x13/0x14` carry extra-word payloads, and the current safest read is `slot-stable payload-shape taxonomy` rather than direct event-name promotion.
@ -128,6 +129,10 @@ Detailed completed analysis belongs in the files under `docs/`, not in this plan
- The print inventory behind that same `-debug` lane is now materially tighter too. A focused pass recovered concrete `ConsolePrintf` / `DebugPrintAndWaitForInput` strings instead of only caller families: startup/arg strings such as `Debugging mode ON.`, `You DO need help!`, `Enabling ENHANCED mode. (NOT!)`, `Warping to mission %d ...`, `Defaulting to skill level %d`, and `Demo mode.`; init/config strings such as `Using map patch file.`, `Running with partial installation.`, `Running with full installation.`, and `Redirecting mission %d tune to '%s'`; cache/swap progress scaffolding such as `Creating Swap file [` and repeated `.` / bracket fragments; plus stronger failure/debug-stop fingerprints like `COULD NOT CREATE GLOB ITEM!`, `No room for Dispatcher Record/Playback.`, `End of script! (press any key)`, and `Out of Memory! [%u]`. Recovered call levels so far are `0x32` and `0xff`, both above the `-debug` threshold of `10`, which reinforces that the practical scarcity of visible text is about path frequency and graphics-mode presentation, not about the threshold still filtering these known messages out.
- The older folklore claim about flat offset `E69FB` and a possible secondary monochrome monitor is now materially weaker too. Local NE-segment mapping puts `0xE69FB` at live address `1478:2dfb`, which falls inside the `SYSTIMER.C` string in a data/name table (`KeyboardProcess`, `KEYIO.C`, `PRIORITY.C`, `SystemTimer`, `SYSTIMER.C`, `AccWait`), not inside executable instructions. The current retail print lane still points to ordinary `stdout` at `1478:6c46`, and targeted searches found no direct `mono`/`monochrome`/`hercules`/`MDA` strings or obvious monochrome-adapter port/memory references (`0x3b4/0x3b5/0x3b8/0x3ba`, `B000`). Current best read is therefore `folklore or address-mapping mistake`, not evidence for a hidden retail secondary-monitor debug display.
- A focused localized-build comparison is now tighter too. The live `/es/CRUSADER.EXE` pass still shows the same broad cheat/debug framework with shifted addresses rather than a rewritten system: `-laurie` sets the broad master gate at `1478:0910`, the gameplay-input gate still exists at `1478:0927`, the lower keyboard-cheat latch still exists at `1478:5fb3`, event `0x410` at `13e8:2211` still toggles the CD transfer display, and `13e8:24a5` still toggles Hack Mover with English-facing strings. But the sequence side is narrower and more specific now: a direct live byte scan found no exact `jassica16` table `24 1e 1f 1f 17 2e 1e 02 07 00` anywhere in Spanish data `1478:0000-8c3f` or `1480:0000-1fff`, and the old English-side slot at `1478:2833` now holds pointer-like words instead of the matcher bytes. The same pass also surfaced a likely Spanish post-sequence latch analog: Hack Mover is pre-gated by `1478:8ad6` before the broad gate check. So the remaining open question is no longer "does Spanish have the same cheat/debug family"; it is "where did the Spanish secret matcher move, and what writes `1478:8ad6`?" Detailed notes now live in `docs/spanish-cheat-differences.md`.
- The follow-up Spanish-cheat pass narrows that further: in the live `/es/CRUSADER.EXE` database, `1478:0910` still has only the `-laurie` write at `1050:0985`, `1478:5fb3` still has only the Laurie-hint helper writes at `13e8:0071/0077`, and `1478:8ad6` still has no recovered direct writer even though `13e8:249b` tests it before Hack Mover. The old English matcher slot at `1478:2833` remains repurposed as pointer-like words, and the only explicit multi-key helper recovered in this pass (`11d0:024b`) is just a generic key-list membership check used from a movement/control cluster, not a cheat-toggle lane. Current best read is therefore now stronger than "unknown moved Spanish matcher": no live replacement cheat-trigger byte matcher has been recovered at all, and the remaining proof frontier is any non-`-laurie` writer of `1478:0910` or a real writer for `1478:8ad6`.
- The next localized-build pass narrows the practical keyboard side too. Full decompilation of `World_HandleKeyboardInput` (`13e8:14b4`) still shows the Spanish broad-gate debug family (`0x141`, `0x241`, `0x410`, Hack Mover), but no recovered translated `~` / `0x7e` cheat-latch branch. That means the old English `-laurie` plus tilde bootstrap is no longer a defensible Spanish assumption: `-laurie` still raises `1478:0910`, but no runtime tilde writer of `1478:5fb3` has been recovered, and `1478:5fb3` itself now reads more like a widely consulted gate byte than a proven English-style keyboard-cheat latch.
- The deeper keyboard-handler pass strengthens that again: `1478:5fb3` is not just missing a recovered tilde writer, it no longer behaves like a positive enable latch at all. Every recovered consumer in `World_HandleKeyboardInput` requires `1478:5fb3 == 0`, and the only recovered writers are the Laurie-hint helper pulse `13e8:0071` then `13e8:0077`, which leaves the byte cleared. Current best localized-build answer to the user-facing cheat question is therefore: `-laurie` is the only recovered positive enabler for the surviving broad Spanish cheat/debug hotkeys, while Hack Mover remains separately blocked behind the still-unwritten `1478:8ad6` gate.
- The next Spanish follow-up narrows two remaining folklore assumptions too. First, the old English immortality-string slots at `1478:2850/2866` are repurposed as pointer-like data in `/es/CRUSADER.EXE`, and no direct uses of those addresses were recovered, so the English `F10` replenish / immortality path is now `unproven in Spanish` rather than merely `not yet re-closed`. Second, the new `8ad6` hunt found a nearby runtime-state cluster at `8ad7/8ad8/8ad9`, but the actual neighbor writes belong to gameplay-input modal helpers and the Hack-Mover-adjacent runtime helper `13e8:282f`; they still do not touch `8ad6`, which keeps the best writer hypothesis pointed at an indirect or script-driven path rather than ordinary compiled keyboard logic.
### Recently Closed Or No Longer Live