Building Custom Halo PC Race Tracks Without Sapien

The current Halo PC Race tracks do not begin as new map files.

They begin as Lua tables.

A track configuration describes checkpoints, player starts, vehicle settings, portals, flingers, lap rules, messages, and visual markers. Phasor then applies that configuration to data already loaded by the retail Halo PC dedicated server.

No Sapien rebuild is required.

Data edits, not engine patches

The project follows a deliberate boundary.

It can rewrite fields in structures Halo PC has already allocated, including scenario netgame flags, player starts, vehicle positions, waypoint slots, and the loaded gametype variant.

It does not grow arrays, inject executable code, or patch the Race engine.

That boundary explains both the project's flexibility and its limits. A spare netgame flag can become a Race checkpoint because the entry already exists. A 33rd checkpoint cannot be added cleanly because Race stores progress in fixed 32-bit masks and a 32-entry waypoint table.

A track as configuration

The track script contains route data and module settings rather than reimplementing every feature.

A simplified setup looks like:

local host = TrackHost.new()

host:add(RaceCheckpoints.new({ nav_points = nav_points }))
host:add(CheckpointProgress.new({ command = "nav" }))
host:add(GametypeVehicles.new({ red = vehicle_counts }))
host:add(VehiclePortals.new({ portals = portals }))

host:bind()

The real configurations include more detail, but the principle remains the same: the track declares what it needs, while reusable modules handle the implementation.

What changes at runtime

Checkpoint modules rewrite type-3 netgame flags and Halo PC's waypoint table. Player-spawn modules claim Race-compatible start slots. Gametype modules change lap limits, Race mode, vehicle counts, weapons, and other live variant fields.

Other systems create new world objects. Checkpoint carets use flags and health packs, portal origins use T-shaped markers, and flingers use visible rings.

Together, these edits turn a stock Halo PC map into a different Race course without distributing a rebuilt map.

Why TrackHost exists

Phasor exposes global callback names such as OnNewGame, OnClientUpdate, and OnServerChat. A growing collection of modules cannot each own those globals independently.

TrackHost provides one dispatcher.

Modules register with the host, and their order becomes the callback order. Ordinary notifications fan out to every interested module, while veto-style hooks stop when a module returns false.

That arrangement also makes interactions visible. Drift runs after leap so crouch braking wins, while object-interaction hooks prevent players from collecting marker items.

The trade-offs

Runtime modification is not free.

The scripts depend on retail Halo PC addresses, timing around round initialization, and structures that were never designed as a public modding interface. Visual markers also consume slots from Halo PC's shared 2,048-object table.

Some changes require a map reset before Race rebuilds its internal state. Others, such as player-spawn positions, are read directly and take effect without one.

Each module documents those differences because treating every structure alike is how subtle bugs appear.

A different kind of track building

Sapien remains the proper tool for building maps. This project solves a different problem.

It lets a server compose new Race experiences from stock Halo PC maps, using configuration and live data edits instead of distributing another map build.

For now, that is enough to create 32-checkpoint routes, custom vehicle grids, portals, flingers, dynamic laps, and track-specific rules.

The engine stays the same. The course does not.