LYT (Layout File)
LYT files are ASCII configuration arrays that define the spatial 3D placement and orientation of independent room models to construct a complete area map.
At a Glance
| Property | Value |
|---|---|
| Extension(s) | .lyt |
| Magic Signature | None |
| Type | Plain Text Layout |
| Rust Reference | View rakata_formats::Lyt in Rustdocs |
Data Model Structure
The rakata-formats crate parses LYT files into the strongly-typed Lyt container. The parser segregates the raw nested lines into distinct rooms, tracks, obstacles, and doorhooks collections, natively mapping coordinate strings into engine-standard Vec3 and Quaternion structs for immediate mathematical interoperability.
Engine Audits & Decompilation
The following documents the engine’s exact load sequence for Layout configurations mapped from swkotor.exe.
(Decompilation logic for this section was audited and verified via native Ghidra pipeline against swkotor.exe, explicitly pulling from CLYT::LoadLayout at 0x005de900.)
| Pipeline Event | Ghidra Provenance & Engine Behavior |
|---|---|
| Newline Bounds | The parser heavily expects explicit \r\n (CRLF) endings. Scanning extracts target strings utilizing _sscanf("%[^\r\n]", ...) patterns and frequently relies on blind +2 byte pointer leaps to manually clear the terminators. |
| Preamble Skipping | All file lines existing prior to the beginlayout execution marker (such as the ubiquitous #MAXLAYOUT ASCII header) are deliberately skipped and ignored. |
| Sequential Parsing | The structure mandates a rigid sequential ingestion. Data collections must explicitly appear geographically in the exact order: roomcount → trackcount → obstaclecount → doorhookcount → donelayout. |
Warning
Boundary Oversight While the engine systematically verifies
donelayoutboundaries separating the primary collections, the underlying parse loop functionally neglects to verify the finaldonelayoutsignature upon closing thedoorhookssegment.