-
Notifications
You must be signed in to change notification settings - Fork 5
Romlist
Each map has a [mapname].romlist.zlb file in the root of the disc. This file is a ZLB-compressed list of objects on the map.
Entries in this list are variable length, following this format:
| Offset | Type | Name | Description |
|---|---|---|---|
| 000000 | s16 | type | Object type (ObjDef) |
| 000002 | u8 | size | Entry length in (4-byte) words |
| 000003 | u8 | acts0 | Bitmask of map acts to load in |
| 000004 | u8 | loadFlags | Loading flags |
| 000005 | u8 | acts1 | Bitmask of map acts to load in |
| 000006 | u8 | bound | Load if distance to player is less than (bound * 8) |
| 000007 | u8 | ? | Possibly object "slot" whatever that is |
| 000008 | vec3f | position | Object position |
| 000014 | u32 | id | Unique ID |
| 000018 | varies | - | Parameters depending on object type |
The object type is translated:
- If it's positive, the corresponding entry in
OBJINDEX.bin(which is simply an array ofs16) is used. - Otherwise, the absolute value is used.
The resulting ID is an index into OBJECTS.tab, which gives the offset in OBJECTS.bin of the ObjectFileStruct.
(Why are these in the disc root, instead of the map directory? No idea.)
The unique ID is used to persist the object in the save file. The coordinates of up to 63 objects can be saved using this ID. This ID is also used to look up the object in scripting. Every object in the romlist files has a unique ID. (Exception: Multiple objects in unused maps have the ID 0xC5D.) Dynamically created objects have ID 0xFFFFFFFF.
Each bit of acts0 and acts1 corresponds to an act number:
| Bit | Act1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| acts0 | 01 | 02 | 04 | 08 | 10 | 20 | 40 | 80 | |||||||
| acts1 | 80 | 40 | 20 | 10 | 08 | 04 | 02 |
- If the given bit is not set, the object will load in this act.
- The lowest bit of
acts1appears to be unused. - Act 0 loads all objects.
- Act -1 loads no objects, but since the act number ranges from 0 to 15, this is impossible.
LoadFlags:
| Flag | Name | Description |
|---|---|---|
| 0x01 | isLevelObject | Load if act bits allow |
| 0x02 | isManualLoad | Always load - used for dynamically created objects |
| 0x04 | OnlyLoadIfNearPlayer | Use bound
|
| 0x08 | ? | ? |
| 0x10 | loadForOtherMap | Load for a different map ID |
| 0x20 | isBlockObject | Load regardless of position |
| 0x40 | ? | ? |
| 0x80 | ? | ? |
(names are inferred from debug messages)
These are the warp pads, or more accurately, the particle effect on top that actually triggers the warps.
- 0x18: Object's (or player's?) initial rotation
- 0x1A: Warp index? (maybe only for some of them)
- 0x20: GameBit ID to enable the warp (FFFF=always enabled)
Old version of Transporter found in the unused old Krazoa Palace map.
- 0x19, 0x1A: Source/Destination warp IDs (indices into
WARPTAB.bin)
(XXX which object(s) is this?)
- 0x1C: GameBit: whether lock has been opened
- 0x1E: GameBit: key item
Switches that are activated by inserting the staff and using it as a lever.
- 0x18: GameBit which is toggled when activating the switch