Ready
Load a BESM/BESP/BESL or CSV file to start
Idx Sig FormID EditorID Name Flags Size
No file loaded
Showing 0-0 of 0
Schema Preset:
FormID Editor ID Text String
No file loaded
Showing 0-0 of 0
BESM Memory Map & Binary Specification

The BESM file structure is optimized for rapid multi-core seeking and 1:1 rebuilding. Click on any section block below to inspect its detailed offset mapping and byte-level schema definitions.

FILE HEADER
Offset: 0x00 (108B)
SUBSECTOR DIR
Offset: 0x6C (sec*40B)
BLOB POOL (bPool)
[Zlib Deflate Pool]
STRING TABLE (sTable)
[Zlib Deflate Pool]
CUSTOM SCHEMAS
[Zlib Deflate Preset]
REBUILD CHRONO MAP
[Zlib Deflate Heap]
File Header Layout (108 Bytes)
Offset Type Field Description
0x00 (0) char[4] magic Magic identifier bytes: 'BESM'
0x04 (4) uint32 version File format version (0x00000001)
0x08 (8) uint32 secCount Total count of record subsectors in the directory
0x0C (12) uint64[3] bPool Blob Pool Descriptor: [fileOffset, compressedSize, uncompressedSize]
0x24 (36) uint64[3] sTable String Table Descriptor: [fileOffset, compressedSize, uncompressedSize]
0x3C (60) uint64[3] schemas Schema Preset Descriptor: [fileOffset, compressedSize, uncompressedSize]
0x54 (84) uint64[3] reconstruction Reconstruct Map Descriptor: [fileOffset, compressedSize, uncompressedSize]
Subsector Directory Entry (40 Bytes)
Offset Type Field Description
0x00 (0) char[4] signature Record type signature (e.g. 'REFR', 'WEAP')
0x04 (4) uint32 rowSize Uncompressed size of a single row/record inside the subsector table
0x08 (8) uint32 rowCount Total record rows stored in this subsector block
0x0C (12) uint64 sOffset Absolute file offset to the compressed data block
0x14 (20) uint64 sCompSize Compressed block size (Zlib Deflate)
0x1C (28) uint64 sUncompSize Uncompressed size of the parsed records table
Blob Pool Segment (bPool)

Uncompressed byte heap containing remainder subrecord fields. Mapped records reference their bytes using a 4-byte BlobOffset field inside the flat record row.

Relative Offset Type Field Description
+0x00 (0) char[4] signature Subrecord type signature/tag (e.g. 'VMAD')
+0x04 (4) uint16 length Subrecord data payload size (len) in bytes
+0x06 (6) uint8[len] payload Raw subrecord payload bytes
String Table Segment (sTable)

Stores all string mappings (like EDID / FULL string fields) mapped to their corresponding FormIDs. It contains a String Count header, followed by a contiguous Directory index, followed by the UTF-8 String Heap.

Offset Type Field Description
0x00 (0) uint32 count Total count of string entries in this table
0x04 (4) Index[count] directory Directory mapping entries (10 bytes each)
Dynamic char[] heap Contiguous UTF-8 string heap (encoded as 'Name|EDID')
Directory Entry Structure (10 Bytes):
  • +0x00 (uint32): FormID (fID)
  • +0x04 (uint32): Offset in String Heap (sOffset)
  • +0x08 (uint16): Length of string (sLength)
Custom Schemas Segment (schemas)

Stores the exact plain-text schema definition rules used to decompose the nested records into flat record rows. Stored as raw UTF-8 text strings.

[REFR:44]
  FormID:UInt32:HeaderFormID:0
  BaseID:UInt32:NAME:0
  X:Float:DATA:0
  Y:Float:DATA:4
  Z:Float:DATA:8
Reconstruction Chronology Map (reconstruction)

Reconstruction sequencing index which preserves the chronological ordering of the original ESM. Enables byte-perfect 1:1 rebuilding of the ESM file.

Offset Type Field Description
0x00 (0) uint32 count Total chronological records/entries
0x04 (4) Entry[] chronoEntries Repeating stream of chronological records
Chrono Entry Layout (Variable Size):
  • +0x00 (char[4]): Original record signature/type (e.g. 'WEAP')
  • +0x04 (uint8[24]): Original 24-byte record header raw bytes
  • +0x1C (uint32): Record body size (bodyLen) in bytes
  • +0x20 (uint8[bodyLen]): Raw body payload (if body is not reconstructed from database tables)
Address Offset Mathematics & ESM Comparison

1. Memory Address Calculations

To seek the database field column $C$ of record index $r$ inside a decompressed subsector block, the memory offset is calculated as:

Offset(r, C) = (r * rowSize) + colOffset

Where:

  • r: The zero-based row index of the record.
  • rowSize: Fixed size of a single record database row.
  • colOffset: The relative field offset defined in the schema.

2. Architectural Advantages Over ESM

  • O(1) Seek Performance: Unlike ESM which requires sequentially walking through nested variable-length record nodes, BESM permits instant index-based seeking.
  • Multi-Core Optimization: Subsector blocks can be decompressed and searched independently in parallel across multiple CPU cores.
  • Cache Locality: Identical record structures are stored contiguously in memory arrays, minimizing CPU cache misses.
  • Higher Zlib Compression: Isolating text strings (String Table) and variable-length data (Blob Pool) leaves highly uniform binary data arrays, achieving much higher compression ratios.
Understanding Bethesda FormIDs & Load Order Prefixes

A FormID is an 8-digit hexadecimal number (32-bit unsigned integer) that serves as a unique identifier for everything in a Bethesda master file.

FormID Byte Layout Structure

[XX][XXXXXX]
Prefix (2 Hex Digits): Load Order / Origin Mod
Index (6 Hex Digits): Record Unique Identifier
  • 00: Main Game (e.g. Skyrim.esm or Fallout4.esm)
  • 01: Update files (e.g. Update.esm)
  • 02-FD: standard ESM/ESP plugins depending on active load order
  • FE: Light Plugins (.esl / Creation Club) - uses 3 intermediary digits (e.g. FExxx123)
  • FF: Dynamically allocated in-game objects (temporary playthrough data)

BaseID vs. RefID

BaseID defines the prototype/template structure of an item, NPC, or object (e.g. the weapon stats of a Steel Sword).

RefID defines a specific placed copy/instance of an object in the world space (e.g. the specific Steel Sword sitting on a table in Breezehome).