This is about general changes that can be applied to all boards. Individual changes will be discussed within their games. I think ? Or should we always discuss such changes here everytime now ? For now, we'll handle it the former way.

In there you have access to info about the game, a walkthrough, a comment section and other misc : https://taldius.itch.io/klonoa

Wii and WiiU console runs are allowed. Emulator or USB loader runs share their own sub category due to having much faster loading-times than what's possible on console. But this doesn't concern time-attack mode.

Wii Mini would first require testing to see how it is like compared to its neighbors, then we can determine how it would be implemented it in the leaderboard.

This will naturally update as things evolve.

[Edit 24 april 2022 : discussion about the revival of the all visions category is taking place in the second page on this thread]

In the light of the eventual resurrection of a previously removed category, all visions, some discussion has sparked surrounding the topic of stage order. As it is today, we don't seem to have any stance about it, and rules don't speak about it either... despite 100%NG+ category being open and hosting runs for years. There are few runners of that category, and although such a case hasn't happened yet, how would we respond to someone submitting a run with a completely different stage order outside of the final vision ? Such a technicality would also affect the all visions category, and more generally any category that involves the stage select screen.

What's more, if we were to effectively allow a freedom of choice with the stage selection (outside of extra and final), then we would most certainly have to change the beginning timing point of these categories to not be the one we have in 1-1 due to otherwise time discrepancies (for which there already are ideas). While such a discussion wasn't originally meant to take place here, points being raised on Discord and the realization of its significant impact both on the current runs and also the community now fully requires it to.

Being able to play stages out of order would almost always result in you losing some time navigating the stage select screen, compared to an in-line order. On the other hand, it would allow you to clear the harder stages first, without having to wait minutes for them to come up normally. It's more time effective and less annoying, and will thus allow to have better times overall.

So, once and for all, let's try to get to a consensus on the subject. Should we allow stages being played through whichever order people want, or should stage order be enforced to the runner ? Why, and possibly how so ? If we allow for it, should we make two sub-categories, or track runs using such freedom with a variable, similarly to what's done with the extra stage ? The response to this might be really simple and obvious to some of you, but you'd be surprised that opinions have been much more conflicting on the question (referring to Discord conversations). You'll have to discuss it out regardless.

Hope I didn't forget anything.

This is the thread dedicated to DCT's categories. Adding and removing them, their rules... This is merely a simple post presenting the thread. For actual subject matters, read what's below.

