Resuming a Multiplayer Race

The rationale for having an option to resume a race is that for various reasons we have the need to be able to resume a race that has somehow been interrupted. The cause can be a DDoS attack on the server, general network issues, groups of clients disconnecting because of specific provider/regional issues, bugs in the server or clients, human error. In all of these cases we want to have the ability to resume a race, either on the same physical machine or a different one.

How does this work?

Every lap, when the leader crosses the S/F line, we save two batch files on the server:

  1. The first records the order on track of all the cars and writes a “grid” that we can load in a new (warmup) session to ensure the cars restart a race behind a (virtual) pace car in the right order.
  2. The second records the number of laps each car has driven as well as the current event time, so we can fast forward the race session and give everybody their laps back.

If we now want to resume a race, we simply pick the two batch files for the lap we want to restore, we start the server with the same settings as before, wait for all the teams to join and then we:

  1. Go to warmup, and execute the batch file that sets the grid.
  2. Go to race, and execute the batch file that fast forwards time and gives everybody their laps back. You typically want to do this when all cars are on the grid, but standing still as forwarding time typically causes a little warp that might cause issues when cars are moving. Optionally you can even ask people the shut off their engines during the procedure.
  3. Resume the race after a formation lap.

Configuring the Server

Before this feature becomes active, you need to create a configuration file for it. The file needs to go in your UserData folder and it is called ResumeRace.json:

	"enable": true,
	"doDebug": false

When this configuration file is present, and "enable" is set to true, you will end up with the two batch files for each lap in UserData\Log\ResumeRace which you can then use to restore a session as explained above.

Background Information

The information in the batch files, especially for multi-class races, requires some thought. When we do a restart, we want to separate the classes to ensure a smooth restart. Furthermore we want to make sure we keep the number of laps completed "consistent" per class. These things are best illustrated based on a picture that is taken at the moment the race leader crosses the S/F line:

So in the picture we've "straightened" the track to a line from start to finish, and on this line we put the positions of the cars, the color depicting the class they're driving in. Let's also list the number of laps each car has driven (assuming the leader is crossing the finish but we're not yet counting its extra lap).

  • 20 laps: 1, 2, 3, 4
  • 19 laps: 5
  • 18 laps: 6, 7, 8, 9, 10, 11

Order per class

Now let's look at the order per class we need to create based on this:

  • Red: 1, 2, 3, 6, 9, 4
  • Green: 5, 11, 7, 8, 10

In both cases we look at where the leader in class is and then go backwards from there to order that specific class. In the overall grid cars are grouped by class, i.e. not interlaced. Classes are ordered by the position of their leader. In our example all reds come before all greens, so final order on the grid will be: 1, 2, 3, 6, 9, 4, 5, 11, 7, 8, 10

Laps per class

For the number of laps, we do something similar:


  • 20 laps: 1, 2, 3, 4
  • 18 laps: 6, 9


  • 19 laps: 5, 7, 8, 10
  • 18 laps: 11

Note that for the slower green class, we again look at the class leader. He has driven 19 laps so far. This means that every other car in that class that has not been lapped by the leader yet needs to remain on the same lap. That is why we give cars 7, 8 and 10 the same number of laps (19) as the class leader. So again we start with the leader in class and then go backwards, assigning the amount of laps driven compared to that position. Which means it might not be the actual number of laps driven!