Section Tracking

Section tracking is the process of the game figuring out which track section a ship is currently at, without scanning the entire track.

As of version 1.3.3 the game has undergone a massive overhaul to this system and this page documents how the system works, how you can work with it and how to access visualization tools to help develop your tracks.

Note

The layout creator tracks the entire layout and is not representative of how tracking will work in your built track.

Open The Visualizers

It’s best you learn the system by using the visualizers, this will let you see exactly what the game is doing.

Section Tracking

This visualizer continously runs and shows you what the section tracker sees.

  • Press CTRL + Backspace to open the command console

  • Enter debug_sectiontracking ship and press enter

  • Close the console

If you’d like to disable the visualizer, use the debug_sectiontracking off command. You can also see what the projectile section tracker sees using the debug_sectiontracker projectile command.

Section Setup

This visualizer runs once and is active for a few seconds. Pause the game and enter photo mode to freeze the cooldown timer. It shows you a simplified version of the section setup you created in Unity.

  • Press CTRL + Backspace to open the command console

  • Enter debug_drawsections and press enter

  • Close the console

Generated Routes

This visualizer runs once and is active for a few seconds. Pause the game and enter photo mode to freeze the cooldown timer. It shows you the routes that have been generated for the track.

  • Press CTRL + Backspace and open the command console

  • Enter debug_drawroutes and press enter

  • Close the console

The Basics

../../../_images/tracking_marching.png

Section tracking works by taking the ships current section and marching forwards and backwards along the track, up to 20 sections, to compare distances. The section with the smallest distance to the ships position is chosen as the current section.

If the chosen section is marked as the jump type, the game chooses the next section to provide a recoverable respawn position. Note that the visualizer does not show this.

By itself this is simple enough, but the complexity of this system comes from junction marching.

Junction Marching

../../../_images/tracking_junctionmarchingroutestart.png

When the section tracker finds a junction it branches down it. The current march progress is carried over, so if the march is 10 sections in then only 10 sections will be marched down in the route. If the ship is at the junction, the full range of 20 sections will be marched down in the route. This is done as an optimization to reduce the amount of calculations required.

This logic applies to both junctions connecting to a route start section and junctions that connect to a regular section. This is important to note as it allows route linking.

../../../_images/tracking_junctionmarchingnormal.png

When a junction is used without a route start target, the junction marching works in both directions along the track, like the image above. Using junctions like this is intended to link routes together for tracking, hence route linking.

The tracker searches backwards before forwards to always allow junctions behind the ship to have the maximum possible march distance, as there can be setups where a route exit in front of the ship can branch back onto junctions behind the ship and take priority.

Route Linking

While route start and route end section types are important to define the start and end points of routes for indexing purposes, it’s possible to use junctions to simply connect two routes together for tracking.

For example, if you have a track where a part splits off into two routes but those two routes sometimes come near each other without walls, you likely intend for the player to be able to switch between the two routes. If the split is short enough then the junction connecting the 1st route to the 2nd may be enough to cover the length and allow this, but for longer routes the player will go out of range of the junction and not be able to switch routes.

Creating a junction along the first route that points to a nearby section in the 2nd route allows the section tracker to access the 2nd route. You can do this the other way round too, and even have two junctions pointing at each other to create a bi-directional bridge using only two sections.

Note that while the tracker keeps a record of all junctions it has previously searched down, and will not search back on bi-directional junctions since it already knows one side of the link, it does not keep track of individual sections. For this reason it’s reccomended that route links connecting the same two routes together are spaced out to a maximum of 20 sections and are always setup as bi-directional junctions. This minimizes the number of section iterations required, which maximizes performance with complex track setups.

Note

AI have a 50/50 chance of taking a junction, regardless of where it leads. For cross route links, you may want to enable the (AI) Ignore Junction setting in the metadata tab. This 50/50 chance happens on both sides of the link.

Section Reference Generation

When the track is loaded the game performs many tasks to prepare it for gameplay. Two of these processes is Junction Resolving and Previous Reference Assignment.

Junction Resolving

Junction resolving is the process of looking at junctions and marching down routes to interpolate section indicies to match up to the main route. This enables the race position tracker to identify where along the track a ship is, regardless of routes that they’re currently along. The hunter missile can also use this information to redirect down routes where the race leader is.

This process requires that route start and route end section types are setup correctly. If a junction points to a route start section then the game will generate a new route and begin searching for a route end. If a route end is found then the route is registered into the game and used. If a route end isn’t found, or the section holding the junction reference that points into the route is hit, then the game discards the route.

The junction resolver begins at the tracks start laser and then moves forward until it either hits the end of the track (point to point tracks) or loops back round to the start laser. If a junction is found along the way, the resolver branches down the junction and attempts to build a route. The resolver will keep branching down any other junctions it finds while looking down routes.

Once the resolver has built a list of valid routes it begins re-indexing them. If the re-indexer determines that a route exits onto another route that hasn’t been indexed yet, it will wait for exit route to be indexed and then come back later.

What this all means is that the route must be accessible from the tracks main route to be re-indexed. If it’s not then the section indicies of inaccesible routes will be left at invalid values, which makes them unsuitable for race position tracking. You’ll see your race position drop to 8 in routes that haven’t been indexed correctly.

Unused Section Looping

If there are track sections which go unused then the unused sections should be setup to loop. This will create an unreachable set of sections which the game won’t need to worry about, which helps eliminate scenarios where unused sections will mess with the race position tracking.

Previous Reference Assignment

Sections are assigned a previous reference for section tracking to work backwards. The game goes through all of the sections in the track and will set a previous reference by taking the current sections next reference and setting that sections previous section to the current section, with the following rules:

  • If the section type is a junction end, the previous assignment for the next section is skipped

  • If the section has a junction and it points to a route start, the route start section has its previous assigned to the section holding the junction. The assignment is skipped if the junction is pointing to a normal section.

It is important to correctly setup route start and route ends on routes, including pitlanes, so the section tracker can correctly branch out. If, for example, a route cannot be created for a pitlane, you will not be able to backtrack out of the pitlane, and once you leave the pitlane the start grid behind it will not be accesible. This isn’t a game breaking issue, but is something to be wary of. You can use the section tracking visualizer to validate that routes are configured correctly.