LTR (Letter Frequency)
LTR files contain matrices defining the probabilistic sequence groupings of letters used by the engine’s random name generator.
At a Glance
| Property | Value |
|---|---|
| Extension(s) | .ltr |
| Magic Signature | LTR / V1.0 |
| Type | Naming State Matrix |
| Rust Reference | View rakata_formats::Ltr in Rustdocs |
Data Model Structure
The rakata-formats crate maps character frequency architectures directly into the strongly-typed Ltr container, safely abstracting away the fallible raw string-parsing logic for downstream implementations.
Engine Audits & Decompilation
The following documents the engine’s exact load sequence for Letter Frequency structures mapped from swkotor.exe.
(Decompilation logic for this section was audited and verified via native Ghidra pipeline against swkotor.exe, explicitly pulling from CResLTR::OnResourceServiced at 0x00712410.)
| Pipeline Event | Ghidra Provenance & Engine Behavior |
|---|---|
| Magic Validation | The native parser enforces a mandatory "LTR " signature and strictly validates the "V1.0" format tag. These parameters collectively structure a rigid 9-byte header block. The sequence natively defines the letter_count variable as a single byte resting exactly at offset +0x08. |
| Contiguous Ingestion | Memory buffer extraction initiates immediately at offset +0x09. The parser algorithm sequentially extracts natively chained string arrays grouping start, middle, and end blocks to map against procedural probability matrices. |
| Payload Bounds Check | Upon closing the read operations, the memory allocator immediately verifies a structural bounding condition asserting that the terminal parsing offset explicitly matches the buffer array’s total byte allocation length. |