By September 2026 the phrase “Merged Plugin Project” no longer describes the scope of the work very well.

The current project is simultaneously dealing with:

• content integration;
• dependency/master decoupling;
• dialogue reconstruction;
• record liveness/provenance;
• CPP fixes;
• Naboo and other community content;
• asset optimization and compatibility;
• OpenMW-native Lua modernization;
• long-term documentation and reproducibility.

R3mastered is the point where those lines become one explicit project boundary.

Approximately 42 months passed between the first preserved StarwindServer commit on 2023-03-31 and the merged-plugin rework and creation of this repository on 2026-09-13–14.

September 13: motherJungle attacks the hard version of decoupling#

The 2026 motherJungle sequence is the mature descendant of the original 2023 cleanup/decoupling work:

• 9120e55 — pull recursive dependencies.
• 39f24ee — rebuild correct dialogue sequences from the vanilla ESMs.
• b5ec24f — prune unused vanilla dialogue.
• 9397e02 — narrow dialogue-liveness validation.
• 370f089 — do not serialize truly dead INFOs.
• 6d3bd26 — do not materialize actors that will not be used.
• 6d1eea2 — track actor liveness in the Rust parser and skip deleted actors.
• 788557e — narrow dialogue-record resurrection again.

This is no longer “remove Bethesda masters from the header.” It is database reconstruction: determine which vanilla records are actually required, reconstruct dialogue semantics correctly, preserve live dependencies, and avoid resurrecting dead data merely because it existed somewhere upstream.

September 13: the St4sh Definitive builder becomes a staging point#

The St4sh history records the companion work:

• f32808bf — adds the Star_Data / Starwind splitter.
• b1e94602 — adds a dedicated “definitive edition” builder including Bing’s content, Enhanced, Planet Expansion, Alt Start, CPP, Naboo, Party Hats, and other sources.
• 31798472 — reorganizes the Starwind documentation into the API/reference format that this R3mastered documentation intentionally inherits.
• 717a31b8 — tags/records Starwind Merged V1.0 in the repository history.

The current public Starwind Merged Plugin Project page describes a maintained, masterless Starwind build split into stable data and content plugins. Those documents are the immediate technical predecessor to R3mastered’s long-term build documentation.

Asset modernization enters the same project boundary#

The current R3mastered work is also auditing the inherited asset corpus rather than treating meshes/textures/sounds as immutable baggage. That includes:

• mesh optimization and structural cleanup;
• identifying duplicate/vanilla-equivalent assets;
• texture-format/recompression evaluation;
• sound cleanup;
• compatibility with modern OpenMW rendering behavior.

This matters historically because the normal-map saga already demonstrated that “content assets” can be engine-critical. R3mastered treats assets as part of the maintained software/content system, not merely files copied beside the plugin.

Lua modernization returns from archaeology to product work#

The SW4 exhumation also becomes active development again. The current plan is not to revive the monolith, but to rebuild coherent descendants:

• freighter Lua rewrite;
• KOTOR-style controls;
• automatic blasters;
• mount/speeder controller;
• quick cast;
• runtime record/instance migration where the freighter proves the need.

Where a concept already matured into H3 or T4, R3mastered uses the modern project instead of copying the fossilized implementation.

Why a new repository is justified#

By this point the project is no longer accurately represented by any one of its historical containers:

• StarwindServer is too server-specific and private.
• motherJungle is a transformation/tooling lab, not the whole product.
• CPP intentionally remains a portable patch layer.
• Starwind-Builder is a forge and deployment system, not a long-term home for every gameplay subsystem.
• St4sh is personal publishing/skunkworks infrastructure.
• H3/T4 are reusable standalone dependencies with broader audiences.

SW-R3 / Starwind: R3mastered becomes the consumer/project repository that can own the integrated result and its documentation without forcing any of those older projects to become something they are not.

What “R3mastered” can mean historically#

The name was chosen for style, but the development record supports a useful three-generation interpretation.

Generation 1 — hand-integrated Starwind#

StarwindServer / early TSI:

• editor-maintained merged artifact;
• server-specific runtime fixes;
• binary integration;
• direct operational patches.

Generation 2 — reproducibly built Starwind#

motherJungle → Makron → Starwind-Builder / CPP:

• build steps encoded as tools/scripts;
• deterministic cleanup;
• generated server databases;
• split single-player/multiplayer outputs;
• CI and deployment automation.

Generation 3 — OpenMW-native Starwind#

St4sh/SW4/H3/T4/DreamWeave → R3mastered:

• modern OpenMW-Lua replacing brittle MWScript where appropriate;
• explicit runtime migration of legacy instances;
• current OpenMW gameplay/UI APIs;
• master decoupling and dialogue reconstruction;
• maintained asset pipeline;
• auditable provenance and durable documentation.

This generation model is interpretation, not a historical naming scheme used by the old repositories. It is included because it accurately explains why R3mastered is more than a spelling gimmick without rewriting the past.

The project rule going forward#

The history suggests one durable principle:

Preserve provenance, reproduce the build, upstream or generalize what deserves to escape, and do not force future maintainers to rediscover why a weird Starwind rule exists.

That is why this history is part of the repository’s first major documentation commit rather than an external retrospective.

Next: chronology →