MSTS Gantry Configuration

MSTS gantry configuration (gantry.dat)

gantry.dat is a Route Editor auto-placement catalog. It describes named sets of shapes, longitudinal spacing, and span-dependent selection. It is not the placed-object database, a signal-gantry definition, or the simulator's procedural overhead-wire system.

On this page

• Schema: Location and encoding · Catalog grammar · Fields and styles
• Authoring: Placement and shape geometry · Placed world objects
• Evidence: Observed variants · Implementation boundaries · Validation and preservation · Sources

Location and encoding

The catalog belongs to the route's authoring support:

ROUTES/<route>/gantry.dat
ROUTES/<route>/SHAPES/<gantry-shape>.s

Yuri Sos's community tutorial describes a Unicode structured-text file. Three locally inspected catalogs have UTF-16LE BOMs and the same envelope:

SIMISA@@@@@@@@@@JINX0g0t______

The lowercase g matters when identifying the signature: the examined FTS content checker distinguishes it from the uppercase G signal-configuration signature. This observation does not establish every encoding accepted by the original editor. See Kuju serialization.

No dedicated gantry authoring note was identified in the local document inventory. The semantic account below is attributed to the public tutorial and observed catalog comments, not to an official Microsoft/Kuju specification.

Catalog grammar

The tutorial and ordinary observed catalogs support this nested body. Symbolic field names below are placeholders, not literal values:

Tr_GantryFile (
    GantrySets ( set-count
        GantrySet (
            Name ( "set display name" )
            Style ( style-word )
            Separation ( longitudinal-spacing )
            GantryTable ( entry-count
                GantryTableEntry (
                    Filename ( shape-file.s )
                    Distance ( span-width )
                )
                ...
            )
        )
        ...
    )
)

GantrySets declares the number of GantrySet blocks; GantryTable declares the number of GantryTableEntry blocks. The tutorial explicitly requires these counts to match their child collections. This is a documented authoring rule, not a measured parser-tolerance rule. Preserve mismatches and repeated records rather than truncating data.

Each documented set has a name, style, separation, and table. Each ordinary table entry has a shape filename and distance. No universal requirement for child ordering, duplicate handling, or empty collections has been established.

Fields and styles

Record	Meaning and evidence
Name	Set name presented in the Route Editor auto-placement selector.
Style	Community documentation identifies 00000001 as pylon and 00000002 as overhead. Retain the whole word and original spelling; independent bit meanings or combinations are not established.
Separation	Spacing along the track, in metres according to the tutorial's Separation section.
Filename	Shape used for this span category; a named-resource reference, not a world-object UID.
Distance	Span/width criterion used to choose the shape, not longitudinal spacing and not an instruction to scale the mesh. The tutorial explains it with metre-valued track-width examples.

The two documented styles differ:

• Pylon (00000001): paired shapes on opposite sides of the track or outer tracks. Observed catalog comments call Distance the maximum separation of a pair.
• Overhead (00000002): one shape centred over the track group. Observed comments call Distance the inside separation of its vertical supports; the tutorial describes it as the maximum span category.

Spanning entries must be ordered by increasing width in both the tutorial and observed comments. Preserve that order; alphabetically sorting by shape name would change the authoring contract.

Do not infer an original flag mask from the two familiar style words, or turn their presentation into a global hexadecimal grammar. See flags and selectors, numeric values, and counted collections.

Placement and shape geometry

The tutorial's Overview, Style, Separation, and Distance sections describe:

• Auto-placement along tracks within a selected tile.
• Width-based selection of shapes, with spanning shapes centred over the track group.
• Spacing restarting at a point/switch rather than necessarily continuing from an earlier placement.
• No automatic stretching of the selected shape to fit Distance.
• Incomplete or surprising placement around yards, diverging tracks, and spans wider than the largest entry.

These are community observations of Route Editor behavior, not experiments reproduced by this wiki. Exact track grouping, equality at width thresholds, spacing phase, direction selection, and gradient handling remain unresolved.

The Filename section and observed comments recommend a bottom-centre shape origin aligned with the centre of the intended span. Mesh orientation and lateral offset matter. The tutorial demonstrates using the same facility for fences, vegetation, and bridge supports; the catalog is not limited to electrical equipment.

