KEY (Global Index)
Think of the KEY file as the absolute master table of contents governing the entire game directory. Because uncompressed BIF archives are completely blind payloads that contain no internal filenames, the KEY file acts as the singular, authoritative index that tells the engine exactly which BIF holds which file, and precisely where to seek inside that BIF to find it.
At a Glance
| Property | Value |
|---|---|
| Extension(s) | .key |
| Magic Signatures | KEY (version V1 ) |
| Type | Archive Global Index |
| Rust Reference | View rakata_formats::Key in Rustdocs |
Data Model Structure
The rakata-formats crate evaluates the .key file as the holy grail mapping for global engine initialization.
- Indices Hierarchy: Internally, the format houses an array of
bif_entriesbounding archive paths and sizes, alongside a massive array ofKeyResourceEntrystructures fusing a standardResRefstring and a formatTypeCodeto a bit-packed numericResourceId. - Conflict Resolution: Because the game engine relies on a strict override hierarchy, multiple KEYs might accidentally declare the same resource! When constructing the active dictionary out of a KEY file (
KeyFile::build_key_resource_index), Rakata explicitly utilizesor_insert()to strictly ensure only the first defined entry for a conflict is honored, perfectly mimicking the engine’s aggressive linear-scan precedence rules.
Engine Audits & Decompilation
The following information documents the KOTOR engine’s exact load sequence and field constraints for genuine .key files. All behavior was mapped natively from swkotor.exe during clean-room reverse engineering.
Key Table Registration (CExoKeyTable::AddKeyTableContents)
Mapped from 0x0040fb80.
| Action | Engine Behavior |
|---|---|
| Signature Check | Validates exactly for the KEY magic and the explicit V1 version signature. |
| Version Branching | There is absolutely zero logic handling any speculative V1.1 version branch in vanilla K1. It is currently unknown if a V1.1 KEY format actually exists in the wild, but the engine certainly wouldn’t load it. |
| Payload Mapping | Extrapolates the file location natively by tearing apart the ResourceId bitmask to locate both the target BIF file index and the internal struct array offset. |
Note
The engine handles
KEYtable loading extremely early in the application lifecycle duringCExoBase::InitObject. If a globalKEYfails to mount due to malformed headers, the engine immediately aborts execution.