I think there is a problem with the tool we are using now for giving the correct time of a run. And the problem is inaccuracy.
My time for "A village is born" was 7:91 according to livesplit with the autosplitter. It was changed for 7:933 by Gheekss who used Youtube video timer and there is no problem with that. However I used the same method and got different times (7:94, 7:928, 7:934).
So either we stay with this method or we use the autosplitter, also we should see about the rules either we use the Victory screen as a sign of the end of the run or what the autosplitter tell us (it seems there are some frames between when the game stop because you won and when the victory screen appearing).
If the problem is accessibility we can make a guide to help people use livesplit and the autosplitter.
Hey, is there really an accuracy problem with the yt-timer method? Even when going frame by frame?
I wouldn't see any theorical problem about using the autosplitter, but I'm not quite confident it is perfect either.. Have you tried it on more advanced levels?
Also, it isn't really publicly available yet, I will try to look into this soon.
Good take @Cipix - I understand what you mean. In my opinion, the inaccuracy of the auto splitter is similar to the one for the yt-spliter - it depends on how the protocol is defined (researchers have the same issue in science ^^).
So I understand the auto splitter will take one « measurement » as a result of how it’s coded. For the yt-spliter, I’m curious to how you may have gotten several results, given that the frame by frame approach should only give one possibility (e.g either you have started the level or you haven’t + either you have the victory screen or you don’t). In the end, it’s especially a matter of making sure we do it in a manner that is repeatable, robust, and simple enough that all can do it. If the auto splitter route fulfils that sufficiently (especially the ease of use) that could eventually be a route to go with to avoid user errors.
The criteria we, as a community, choose (victory screen or fulfilled conditions) is also a factor to consider : on early levels where it’s only population it’s easy to « see » when you win, but I’d rather stick with the victory screen because later levels need metrics that aren’t necessarily visible on the screen (even if Julius solves that). It may include a « calculation » delay, but I’m not sure if that’s really an issue - maybe something the mod devs on the C3 Discord could help us with.
We’re at an early stage where records aren’t within 0.01s of each other so I guess it’s ok, but you’re right that we could try to improve things.
Congrats on that record in the meantime !
Hey guys, so quick check on the method, yt-timer can show frame by frame either at a "frame" rate (with the "," and "." shortcuts), meaning that you get an image every 0.015s to 0.030s (depending on the FPS), or you can manually choose images every 0.001s.
This last method is thus the most precise and should be used to determine the times in my opinion. The way I would proceed moving forward, and to have the highest precision is :
- locate the last frame before starting the level and the first frame with the victory condition with the "frame-by-frame approach" as it's quicker : this will give a good estimate of the run time, with a reasonable precision in the range of +/- 0.10s
- narrow down the range by specifically searching the last frame before starting the level and the first frame with the victory condition, at a 0.001s rate.
Moderation requirements for times would then only need to be that the first frame is indeed "not the level" and the last frame is the "victory".
Let me know if this gives more consistent results on your end - in any case, it's only necessary for very closely timed runs (which may only be a thing on Level 1 at this point)
