File Formats

This section describes the extensions that are found in the game files and the SDK.

General

Configuration and script files

Textures

Shaders

Models

Animations

Archives and Resource Packages

Game level

Starting here, the details of the formats are written. You are encouraged to use links from the tables above to jump directly to the format you are interested in

Binary files

About

This article is an introduction to binary files.

Before reading the other articles in the "File Formats" category, you should read this one first.

Structure

In binary files, bytes are represented in reverse order.

For example, the number 0x12345678 in a file would look like this: 78 56 34 12.

Data types

Let's introduce the notation of data types.

These notations will be used in other articles.

In some files a value may not be stored in the whole byte, but only part of it (e.g. 4 bits).

As a result, one byte will store two values.

In articles about binary files, sizes will be specified either in bits or in bytes.

Strings necessarily have a null byte at the end, which indicates that the string has ended. For example: "test_string0x0".

As a result, the length of the string is equal to the number of characters in it + 1 (null byte).

Blocks

In X-Ray, some binary files are in RIFF format.

Such files have blocks (also called chunks or sections).

A block is binary data with a header.

Block structure

You can see from the identifier what is stored in a particular block.

If the compression is set to 0x0000, the block is uncompressed, and if it is set to 0x8000, the block is compressed by the Huffman method.

You can use a program from xray_re_tools (trunk\garbage\lzhuf\lzhuf.c) to decompress compressed blocks.

In the files of the final version of the game most blocks are uncompressed.

The size of the block content indicates only the number of bytes of data (not including identifier, compression and size bytes).

Binary block data can be represented by nested blocks.

Sources

Source

.anm (Animated paths)

About

A set of coordinates, which works as an animation of the actor's camera movement. It is also used for anomalies, which need to be given a path.

Technical information

• Order of rotation: YXZ

Interpolation types

• TCB
• BEZIER_2D
• BEZIER_1D
• LINEAR
• HERMITE

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

bump#.dds

About

Corrects DXT compression errors in .bump

Technical information

Format

• RGB - Error correction for normal map (bump.dds) - Not necessary if you're using good quality normal map. It's generated with SDK
• A - height map; used for parallax, if the use of it was turned on when setting up the texture

The engine currently supports the following compressions

• DXT5
• BC7

Can be generated by

• Bump Generator
• SDK 0.7

bump.dds

About

The bump map is a regular normal map in A(BGR) format (typical for DXT5_nm compression format). The developers used this order for a very simple reason - DXT compression "spoils" the texture much less, since the alpha channel is not subjected to compression and remains almost in its original form.

Technical information

Format

• R - Glossiness (Glossiness, aka inverted roughness. It works best in stalker, and allows for using better BRDF)
• G - Normal Z (Unused in Anomaly 1.6.0)
• B - Normal Y (DIRECTX format.)
• A - Normal X

The engine currently supports the following compressions

• DXT5
• BC7

Can be generated by

• Bump Generator
• SDK 0.7

.cform (Collision Form)

About

Contains a solid map structure. All tangible objects with materials live here. Because of this, the game knows with what sound and property objects should react when they are hit by bullets or walked on

Technical information

• Format version: 4

The file consists of one block, which contains the following

BBox

BBox describes the entire map, including absolutely all static objects. The BBox diagonal is represented by two vertices that have the same format as the others:

Triangle

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

.dds (DirectDraw Surface)

About

DDS is most often used to store textures and is used in many 3D applications, as well as in modern 3D games. It allows you to store textures both in compressed and uncompressed form.

Technical information

Format

• RGB - Diffuse colour
• A - Alpha (Used for translucent/transparent shaders like glass/grass)

The engine currently supports the following compressions

• DXT1
• DXT5

Programs editing this file

• Any program that works with .dds files (Example: Paint.net or GIMP)