[This thread doesn't talk about emulation.]

This is a thread dedicated to updating and explaining the new reasoning behind the way the platforms (broader term that encompass consoles, computers...) are currently selectable when submitting a run. It concerns the Klonoa GBA boards. Heroes is expected to come at a later date.

Link to the DCT mirror thread : https://www.speedrun.com/klonoadct/thread/1w6ud

Have you ever wondered why you cannot select a DS type console, or some of the less popular GBA consoles for your run ? Why's it so ? Well, that's the wonder I had one day, and I never once suspected it to lead me to this rabbit hole and shatter my world. Seriously. For about a month, I went to a couple servers and asked them questions about this. And this is the conclusion I've been led to. If you want to skip to the changes, search for "So, for our sanity and for simplicity sake". The content skipped is my reasoning behind this forum post and change. Feel free to challenge or complete it.

At front value, it seems to make absolutely no sense at all. Why not just distinguish all official consoles ? Why can't I submit using the console I played the game on ?? Well, before anything else, and to my surprise, not all GBA compatible platforms are available to bed used on src in the first place. Yup, that's right, Game Boy Micro ain't a thing for some reason. You'd have to ask the moderation team to add it in, so I guess it could potentially solve this problem for us. If they don't though... we could then do nothing but ditch the idea. Or create our own hosting website away from src. Which, in all possibilities, is a possibility ?!

But is bothering about the proper distinction of all consoles actually useful for us ? What actual good does it bring us ? The main reason why leaderboards are susceptible to group platforms together is because the grouped platforms (GBA, GBP, DS...) technically basically play the game the same way, with no meaningful differences. In this sense, despite what anyone could say about it, we technically have the right to group them under a term. While we know this would never be possible with the PS Klonoa games, it's a particularly common problem with GBA and below.

So why one could be against such this platform handling approach ?

• Well, one argument is that, as stated before, it would be very user friendly. Submit your console, which you obviously know what it is, and that's it. Whereas, having multiple consoles grouped as one term (GBA) is not at all intuitive. This can easily be circumvented however if we clarify what that term means in the rules. Believe it or not, but the boards of the way bigger games I've visited don't take the time to do that, even though it would only take a 2-3 lines. Apparently it's not perceived to be a big problem to them, like they've rarely got users being confused over it as much as me. Still, I think this doesn't hurt to add. So that our intention is clear on the subject of platform management.

• Another argument, and that originally was my main one at first, it would be meant for transparency purposes. It would for instance allow to know who played on what, make observations and statistics. Fun stuff, basically ! But also, if not more importantly, being able to compare ourselves on equal footing too.

But after studying it a bit more, I'm personally lead to think otherwise. Simply put, there are way too many GBA compatible consoles, and they either play the same, or with negligible time differences that would make it very difficult to justify separating them. Additionally, we are not at a level where these things matter much. Separating them adds more clutter than anything. Src is also made in such a way that you can only filter runs using only one variable. If you wanted to compare runs of many different platforms or variables, you'd need to constantly switch, take screenshots, or open multiple tabs at once. Although it is merely a limit on the system, it only seems to point out that simplification is better suited here. And finally, we don't have much ability in managing these things. This is a very tech heavy subject, that require a lot of testing and knowledge to lead well.

So, for our sanity and for simplicity sake, from now on players will only have a select few platforms to choose from. They will be :

• GBA. Most consoles will land by default. Game Boy Advance, GBA Special Edition, Game Boy Interface, Game Boy Micro... I also include Game Boy Player. It is know to have some input lag, but since it's not the game's fault, it's not really a difference even if meaningful under gameplay. Besides, I reckon input lag could still happen in other circumstances.

• WiiU Virtual Console. It has significant faster loads.

Of course, if we happen to find significant time-saves with a new platform, we might separate them.

There will be a rule line about this in the main rules panel : " Here are the two platforms you can submit on (more info on the stickied thread) :

• GBA. Designate the vast majority of GBA compatible consoles, such as GBA SP GBP, GBI, DS...
• WiiUVC. "

This would only affect one run, Haru's EoD GBP submission. So pulling or reverting the changes won't hurt if necessary.

So at last, this bit in our boards is made clearer.

This is a thread dedicated to updating and explaining the new reasoning behind the way the platforms (broader term that encompass consoles, computers...) are currently selectable when submitting a run. It concerns the Klonoa GBA boards. Heroes will come at a later date.

The core of the post can be found in the EoD thread, so please check it out : https://www.speedrun.com/klonoaeod/thread/6sw8d

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

This is important as there are many different ways to play this game, amounting to different loading-times (and sometimes more drastic differences).

Most of what isn't allowed isn't being so permanently, we simply don't have enough footage of the game being played this way to tell if it is legitimate to be used in runs. (Especially the main game. There is more tolerance when it comes to Balue's Tower) In such cases, it's better to stay safe and not allow their use, until someone does a run with it or tests its viability.

So :

• PS1 console and emulation (any software) are allowed. See Amoser's comment below for specification on two specific emulators.

• PSP is allowed. See the 4th post for more info. Emulators ? We don't know.

• PSVita is allowed. Also read the 4th post for details. Same deal with emulators.

• PS2 console is allowed, but emulation is a tricky subject. Not only it is reputed to not be of great consistence, we also simply have no idea how it really looks like.

• PS3 console (PSN) is allowed, but the emulation of the console itself or homebrow PS1 emulation aren't, for the repeated reasons.

