I know this hasn't been communicated well in the past, but I have realized that there may be several runners who think they are timing the game accurately but are not.

To put it simply: Livesplit is not accurate when demo recording is not used. Use Portal 2 Live Timer, or if you want to run with livesplit, time the demos after the run.

Explanation:

Demo recording has always been, and will always be the most accurate way to time runs. It is resilient to lagspikes, loads, etc. and has proven to be 100% accurate giving the exact number of ticks (1/60th of a second, think of it like a frame) that a chamber takes.

It was discovered in 2011 or 2012 that demo recording through a load causes roughly a 0.4 second delay. To avoid this problem, challenge mode runners would always stop their demo before the next attempt and begin one after they loaded in. This is the norm for challenge mode. However, in a single segment run there is no way to accurately get rid of this 0.4 second delay. The best way to get a consistent timing is to allow the demos to automatically continue recording through each chamber. In the case of a death, the best way to continue timing is to pause upon reloading and record a new demo before continuing. Unfortunately there is no way to make demos automatically continue recording after a death, but of course deaths can only lose time so there shouldn't be a lot of them to worry about.

During the course of the run (62 chambers, so 61 between-chamber loads) this 0.4 second (approx.) delay would amount to about 24-25 seconds. We accepted this in single segment timing because demos was (and still is) the most consistent method of in-game timing and also they allow you to later play back the run and render it in high quality.

Fast forward a few years and Sourcesplit (a plugin for Livesplit) was developed to remove loads from source games. This was extremely helpful for games like half life 2 where RTA was previously the standard. It "works" in portal 2 as well as it does for other games, but it's not like demo timing... it doesn't base its timing on the amount of in-game ticks that pass so it can differ and can be a few seconds off across a full run. Most importantly, if demos are not being recorded, the 0.4 second delay will not be captured in the timing and the time will not only be less accurate, but unfairly faster than demo recording. For some other source games (including Aperture Tag) sourcesplit is still your best option. For Portal 2, we already had something better.

I don't want to start removing people's times because they didn't know all of this (honestly, if you weren't around in the community 2-3 years ago you just wouldn't know), so instead I want to propose: -A penalty of 30 seconds to be added to those runs which did not record demos and used livesplit to track in game time. (to counter estimated 24.4 seconds of delay, plus generally less accurate timing method)

-A penalty of 5 seconds for those runs which use livesplit timing while demo recording. (To counter generally less accurate timing method)

Of course, runners who have demos can and should use the time given by Portal 2 demo timer or Portal 2 Live Timer so they would have no penalty.

I don't mean for this to be harsh, I just want to make our leaderboards more fair. I do apologize for the lack of this timing explanation being readily available and known, it's partly due to the fact that I am not as active as I used to be , and also partly because I never expected there to be so many newcomers to speedrun the game (which is a really awesome thing!!!)

I have not made any edits to submissions yet, I want feedback before I actually implement these ideas.

Very informative Znern. I know you always endorsed the Live Timer but didn't realize the inaccuracies were this big. I think the 30 seconds penalty is extremely fair. Currently, I'm dying enough during single segments that P2LT would be a huge pain, so I'll just eat the 30 seconds.

Thanks for the information, though.

So how does this effect Coop runs?

This is just talking about Single Player Single segment category. Coop runs are not affected by the demo delay the same way. Their demos are more complicated to time because they start with a piece of the loading screen, so the demo timer already has to cut that out. I don't know much about differences in livesplit in coop vs. the specially made coop demo timer, but it wouldn't create that 20+ second difference I'm pretty sure.

Also Peroculos wants to do some testing on the timing difference of demos/no demos and livesplit, the estimate of 24.4s may change, he expects it will actually decrease slightly. We'll try to figure out the most fair difference to add but regardless demo timing is encouraged.

Í've always used both LiveSplit and the demo timer at the same time during runs. LiveSplit has never been off by more than 3 seconds after a full run.

For my last PB, LiveSplit said 1:17:49.71 and the demo timer said 1:17:50.983.

good to know! In this case you would put 1:17:50 on the board. Is 3 seconds the most it's ever been off? Maybe the short penalty can be reduced to 3 seconds instead of 5.

I guess it would be safer to use 5 seconds because I'm pretty sure you can save 0.03 seconds off every segment by alt-tabbing out during the loading screens (I found out because I saved .03 seconds if I alt-tabbed before tube ride / the fall).

I think it will difficult to correct the runs with the current rules. Example: Some provides no video what do you do?. Maybe we could add a variable that lets us know what timing has been used for example Livesplit P2LT and timed the demos after the run.

Also I had P2LT and livesplit run at the same time and experienced not more than .1 seconds difference