Building Whole-Vehicle Portals for Halo PC Race

I started with the obvious test: drive a Warthog into one of Halo PC's native teleporters.

Nothing happened.

The teleporter only reacted after I climbed out and walked the biped through it. I appeared at the destination, while the Warthog stayed exactly where I had left it. That behaviour is fine for an ordinary multiplayer map, but it breaks a Race route built around keeping the vehicle with the player.

I needed a separate portal system that treated the Warthog as the thing crossing the boundary.

Starting from the player

Phasor gives me the player, so I began with the player's biped. At offset +0x11C, the biped stores its current vehicle object identifier:

biped + 0x11C = current vehicle object id
0xFFFFFFFF    = player is on foot

That gave me the first useful branch. If the value was 0xFFFFFFFF, there was no vehicle to move. Otherwise, I could follow the identifier to the vehicle object and inspect its occupants.

The relevant vehicle fields were:

vehicle + 0x324 = driver object id
vehicle + 0x328 = gunner object id
vehicle + 0x32C = passenger object id

The occupant object then exposed the zero-based Phasor player identifier at +0xC0.

I only needed enough seat information to prove that the player was attached to the vehicle I was about to teleport, and to keep the behaviour predictable for the chaingun Warthog, Rocket Warthog, and Ghost.

Logging the chain

I logged the identity chain alongside the vehicle position, portal index, and cooldown state:

player -> biped -> vehicle
vehicle position -> portal origin
driver / gunner / passenger object ids
vehicle id -> cooldown expiry

My first version checked the biped's reported position. While the player is in a vehicle, that position is offset from the vehicle's actual world position, so the portal trigger was testing the wrong point.

The logs made the mistake obvious. I changed the trigger to test the vehicle's world position and wrote the destination directly to the vehicle object.

Once I changed the problem from “teleport this player” to “move this occupied vehicle,” the passengers came along naturally because they were already attached to the same object.

The trigger I actually needed

Each custom portal is a sphere with one origin and one destination.

When the vehicle enters that sphere, I write the destination position directly to it. The driver, gunner, and passenger stay attached, and Halo PC's native teleporter never enters the path.

It just worked: the Warthog popped out at the destination with everyone still seated.

I had assumed a portal definition worked both ways. It does not: each definition is one-way, with one origin and one destination.

If I want travel in both directions, I add a second one-way portal whose origin sits at the first portal's destination.

Why the cooldown exists

That second portal creates a new problem.

The arriving Warthog may land inside the return portal's trigger sphere. Without a guard, it immediately travels back to the first destination, lands in the first trigger again, and can bounce between the two definitions.

So, I attach a three-second cooldown to the vehicle identifier after a teleport. During that window, any return portal at the destination ignores the same vehicle.

A single definition remains one-way because it has only one origin and one destination. The cooldown lets a track builder add a separate return portal without creating an immediate loop.

I key it to the vehicle rather than the player. The vehicle is the object entering the trigger, and it may contain more than one player.

Portal markers and track layout

The trigger itself is invisible, so the tracks use T-shaped markers to show portal locations.

Boarding Action currently uses portal spheres with a radius of 1.2 world units. Some connections use two one-way portal definitions to allow travel in both directions, while others deliberately provide only one route.

I adjusted the locations by driving through them repeatedly, checking whether the Warthog body entered cleanly, and watching where it landed relative to the return trigger. The destination needed clearance around the full vehicle, extending well beyond the driver's biped position.

Reusing the same detection for flingers

Once I could reliably detect an occupied vehicle inside a custom trigger, the same foundation worked for flingers.

A flinger can optionally reposition the vehicle and then overwrite its linear velocity, with angular velocity added when the track wants spin. Empty vehicles are ignored.

This system needs its own cooldown for a different reason. If I keep applying the launch every update while the vehicle remains inside the trigger, the script continually replaces its velocity and the Warthog can hang or hover instead of leaving cleanly.

Both use a vehicle-keyed cooldown. For portals it guards the optional return route; for flingers it stops repeated launch application.

Where it ended up

I can now drive into a custom portal without getting out, and the Warthog, driver, gunner, and passenger arrive together.