In-game Timer Patch Complete!
3 years ago
United States

TL;DR A .zip with a patched in-game timer has been uploaded to the resources tab

Summary: As many of you know, the in-game timer originally built into this game is unreliable. It was found that laggy computers have faster in-game times, but for a long time we did not know why this was the case. This patch was developed by analyzing the original game code to figure out what makes the timer tick, identifying where this goes wrong, and then patching in modified code to fix the reported time. I had been stumbling around attempting this project for awhile, but the big breakthrough was when I managed to enlist the help of legendary shockwave programmer TOMYSSHADOW who went through everything with me and ultimately implemented the patch. This is actually the same guy who put together the original offline projector that we have been using this whole time!

Technical Details:

Background In order to run the physics in this game, On the Run uses a director xtra called Havok which has a property simTime that keeps track of how long the physics of the game has been active: every frame your car moves, there is a step of physics and the simTime value increments. This simTime property is also what gets used to calculate the in-game time. Normally, this timing method functions perfectly regardless of lag since all users on all computers will drive the same distance for the same number of physics steps, regardless of how often those physics steps occur.

The Problem Case 1 - The first case this timer fails is when sitting at the red light at the beginning of the game. During this phase, the game steps the physics according to the framerate of the game, but the time the light turns green is dependent on the change in the system time of your computer. Therefore, if your game is running at 15 fps, you will only have 45 physics steps in the 3 seconds before the light turns green while if your game is running at 30 fps you will have 90 physics steps in those same 3 seconds. In this case, the physics-based in-game timer would register only half the passage of time for the 15 fps user, giving them an advantage. Case 2 - The second case the timer fails is at the very end of the game after crossing the tracks. The run is effectively done once you cross the tracks, but the time doesn't stop here. The physics keeps running, but it is once again disconnected from the speed you are actually moving through the game since the end screen is triggered based on system time. As a result, someone playing at 15 fps will register half the physics steps in the ending sequence when compared to a 30 fps user, once again shaving off time from the in-game timer. There is actually an interesting workaround for this case I discovered while working on this patch. If you hit "P" to pause the game right when crossing the tracks, your in-game timer also pauses since the physics stops, but the game will complete, giving you a much lower in-game time than previously thought possible. This phenomenon can be seen here:

The Patch Step 1 - After figuring out these two cases with TOMYSSHADOW, he immediately began work on a fix. First, he modified the program that steps the physics to include an ability to track if the game was in either of the aforementioned cases. We can tell if the first case is occuring by seeing if the file is on a certain frameScript number, and we can tell we are in the second case by registering the moment the animation for the user crossing the final tracks is tripped. When either case is active, we keep track of the number of physics steps that occur by incrementing an"invalid" physics step counter. The idea is to subtract these invalid steps from the total at the end to give an actual count of the in-game time from green light to crossing the tracks. Step 2 - Finally, we modify the end screen code. Instead of displaying the time dependent on just havok.simTime, we display a time dependent on havok.simTime - invalidSimTime, where invalidSimTime are the physics steps that happened during case 1 or 2 that should not count toward in-game time.

With this patch implemented, the in-game timer effectively starts ticking the moment the light turns green and effectively stops ticking the moment you cross the final tracks. Therefore, runs recorded with this patch will have in-game times that are accurate to the amount of physics-based time the user actually spent controlling the vehicle. As a result, the timer is now completely independent of the framerate you are able to operate the game at.

Notes:

  1. The cutscene sequence showing the gates coming up pauses the physics, so we didn't have to implement any kind of fix for that part
  2. In-game times recorded with the fixed timer will naturally be lower since they exclude parts the timer is improperly incrementing. Users should make sure to note that runs were performed using the IGT patch, and maybe F1 could adjust the leaderboards to clearly report how runs were conducted

Once again, shoutouts to TOMYSSHADOW since there is no way I would have been able to implement this fix on my own. Happy running!

Edited by the author 3 years ago
Jumpyluff, Goomba, and f1 like this
Gelderland, Netherlands

This is actually legendary plot development, incredible work you two.

I do have a question, since I don't think you've mentioned it. How about the cutscene where the rails go up? does that also get subtracted from the IGT?

United States

The cutscene where the rail goes up already pauses the game physics which also pauses the in-game timer there. Since that's exactly what we want to happen during that cutscene, we didn't need to worry about it

Wow, this is incredible work. Inevitably, some testing needs to be done before runs are accepted that deviate from the orginal version of the game/timing. And to be honest, I'm not sure where to start. I can't just retime every run that's been submitted and subtract the invalid time sitting at the light/crossing the tracks since each system is different. Therefore, should it be fair knowledge that a "new" version of the game is available at this one speedrunning website, and other speedruns become (somewhat) obsoloted? Or should a new variable be introduced that indicates the new timing vs the original timing? I hope this doesn't come across the wrong way and can be understood by everyone, but a fair method needs to be evaluated before a new timing becomes implemented.

Edited by the author 3 years ago
Colorado, USA

I agree with f1 but it's hard to trust him because the foreground scrolls the wrong way. There are no parts of a valid speedrun that throw the car into a diagonal reverse.

United States

There truly isn't a way to compare old runs and new runs. This fix was done to allow the game to remain competitive and not be stuck with a timing system and world records that no one is happy with.

If it's possible, I propose that we change labelling on the leaderboards to note that a run was performed with the modified in-game timer (yes/no), and to include a reference to where the patched game can be found in resources in the rules. The effort someone new to the community must take to play with the patched game is minimal, and gameplay is identical. I think most people are competitors who want their times to be fair and comparable to the times of others and will gladly play with the patched game to prove their ability on an even playing ground. The patch is meant to be forward looking not backward looking.

One thing I feel like I should point out is that the video linked in my original post with the "pause strat" is actually world record in the unmodified game, but I didn't want to submit it because an actual patch to the issue was in the works. It seems silly to pause the game after you finish driving to achieve a faster IGT by several seconds. There is minimal skill in this, and it is not reflective of how you actually drove. Additionally, even if everyone began doing this, it STILL isn't fair because you cant pause at the light at the beginning of the game where the timer also improperly increments.

No matter what we decide, the old runs are obsolete: either everyone starts using a pausing strategy that still isnt comparable between PCs because it can't fix different timings from the light at the start, or we tackle the issue head on by deciding as a community to play with a patch that fixes the underlying problem.

The main reason I favor the patch is that absolutely nothing about the gameplay changes except the timer. It is essentially just one variable that has been added to change how times are calculated. The code has also been implemented, tested and vetted by someone independent from this community who had no other motive than to solve our timing issues.

I'm happy to discuss this more here or on the discord https://discord.gg/4mN9pW

Edited by the author 3 years ago
f1 likes this
Game stats
Followers
64
Runs
171
Players
82
Latest threads
Posted 2 years ago
3 replies
Posted 3 years ago
2 replies
Posted 3 years ago
2 replies
Posted 3 years ago
1 reply
Moderators