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

Documentation progress

Browse source
This commit is contained in:
Marco 2026-04-01 17:40:52 +02:00
commit 5f22a8e2fd
13 changed files with 307 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/map_renderer/egg-identification.md
View file

@ -73,6 +73,21 @@ ScummVM's generic egg intrinsics expose:
So family `4` eggs use `mapNum` as their generic egg id in the engine interface.
Current Crusader viewer work now closes one additional family-4 detail for the `0x0011` placements used as usecode-trigger eggs:
- `quality & 0xFF` is the subtype selector for the authored family-4 usecode class.
- The runtime resolves that class as `0x0900 + QLo`.
- The currently verified authored subtype sets are:
- Remorse: `QLo 0, 1, 2, 13` -> `TRIGEGG`, `ONCEEGG`, `FLOOR1`, `MISS1EGG`
- Regret: `QLo 0, 1, 2, 5, 8, 10, 13, 24` -> `TRIGEGG`, `ONCEEGG`, `FLOOR1`, `MHATCHER`, `CHANGER`, `DOOREGG`, `MISS1`, `VIDEOEGG`
- `npcNum` does not behave like a DTABLE row here.
- `xRange = (npcNum >> 4) & 0x0f`
- `yRange = npcNum & 0x0f`
- Crusader multiplies those range nibbles by `64` world units.
- The runtime trigger check also uses a `+/-48` Z window.
That is why the renderer now treats `0x0011` as a proximity/usecode-trigger egg with a projected footprint overlay, a subtype-aware USECODE landing point, and only the narrower local-arrow rules that are actually justified by the recovered subtype body.
### Monster eggs
ScummVM's monster egg accessor exposes:
@ -422,18 +437,18 @@ What helps in the editor:
- show the `mapNum`/`mapArray` byte in hex because it behaves like a flag lane selector here
- describe the four resulting trigger lanes explicitly
### `0x04F8` frame `0`: door death helper
### `0x04F8` frame `0`: destroyable-door helper
This shape still lacks a clean No Remorse class label in the recovered tables, but the door-side behavior is already concrete enough to expose in the editor.
- `DOOR.slot_23` iterates nearby `shape=0x04F8` items after the door damage/crush path
- `DOOR.slot_23` iterates nearby `shape=0x04F8` items after the door damage path
- it matches them by `Item.getQLo(deathBox) == Item.getQLo(arg_06)`
- it dispatches `TRIGGER.slot_20` on lane `0` when `Item.getMapArray(deathBox) == 0`
- otherwise it dispatches the `0x80`-offset lane
Current best read:
- `0x04F8` is a door-side death or crush trigger helper
- `0x04F8` is a door-side helper that lets authored doors become destroyable and then forward into trigger logic
- `QLo` is the local door/link key
- the map-array byte chooses the normal trigger lane versus the `+0x80` variant
@ -728,7 +743,7 @@ That overlay is intentionally narrower than the existing verified teleport/eleva
- `ALARMHAT (0x0561) -> nearby 0x04D0` helpers, using the recovered local alarm scan behavior
- `STEAMBOX (0x0500) -> nearby steam-family targets`, matched by shared `QLo`
- `0x04F8 -> nearby door-family targets`, matched by shared `QLo` and local placement
- `0x04F8 -> nearby destroyable door-family targets`, matched by shared `QLo` and local placement
- `BRO_BOOT (0x04FE) -> nearby SPANEL targets`, matched by shared `QLo`
- `PANELNS (0x00A1)`, `CARD_NS (0x031D)`, and `SPANEL (0x03AA) -> nearby 0x04B1` controller helpers when they share the same local `QLo`
- `BOX_EW (0x0080) frame 0 -> nearby 0x04B1` controller helpers when they share the same local `QLo`