• PSTV is allowed, idk if there's emulation of the entire thing but it should be obvious as to what that entails.

• Any weirder console setups (homebrew PS2 on PS3, PS1 through PS2 through PS3 on PS4), will probably not be allowed for the same reasons.

At least until we make our own.

The retroachievements site has developed an entry for this particular game, and along it are leaderboards for each "bosses" of the game (minus Garlen for some reason) and the three of the five extras. So if you want to have fun running against other players, this will be it. I assume they get their time via the the in-game timer. There are no equivalent to this for EoD. You will need RetroArch and if you actually want to register your times there, but you can probably play along just fine

https://retroachievements.org/game/5530

(formerly named "any% definition change", but this was heavily misleading)

This is a forum thread meant to discuss a new timing definition for the any% of both games. Specifically, the beginning point. Why is that, you might ask ?

Well, to find out, please make sure to check the EoD mirror thread : https://www.speedrun.com/klonoaeod/thread/lbyto/1#qkfei It is preferred that you respond in that thread instead.

https://www.speedrun.com/klonoaeod/thread/lbyto

[Edit] Choice decision has been announced in the other thread.

(formerly named "any% definition change", but this was heavily misleading)

This is a forum thread meant to discuss a new timing definition for the any% of both games. Specifically, the beginning point. Why is that, you might ask ?

Right now, the rules says that "Timing starts on file select". So, upon the button press. As natural as it is for runners to use, it poses a severe issue when wanting to accurately time runs to the frame. Indeed, it is very difficult to determine when that button is pressed exactly, since the game doesn't visually represent that input. Indeed, nothing actually happens until roughly 0.1 second, time where the game plays a sound effect, and 0.1 second after, after the fade-down to black begins.

If it was only that, it would be a little annoying but ultimately fine, as would simply be able to determine where the input happens based on the audio or visual part. But it couldn't be further from the truth. Because both those time estimations are in reality random in length. They can either be normal, or straight up 4 frames longer, and in-between, all at 60 fps. This is an absolutely unreliable timing method, and is the main reason why it currently is being subject to change. But also, to make the run much easier to time for everyone.

The newly developed method, favored by the current runners and that works for both games, is timing from the first frame of the black screen after the save select screen has faded down. It is easy for runners to split to, reviewers to time from, and compatible with autosplitters.

Such a change will ask for a potential re-timing of every single runs (27 in total), due to the slight time difference with the current timing method. Because of this, it is mandatory that we ask the community about a change of this scale.

Now that things are explained, this is you moment for you to vote and express your thought on which is better :

• Keeping the current timing method for the beginning point of any%
• Using the newly-developed timing method

This thread has been duplicated in the DCT game board, but it is preferred that you respond here.

We will call it off once enough people have responded in the following days.

Link to the DCT mirror thread https://www.speedrun.com/klonoadct/thread/trkp6

Hi. I have noticed a small issue when interacting with the stats screen of leaderboards. It happens when viewing the IL history of any games (works with even SM64).

While the ILs history, curves, times and info are correct, whenever you click on any of the dots to access their corresponding submissions, that will instead bring you to runs of the very first category listed in the "Full-game" section. . Not the IL submission itself.

Another thing that would also be handy regarding the stats panel, is a way to see the dots clearly, especially when they tend to agglomerate. Maybe some built in zoom function.

Unrelated to this thread, but I found out yesterday that an issue I had posted about a month ago has yet to see a fix : https://www.speedrun.com/the_site/thread/a5bn3 I'm only just reporting on it again, I don't know what actually goes around fixing such a thing. Maybe it would require an unreasonable site overhaul. I'm not entirely enticed with this move, but I couldn't hold myself not to report again on a clearly still present oversight. I guess I simply want some sort of closure on it... but anyways

[Edit : thread previously known as "Rule clarification for full-game runs".]

A line in the rules has now been changed, to explicitely state that you must play the run through a newly created save-file for the run to count.

