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

Project Roadmap

This document outlines what we’re tinkering with in rakata and where the project is heading.

Note

For day-to-day progress, bug fixes, and specific technical tasks, check out the Codeberg Issues tracker instead.

The End Goal

There are two of these, and they sit at very different distances.

The near one: be the reference implementation. Plenty of tools can read KOTOR’s formats. What almost none of them tell you is what the engine actually does with a field your file leaves out, and that is the difference between a document you can read and one you can build from. Every format page here is written against swkotor.exe itself rather than against folklore, and we are working toward the point where somebody can implement a conforming reader and writer from the page alone, without ever opening our Rust. That one is close enough to be a plan rather than a wish.

The far one: an actual engine integration. It would be very cool to tie all these isolated pieces together into a real rendering pipeline - dropping a vanilla model into an active window and having it stream textures and background audio straight out of the game data. That is a pipedream and we are honest about it, but the closer the foundation gets to exact, the less mad it sounds.

How We Get There

Since this is a passion project, we try to match the original game behavior down to the exact byte before building higher-level abstractions on top of it. It takes a bit longer, but it keeps us from having to constantly rewrite core parsers when we stumble into weird edge cases.

1. Laying the Foundation (Mostly Done)

Our core libraries (rakata-formats, rakata-save, etc.) can currently read, write, and safely roundtrip 19 different KOTOR file formats. We’ve tackled a lot of the weird legacy archives (BIF), models (MDL/MDX), raw textures (TPC), and the binary walkmeshes behind WOK, DWK and PWK, ensuring they line up with vanilla behavior.

However, the foundation is still growing! We still have a handful of outstanding data formats to map out and implement, including Pathfinding (PTH), UI Layouts (GUI), and Journals (JRL).

Additionally, formatting and bytecode support for NCS (Compiled Scripts) is actively being prioritized (see Issue #19) to allow rakata to interface natively with upcoming Rust-based community compilers and decompilers.

2. Writing It All Down (Also Active)

The formats/ manual isn’t a side effect of the code, it’s a deliverable in its own right. Every page is written from Ghidra work against the real executable, and every claim is meant to trace back to either a decompilation finding or a measurement across the vanilla corpus.

The part nothing else has is absent-field behaviour: for each field, what value the engine is actually holding when a file doesn’t carry it. That matters more than it sounds. An absent TrapType resolves to 0xFF, meaning no trap at all - read it as 0 and you have just named a real row in traps.2da. An encounter missing its Geometry field loads perfectly well, while one carrying an empty Geometry field gets refused outright. That isn’t trivia, it’s the difference between a mod that works and one that dies on load.

What’s missing, because a roadmap that only lists wins isn’t much use: compiled scripts (.ncs) have no page at all, and they are the most cross-referenced format in the whole manual, since nearly every blueprint points at one. Until Issue #19 lands, every other page carries a reference into a hole. PTH, GUI and JRL are smaller gaps. And a fair chunk of binary layout detail still lives in Rust source comments rather than on the pages where a reader would go looking for it, which we are partway through moving out.

3. Building Real Tools (Our Active Focus)

Now that we can parse the data reliably, we are building stuff the community can actually use:

  • Mod Linter: A tool to scan modded files and point out if they break the game’s actual data constraints, catching crashes before you load them in-game.
  • Save Editor: A basic offline save editor (rakata-saveeditor) built directly on top of our stable format parsers.
  • Audio Streaming: Updating the generic audio logic (rakata-audio) so we can natively stream game music and voice lines instead of loading giant buffers into memory.
  • Drop-in Replacements: Providing modern, reliable drop-in replacements for legendary (but aging) community tools. By backing these with rakata’s strict parsing rules, we can offer faster, safer, cross-platform native tools for unpacking archives, compiling models, and building mods. (Note: While we aim to replace these tools, we will not inherit their legacy bugs or non-vanilla API quirks. When in doubt, the original game engine is our only source of truth).

4. KOTOR 2 (TSL) Support

We are strictly focusing on KOTOR 1 right now, but extending parsing support for TSL via compatibility flags is a planned enhancement for further down the line once K1 is completely stabilized.

5. The Runtime Engine (The dream but probably a few years away)

Once our standalone tools prove that our format parsers are perfectly stable, we have a pipedream to one day start weaving them together into a natively synchronized rendering loop.