In-game formats status

[DronCode]

All formats list:

• GMS - in progress
• PRM
• BUF
• PRP - reversed, need to make docs for it
• TEX (created subtool inside GMSTool, not refactored to external plugin yet)
• LOC - reversed, tested, created plugin. Working under Qt5 tool.
• SND - in progress
• MAT - in progress
• ANM - in progress (WIP, we have PoC with, but depends on PRM)
• SUP - skipped
• SGP - skipped
• SGD - skipped
• ZGF - skipped
• RMI - finished, PoC, in local BMEdit
• RMC - finished, PoC, in local BMEdit
• OCT - skipped
• WHD - not in BMEdit, WIP
• STR - not in BMEdit, WIP

[DronCode]

PRP Format:

Header

• 0x0 to 0xD - Magic bytes string "IOPacked v0.1\0x0"
• 0xE - Is raw view flag (endianess reader not required if byte equals to 0x0) (1 byte)
• 0xF to 0x12 - Flags field (4 bytes)
• 0x13 to 0x16 - zeroed (4 bytes)
• 0x17 - total keys count (4 bytes)
• 0x1B to 0x1E - data starts at (from 0x1F !!!) (4 bytes)

Header. Flags field description

In the most cases used 0xD value. In hex it means 0b1101

Bit nr	What's mean
0	???
1	is save?
2	behaviour of TAG_StringArray, TAG_StringOrArray_E and TAG_StringOrArray_8E
3	is tokens table presented
4	Not used
5	Not used
6	Not used
7	Not used

So, in usual case value 0xD means:

• is save - false
• should load tokens table - true

Bits from 4 to 7 aren't used.

Little note: game loading 4 bytes, but actually used only a few bits. Maybe I lost something but it looks weird.

Tokens

    struct ZToken
    {
        static constexpr PRPToken Void    = 0x0FFFFFFFF;
        static constexpr PRPToken Unknown = 0x0FFFFFFFE;
        static constexpr PRPToken Joker   = 0x0FFFFFFFD;
    };

Tags

enum PRP_ETag : uint8_t
    {
        TAG_Array               = 0x1,
        TAG_BeginObject         = 0x2,
        TAG_Reference           = 0x3,
        TAG_Container           = 0x4,
        TAG_Char                = 0x5,
        TAG_Bool                = 0x6,
        TAG_Int8                = 0x7,
        TAG_Int16               = 0x8,
        TAG_Int32               = 0x9,
        TAG_Float32             = 0xA,
        TAG_Float64             = 0xB,
        TAG_String              = 0xC,
        TAG_RawData             = 0xD,
        TAG_Bitfield            = 0x10,
        TAG_EndArray            = 0x7C,
        TAG_SkipMark            = 0x7D,
        TAG_EndObject           = 0x7E,
        TAG_EndOfStream         = 0x7F,
        TAG_NamedArray          = 0x81,
        TAG_BeginNamedObject    = 0x82,
        TAG_NamedReference      = 0x83,
        TAG_NamedContainer      = 0x84,
        TAG_NamedChar           = 0x85,
        TAG_NamedBool           = 0x86,
        TAG_NamedInt8           = 0x87,
        TAG_NamedInt16          = 0x88,
        TAG_NamedInt32          = 0x89,
        TAG_NamedFloat32        = 0x8A,
        TAG_NamedFloat64        = 0x8B,
        TAG_NamedString         = 0x8C,
        TAG_NamedRawData        = 0x8D,
        TAG_NameBitfield        = 0x8F,
        TAG_UNKNOWN, //14,16-123,128,142
        NO_TAG,

        /// My tags
        TAG_StringOrArray_E = 0xE,
        TAG_StringOrArray_8E = 0x8E,

        TAG_StringArray = 0xF,
    };

PRP File Map

Each PRP file contains those sections:

• Header - contains basic information about file
• Token Table - table of string tokens
• Objects Counter - 4 bytes U32 integer, means the total count of objects, described in PRP
• ZDefines - level base properties (see example here)
• Properties - contains the list of PRP Tags and references to Token Table.

Be aware of the order of entries in the "Properties" section is important for the game loader. The order of entries in GMS and their properties in PRP must be the same.