Besides for clarity sake, this is mainly due to ensure all runs come out the same way. We recently found out that FestivalTemple's two top runs has started the game via an already created file, which messes with the definition of the run since you never encounter the "Save complete" panel.

We'll exceptionnaly turn an eye to these runs (any of the already existing ones that have this problem, which I'm not even sure they are) since first : they were both from an era where the rules might have been different or simple unclear on this. And second : they had been accepted back then either way, and the lost time had been accounted for in their final time. But this won't be the case for any of the new runs. [Done, after only 4 days of waiting]

Just as Lunatea's Veil, here's a thread dedicated to those very old Balue's Tower records.

1:42.03 (with clock abuse) 2007

1:45.51 (without clock abuse) well that one isn't really old, but it's still noteworthy

I remember the second one being overall a tiny extra bit faster than the execution of the 1:42.03, but that doesn't mean it's much harder to beat back because of the new strats and game knowledge

Downloaded the second one as well.

Edit : Well I downloaded the Nico one after learning how to. When it'll go down, I'll upload mine

Title says it all. This is just a thread to quickly find these very old (2007 !) videos again.

Chamber o' Fun 1:01.55 &

Chamber o' Horror 1:43.55 (couldn't find a youtube upload)

I also personally downloaded the Fun video.

Edit : Well I downloaded the Nico one after learning how to. When it'll go down, I'll upload mine

This thread is mostly just to make official the fact that an IL section of this game has been created. Have fun illing !

Of course, this remains open so you can ask questions about it, report issues or suggest ideas, changes.

[Edit 17 april 2023 : thread renamed from "Banning the usage of pausing for extra vision running" to "About developing the leaderboard". This will now become the main thread for leaderboard discussion pertaining to Klonoa : Door to Phantomile.]

Since Balue's Tower is using the in-game time as its main timing method, it's completely possible though unlikely that people use the pause function of the game in order to either take an undeserved break, or use it to make hard tricks easier or to spend time perfecting their movement without any penalties on their overall times. This would go against the spirit of the challenge. It's similar to the Minecraft pausing dilemma. And I don't think anybody will mind not being able to pause during ILs attempts.

As such, I currently stand in favor of its ban, but I want to make sure we're in agreement before I push anything through.

Hi, I would like to report a small inconsistency with one of the notification templates.

One user in one of the game I moderate was given the verifier status by a super mod. However, the notification message states that they were added as a "moderator", see images.

https://imgur.com/a/R4CURzM

I wonder if this can also happen with the super mod status, might be worth a look as well

A new trick about loading times has recently been brought up. For what I know, it's only possible to use with duckstation, and retroarch/beetle.

It consists of changing the emulated disc reading speed. Increasing it causes loading-times to charge faster, much more than was normal disk speed allows for PS1 emulators. It would even be fast enough to stand a chance against the likes of Namcollection and PSTV, though there are no estimations. Despite this, we must put a limit to that disc speed, as it must not yield faster loads than that of consoles, to avoid unfair advantages. Thanks to Amoser who conducted tests, we came to the conclusion that the disc speed should not go higher than these numbers :

• 2x (quad speed) for duckstation
• 4x for retroarch/beetle.

Now there might or might not be side-effect gameplay issues that could warrant an automatic ban. But so far, no issues have been reported, and one run (done by the same person who did those tests) has actually been completed using this functionality, without any problems (). So we can't say for sure, and this def need more research in general, but it's not a bad start. Worth mentionning that this has apparently been accepted for other games such as Rayman original, Twisted Metal 4. Though each cases are, needless to say, completely unique.

Anyways, this thread is mainly to discuss if such a practice should be allowed for leaderboards runs. It could be a nice quality of life for those runners, and a nice way to mitigate the main downside of emulation. But you tell us. If it gets allowed, we'll make sure to ask for clarification when people use it in the submission description. Perhaps, even create a whole separate column of information based on that difference (so that it is easier to find).

The final verdict will likely take place during the 12th of this month.

[Edit : disc speed numbers are now in correct order]