detail_map_name_(with bump or bump#).dds

About

Same as a regular .dds texture, needed as an extra map in a .thm

Technical information

The same as the .dds. But overlaid on top of an existing texture, for more detail

Example:

Programs editing this file

• Any program that works with .dds files (Example: Paint.net or GIMP)

.details

About

Detailed objects (grass, cigarette butts, construction debris) on the level

Technical information

• Format version: 3

General structure - file blocks

It consists of three RIFF sections (blocks):

Block order in version 3: 0x1, 0x2, 0x0

One cell (slot) is a parallelepiped.

The dimensions of all cells along the X and Z axes are the same and equal to 2 meters.

The height of the slot (the dimensions of the parallelepiped along the Y axis) in all the slots is individual.

slot in the Level Editor

Blocks

Block 0x0 (header)

Block 0x1 (meshes)

A block consists of nested blocks.

The nested block identifier is the mesh index of the detailed object.

Nested block data is a mesh in .dm format

Block 0x2 (slots/cell table)

The block stores cells (slots).

The slots in this block are written alternately.

Up to four meshes of detailed objects can be attached to each slot.

The mesh index of a detailed object can be in the range [0 ... 62] (63 is no mesh).

One slot's data is stored in 16 bytes (128 bits), which store the following:

As you can see from the table, each slot has 16 density values.

Each of the four meshes has four density values (for the four corners of the slot).

The density values within a slot are interpolated from the density values of the slot corners.

Let us denote the densities as follows:

• a0 - density for the left front corner of the slot

• a1 - density for the right front corner of the slot

• a2 - density for the left rear corner of the slot

• a3 - density for the right rear corner of the slot

If you look at the slot from above, the densities will look like this:

Mesh density, slot view from above

Restrictions are imposed on the position of slots along the Y axis.

The lower limit is -200 meters.

And the allowed range: from -200 meters to 619 meters (0.2 * 4095 - 200).

The maximum height of the slot (parallelepiped) is: 25.5 (0.1 * 255).

The upper boundary of the slot is equal to: the lower boundary + the height of the slot.

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

.dm (Detail Model)

About

Effect of a dynamic weather environment (e.g., rain or lightning)

Technical information

It works like this: UV descends down the Y coordinates to the texture

Format limitations

• Must have one material
• Does not support antialiasing

General structure

Structure description

Shader name

Texture name

Flags

Minimum size

Maximum size

Number of vertices

Number of indexes

Vertices

The vertices are stored sequentially.

The structure of a single vertex:

Restrictions are imposed on the vertices:

1. one vertex may have only one texture coordinate. When saving the model in *.dm, a vertex that has two (or more) texture coordinates is converted into two (or more) vertices.
2. Their number should not be more than 65536, because their triangle indices are stored in 2 bytes.

Indexes

The indices of the vertices by which triangles are formed.

The indexes are stored sequentially.

The index structure:

Programs editing this file

• Blender (X-Ray Addon)
• X-Ray Export Tool (Object Tool)
• SDK 0.7

Sources

Source

.efd (Evaluation Function Data)

About

Table of AI heuristic parameters, contains constants for fine-tuning A-Life. They are used as input parameters in scripts.

Example

anomalydetectprobability.efd

[values]
offset_0: value_0 = 1
offset_4: value_1 = 1
offset_8: value_2 = 2
offset_12: value_3 = 8
offset_16: value_4 = 3
offset_20: value_5 = 49
offset_24: value_6 = 9
offset_28: value_7 = 79
offset_32: value_8 = 20
offset_36: value_9 = 100
offset_40: value_10 = 1
offset_44: value_11 = 2
offset_48: value_12 = 0
offset_52: value_13 = 1
offset_56: value_14 = 19.9940643310547
offset_60: value_15 = 59.9821968078613
offset_64: value_16 = 99.9703216552734
offset_68: value_17 = 19.9940643310547
offset_72: value_18 = 59.9821968078613
offset_76: value_19 = 99.9703216552734
offset_80: value_20 = 29.9910984039307
offset_84: value_21 = 59.9821968078613
offset_88: value_22 = 89.9732894897461
offset_92: value_23 = 69.9792251586914
offset_96: value_24 = 74.9777450561523
offset_100: value_25 = 84.9747772216797
offset_104: value_26 = 89.9732894897461
offset_108: value_27 = 89.9732894897461
offset_112: value_28 = 89.9732894897461
offset_116: value_29 = 79.9762573242188
offset_120: value_30 = 79.9762573242188
offset_124: value_31 = 79.9762573242188
offset_128: value_32 = 79.9762573242188
offset_132: value_33 = 79.9762573242188
offset_136: value_34 = 79.9762573242188
offset_140: value_35 = 39.9881286621094
offset_144: value_36 = 49.9851608276367
offset_148: value_37 = 79.9762573242188

Programs editing this file

• Evaluation Function Consctructor

Sources

Source

.err

About

Contains information about geometry errors during level compilation with xrLC.exe

Technical information

It consists of three blocks:

Blocks

All vertices in the file are stored in the following structure:

Block 0x0 (vertices)

Contains vertices that were glued during compilation.

Block structure:

Block 0x1 (edges)

Contains edges that were deleted during compilation.

Block structure:

Structure of a single edge

Block 0x2 (triangles)

Contains broken triangles (the area of which is close to 0.0).

Block structure:

Structure of a single triangle

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

.geom

The format was disassembled by Haper (not completely disassembled, adjustments are needed)

About

Contains all visible map geometry. It contains all vertices with normals and coordinates for textures and indexes for building geometry, as well as synchronization.

Technical information

The file consists of the following blocks

Types of variables

Map compiler version (the block is the same for all maps)

Vertex description

Vertex description block

A few words about the vertex format. As you already know, there are several vertex description blocks in the file. Not all objects in the game are the same: you have to specify coordinates of lightmaps for brushes, and coordinates of textures for trees can be simplified. Therefore, vertices specified in different blocks may be different. The vertex format is specified using several structures - this is the standard D3D vertex buffer format. That is, the file contains ready assembled vertex buffers for D3D:

At the very beginning of any vertex are the coordinates of its placement, so the vertex format does not include a description of the coordinates. There are only three vertex formats in the 2215 maps:

Vegetation

Thus, the total length of one vegetation vertex equals 32 bytes.

Brush

The total length of one brash vertex is 36 bytes.

Entity

The total length of one vertex of an entity is 36 bytes. Based on this, we get, for example, this view of the vertex:

Brush

Indexes description

Index description block

Index: Word(2) . The number of indexes must always be a multiple of three, because triangles are constructed using indexes.

Synchronization description

(what they synchronize is still a mystery to scientists)

Synchronization block

Synchronization unit

Sources

Source

.hom (Hierarchical Occlusion Mapping)

About

HOM is a geometry cutter, which is a mesh and is needed to increase performance. This file is created during level compilation.

Technical information

Blocks

Consists of two blocks:

Block description

Block 0x0 (header)

Block 0x1 (mesh data)

Contains the data of the triangles, which are written one by one.

The data is for one triangle:

Possible values of the "two sided" option: 0x0, 0x1

The polygon indices are not saved, but they can easily be generated, since all vertices are saved so that the polygon indices are in ascending order.

The first triangle will be: 0, 1, 2, second: 3, 4, 5, third: 6, 7, 8, etc.

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

level

About

Contains all the essentials. This contains light sources, object descriptions, names of their corresponding textures and shaders, portals, and sectors.

Technical information

• Format version: 14

General structure - file blocks

Map compiler version (the block is the same for all maps)

Description of portals (the block for all maps is the same and contains no data)

Light sources

Light Source

Coronas of light sources

Corona of the light source

Textures

Texture

Note: the zero texture is specified without the file name and consists only of the symbol #0. So, after the field "number of textures" right after the symbol #0, do not be alarmed :)

Sectors

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

LTX files

About

LTX files are basically ini files with some custom additions. They are located all over the gamedata/configs and are used for, well, configs.

Here's how ltx config might look like:

#include "tables/gun_*.ltx"

[some_nice_gun]
recoil              = 0.8
boosts              = a, b, c, d    ; list
fancy_feature       = {=is_night()} true, false

[some_other_gun]
...

From this example we can see some fancy ltx features:

1. #include preprocessor command. This command basically merges the file into this config. Many of the configs are included into system.ltx this way, so you can access almost all sections through ini_sys handler.
2. Wildcard imports - * in include statement corresponds to any text, so the given include will include both gun_ak.ltx and gun_m4.ltx. This feature was developed for Anomaly, so you may not find it in other mods.
3. Name of the section in square brackets - this is referred in scripts as section_name or just section.
4. Key-value pairs. Values may include comma-separated lists.
5. Comments start with ;.
6. fancy_feature uses something called "condlist". Refer to condlists manual to understand this bs.

Programs editing this file

• Any text editor
  • There are also extensions for VSCode for .ltx (LTX Support Extension by AziatkaVictor)

.object

About

These files are intended for the X-Ray SDK to store 3D content in its original, uncompressed, lossless form. They are source files that store information before compilation into other game compressed formats.

Technical information

The format can store the following basic data (the list is not complete)

• meshes
• materials
• bones
• skeleton animations

Possibilities and limitations of the .object format

One *.object file can store:

• one or more meshes if it has no skeleton and only one meshes if it has a skeleton
• one or more materials
• a skeleton can be absent, or it can hold at least one
• a skeleton can store a minimum of 1, a maximum of 64 bones (for X-Ray SDK 0.4)
• skeleton animations may not be present, or one or more animations may be stored
• skeleton animations do not support Scale keys
• each mesh can have one or more materials
• each mesh must have one UV scan
• each material can store only one texture

Programs editing this file

• Blender (X-Ray Addon)
• X-Ray Export Tool (Object Tool)
• Ogf Editor by ValeroK - (Only as a converter!)
• SDK 0.7

Sources

Source

.ogg

About

The sound format used by the game engine

Technical information

• Supports up to 44.100 Hz
• Audio format:
  • Mono audio format (For the game world)
  • Stereo audio format (To play in the player's head)
• Audiocodek: Vorbis

Programs editing this file

• Any sound editor that supports .ogg (But it won't write comments into the chunks!)
• Sound Attribute Viewer And Tweaker or OGG Editor
• SDK Sound Editor - Only source .wav file

.omf (Open Motions Format)

About

A specialized S.T.A.L.K.E.R. game format containing animations. This is a separate dedicated file used in conjunction with .ogf models. Was created in order to optimize process when some different models use the same list of animations.

Technical information

They are in RIFF format. That is, the file is divided into chunks. The omf file consists of two chunks:

• 0xE - stores animations (rotation, movement of bones)

• 0xF - stores the Bone Parts and animation parameters.

These chunks can be found inside the ogf files. In other words, an omf file is a slice of an ogf file that is moved to an external file. The structure of the 0xE and 0xF chunks in ogf is identical to those in omf.

The structure of the 0xE chunk

This chunk consists of nested chunks. The first nested chunk is the one with the identifier 0x0. The zero chunk stores an unsigned 32-bit integer number. This number indicates the number of animations in the omf file. The identifier of each subsequent chunk is one more than the previous one. That is, 0x0 is followed by 0x1, then 0x2, 0x3, etc. All the chunks following 0x0 contain animations. Description of the nested chunk that stores the animations The animation name comes first, which is a string ending with a null byte. Next is an unsigned 32-bit integer, which specifies the number of animation frames. The following data is the dice transforms. For each bone, rotation, movement, and flags are stored. Flags come first. Flags is an unsigned 8 bit integer. The first bit of this byte indicates if the movement is modifiable. If the bit is 1, then the movement has values throughout all frames. If the bit is 0, then the movement has only one value for the entire animation interval. This is done to optimize it so that it doesn't store a bunch of identical keys, but instead has a single value. The second bit of this byte indicates whether the rotation is static (not changing throughout the animation). The third bit is the High Quality flag. If it is 0, then the position has an 8-bit representation, otherwise it is 16-bit. Next comes the information about the rotation. What will be written to the file next depends on the flags. If the second bit of the flag is 0, the file will contain the following: One rotation value as a quaternion with two-byte signed components. That is, QXYZ, each 2 bytes, for a total of 8 bytes. And if the second bit of the flag is 1, then the following follows: crc32 sum as a 4 byte unsigned integer. And after that come the rotation quaternion values for each frame. The format of rotation is the same as described above (the same 8 bytes). Now comes the movement information. If the first bit of the flag is 1, then follows a 32-bit unsigned integer, which is the crc32 sum. This is followed by three eight-bit numbers, which indicate the position of the bone on the x, y, z axes. These positions are written for each frame. That is, the positions should be read in a loop, which is repeated as many times as the number of frames contains the animation. After all these positions are data about the initial conditions of movement: Amplitude or size of movement. These are three float numbers (4 bytes each). And then there is the initial value of movement. These are also 3 float numbers. These initial conditions are stored in a single instance for each bone in this animation. That is, these values do not change throughout the animation. If the first bit of the flag is 0, there is one move value for all frames. This movement is stored in 3 float numbers (4 bytes each).

Below is a pseudocode that describes one animation:

name = string
length = uint32
for bone in bones {
    flags = uint8
    translate_present = flags(0)    // get bit 0
    rotate_absent = flags(1)    // get bit 1
    high_quality = flags(2)    // get bit 2
    if rotate_absent {
        quaternion = int16, int16, int16, int16    // Q, X, Y, Z
    } else {
        motion_crc32 = int32
        for (i=0, i<length, i++) {
            quaternion = int16, int16, int16, int16    // Q, X, Y, Z
        }
    }
    if translate_present {
        motion_crc32 = int32
        if high_quality {
            for (i=0, i<length, i++) {
                translation = int16, int16, int16    // X, Y, Z
            }
        } else {
            for (i=0, i<length, i++) {
                translation = int8, int8, int8    // X, Y, Z
            }
        }
        translate_size = float, float, float    // X, Y, Z
        translate_init = float, float, float    // X, Y, Z
    } else {
        translate = float, float, float    // X, Y, Z
    }

Chunk structure 0xF

Stores bone parts and animation parameters. The code that describes this chunk is shown below:

params_version = uint16 // parameter format version
partition_count = uint16 // number of bone parts
for (i=0, i<partition_count, i++) {
    partition_name = string // name of the bone part
    bone_count = uint16 // number of bones in this bone part
    for (j=0, j<bone_count, j++) {
        if params_version == 3 {
            bone_name = string // bone name
            bone_id = uint32 // bone ID
        }
    }
    motion_count = uint16 // number of animations
    for (j=0, i<motion_count, j++) {
        // animation parameters
        motion_name = string
        motion_flags = uint32
        bone_or_part = uint16
        motion = uint16 // animation identifier from the 0xE chunk
        speed = float32
        power = float32
        accrue = float32
        falloff = float32
    }
}

Programs editing this file

• Blender (X-Ray Addon)
• OMF Editor by ValeroK

Sources

Source

.seq (Sequence)

About

Text file that is used to create a simple animation texture, by recording a sequence of "frames" and a playback speed.

Example

15
ui\ui_ani_cursor_01
ui\ui_ani_cursor_02
ui\ui_ani_cursor_03
ui\ui_ani_cursor_04
ui\ui_ani_cursor_05

Order in which the textures are played will be 1234512312312345

cycled
15
ui\ui_ani_cursor_01
ui\ui_ani_cursor_02
ui\ui_ani_cursor_03
ui\ui_ani_cursor_04
ui\ui_ani_cursor_05

In this case, because of "cycled" the playback order will be 1234543212345432123454321 Speed of texture change is set in numerical format before the enumeration

The number of textures in the list is arbitrary, but the more frames, the greater the load on the engine, respectively. The name of the file is set by the name of the assigned texture (without taking the extension into account). If there is a *.dds file in the folder with the same name as the *.seq file, the engine ignores the original texture, giving priority to the *.seq file. The priority of file search by extension is as follows:

• .ogm
• .avi
• .seq
• .dds

Parameters

• The "cycled" parameter is optional if you want to loop from the first texture to the last texture and from the last texture to the first texture. If you don't write it, it will play in a normal circular loop.
• Playback speed (frames per second) (written before the list of textures)

Programs editing this file

• Any text editor

Sources

Source

.som (Sound Occluder Mesh)

About

Geometry for calculating sound propagation. Used to allow sound to pass through walls, ceilings, floors, etc. with varying strength.

Technical information

• Format version: 0

Blocks

It consists of two blocks:

The structure of the file is similar to .hom

Block 0x0 (header)

Block 0x1 (mesh data)

Polygon indices are not saved, but they can be easily generated, because all vertices are saved so that polygon indices are in ascending order.

The first triangle will be: 0, 1, 2, second: 3, 4, 5, third: 6, 7, 8, etc.

Programs editing this file

• Blender (X-Ray Addon)
• SDK 0.7

Sources

Source

.thm

About

They are used to set the parameters of .dds textures - bump, detail, and more. Without them the game does not give textures the necessary parameters, and therefore they are obtained "flat", worse than the static lighting.

Programs editing this file

• THM Editor by ValeroK or THM Editor by i-love-kfc
• SDK 0.7

XML files

About

XML files are used to save text strings used for translation. All XML files are located in gamedata/configs/text/*lang*. XML files have these properties:

1. They are saved in encoding Windows-1251. English translation won't break if you're using UTF, but russian will.
2. Every string must have an unique id assigned to it.
3. There is a single namespace for all xml files of one language. That means, no matter in which file you are saving your strings, they will be available in one place, namely game.translate_string(*id*).

XML file will look something like this:

<?xml version="1.0" encoding="windows-1251"?>
<string_table>
	<string id="nice_text_id">
		<text>Cool text inside text tags</text>
	</string>

    <string id="another_text_id">
		<text>...</text>
	</string>
    
    ...
</string_table>

Programs editing this file

• Any text editor