Hi everyone. This is a thread meant to discuss a potential modification of the any% category timing definition.

You see, as it stands, the current definition has problems that makes timing runs not only a pain, but also inaccurate. Both the beginning and ending extremities of the run are concerned for a change. Making a modification on any of these will thus warrant a global run retime effort, but there are very few to begin with so that'll quickly get dispatched.

We shall now see what these problems consist of, and list possible fixes (that we've thought of so far), for both run points respectively :

Beginning point of the run :

It doesn't look like there ever was any written rules for this game (the Japanese ones were added only recently and will be reworked once this ends), so it seems the players agreed upon a convention through the media of runs and maybe words. What convention has been chosen, then ?

Well, given the footage of most old runs, it seems that the run officially begins once the player presses the input that activates the "yes" panel that loads the speedrun. This method, while self-explanatory for players, has a major downside when it comes to the retiming end : the game doesn't react. That's right, nothing visually changes when you do that. I then ask you this simple question : on what exact frame has the player began the run ? Me neither, can't find it. How we do now ? Obviously, we can't use LiveSplit as it is a human-error fuelled inaccurate method of measurement. Only downloading the file of the run for frame-by-frame inspection with a program can do. Sure, the game both plays audio and initiates a fade-down to black, shortly after you press the button. Respectively after a generally consistent 4 and 11 frames (60 fps). Thanks to this, we technically could determine the moment of the of the press by doing a simple subtraction. Still, it makes us time the run indirectly, in other words by not measuring it from the intended beginning point, but rather from later in the run. This is janky and it absolutely doesn't have to be for how small of a community we are and will indefinitely be. To add the cherry on top, let's not even get started on dealing with different video framerates altogether, which makes these frame estimations all different, less reliable, and making calculations prone to many more human errors. May I recall that this is all just to estimate where the player input was made to proceed with the "yes" option... yea if we could avoid doing that I think everyone would greatly appreciate it.

Alternatives (Game timestamp put in 60 fps). The run begins :

• when the "start game" button is selected. It is a better alternative because here we can actually visually see the input being made. However, it has the small downside that the player would now have to spam X to get through the immediately following "yes" textbox.
• when the first frame of the screen fade-out to black begins after selecting "yes". This is actually the same exact solution we adopted for EoD and DCT. It is very easy to see, and it covers the entire screen. Bear in mind that it is not about using the side borders, nor the Moo ball as indicators, as these are a bit less notable in comparison

Ending point of the run :

Here, people seem to prefer ending it when the screen is fully black. In other words, at the end of the fade-out to black and once the Moo ball goes offscreen, as the player is then redirected to the stats screen of the final match is won. Now this one is especially troublesome because complete black screens generally are not good to use as reference point. You often get fragments of older, dim but colored frames, that sometimes stay forever until the image updates. Annoying artifacts to deal with, not everyone has the luck to be able to output at high resolutions. And, while this isn't a problem here with KBV due to the Moo Ball staying bright, if the given footage were to be darker than usual, then it would all turn to black before it actually gets fully black. When the object in question is a big bright panel that suddenly disappears, it's okay (L'sV example : ), but when it comes to small objects like the ball, it becomes increasibly unreliable.

Alternatives (Game timestamp put in 60 fps). The run ends :

• the first frame the end match stats screen appears. Very reliable and easy to see, no confusion possible. We can't use the first frame of fade-down here as there isn't one to begin with. Only the borders and ball remain, which as we've said aren't quite as clear to use with. Plus the overall timing of this end point doesn't look very meaningful game-wise. The stats screen one is much better.
• the first frame of the credits playing. This option exist and works, but it would add around 5 seconds of game time, and you'd have to clear through the stats screen as quickly as possible. Why not just allow the player to let go of the controller once they score the final point ?

These changes, outside the credits one, wouldn't alter the run time for more than a couple tenths of a second.

I might have been the instigator of this matter, and done most of the work studying footage, testing, thinking, and discussing it with our (countable-with-one-hand small) community, it's still one opinion. And now it's your turn to fill in the spaces below. (debating in the Discord is fine obviously, but if you actively participate in the move, please make sure to comment here with at least a word or two. Src should be the official place for taking decisions please I'm lonely down here)

I'll leave this on till new weekend I think. We'll see how it goes from here

The end timing proposition makes sense. I was using the older 'wait until the moo ball has fully disappeared off-screen' measurement for splits and changing it to the stat screen I feel is a better indicator to use.

I can see why the start can be changed too, I'd also be in favor to changing it to once the screen starts to fade after hitting the confirmation button. Tracking the start game button beforehand seems a tad unnecessary to me as it adds the extra button input.

Having taken part in the discord discussion while you were investigating, and then after reading your writeup here, I see no reason not to agree with these proposed changes! While, true, it might make things a little more awkward for our manual LiveSplit timing, ultimately it is the official timing that matters, and that requires precision.

My preferences would be to use the first frame of the screen fadeout for the start, and the first frame of the stats screen for the finish, since, as you explain, these options would not alter the run by any meaningful amount of time or add any additional button mashing like the other options would. Seems like an ideal compromise for the runners in order to make the official timing more accurate and consistent!

Late closure to this thread, I got a bit sidetracked, but now it's good. Not like it wasn't.

I'd say we've gathered enough opinions - at least for how many runners there are that are active to begin with - to justify making a decision.

So, in light of our discussion, it seems like we'll be leaning in the direction of :

• the beginning point of the run being the first frame of the fade-down to black
• the ending point being the first frame of the stats screen of the grand finale.

But before we can actually push the changes, and get onto retiming runs, we need to agree on a clear rule counterpart.

Following the style of the other games of the series, this is what I came up with :

• Timing starts upon the first frame of the fade-down process that happens after selecting "yes" to get to play the game.

• Timing ends on the stats screen of the final match.

As an added note, I'll probably end up adding one or two rules just for clarity sake. Stuff like the definition of any%, that a run requires proof, that times are to be in seconds (at least for now)...

Nearly in there guys !

That all sounds good to me.

Ok. We had twice as less player inputs this time, but it's not that important, we can always change it later. Let's go with that for now. Hold on (done)

OK well the rules are set, and now the rest is for the mod team to do. You can now safely submit runs again !

(Run retiming progress : COMPLETE !! Things can now resume as normal !)