OBD:BINA/OBJC/DOOR

From OniGalore
< OBD:BINA‎ | OBJC
Revision as of 00:00, 18 July 2010 by Iritscen (talk | contribs)
Jump to navigation Jump to search
This is about door instances. For the door class resource, see OBD:DOOR
ONI BINARY DATA
AKVA << Other file types >> CBPI
BINA : Binary data
TMBD << Other BINA >> ONIE
OBJC : Objects
CONS << Other OBJC >> FLAG
DOOR : Door
XML tutorial
Overview @ Oni Stuff
OBD.png


Bin r do.gif


Offset Type Raw Hex Value Description
0x00 char[4] 43 4A 42 4F OBJC object collection
0x04 int32 15 19 00 00 14344 size of the complete door part from this postion in bytes
0x08 int32 27 00 00 00 39 object collection version
0x0C int32 FC 00 00 00 252 size of the following element in bytes
First element (black outline)
0x00 char[4] 52 4F 4F 44 DOOR door
0x04 int32 57 12 00 00 6421 object ID
0x08 int32 08 00 00 00 8 object flags
0x0C float 00 00 4F 43 207.000000 x-position of the bottom of the door
0x10 float 00 00 D8 42 108.000000 y-position (height) of the bottom of the door
0x14 float 98 7F CC C3 -408.996826 z-position of the bottom of the door
0x18 float 00 00 00 00 0.000000 rotation on the x-axis in degrees
0x1C float 67 85 25 3D 0.040410 rotation on the y-axis in degrees
0x20 float 00 00 00 00 0.000000 rotation on the z-axis in degrees
0x24 char[63] TCdouble door type name (reference to 00957-TCdouble.DOOR of level 0)
0x63 int16 01 00 1 door ID
0x65 int16 00 00 0 key ID
0x67 bitset16 15 00 21, 0 door options; the following bits are possible:
0x01 00 - "initially locked" (at level load or after calling reset_mechanics)
0x02 00 - unknown; never used
0x04 00 - unknown; probably "locked" (whatever that means)?
0x08 00 - unknown; never used
0x10 00 - require player to press action to open door
0x20 00 - unknown; never used
0x40 00 - unknown; never used
0x80 00 - double door
0x00 01 - "mirror door" (mirrored along door's Z axis)
0x00 02 - one way door (one side locked, other side unlocked)
0x00 04 - reverse of the one way door (now the other side is locked)
0x00 08 - unknown; never used
0x00 10 - unknown; never used
0x00 20 - unknown; never used
0x00 40 - unknown; never used
0x00 80 - unknown; never used


0x69 float 00 00 4F 43 207.000000 x-position of the center of the door
0x6D float 00 00 F6 42 123.000000 y-position (height) of the center of the door
0x71 float 98 7F CC C3 -408.996826 z-position of the center of the door
0x75 float 00 00 61 44 900.000000 activation radius (squared)
0x79 char[63] _DOOR_RL_FLOOR3 first door texture (reference to 00216-_DOOR_RL_FLOOR3.TXMP)
0xA8 char[63] unused second door texture (reference to a TXMP file)
0xE7 int16 00 00 0 number of events (executed when the door is opened)
0xE9 padding
Instances NOT using bit 0x04 of bitset 0x67 ("locked"?)
(level:door)
2:26; 3:62; 6:1,41,42,43,45,46,47,48,49; 8:73; 18:97; 19:43,44
It's not clear what the effect of a "locked" bit would be; "initially locked" is what matters at level load and when calling reset_mechanics. Maybe "locked" was part of a runtime dump, but is ignored by the engine?
Instances using bit 0x100 of bitset 0x67 ("mirror door")
(level:door)
1:4,6,7,9,15,16,24,25,26,27,32,33,36,37,61,68,79,92,108;
3:50; 6:29,31,33,46,47; 8:14; 10:11,14,18,20; 18:14,42,70
The mirroring is complementary to the transformation in the ONLV'sOBOA.
Bluebox screenshot

221_door_properties.png


ONI BINARY DATA
AKVA << Other file types >> CBPI
BINA : Binary data
TMBD << Other BINA >> ONIE
OBJC : Objects
CONS << Other OBJC >> FLAG
DOOR : Door
[[OBD:File types/{{{family}}}|{{{family}}} file]]