XnGine Framework

Overview

XnGine Framework is primarily a reverse engineering project. The core challenge is not just plugin integration, but accurately decoding legacy XnGine-era file formats, mapping their structures, and building reliable parsers that can support modern mod workflows inside Mod Organizer 2 (MO2).

These games were never designed with modern mod-management standards in mind. Much of the work requires working from incomplete references, validating assumptions against real game data, and iterating until parser behavior is stable across both vanilla assets and modded edge cases.

Historical Significance

This project targets Bethesda's in-house XnGine generation from the mid-to-late 1990s, including games like Daggerfall (1996), Battlespire (1997), and Redguard (1998). That period predates Bethesda's early-2000s transition toward NetImmerse/Gamebryo-era technology (Morrowind released in 2002).

There is also conceptual continuity with later Bethesda tooling. For example, BSA archive usage appears in this earlier era, and archive-centric content packaging remained important in later Bethesda mod ecosystems. While engine internals changed significantly over time, several mod-relevant content-delivery ideas persisted.

Reverse Engineering Focus

The project goal is format-level coverage: identify every mod-relevant file format used across XnGine titles, then implement support for patch-safe parsing and output generation.

• Identified and cataloged game-specific and shared XnGine data formats used by real mod ecosystems
• Reverse engineered undocumented or partially documented binary structures
• Built parsers that prioritize correctness, repeatability, and compatibility with existing mods
• Validated behavior through cross-checks against in-game outcomes and known community expectations

Supported games currently include titles such as Arena, Battlespire, Daggerfall, and Redguard, with the broader long-term objective remaining full coverage of mod-relevant formats across the XnGine ecosystem.

Current State (Toward 1.0)

The framework is approaching a 1.0 state that I am comfortable with. In practical terms, the work has moved from broad foundational format onboarding into diminishing returns: high-impact reverse engineering is complete, and remaining tasks are now mostly long-tail compatibility cases.

At this point, all commonly used formats are implemented. Most remaining gaps are obscure 1990s-era formats tied to a small number of rare mods where documentation is minimal or missing.

Architecture: Reverse Engineering to Runtime Patching

Reverse engineered format knowledge is translated directly into runtime patch workflows. Rather than editing installed game files, patched outputs are generated at launch into a temporary hidden mod and removed on game close.

This allows legacy file formats to function within MO2's VFS model while preserving install integrity and supporting normal mod-manager operations like adding, removing, and reordering mods.

• No direct base-game file modification required for patch workflows
• Runtime-generated outputs based on parser and patch pipeline logic
• Consistent behavior with MO2 load-order and virtualized conflict resolution
• Safer testing and cleaner rollback for heavily modded setups

Why The Reverse Engineering Matters

For legacy engines, tooling quality is limited by format understanding. Without reliable reverse engineering, mod management becomes manual, brittle, and difficult to reproduce.

This project improves that foundation by turning undocumented or weakly documented format behavior into usable, testable tooling that fits modern mod workflows.

Remaining 1.0 Milestones

• Built-in BSA packer: complete integrated archive packaging support
• Redguard save-location parsing refinement: improve reliability and edge-case handling

Once these are complete, the framework reaches the release baseline I consider appropriate for a 1.0 designation.

Repository

View on GitHub