Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Save Game

While KotOR Save Games (.sav) are structurally just ERF containers under the hood, the engine employs complex party-synchronization and module loading logic to physically reconstruct the player’s session.

Data Model Structure

A standard Save ERF container packages a specific set of internal GUI and logic files that the game actively requires to reconstruct a valid player state.

savenfo.res

The overarching save metadata block, primarily responsible for the main menu UI.

  • save_name: Display string for the save file.
  • pc_name: (Optional in K1) Player character name.
  • area_name: Localized display name for the area.
  • last_module: The resref of the specific module being loaded.
  • time_played: Running game time.
  • cheat_used: Global boolean flag to mark corrupted/cheat sessions.

globalvars.res

The universal state trackers running the campaign plot.

  • Segmented explicitly into numbers and booleans.
  • Each global uses a strict Symbol Name.

partytable.res

The live snapshot of the physical adventuring group and global resources:

  • Shared credits and shared party_xp.
  • cheat_used: Independent table-specific cheat flag.
  • members: Fixed list of party members tracking who is currently active and who is is_leader.
  • journal_entries: Currently active quest plot_ids and their numeric stages.

Additional Constituents

  • Character List: Populated using a mix of sources (leader, pc, and availnpc* resources).
  • Inventory: Represents all items the player carries (inventory.res), tracking stack sizes, charges, and upgrade bitfields.
  • Doors: Transient state (locked/open attributes) extracted directly from the module’s GIT.

Tip

Rust Integration The rakata-save crate handles this structure natively via the SaveEditorModel struct. You can use it to directly parse, validate, and write back these internal save components without manually managing the ERF layer.

Engine Audits & Decompilation

The following documents the engine’s exact state restoration logic mapped from swkotor.exe.

(Decompilation logic for this section was audited and verified via native Ghidra pipeline against swkotor.exe, explicitly pulling from CSWPartyTable::SaveTableInfo at 0x005648c0.)

Pipeline EventGhidra Provenance & Engine Behavior
Cheat SynchronizationThe CHEATUSED flag in the savenfo header file isn’t tracked in isolation. When saving the game, the engine simply copies the raw PT_CHEAT_USED numeric flag directly from the party table to keep the UI in sync.
Character Loading HierarchyWhen the engine pushes a character into the game during a standard load (via LoadCharacterFromIFO), it defaults to pulling character data strictly from the active module’s IFO roster matrix. It only falls back to reading the save’s dedicated .pifo (Party Info) file if the target parameter index explicitly equals 0xffffffff.
Area RestorationTo rebuild the dynamic state of the room you were standing in (like which doors are open or locked), the engine restores the area’s Game Instance data by targeting the GIT resource type (0x7E7) and matching it against the module’s core resref string.

Warning

There is zero K1 runtime string evidence for K2 (The Sith Lords) crafting or influence fields (PT_ITEM_COMPONEN, PT_INFLUENCE, UpgradeSlot*). If constructing K1-native party utilities, those fields must be aggressively excluded!