Can we get clarification on the rules, especially in regards to in-game timer vs external timer?

I've noticed a few runs on the leader boards are using in game time whereas as we discovered last night that isn't a good indicator as time can vary run to run compared to something such as livesplit.

Hi there,

The timer starts when the map loads in and ends when the red loading bar appears after stopping at the destination station.

The run time is the difference between 12:00:00 and the moment the red bar appears (so if the red bar appears at 12:30:00, the run time is 30 minutes).

You can have an external timer on your run if you want, but this isn't necessary as we use the in-game clock to time the run, and for verification purposes we look for the exact moment the red loading bar appears. If there is a discrepancy in the submission, then we do re-time runs to accommodate this so that all runs on the leaderboard use the same metric.

Hope this helps :) please do let me know if you need any more clarification on anything.

Sadly going forward I feel in game time isn't acceptable as it will fluctuate run to run compared to something such as livesplit etc.

Upload below of one of my latest failed runs where it starts off in sync, then falls out of sync at approx 7:20 into the run before correcting itself at approx 9:50.

It then goes out of sync again a couple more times before finally at approx 15 mins in it seems to keep losing more & more time. At the end of the run i've lost nearly 15 seconds in game vs real time and seems unfair to penalise for an issue with the game engine.

Hi All.

So, I have not had a chance to update instasim on this situation yet, but have been talking to KCEdwards, and one of the game developers.

So, it seems clear there is a discrepency between real world timers and in game timers, but at this moment it is unclear whether the actual in game run goes faster or slower based on this bug, or if it's only the timer impacted.

If the timer AND the gameplay slow down and speed up relative to real world time, but in sync with each other, then in game time seems like the correct metric to score runs on.

If the timer runs slow or fast in game, but the game itself still finishes the run at the same speed, then real world timer is a more accurate metric.

To Im Cirno, I ask that you have a little patience if possible on this topic. I joined as a mod for the first time on Friday, and am trying to take a few days to get some dev answers on this game so I can bring an accurate assessment of the situation, and proposal for how to keep things fair, to the other mods.

I am waiting for a message back from the dev team on the game, which I expect today now it's a week day again, then I'll come up with a proposal for the other mods, and some explaination of where we are at with things I can share to you.

The main reason I initially decided on In Game Timer when I made the leaderboard is because it seemed the more accurate metric to use as it starts and stops at the exact same time (you aren't accounting for reaction times to start and stop, and even if using an auto-splitter you aren't relying on third-party code and RAM allocation, which is undoubtedly fast enough to not really be noticed but a delay will still be there regardless).

If everyone uses In-game time for their runs, then the difference really becomes negligible and the time lost really isn't all that significant. When you compare between the real-world timer and the in-game timer, there will be discrepancies as potentially it very largely depends on how smooth the game is running (from Laura's reply, we may receive more clarification on this).

As Laura mentioned above, it's unclear whether the in-game timer runs any faster or slower based on the game or if it's just the clock (I do notice the clock sometimes going a bit faster and slower now and again when I play the game casually as well, but whether it's because there's frame drops or if the clock just has an actual issue is unclear).

As of right now, timing continues to be IGT as it gives a clear indication of the start and end of the run. However, if following Laura's investigation we find there is a real case to move to a real world timer then we will provide an update on that as soon as we have one.

So, here's the first info I have from the dev team on this issue.

hope this helps :slight_smile: There are multiple reasons for the clock times in TS here is the reasons and how can it be different … • One of the main ones is the ETA & ATA, one is an estimation based on calculable factors and the other is a measure of actual time accounting for limiting factors such as lost frames, disk reading, etc. • Also it is dependant on what your PC is like if you are getting 60 fps then there is a consistent measure of time for each player as it will be measured in real time. This remains true until you begin to reach the limits of game thread processing time. i.e. if the frame rate reduces below 15 fps, then you'll find that the game thread is not being managed in time with the game clock so time dilation occurs. • The only way to ensure a consistent measure is playing on the same PC on the same route and same scenario Have a look at some of the 4UP challengers you will be able to see how it works as all the PCs are different and can see how it changes the time clocks.

Going to take a little while to parse what that means for us.

Only just had time to come back to this, I am more than happy to wait, I don't have much free time as is so don't want to set some runs for them to be a waste of time etc.

"I.e. if the frame rate reduces below 15 fps, then you'll find that the game thread is not being managed in time with the game clock so time dilation occurs."

Nice to have it confirmed that it is frame rate dependant, Funnily enough I did a couple of test runs last night on SWML at a locked 15/30 FPS and the timings were almost the same time in live split, but massively out in game. Videos to be uploaded.

