.rol files ("Role Object Binary") are scenario entity placement files used by Sega's Kenzan engine (Yakuza 3-5, Like a Dragon series). They define where interactive/reactive objects appear in the game world at runtime - things like weapons on ground, vehicles, drink tables, food stalls, and other scene props that need physics or event interaction.
They live inside stage archives under the ARCMN (Area Common) path:
ST_<CITY>.par/
<CITY>/ARCMN/st_<city>_arcmn_<time>.par/
<time>/ # day / eve / ngt variants
plan_sub_a14_yatai_scn116.rol # scenario placement file
st_fukuoka_arm_laa.rol # large area placement (weapons, items)
... more .rol files ...
Each time-of-day variant (day, evening, night) gets its own copy of these files with potentially different entity counts or positions.
| Offset | Size | Description |
|---|---|---|
| 0x00 | 4 bytes | Magic: ROPB (ASCII) |
| 0x04 | 2 bytes | Version/format flags (02 01) |
| 0x08-0x0C | 4 bytes | Unknown header fields |
| 0x10 | 4 bytes | Entity count (big-endian u32) |
| 0x14 | 4 bytes | Secondary count / stride info |
| 0x18 | 4 bytes | Data offset (where entity data starts, big-endian u32) |
Two sub-formats exist depending on file size:
Entity data starts immediately at data_offset (always 0x30). Each entity occupies a 128-byte slot but only the first 48 bytes contain real data. The remaining 80 bytes are zero-padded duplicate state copies used by the engine.
An index table sits at offset 0x30, with N entries of 16 bytes each:
| Offset within entry | Size | Description |
|---|---|---|
| +0 | 4 bytes | Entity type ID (sequential integer) |
| +4 | 4 bytes | Placement count for this entity type |
| +8 | 4 bytes | Block offset (index into entity data, in 48-byte units) |
| +12 | 4 bytes | Padding (0x00000000) |
Entity blocks follow the index table at data_offset, packed at 48 bytes each.
Every entity block has the same layout regardless of which sub-format:
| Offset | Size | Description |
|---|---|---|
| +0 | 16 bytes | Entity code: null-padded ASCII string (e.g. WEECP0076, WEMAP3092) |
| +16 | 4 bytes | Position X (big-endian float32) |
| +20 | 4 bytes | Position Y (big-endian float32, up axis) |
| +24 | 4 bytes | Position Z (big-endian float32, forward axis) |
| +28 | 4 bytes | Flags/padding (usually 0xFFFFFFFF or 0x00000000) |
| +32 | 4 bytes | Quaternion X (big-endian float32) |
| +36 | 4 bytes | Quaternion Y (big-endian float32) |
| +40 | 4 bytes | Quaternion Z (big-endian float32) |
| +44 | 4 bytes | Quaternion W (big-endian float32, scalar last) |
Quaternions are always unit-length (magnitude ~1.0).
The entity code is the closest thing to a model identifier. The engine resolves it internally:
| Prefix | Category | Example | Typical Use |
|---|---|---|---|
ACDEV* |
Device | ACDEV0046, ACDEV0136 |
Interactive devices, drink tables |
WEECP* |
Environment prop | WEECP0076 (yatai cart), WEECP0390 |
Scene props that need placement |
WEMAP* |
Weapon/item map | WEMAP0000, WEMAP3092 (nobori banner) |
Ground weapons, collectible items, decorative objects |
REMAP* |
Reactor/equipment map | REMAP1000, REMAP0080 |
Physics-reactive equipment, breakables |
RESTG* |
Restage/scene rest | RESTG1518 |
Scene reset trigger points |
WEPRG* |
Program/prg entity | WEPRG1000 |
Traffic/programmed behavior entities |
Entity codes do not directly name model files. Resolution works through the reactor.par archive:
# Example resolution chain:
rol entity code: WEECP0076
--> (search reactor.par for matching prefix)
reactor GMD: weecp0076_yatai_car.gmd
weecp0076_yatai_car_low.gmd (LOD variant)
rol entity code: WEMAP3092
-->
reactor GMD: wemap3092_nobori_a.gmd
Rule of thumb: Lowercase the entity code, then search reactor.par for filenames starting with that prefix. The actual GMD name includes a descriptive suffix (model variant) and may have _low LOD variants.
Same as GMD: +Y up, +Z forward. To convert to Blender/BeamNG (+Z up, +Y forward): negate X, swap Y and Z.
# Kenzan --> BeamNG transform
pos_x = -game_x
pos_y = game_z
pos_z = game_yUsage:
# Decode all .rol files in a stage directory to combined JSON
python3 KenzanROL.py /path/to/stage_data -o placements.json
# Also generate BeamNG-style forest4 instancing files per entity code
python3 KenzanROL.py /path/to/stage_data --forest
# With coordinate offsets for world alignment
python3 KenzanROL.py /path/to/stage_data -o out.json --offset-x 10.0 --offset-z 50.0Each placement entry contains:
file- source.rolfile pathentity_code- engine entity code (e.g.WEECP0076)flags- raw uint32 flags field from binary (usually 0xFFFFFFFF or 0)pos- transformed position[x, y, z]in BeamNG world spacequat- transformed quaternion[x, y, z, w]in BeamNG forest4 order
Forest output writes one <entity_code>.forest4.json per unique entity code with line-per-placement format.
- Entity codes are not filenames. Always cross-reference with
reactor.parfor the actual GMD. - Duplicate placements across time-of-day archives. Day/eve/night each have their own
.rolcopies. If you only need unique positions, deduplicate by comparing entity code + position. - Compact files use 128-byte slots to avoid reading duplicate state data at +0x50 within each slot. The decoder handles this automatically.
- Not all entities have geometry.
WEPRG*program entities and someREMAP*entries are invisible triggers or behavior anchors, not models you can import. - Big-endian throughout. All floats and integers use network byte order (
>f,>Iin Python struct).