ZDefines

Each block in ZDefine has those sections:

• name (String Tag) - name of entry
• type id (I32 Tag) - type id of entry

There are 6 kinds of type id:

• 2 - Array of I32 values
• 3 - Array of F32 values
• 0xC, 0xE, 0x10 - String value, but method the future usage are different
• 0x11 - REFTAB (Array of Strings)

Properties and geoms

Each geom in the GMS file was stored in the same order as in the PRP. But geoms are represented as the tree hierarchical structure and IOI holds children nodes in the separated containers on the end of the current object as the member of the container.
So, each object represented as:

• ZGEOM: BeginObject .. EndObject - general properties of ZGEOM
• ControllerNames: ZEventBase things (custom systems inside the object). It's presented as string and object (contains properties of ZEventBase thing)
• Children: List of BeginObject..EndObject with children objects.

[DronCode]

GMS Format notes:

There are 2 kinds of GMS format:

• With compressed body (most cases; compressed by zlib)
• With raw body (feature for developers)

Any GMS files start with the same header:

Raw header

#pragma pack(push, 1)
struct SGMSHeader_t
{
    unsigned int iUncompressedSize { 0 };
    unsigned int iBufferSize { 0 };
    bool bIsUncompressed : 1 { false };
};
#pragma pack(pop)

Offset	Size	Field	Description
0x0	4	iUncompressedSize	The size of uncompressed body
0x4	4	iBufferSize	The size of compressed body
0x8	1	bIsUncompressed	This flag means that body is uncompressed

The total size of the structure is 9 bytes. #pragma pack(push, 1) is required.
Note: game understanding bIsUncompressed flag as an action to copy raw body instead of decompressing it. It could be useful in case when we need to debug in-memory our binary structure.

Contents map (0x48 bytes; Actually 0x50 with pads)

Offset	Name	Used in	Description
0x0	Entites	ZEngineDataBase::CreateGeoms	Table holds basic information about entities on scene
0x4			Expected 0
0x8			Expected 0
0xC			Expected 4
0x10	Geom stats	ZEngineDataBase::CountGeomsNr	Basic information about usage of entities on scene
0x14	Groups hierarchy info	?	Some sort of group infos & clusterization
0x18	?	ZEngineDataBase::CreateGeoms, CListUser::ConvertOffsetsToRefs	Information about lighting on scene (stored inside CListUser o_0)
0x1C	Events data	ZEngineDataBase::CreateGeoms	Count of ZEventBase things on scene
0x20	Weird data, looks like relative to materials	ZGeomBuffer::InitResourceGeoms	?(Pointer)
0x24	Unknown list of something	ZGeomBuffer::InitResourceGeoms	?(Pointer)
0x28	?	?	?(Pointer)
0x2C	?	?	?(Zeroed)
0x30	Materials	ZEngineDataBase::AllocSequence	?
0x34	Path finder data	ZEngineDataBase::InitPathfinder4Data	Some kind of PF4 data
0x38	Physics data	ZEngineDataBase::AllocSequence	UNUSED; Pointer to physics data, always 0xFFFFFFFF
0x3C	Base geoms pool size	ZEngineDataBase::CreateGeoms	Contains uint32_t value how much base geoms should be allocated on stack
0x40	Weapon handles	?	Array of u32 hashes of used weapons
0x44	Excluded animations list	?	Length & array of animation names which was excluded from scene

Offsets 0x48, 0x4C are padding (always zeroed)

More detals

Entities table (+0x0):

On +0x0 placed offset of U32 with an address of entities header table:

struct EntityHeader {
    uint32_t entOffset;  //real offset from top header is pBase + (4 * (entOffset & 0xFFFFFF)); Also, this value contains depth level
    uint32_t alwaysZero; // ?
};

struct EntitiesHeader {
    uint32_t totalEntities;
    EntityHeader headers[totalEntities];
};

