Thanks for the update, just a couple more questions i have.
- Will existing runs be re-timed to reflect the new changes?
- Reskins, are they allowed in normal categories?
- Reskins, are they allowed in the AP pack category given AP packs come with them?
- 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
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!
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)
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.
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.
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.
I'd be inclined to go with
Timer starts when you enter the first level Timer ends when the stats screen for the final level shows up & a visible timer would be ideal, helps cut down if anyone tries to cheat (But being a small game, I doubt that's likely)
Can we get some clearer rules?
When does timing start? When Does timing end? Do we need timers to be visible?