Locked @ 30FPS - 19:19 In game time & 18:19 LiveSplit Locked @ 15 FPS - 18:35 In game time & 18:31 LiveSplit (Braked a fraction too early, should've been approx 18:16 IGT & 18:20 LS respectively) Locked @ 60 FPS - 17:41 In game time & 18:28 LiveSplit (Braked a fraction too early again, should've been approx 17:31 IGT & 18:18 LS respectively)

More dev info

Can use either method but would suggest using the in-game ATA clock as that will account for pauses in the game thread due to fetching data. The real time external clock won't do that and there is varying degrees of data fetching times depending on hard disk access. Manipulating in-game frame rate will be the easier method for players as that can be accomplished by adjusting in-game settings to ensure the game clock is running properly - all you'll need to make sure is that players are not running below 15 fps. Ideally they need to be above 30 fps to guarantee the time is going to be consistent across PCs I would also recommend advising players to ensure all background processes are closed before attempting the run - that is going to free up processing time as well as memory so there's less reliance on hard disk access No need to kill everything in the background, just as much as the player feels comfortable with. Fan control software has minimal overhead so is usually ok to leave running but things such as web browsers chew up memory and that's only going to slow things down. Another method that could be employed is asking to attempt the same scenario multiple times and the best time or averaged time across each run is then used as the final result

Updated my previous post with a 60 FPS run and can safely say that LS seems to be the way to go, ATA is varying wildly between FPS and even on uncapped FPS will fluctuate up & down as can be seen on both of our runs for SWML & BML in your case (Albeit it's a lot less prevalent there).

Thanks for the further information too, sadly they seem to think we're all still running IDE hard drives, a small amount of RAM and single core, low speed processors. "pauses in the game thread due to fetching data" Or what It's widely known as "tile load" isn't much of a thing these days, especially If you run the game off an SSD and have a modern processor. Hell even running off a 4th Gen i5 & 7200 RPM hard drive I only had the odd stutter and that was mostly on new routes where the cache hadn't been built.

There are exceptions to the above (I'm looking at you Clapham Junction on PDL) but that's usually down to highly detailed models and/or a lot of A.I in the vicinity.

Feel free to experiment yourself, you can cap the FPS using the command line tool on steam or the launcher and using the command

-FPSLimit=30

Finally I want to apologise If It seems like I'm barging In & demanding all these changes, I just want a level playing field for all & any confusion cleared up for future runners, Probably rambling now so going to set out to finish what I'd planned with my day off!

It definitely looks FPS dependent. We could have both timing methods in all fairness if there is a major disparity between IGT and LiveSplit (I'm pretty sure there is an option to add a time with loads and time without). That way players can time with both and submit both times in their runs.

It might also be beneficial to not limit the framerate in the game if IGT is used as it seems that's where most of the discrepancy comes from, it's certainly concerning to see a 1 minute gap between the times on 30fps.

Personally I don't think multiple runs and averaging the result is such a good idea as runs can vary in length for any reason, and some variances can be huge and others minor, so it's really not the best idea in my opinion.

Also, no need to apologise for making a suggestion :) we all welcome suggestions and we try to keep things similar. In all honesty, I don't think we've had any major issues with IGT before and probably never realised there was such a discrepancy, so it's really good that you have brought it to our attention. It's certainly something to look at and whether we change the rules or incorporate External Timers in some way, this will all be incredibly helpful for us :)

No need to appologise, this needed working out and working through, and was bound to come up, you know, as soon as someone started trying to beat existing times and not filling in blank slots haha

Going to experiment a bit more myself this weekend with FPS locks and see what can be done to find a good solution.

So I've just found a setting in speedrun.com which provides a submissions field for Real Time and In Game Time, so we might be able to utilise both timing methods (and it'll also help us find a discrepancy).

It could be something for us to use for the leaderboard, then providing a choice to players whether they want to use an external timer or not. Just a thought really (I'll have a chat with the other mods).

Thanks for the update, just a couple more questions i have.

1. Will existing runs be re-timed to reflect the new changes?
2. Reskins, are they allowed in normal categories?
3. Reskins, are they allowed in the AP pack category given AP packs come with them?
4. Are we able to use keyboard shortcuts to disable onboard systems (E.G CTRL & D to turn the Driver Vigilance Device off or other systems as appropriate?)

Cheers

Hi there,

Sorry for the response delay. Past couple of weeks have been manic with InstaSpeedathon preparations on my end so only just had the time to respond. I'll answer the questions in order.

1. Current runs which only have In Game times will have this reflected (just need to sort that out is all). Re-timing runs will be up to the runners themselves though if they wish to do so. I believe runs can be edited after verification so the time can be added later, but if not just send one of us mods a message with the new time and we can update it for you.

2. Reskins are allowed provided the consist is the same as the rules allow.

3. Same as answer 2, as long as the consist is the same as what's mentioned in the rules.

4. You can disable them as long as disabling them doesn't require editing game files to give players an advantage (So Ctrl+D to disable them is fine).

Hope these help :)