Each entity is a structure of 0x40 bytes size:

   +0x0 - name (in BUF file offset)
   +0x4 - ?
   +0x8 - ?
   +0xC - primitive id
   +0x10 - ?
   +0x14 - type id
   +0x18 - ?
   +0x1C - control flags
   +0x20 - (in PRM file offset, don't know what is it)
   +0x24 - ?
   +0x28 - ?
   +0x2C - ?
   +0x30 - id
   +0x34 - ?
   +0x38 - ?
   +0x3C - ?

Geom stats (+0x10)

At this chunk stored basic information about geom usage stats.

It could be represented via this structure:

struct GeomStatsByType {
    u32 typeId;
    u32 entitiesCount;
    u32 unk8;
};

struct GeomStats {
    u32 statsCount;
    GeomStatsByType statsByType[statsCount];
};

In most cases, GeomStatsByType::unk8 is zeroed but sometimes it contains some positive value.
Game code sub this value from total allocation size, so I guess that value doesn't matter for us.
Also, the game will add 0x112 at the end of ZEngineDataBase::CountNrGeoms. It looks like a hack (as always).

See ZEngineDataBase::CountNrGeoms (0x0045F2D0) for details.

Groups & clusters info (+0x14):

GMSGroupClusterInfo (SPackedGeomsHeader::m_lGroupHierarchyInfo +0x14)
Purpose: Pre-allocation bookkeeping for ZGeomBuffer. Stores per-cluster entity counts broken into 24 classification slots (8 draw lists × 3 renderable base types). Used by the engine during ZSYS_AllocSequence to pre-size geometry memory — irrelevant for rendering, safe to skip.

Serialization:

struct GMSGroupClusterInfo {
    u32 data[24];       // entity counts per classification slot
};

struct GMSGroupsCluster {
    u32 clustersCount;          // N
    GMSGroupClusterInfo clusters[clustersCount];  // N × 96 bytes
    // followed by optional 12-byte zero padding
};

Reading rules:

1. Seek to gmsBody[0x14] → read clusterDataOffset (LE u32)
2. Seek to clusterDataOffset
3. Read clustersCount (LE u32)
4. Read clustersCount × 24 × u32 (96 bytes per entry)
5. Sum of all 24 values per entry = clusterSize (number of entities in that cluster)
6. Sum of all clusterSize across all clusters = total entity count (excluding synthetic ROOT)

Simple PoC code (python):

import struct

def read_clusters(gms_body: bytes):
    """gms_body is the decompressed GMS body (after zlib raw inflate)"""
    cluster_off = struct.unpack_from('<I', gms_body, 0x14)[0]
    data = gms_body[cluster_off:]
    
    count = struct.unpack_from('<I', data, 0)[0]
    entries = []
    
    for i in range(count):
        off = 4 + i * 96
        slots = list(struct.unpack_from('<24I', data, off))
        entries.append({
            'slots': slots,
            'total': sum(slots)
        })
    
    grand_total = sum(e['total'] for e in entries)
    print(f"Clusters: {count}, grand total: {grand_total}")
    
    # Slot usage analysis
    for si in range(24):
        used = sum(1 for e in entries if e['slots'][si] > 0)
        if used:
            print(f"  Slot[{si:2d}]: {used}/{count} clusters use this slot")
    
    return entries

Events data (+0x1C):

Here stored a count of ZEventBuffer instances per level.

If events count < 0x40000 game will allocate 0x40000 events.

For some "special" levels game will allocate extra event buffers:

Any level	M09	M10
0x57800	+0x53000	+0x70800

RES_HEADERS (+0x20) & RES_DATA (+0x24)

struct GMSResourceHeader {
    // Descriptor table (always 2 entries)
    u32  descriptorCount;          // = 2
    struct { char tag[4]; u32 a, b; } desc[2];  // "BOCZ"(0,1) "METI"(1,17)
    u32  padding;                  // = 0

    // Entity resource table
    u32  recordCount;              // = N (80 for M00_main)
    struct { u32 typeId; u32 resourceCount; u32 _pad; } records[N];  // 12 bytes each
};

resourceCount = total number of resource units needed for entities of this type. For ~75% of types it equals exact entity count. For complex types (ZGROUP subtypes, compound ZSTDOBJ) it's higher — likely including sub-primitives, child geometry, or extra vertex data units.

Example from M00_main:

0x00100001 (ZGROUP root group):       359 resources = 359 entities  ✓
0x00200002 (ZSTDOBJ basic geometry):  4797 resources vs 4377 entities (+420 extra)
0x00800024 (physics collision):       244 resources vs 178 entities (+66 extra)
0x00100428 (complex group variant):   67 resources vs 16 entities  (+51 extra)

RES_DATA is nn array of 19 (count, typeId) pairs (8 bytes each), followed by an embedded copy of the RES_HEADERS block:

u32 count;       // resource data value
u32 typeId;      // entity type hash

Materials (+0x30):

NOT CONFIRMED, NEED R&D

Header is

struct SRoot {
    uint32_t m_MaterialDefinition; //
    uint32_t m_PropertyDefinition; // id 7681
    uint32_t m_EnumDefinition;     // id 7694
    uint32_t m_MaterialSize;       // id 1954
    uint32_t m_StringDB;           // id 7707
    uint32_t m_MaterialData;       // id 7717
};

Offset	Type	Description
0x0	Pointer	m_MaterialDefinition
0x4	Pointer	m_PropertyDefinition
0x8	Pointer	m_EnumDefinition
0xC	Int32	m_MaterialSize
0x10	Pointer	m_StringDB
0x14	Pointer	m_MaterialData

struct SRoot {
// оффсеты в байтах: 0,4,8,12,16,20
uint32_t m_MaterialDefinition; // id 7668, 32 бита (хэндл/ofs)
uint32_t m_PropertyDefinition; // id 7681
uint32_t m_EnumDefinition; // id 7694
uint32_t m_MaterialSize; // id 1954
uint32_t m_StringDB; // id 7707
uint32_t m_MaterialData; // id 7717

void SerializeThis(ZStream& stream) const; // _ZNK...SerializeThisERNS_7ZStreamE

};

TODO: Complete reverse

Weapon handles (+0x40):

On +0x40 placed offset of U32 with an address of weapon handles list.

Excluded animations table (+0x44):

On +0x44 placed offset of U32 with an address in BUF file. It contains list of strings and their lengths:

+0x0 - length of string
+0x4 - the start of the string

Path Finder data (+0x34)

On +0x34 placed offset of U32 with an address of PF4RunTime data. The next U32 - size of PF4 data buffer.
Then stored next structure:

struct SPF4DataBlock
{
    short field0;
    short field2;
    short field4;
    short field6; //x4 - allocate memory, x4 + 0x3E - third alloc
    short field8;
    short fieldA; //x2 - allocate memory
    short fieldC;
    short fieldE;
    short field10;
    short field12;
    short field14;
    short field16;
    short field18;
    short field1C;
    int field20;
};

Read implementation is here
.text:0045A930 ; int __thiscall ZEngineDataBase::InitPathfinder4Data(ZEngineDataBase *this, int data)

Physics data (+0x38, legacy):

On +0x38 could be placed offset with physics data. Usually it's 0xFFFFFFFF to avoid loading physics data from GMS.

Entities pool size (0x3C):

This section contains how much ZBaseGeoms should be allocated at runtime + 1

[DronCode]

Few tools for PRP:

• PRP decompiler/compiler: HBM_PRPTool
• IDA Pro plugin for work with pre-compiled properties: G1 Props extractor IDA Plugin

Also, few words about my 'custom' PRP tags:

TAG_StringOrArray_E = 0xE,
TAG_StringOrArray_8E = 0x8E,

I'm thinking that TAG_StringOrArray_E and TAG_StringOrArray_8E actually is TAG_Enum and TAG_NamedEnum but I'm not sure that I'm right, need to test it.

[DronCode]

GMS: Read entities stats data PoC script:

class GeomStat:
    def __init__(self, type_id: int, count: int, unk8: int):
        self._type_id = type_id
        self._count = count
        self._unk8 = unk8

    @property
    def type_id(self) -> int:
        return self._type_id

    @property
    def count(self) -> int:
        return self._count

    @property
    def unk8(self) -> int:
        return self._unk8


class GeomStats:
    def __init__(self, stats_data: bytes):
        self._stats = []

        stats_count: int = struct.unpack('<i', stats_data[0:4])[0]
        stat_idx: int

        for stat_idx in range(0, stats_count - 1):
            type_id: int
            count: int
            unk8: int
            type_id, count, unk8 = struct.unpack('<iIi', stats_data[4 + (stat_idx * 0xC): 4 + ((stat_idx + 1) * 0xC)])
            self._stats.append(GeomStat(type_id, count, unk8))

    @property
    def stats(self) -> [GeomStat]:
        return self._stats


def prepare_gms_body(gms_body: bytes):
    stats_begin_at: int = struct.unpack('<i', gms_body[0x10:0x14])[0]
    geom_stats: GeomStats = GeomStats(gms_body[stats_begin_at:]) # All stats here

[DronCode]

PRM File Format:

This file contains geometry, lighting, bones, textures and material linking for models (primitives as "Glacier" says).
PRM File contains few sections:

• Header - contains basic information about where located other structures and how much of them.
  

• Descriptors - base information about primitive chunk
  

• PrimitiveChunk - a lot of data, contains kind of geometry, texture, material, offset of bones info and lighting info. This structure has "dynamic" size and it's defined by "kind" field.
  

• BonesInfo - not researched, but PrimitiveChunk refs to it by offset from start of file.
  

Header

This structure contains base information about contents in PRM file.

Name	Offset	Size	Description
Descriptors Offset	0x0	0x4 (u32)	Where descriptors list are stored
Primitives count	0x4	0x4 (u32)	How much primitives (without their variations) stored in PRM
Descriptors Offset 2	0x8	0x4 (u32)	Usually it's same to "Descriptors Offset"
Zeroed	0xC	0x4 (u32)	Zero

Descriptor

This structure contains information about primitive chunk (where it's stored, how much memory used for)

Name	Offset	Size	Description
Declaration offset	0x0	0x4 (u32)	Offset (from beggining of the file) where descriptor stored
Declaration size	0x4	0x4 (u32)	Size of chunk, allocated for descriptor
Should be loaded	0x8	0x4 (u32, but it's bool)	If this value marked as false primitive will not be loaded in game and will be ignored in primitives table. It's useful for primitives injection technique
Unknown C	0xC	0x4 (u32)	Really don't know what is it, in most cases zeroed

PrimitiveChunk

This is the hardest thing in PRM format. This structure has dynamic size and it's defined by it's kind. Known kind values:

Value	Description
0	?
1	?, but total structure size is 0xA0 (?). Theory: it's primitive with bones. Used at 0046D680
4	? Usage reference 0x00487480 & 0x00487450
6	?
7	Generic model?
8	Usage reference: 00487740
10	?
11	?
12	Usage references: Fn at 0046D250, 0046D220, 0046D1F0, 0046D1C0, 0046CFE0 (!!!), 0046CFA0, 0046E1B0 (!!)

The kind represents how much bytes will be used for primitive.

To be continued

BoneInfo

Name	Offset	Size	Description
Bones count	0x0	0x4 (u32)	How much bones in primitive

To be continued

[DronCode]

GMS Hierarchy storage format

It's been a long time research, but now I know how it works. First of all we need to discuss about EntityHeader structure.

Previously, I said this as

struct EntityHeader {
    uint32_t entOffset;  //real offset from top header is pBase + (4 * (entOffset & 0xFFFFFF)); Also, this value contains depth level
    uint32_t alwaysZero; // ?
};

but now I know that second entry really zeroed, but first entry is a little bit more difficult:

• Bits 0 to 24: It's an entity global offset. Operation entOffset & 0xFFFFFF extracts global offset inside file. Multiply by 4 means that we operating pointers (since Hitman Blood Money is x86 application all pointers size are 4 bytes).
• Bits 25 to 31: It's depth level.

Another note that when 25'th bit is set we should know, that entity may contains another entities (ie entity is a ROOT for something).

So, depth is a parameter, which means that actual parent is depth'th object in current path. What is path? Path is an list of ROOT objects. Hierarchy parse algorithm is pretty simple:

1. Put ROOT object (entity at 0) into path array
2. Take an object and calculate path length as path.size() - depth
3. Take a slice of path as [0: path.size() - depth]
4. Last element of path slice is a parent of our object
5. Save new slice as a path
6. If current object is a ROOT - push our object to back of path
7. Repeat from step 2.

[DronCode]

SND, STR, WAV and WHD formats are completely reverse engineered by @WSSDude here: https://github.com/WSSDude/Glacier1AudioTool/tree/main/docs/HitmanBloodMoney/Formats

[DronCode]

RMI & RMC

Overview

The format stores a static octree used by the game for spatial partitioning of objects. The file consists of:

• Header (SCompiledTreeHeader) — world origin, scaling, and offset to the objects array.
• Nodes (ZNodeCompiled) array — compact tree topology (each node = 6 bytes).
• Objects (CObjectInfo) array — axis-aligned bounding boxes (AABB) of game objects plus a reference.

The tree is stored in a linear array of nodes. Children of a node are stored contiguously. The last child in a run is marked with a high-bit flag in its childrenObjectsCount field.

File Layout

0x00 uint32  objectsOffset    // either absolute file offset or relative to end of header
0x04 float32 originX
0x08 float32 originY
0x0C float32 originZ
0x10 float32 worldScale
------ end of header (0x14 bytes) ------
[ nodes array ... ]   // size = NODE_SIZE * nodes_count
[ objects array ... ] // size = OBJ_SIZE * objects_count

• NODE_SIZE = 6 bytes (<HHH)
• OBJ_SIZE = 16 bytes (<i HHH HHH)

The meaning of objectsOffset is game-specific. In most files it is a relative offset from the end of the header to the start of the objects array. In some, it may be an absolute offset from the file start.

UPD: Original Glacier 1 structure looks like:

struct SCompiledTreeHeader {
    int32_t iObjectOffset;   // Offset 0
    float   vOrigin[3];      // Offset 4 (96 bits)
    float   fScale;          // Offset 16
};

Strutures:

SOctreeNode (6 bytes)

struct SOctreeNode {
    uint16_t childrenObjectsCount; // bits 3..14 = object count, bit 15 = last sibling flag
    uint16_t childrenNodeIndex;    // index into nodes[] of first child (0 = leaf)
    uint16_t objectIndex;          // index into objects[]
};

• (childrenObjectsCount >> 3) & 0xFFF = number of objects in this node.
• (childrenObjectsCount & 0x8000) = last child in siblings run.

Children are stored sequentially in nodes[] starting at childrenNodeIndex, ending when a node has the last-sibling flag set.

UPD: Original Glacier 1 structure looks like:

struct ZNodeCompiled {
    uint16_t m_iInfo;        // Offset 0
    uint16_t m_iFirstChild;  // Offset 2
    uint16_t m_iFirstObject; // Offset 4
};

SOctreeObject (16 bytes)

struct Vector3S { uint16_t x, y, z; };

struct SOctreeObject {
    int32_t   gameObjectRef; // handle or index into game object table
    Vector3S  vP1;           // min corner of AABB in tree space
    Vector3S  vP2;           // max corner of AABB in tree space
};

Coordinates are in tree space (uint16). The conversion from world space is:

treeCoord = (worldCoord - origin) * worldScale + 32768.0;
Values are clamped to 0..65535.

UPD: Original Glacier 1 structure looks like:

struct CObjectInfo {
    int32_t iID;    
    int16_t iMinX;
    int16_t iMinY;
    int16_t iMinZ; 
    int16_t iMaxX;
    int16_t iMaxY;
    int16_t iMaxZ;
};

Tree Traversal

PoC

void GetObjects(Node* n, Context* ctx) {
    // Objects of this node
    uint32_t cnt = (n->childrenObjectsCount >> 3) & 0xFFF;
    if (cnt) {
        Object* o = &ctx->objects[n->objectIndex];
        for (uint32_t i = 0; i < cnt; ++i) {
            ctx->predicateCallback(o->gameObjectRef, ctx);
            ++o;
        }
    }

    // Children
    uint16_t firstChildIdx = n->childrenNodeIndex;
    if (firstChildIdx) {
        Node* child = &ctx->nodes[firstChildIdx];
        while (true) {
            GetObjects(child, ctx);
            if (child->childrenObjectsCount & 0x8000) break;
            ++child;
        }
    }
}

Python PoC which read & write file: https://gist.github.com/DronCode/36542b70a80ce7fc2cb4d0c18f61c51d

[DronCode]

Details about GMS:

Final header is 0x44 bytes, ref to original code

struct SPackedGeomsTree {
  int32_t lCompiledGeomOffset; // +0x00  offset to SCompiledGeom
  int32_t lLightListID;        // +0x04
};

struct SPackedGeomsHeader {
  int32_t m_lPackedGeomsTreeOffset; // +0x0
  int32_t m_lFormat0; // +0x4 - usually 0
  int32_t m_lFormat1; // +0x8 - usually 0
  int32_t m_lFormat0; // +0xC - usually 4
  int32_t m_lGeomStats; // 0x10
  int32_t m_lGroupHierarchyInfo; // +0x14
  int32_t m_lUnk18; // +0x18
  int32_t m_lEventData; // +0x1C
  int32_t m_lGeomResourcesHeadersOffset; // +0x20
  int32_t m_lGeomResourcesOffset;        // +0x24
  int32_t m_lRoomEnvironmentListOffset;  // +0x28
  int32_t m_iCollisionDataOffset;        // +0x2C
  int32_t m_iMaterialDescOffset;         // +0x30
  int32_t m_lOffsetPathfinder4Data;      // +0x34
  int32_t m_lPhysicsDataOffset;          // +0x38
  int32_t m_iHighestGeomNr;              // +0x3C
  int32_t m_iWeaponPrimsOffset;          // +0x40
  int32_t m_iExcludedAnimNamesOffset;    // +0x44
}; // size 0x48

• m_lGeomResourcesHeadersOffset refs to SGeomResourcesHeader structure
• m_lGeomResourcesOffset refs to SGeomResources

// s12
struct SGeomResourcesHeader {
  int32_t m_lId;                   // +0x00 (515)
  int32_t m_lGeomResourcesStart;   // +0x04 (515) offset to SGeomResources
  int32_t m_lNrGeomResources;      // +0x08 (515) count of resources
}; // 12 bytes

// s8
struct SGeomResources {
  int32_t m_lGeomType;       // +0x00 (515) type of list
  int32_t m_lNrUnusedGeoms;  // +0x04 (515)
}; // 8 bytes

Entity is

enum EAssumedGeomDrawListType : uint8_t {
  GDLT_FastDraw   = 0,
  GDLT_CustomDraw = 1,
  GDLT_DynamicDraw= 2,
  GDLT_SIZE       = 3
};

struct SCompiledGeom {
  int32_t lOffsetName;          // +0x00 
  int32_t lOffsetMat;           // +0x04 
  int32_t lOffsetPos;           // +0x08
  int32_t lPrim;                // +0x0C
  int32_t iColiId;              // +0x10
  int32_t lGeomType;            // +0x14
  int32_t lEvents;              // +0x18
  int32_t lGeomAndGroupCon;     // +0x1C
  int32_t lExData;              // +0x20 - mostly unused, but it's CHUNKFILE in BUF file
  int32_t lDataBlock;           // +0x24
  int32_t lWorldFileId;         // +0x28
  int32_t lScripts;             // +0x2C
  int32_t m_iGeomNr;            // +0x30
  uint8_t cLightCon;            // +0x34
  uint8_t cAssumedGeomDrawList; // +0x35  EAssumedGeomDrawListType
  uint8_t cDummy[2];            // +0x36 
};

So, final path to entity is

SPackedGeomsHeader -> (m_lPackedGeomsTreeOffset) -> SPackedGeomsTree -> (lCompiledGeomOffset) ->

struct SGeomsHeader {
int32_t lCount; // +0x0
int32_t lGeoms; // +0x4
};

-> SGeomsHeader::lGeoms -> SCompiledGeom[]

[DronCode]

struct GeomStatsByType {
    u32 typeId;
    u32 entitiesCount;
    u32 unk8;
};

struct GeomStats {
    u32 statsCount;
    GeomStatsByType statsByType[statsCount];
};

Change to

struct SGeomTypeCount { // ex GeomStatsByType
    int m_lGeomType;        // 0:32
    int m_lGeomCount;       // 4:32
    int m_lNoNeedExtraGeom; // 8:32
};

struct SGeomTypeStats {
    u32 m_lCount;
    SGeomTypeCount m_aStats[m_lCount];
};