United StatesThe fastest split I have written down for myself is 1:12.5. But as far as the potential? I’d say sub 1:10 is absolutely possible and as low as 1:05 can probably happen. Assuming solid movement, it is probably something like 1/6 chance for a good boost right after the green light, 1/60 chance you keep getting boosted after, 1/200 its extended, 1/20 for a perfect tunnel boost, 1/30 for a boost before the tracks, then 1/30 for a very good second tunnel boost. Combine all those in one magic 1 in a billion run, you’re probably looking at sub 1:05 :)
Unfortunately the game doesnt work that way. There is actually a gigantic invisible cube there that prevents you from getting by even if you did dodge the first gate trigger.
Then, even if you somehow manage to get past the cube, the ending sequence would never play because the game only checks for a cutscene trigger in a specific order. If you miss one trigger (e.g. gate opening), then it is impossible to activate the final ending trigger. Check out this vid where I hacked out the invisible cube to see what would happen. https://m.youtube.com/watch?v=JQTW2zcXWXA
Also, I updated the resources page to include a TOMYSSHADOW-approved fullscreen projector for on the run.
One cool thing about FFX Runner/Alias Runner/Alias Runner Beta is that they all work with the in-game time patch made for the original game if you replace the runner.dcr in your On the Run folder with the runner.dcr that comes from each of the other games. The only minor annoyance is the timer is not as far in the bottom right corner, which is a relatively simple fix if need be. While the games are super similar in general, some mechanics (such as what happens when your car turns over) are notably different from the miniclip version.
There are quite a few of them! Here's some of the more well known ones and where you can get them
BlueMaxima's Flashpoint is a great source for tons of curated shockwave games and includes most of the On the Run series. You can download flashpoint infinity here: https://bluemaxima.org/flashpoint/downloads/
Link to Tomy's Mega: https://mega.nz/folder/ppJBySSC#LCR6NbqXpUpyXqH_1eemhQ/folder/VghSFKLb
My sources for all the other On the Run games that are shockwave based: FFX Runner - Flashpoint Alias Runner - Flashpoint Alias Runner Beta - Flashpoint On the Run 2 - Flashpoint or Tomy's Mega On the Run Vegas - Tomy's Mega
Related "On the Run" games: FFX Runner HD - https://ffx.itch.io/ffx-runner-hd On the Run Getaway - Searchable online, might still work in old browsers Alias Runner 2: Apocalypse - Flashpoint. Also a very bad game lol.
Unfortunately, the current On the Run 2/Vegas curation has issues with showing the score at the end which would make it difficult to speedrun.
Epic. You have an nvidia graphics card?
Ok cool! Do you have an Nvidia graphics card? If you are willing to indulge me, try the latest version I just posted with antivirus and everything fully enabled.
I think the antivirus is triggering because I had been using a director xtra with an identical name to a xtra that comes with director, except the new version is meant to fix an issue that occurs with nvidia graphics cards. I think the antivirus picks up on the fact that this newly created xtra is not what it should be and blocks the executable.
Anyway, I think that antivirus-triggering xtra is redundant when you properly apply the patch on the fly. If you have an Nvidia card and this latest patch works, then I'll know that I succeeded. Annoyingly, my laptop is all AMD so I can't easily test these things.
Could be antivirus software or something... although if I'm triggering the antivirus software that's not a great sign :D . I sent what I did to Tomysshadow so hopefully he will be able to make a better version.
@ValeyardVictorious hmm no idea. Run as administrator? lol.
@ValeyardVictorious I uploaded a new version which will hopefully fix the issue you had. Can you let me know if that one works, and also if there is any particular error if it doesn't? Thanks.
BTW check the resources tab for the big version and let me know if it works lol
Tomysshadow has made some "stretch" projectors which make compatible games full screen. On the Run is compatible in its unmodded form.
Just now I slapped together a projector that includes all the latest patches: -IGT patch -IGT display and finally... -"""high quality""" fullscreen gameplay
I actually had no idea what I was doing, but it seemed to load for me so the most responsible thing was to unleash it over the internet with zero testing. Will probably get in touch with Tomy at some point to make a cleaner version, but am actually pretty busy today.
TL;DR The in-game timer is now displayed live while running the game, check the resources tab!
Hello all! The in-game time project has been a long time in the making and I am happy to announce what should be the final iteration... a live timer display!
Summary: After honing my shockwave knowledge from the previous in-game time patch, I realized it might be possible to have a constantly updating in-game timer displayed on screen. After some beta testing I pitched the idea to TOMYSSHADOW who was once again happy to help! Below is a "casual" speedrun I did with this live timer, so you can see it in action:
Lazy Technical Details: In many ways, the things going on behind the scenes are simpler than the previous patch, since we already have all the code to calculate the patched in-game time at the end. Basically, we can just use the same math from the original in-game time patch, but now do the full calculation before every frame, updating our time display whenever the time increments. There is also a lot of tinkering that is done to have the camera properly display the time without causing lag, flickering, etc., but these things are totally not necessary to get the gist of the patch, and I would be bad at explaining them :)
Happy running!
The reason we use in-game time in the first place and not real-time is because different computers run the game at different speeds. If you compare a lot of different people's runs with similar in-game times, you will notice that they are often wildly different in terms of real-time. For example, Goomba runs this game very smoothly and loses almost no real-time to lag, whereas many others such as myself and f1 have computers that run the game more slowly. To prove this to yourself, try comparing real-time speeds on straightaways (where neither person is getting boosted from behind), since they can often show you how one person starts to slowly creep ahead of the other while the driving is basically the same. The effect is subtle but should be noticeable, and over a whole run that subtle gap in real-time speed adds up.
The method you tried to compare between computers doesn't work because of how the game progresses the cutscenes. In particular, the zoom-out at the end of the game will run for the same time on different computers regardless of framerate because those sequences are governed by the system time of the computer (after your computer's internal clock advances 5 seconds, the game moves on, regardless of framerate). This is much different from standard gameplay, where the physics is capped at 30fps but can dip below that if you are experiencing lag, resulting in RTA timelosses.
The in-game timer accounts for differences in lag because it measures the number of physics steps taken, not the real-time speed of the run. If a computer were to run the game at an average of 28 fps, it might take them 180s RTA to go a certain distance, while a computer running at 30fps would get there in 168s. However, in both cases, the game takes the same number of physics steps to move between those points, so the times are able to be compared.
You can also hit me up on discord if you want to talk about this more. Our semi-official server that we used to address timing concerns in the past is here: https://discord.gg/u2YK4yr
This bug happens when an error occurs in the CPU drive control code while the game is running. When this happens the cpu cars basically stop functioning, with a telltale sign being the high pitched engine sound you start hearing faintly in the background soon after the error occurs that continues until the game ends.
LOL! This is actually a good proof of concept for clipping into unintended zones given a high enough upwarp. These clips often occur for me in the ending section when I'm riding the wall (once had an astonishing 15s+ period of airtime before landing back on the track)
I do think there is probably a way to clip past the gate on lap 1 by triggering similar crazy physics that sends you flying. Both Goomba and I have accidentally done this part of the way by clipping a very particular spot on the fence, but both of us died soon after before figuring out if the clip could actually progress the run and I don't think either was recorded.
This is the first time I've actually looked at one of these events frame by frame. I'm wondering if these events are caused by a "normal" car flip that gets compounded by immediately contacting a sloped object in a certain way on the next frame, triggering physics that multiplies that initial vertical momentum.
Needless to say, these glitches appear impossible to get consistently, but I would love to see someone pull one off to save time.
Hello! The way the projector file was created makes it always show as fullscreen.
If you want to have the game open while troubleshooting OBS, you should be able to use Alt-Tab on Windows or Cmd-Tab on Mac to switch between the game window and OBS window. This should help you check if you are capturing the game correctly. Let me know if there's an issue!
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
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
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:
- 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
- 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!
Kidding aside, I finally figured out how to get the runner.dcr file to run inside adobe director itself (not actually hard to do at all) which allows me to manually change the game's framerate. Can confirm that IGT is unreliable - when I lowered framerate to 15 fps (the standard framerate is capped at 30 fps) I got a 3:31 attempt first try (and it was trash with like 0 boosts).
Now that I know we can actually modify the game in director (although we can't directly modify any of the original Lingo code), it seems that it MIGHT be possible to build in our own in-game timer which properly counts frames and could theoretically be added for speedurning purposes. However, this might not be possible with the limitations imposed and with the files being in the weird state they are. I am also a total novice to Director (and programming in general tbh) so it might be possible but beyond reasonable for me.
