It is basically a list of 2D polygons.
- The first byte is a uint8 version number, which can currently be 1 or 2.
- If version >= 2, it is followed by a string ID. If version < 2, the ID is assumed to be the empty string.
- Next is a uint8 indicating the number of polygons to follow.
- For each polygon, there is then a uint8 indicating the number of vertices in that polygon.
- Following the complete list of polygon sizes, is the complete list of vertices, such that the vertices of one polygon is directly followed by the vertices of the next. Each vertex is an (x, y) pair of half-floats.
Figured I'd make a thread to share some details about the `obst` layer which Loftar is using for newer bounding boxes. It's still a WIP since Loftar hasn't released the official doc on it, but this is what I've found so far that appear to be true with examples.
Layout:
- Code: Select all
uint8 - Version (V)
V = 1: (Found in wall segs, gates, etc)
uint8 - Number of polygons to follow (#P)
For each #P:
uint8 - Number of vertices (#V_P)
For each #P:
For each #V_P:
(float16, float16) coordinate pair
V = 2: (Found in newer bounding boxes like vidol, natural wonders)
string - ID (Most are null 00, but vidol for example has a "build")
uint8 - Number of polygons to follow (#P)
For each #P:
uint8 - Number of vertices (#V_P)
For each #P:
For each #V_P:
(float16, float16) coordinate pair
The (float16, float16) coordinate pairs are relative to gob.rc. To get the actual offset location you simply do
- Code: Select all
(float16, float16).mul(MCache.tilesz)
Type 1 Obsts are fairly simple and i've only seen them for walls to get the exact offsets which are fractions typically. For example a PaliCP:
- Code: Select all
01 01 04 FC B7 FC B7 FC 37 FC B7 FC 37 FC 37 FC B7 FC 37
01 - Version
01 - # of polygons?
04 - # of points for first polygon
Data points: (float16, float16) offset from center of object multiplied by tilesz
Polygon 1:
(FC B7, FC B7) -> (-0.4990234375, -0.4990234375)
(FC 37, FC B7) -> (0.4990234375, -0.4990234375)
(FC 37, FC 37) -> (0.4990234375, 0.4990234375)
(FC B7, FC 37) -> (-0.4990234375, 0.4990234375)
When you multiple the datapoints by tilesz and create a bounding box relative to gob.rc for them you'll end up with the exact size:
yellow = exact based off obst, orange = integer offset estimate
Type 2 Obsts are the new bounding boxes:
Village Idol example. This comes with two Obsts! One defines the overall size while the other defines the actual hitbox.
- Code: Select all
02 00 02 03 03 67 B3 0A 3A BB 39 0A 3A 67 B3 03 3E 67 B3 03 BE BB 39 0A BA 67 B3 0A BA
02 - Version
00 - ID - No Op
02 - # of polygons - 2
03 - # of vertices for 1st polygon
03 - # of vertices for 2nd polygon
The rest are data points that define two triangles:
Polygon 1:
(67 B3, 0A 3A)(BB 39, 0A 3A)(67 B3, 03 3E)
Polygon 2:
(67 B3, 03 BE)(BB 39, 0A BA)(67 B3, 0A BA)
This second Obst is likely for the server only
02 62 75 69 6C 64 00 01 04 91 B9 53 BD 18 3C 53 BD 18 3C 53 3D 91 B9 53 3D
02 - Version
62 75 69 6C 64 00 - ID - `build` Op
01 - # of polygons
04 - # of vertices for 1st polygon
The rest are data points that make up the rect of the vidol
Polygon 1:
(91 B9, 53 BD) (18 3C, 53 BD) (18 3C, 53 3D) (91 B9, 53 3D)
Other examples of new hitboxes:
Rock Crystal:
- Code: Select all
02 00 01 06 5F BA 5B B7 00 00 42 BA 5F 3A 5B B7 41 39 1E 36 02 00 5B 3B DD B9 0F 36
02 - Version
00 - ID - No Op
01 - # of polygons
06 - # of vertices for 1st polygon
Polygon 1:
(5F BA, 5B B7)
(00 00, 42 BA)
(5F 3A, 5B B7)
(41 39, 1E 36)
(02 00, 5B 3B)
(DD B9, 0F 36)
Ice Spires (altho, despite this being a simple type I feel this needs to be rotated by 180 deg)
- Code: Select all
02 00 01 06 3F C1 5C BE C7 34 04 C3 C1 41 00 BF 20 42 7E 3F 05 00 DD 41 ED C0 99 3E
02 - Version
00 - No Op
01 - # of polygons
06 - # of vertices for 1st polygon
Polygon 1:
(3F C1, 5C BE)
(C7 34, 04 C3)
(C1 41, 00 BF)
(20 42, 7E 3F)
(05 00, DD 41)
(ED C0, 99 3E)