The order between gates

2026-10-24, second session on the race rules.

The eight cars' places through the reference race on Beltane, as the game recorded them. The red lines are the 26 samples out of 4,489 where pod-race's order differs.

The last session found that the game changes the race order between the checkpoints, not only at them. This session followed that thread to its end.

How the game knows who is ahead

Every track has race paths: a graph of nodes and links, laid over about ten lanes (racing lines) per section. Each point on a link has a value that falls along the lap, which looks like the distance to the line. Each computer car keeps a place on these paths, a link and a point, and moves it on as the car drives. The game's function for this, FUN_004b0ec0, moves the place forward while the next point is nearer. At a fork it picks the next link by distance and by the sign of a dot product.

When a car's place moves on, FUN_004afd3c compares the car with the cars ahead of it. A car on the same lap and checkpoint passes the one ahead if its value is lower, meaning it is further along. The function has two quirks that a port must keep. A car it does not pass does not stop it, so a pass can jump a car. And after the first comparison, it tests the lap count twice where it meant to test the checkpoint too.

The value never passes the lap line by itself. The "Troncon" gate actions place each car on the next lap's paths. For a computer car the gate also picks its lane, from a lane number each driver carries.

Measured, then ported

As before, the functions were run in the original under an emulator first. A new script, measure/race_paths.py, builds Beltane's path graph in the emulated game's memory exactly as the game lays it out. It then runs the tracker and the order update on 20,000 random cases each. The Rust port gives the same answer every time.

Replaying the race again

The replay of the reference race now runs the trackers too. The first try was worse than no path order at all: the order matched in only 54% of the samples. A printout of each car's place on the paths showed why. The replay had put some cars on pit lanes, which the game never chooses, and their trackers stuck where the car left that lane. With the lanes the game can choose, picked by where each car drove next, the order is the game's in 4,463 of 4,489 samples.

The rest are short runs, one to eight samples long, at the start and in close battles. Which of two cars side by side is ahead depends on the exact step at which each passes a path point. The recording has the cars' positions ten times a second, not at every step, and not the lanes the drivers chose. So 100% needs a better recording, not better rules.

What is known, and how

• Measured: the tracker and the order update match the original on 20,000 cases each.
• Measured: the replayed race keeps every lap, split and record exact, and shows the game's order in 99.4% of samples.
• Observed: how "Troncon" places cars, and how the lanes are chosen.
• Inferred: the path values are the distance to the line; the graph's first word is the lap's length (on Beltane it equals the highest node value).

Next

• Record a race with the new recorder fields: each car's place on the paths, its lane and the points the game really tests. With those, the replay can drop its guesses.
• Port the computer cars' lane choice, with the driving code it belongs to.