Those examples do not justify rewriting a shared shape to suit one placement. Preserve the asset and its authored transform, and distinguish shape geometry from world placement as described in shape files and coordinates and identity.

Placed world objects

The tutorial explicitly says auto-placement creates shapes that can subsequently be moved, rotated, or deleted individually. The catalog entry is not a live foreign key: editing or removing the entry does not imply rewriting existing placements.

The resulting world layer is documented under shape-backed scenery objects. A world Gantry stores its own shape filename, identity, transform, and common rendering fields; it does not embed GantrySets or GantryTable.

The route .trk also has a numeric GantrySet record. The examined sources do not establish whether it indexes this catalog, how an index would be based, or how it interacts with the editor's named-set selector. Do not resolve it to a table entry merely because the token names resemble each other.

Signal gantries require separate signal configuration and scripting. Similarly, placing these meshes does not establish electrification settings or runtime overhead-wire generation.

Observed variants

Three local catalogs were inspected read-only on 25 October 2026. These are corpus labels, not public download locations or claims of original distribution provenance:

Corpus label	Bytes	SHA-256	Observation
DummyTrack	2,578	FD6507D625EC25BAFB3FFEE3938804C08931B67164E9D34B3AE9C62EBF89040A	One declared set and table entry; ordinary single filename/distance pair.
aswtest	8,322	6868614488A105DD9EFD4B340C781B6B366E8F4E26C313ADBE4760DE03B886BF	Four observed set blocks and four tables; table declarations 7, 7, 7, and 4 total 25, matching the 25 entry blocks. Includes non-ASCII display text.
Sig_Test	2,724	8C4D486794A3A6BC12298D9BB8FE93E3558880DE6B81843416AC80EB94253E38	One declared table entry contains two filename/distance pairs. This is an observed duplicate-child form, not proof of acceptance or two logical entries.

All three share the BOM and envelope stated above. Their presence proves serialized variants exist; it does not prove successful Route Editor loading, placement, or rendering. No corpus assets or catalog contents are redistributed here.

Implementation boundaries

• FTS's examined content checker recognizes the signature but returns NotUsedLoader for gantry.dat. A non-error result there is not schema validation.
• FTS/Open Rails token inventories contain gantry tokens, but token presence alone does not establish record grammar or support for auto-placement.
• The examined FTS/Open Rails and TSRE5 world-object readers support placed Gantry records. No dedicated catalog parser was identified in the examined source surface. That scoped finding is not a claim about every release, branch, or tool.
• In particular, TSRE5's static-shape treatment corroborates placement payloads, not the original editor's width-selection algorithm.

Validation and preservation

1. Check the envelope and root independently from the declared collection counts.
2. Compare each count with its actual child blocks; report disagreement without discarding excess blocks.
3. Preserve set order, entry order, duplicate names, unknown style values, repeated filenames/distances, comments, and unknown records.
4. Resolve shape names in route context; report missing or ambiguous resources without changing the raw reference.
5. Report non-positive spacing, non-finite dimensions, and non-increasing spanning widths as authoring-profile concerns. Do not invent original-editor rejection rules.
6. Compare span dimensions with shape geometry without scaling, reorienting, or repairing the asset automatically.
7. Treat generated world placements as independent records; do not require a surviving catalog entry for every placed object.

Remaining questions include count-mismatch tolerance, duplicate-child semantics, exact width thresholds, pylon distance handling, original accepted style values, the .trk GantrySet relationship, and detailed placement/terrain behavior. See validation experiments before making runtime claims.

Sources

• Yuri Sos, Using The Auto-Placement Function (gantry.dat) in Route Editor, with contributions credited to Chris Schwan, Lukas Lusser, Phil Voxland, and Jim Ward. Sections Overview, Structure, GantrySets, Style, Separation, GantryTable, GantryTableEntry, Filename, Distance, and shape examples. Community documentation; edition/publication date not established, accessed 25 October 2026.
• Three locally preserved catalogs identified above: observed content and embedded comments, with original producer/distribution provenance unverified.
• FTS LoaderFactory.cs at examined local revision bf60e7b791cb9d8556aa45390906d8c4ac1d6b59; world model.
• TSRE5 StaticObj.cpp, world-placement evidence at examined tree af99c14a9f42b6e0f02b7e1a4fd5c1e9f46dbecf.