Skip to content
Starwind R3mastered

2025: the SW4 Modernization Burst

The May 2025 Starwind-Builder skunkworks explosion: freighters, mounts, automatic blasters, record migration, KOTOR-style controls, targeting, and UI.

In May 2025 Starwind-Builder stops looking like only a patch/build repository and, for roughly two weeks, turns into a concentrated gameplay R&D lab.

This is the period preserved today as the Scripts/SW4 fossil.

Oral history: why the burst happened#

Dave’s account is gloriously non-corporate: a community modder implied that he did not properly take care of Starwind / the Modding-OpenMW Starwind list, and he got pissed off enough to fl3x by doing a large OpenMW-Lua modernization campaign.

Git cannot prove anyone’s emotional state. It can prove that the resulting commit burst is real and unusually concentrated.

May 7: SWAMP enters Builder#

Yer in mah SWAMP

  • 50af8cb — 2025-05-07 — Add intial version of SWAMP modernization patches with handling for mounts and player ships.

This is the larger successor to the St4sh freighter prototype. The commit adds about a thousand lines of Lua and brings together player-ship behavior, mount handling, helpers, settings, and player orchestration.

May 9: automatic blasters#

  • f87aced — adds ShootManager for automatic blaster fire.
  • cf83986 — adds animation cancelling to blaster attacks.

The surviving system classifies Starwind ranged weapons by type and controls automatic fire, follow-through cancellation, animation speed, shot delay, and skill-based interpolation.

May 12: generic runtime record migration appears#

  • d4f4372 — adds the recordReplacer interface for automatic instance replacement/deletion.

This is one of the most important buried systems because it generalizes a problem the freighter rewrite had already encountered: replacing old scripted content with Lua-controlled/generated records at runtime without requiring all source plugins to be manually rewritten first.

The historical implementation is not a modern API contract; it contains known persistence and callback hazards. Its importance is architectural: Starwind content migration became a first-class runtime concept.

May 14: camera and lock-on experiments#

Three commits land within minutes:

  • 9ae6808 — replaces the built-in third-person camera experiment.
  • 7872e88 — adds a camera helper module.
  • 2b94a9f — adds lock-on and camera managers to reproduce KOTOR-like behavior.

Later that day:

  • fe57c24 — imports the protectedTable class from CHIM.

That last receipt is important for lineage accuracy: not every useful helper was invented inside SW4. The skunkworks was already cross-pollinating with other OpenMW experiments.

May 17–19: replacement movement and KOTOR-style interaction#

The controls stack grows quickly:

  • 1f7190e — May 17 — input controller that completely overrides movement controls.
  • 848c8b7 — May 18 — implements cursorController inside the player controller.
  • 68e20b4 — May 19 — activation banner with activatability feedback.
  • 3c81497 — May 19 — quick turning and mouse-wheel turning.
  • 196db19 — May 19 — contextual cursor colors and optional banner.
  • 2e90f6d — May 19 — custom crosshair manager.

The resulting system is not simply “controls tweaks.” It attempts to replace OpenMW’s ordinary third-person interaction model with something much closer to a KOTOR-era scheme:

  • virtual HUD cursor independent of camera look;
  • rendering-ray target selection from cursor position;
  • activation-range checks and direct world activation;
  • target labels and contextual cursor presentation;
  • movement acceleration/deceleration curves;
  • lateral-input turning versus combat strafing;
  • quick 180-degree turns;
  • mouse-wheel-assisted turning;
  • arbitration with camera, crosshair, lock-on, and mount state.

This is the direct archaeological source for the modern starwind_controls work being reconsidered for R3mastered.

May 20–22: quick cast and quick attack#

  • c4dcd27 — May 20 — quick casting with mount support.
  • d514f48 — May 22 — quick attack manager.

Quick Cast survives as a coherent state-machine idea: temporarily enter spell stance, cast once, and restore the prior stance. Quick Attack is visibly less finished and is preserved primarily as UX archaeology.

What the SW4 fossil contains#

The supplied exhumation audit groups the high-value systems as:

  • Freighter Lua rewrite — strong resurrection candidate.
  • KOTOR-style controls — strong standalone/product candidate.
  • Automatic blasters — strong standalone/product candidate.
  • Mount/speeder controller — Starwind-specific gameplay infrastructure.
  • Quick Cast — small, highly reusable feature.
  • Runtime record/instance migration — generic idea to prove internally before promoting to H3.

And it treats several helper/targeting systems as evolutionary ancestors rather than code to revive in place.

Why SW4 should not simply be “ported”#

The old tree is valuable because it records behavior and intent, not because its 2025 implementation should become the 2026 architecture wholesale.

Known problems include:

  • stale cursor target state;
  • brittle object/type inspection;
  • persistence bugs in recordReplacer;
  • duplicated mount data;
  • unknown ranged-weapon edge cases;
  • unfinished Quick Attack transitions;
  • manager coupling and shared mutable state;
  • old OpenMW API assumptions.

The R3mastered rule is therefore:

Exhume the behavior. Rebuild the smallest modern implementation. Do not reanimate SW4 as a monolith.

Next: H3, T4, and the systems that escaped →