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

We just discovered a very weird and rare final boss behavior that makes it so the dealt final hit won't immediately end the fight. No, King of Sorrow stays alive and fully active with his enemies for the duration of a whole second :

This is concerning because of the current timing rules. They state that the fight explicitely ends on that hit, meaning that we could finish the run, even thought the boss isn't completely done with his stuff and is still dangerous. Unsurprisingly, everyone in the Discord who gave their opinion on this were not okay with it, so a change was necessary.

Thankfully, this strange case is easy to deal with as it is. We simply have to tweak the definition of the end point of the run, so that instead of on the final hit, it ends on the first frame of the flash effect the boss emanates (or alternatively on the first frame of the enemies disappearing), since this is the true end of the fight (at least if you don't get a frame-perfect death, which unfortunately has happened to some)

As such, I'll very quickly change the rules with this. And correct the runner's time by adding a second. (done)

A couple precisions about the high limit of the usable emulator disk speed. Use these as reference for this specific post : (1) (2)

With the assistance of amoser and Ettie, we made some tests about speeds higher than 4x, to see if they can be used while still being slower than the fastest console counterpart, PS2 + FDS (PS3 is slower).

What we didn't expect to find, and that definitely slew things us down a little bit was a previously unnoticed emulation inconsistency during the character loading-screen of a match. Normally, when the loading-screen appears, the loading text is supposed to flicker slowly, and there is a fade-down at the end, transitioning to the match. But on certain emulators (ePSXe, Duckstation, psx/psxfin are generally concerned as far as we know), this is not the case. The loading text will freeze, and there are no fade-down animation, it instantly cuts to the match. Ultimately though it doesn't bother us very much for what we were trying to do.

Now, as emulators are generally infinitely slower than PS2 FDS (see (1)), there shouldn't be problems allowing them. But this isn't about them.

Anything up to 4x works fine and is slower than FDS (both emulators are basically equal on this). But as seen in (2), when it comes to 6x, both emus go faster than it. Therefore, we can't allow them to be used. (The emu stutter at the end of the Retro clip doesn't happen on lower speeds*, probably unimportant)

This doesn't change anything about the rules or what's currently in place.

Some minor questions about the emulation inconsistency remain to be unanswered. We do not know if it happens on an actual PS1, and inexplicably, why it's also apparently a thing on PS3 (see Haru's obsoleted run). If this first wonder is actually real, it would prove that this emulation error isn't one, shockingly enough.

Read the Duckstation / Retroarch through Beetle core emulator disk speed discussion thread, and amoser's guide for setting up those emulators for further information about them that are pertaining to this thread. https://www.speedrun.com/klonoa1/thread/tndcp https://www.speedrun.com/klonoa1/guide/hjy9m

Much like DtP, this game's loads are also affected by PS2's Fast Disk Speed setting, as well as these two emulators's enhanced disk speed. And given submitted runs of this game have already made use of them, I found it necessary to begin tracking them using variables. It simply is for the clarity of information.

This thread and change are mostly justified by the following : while we don't have exact numbers for all of those cases, Ettie has noticed some significant advantages with them - by the order of at least a second per loading-screens - enough to justify tracking those thing seriously.

Rest assured, this decision doesn't change anything about how the game is ran or timed. I was originally going to push this without the community's opinion, cause I had thought this wasn't relevant enough that it would require it. But I still brought it up on the server while writing this, and the reception doesn't seem bad so it's probably fine. And reverting the changes would only take mere seconds anyways.

Only new thing is that - in the case you play on those emulators, or PS2 - you are now strongly encouraged to show trace of this setting somewhere in the footage of your run... but it's in no way mandatory, as people may forget about it (this case has happened with DtP). Rejecting runs solely because they don't show it feels very wrong imo. I don't think we are any worthy of being this strict with moderation when our community is nowhere near big or professional to justify it.

Following this opening post, I will make the technical changes, then add its rules in the main panel section, and finally update some of the current runs with these.

One day this board might also see character variables. Looking forward to it.

[Edit : I should mention that FDS loads are faster than the emulation disk speed enhancements, and that going any higher than the allowed amounts ("2x (Quad Speed)" for duckstation, "4x" for retroarch/beetle]) result in crashes (courtesy of Ettie). So, no issues there.]

[Edit 2, 15 february 2021 : updated most of the runs !]

In preparation to setting up this system with Klonoa Beach Volleyball, I've revisited DtP's system and rules. Currently tweaking them a little bit. I've mainly added cases for when you don't use FDS, and other disk speed settings for the two special emulators. Also changed the wording a little (as a recall, these rules now belong to the main rule panel).

I might do a quick tour and update some of the recent runs with these variables (mostly using the --- one), for information clarity.

Tomorrow I'll probably rearrange the rules and put stuff into the main rule panel, as I said I would have liked to do. (done)

That effectively answers my gripes.

Well, to be fair, another thing that helped me change opinion might be that, since their birth, I always had a picture of the current gameplay restrictions rules standing like "just don't perform x, y, z... and you'll be fine". Literally child's play to know how to play the game. But claiming that this view is an accurate representation of how the rules really look like right now would be a lie. I, probably along with Elsiz, might be the only person with this mental image of the rules, because we were closely involved with the design of glitchless/no skips in the first place. In other words... this isn't the norm at all. And in that sense I can understand people would be more inclined to feel a little uneased playing the category, knowing the outlines of its restrictions and its way of play is all so unfamiliar, blurry and unwelcoming...

In light of this realization, and that your proposed changes would basically stand as means to simply refine the rules to get rid of those concerning side-effects, as it is, I don't see how or why I could be against that.

Oh, I didn't know you also planned on rewriting all the other smaller rules lines present in the panel. If they are agreed upon at the end of this, we'll have to standardize all rule panels with them

It is pretty dense and overloaded as it is, especially in contrast with the other rule panels (even if they can't be compared), but imo I don't think it can be helped much fundamentally. We will most likely do a general rule text reorganization soon afterwards, moving ubiquitous stuff like "run requires video" or the "disk speed" bit in the main rules panel, all in order to significantly reduce text overload, so it'll appear better.

It's a very hard one, as it serves the purpose of explaining the foundation of no skips some more, in a clear and formal manner, but also suffers from being complicated and scary looking. Doesn't it run the chance of confusing/tiring people away from it ? (I don't have the answer to that question)

Maybe we could do a tl;dr in the rule panel of the category, and link to this thread for the complete rule text. Like, "Formerly known as Glitchless. Beat the game without using glitches or other tricks to skip meaningful portions of the game. here's link to full rules (https://full rules). tl;dr : don't use list the skips that can't be used if you have doubts about something, make sure to aks someone "

Cause honestly, even though it would cover the category very nicely, I don't think the vast majority of people will ever be concerned with all those situations, so we shouldn't bother them will all the full thing ...welp, what I just proposed is literally not putting the text you wrote in the rule panel but keep it here instead, huh It's also pretty unorthodox, and I don't know if it is a well appreciated practice (again, don't have the answer).

I don't feel it was particularly hard to manage no skips runs before. After all, we've never had any submissions problems related to what your rules are trying to prevent. And then, I feel that us as reviewers of DtP would easily be able to morally pardon or rule out a run that does these things by the mere hand. These are like obvious unspoken rules of conduct.

So in the end I guess I'm still pretty conflicted about it's actual relevancy and usefulness. Not exactly fully against it, and if that's what people choose then I'll be more than happy for it. But, aside from the look of it, I think it was pretty fine and innocent as it was before.

Well that's it then. I think that removing 9. and the bit that's after explaining what the category stands for (as they are either obvious or negligible information), and keeping the rest for the category rule panel would be good

That's at least my opinion for now. I'm open to any differing statement or mistakes for the time being. And looking forward to what others have to say.

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 !)

This map viewer that Raycarrot has recently developed completes my unfinished work perfectly. Strongly recommend checking it out ! https://raym.app/maps_r1

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 !

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

Thanks to the contribution of Bobbykaze, and after some reconsideration, here's a much needed update to this post :

PSP and PSVita are now allowed. With them being official ways to play the game, there really was no reasons to reject them, even if they might not as stable as other consoles.

And now, about that. This is where Bobbykaze steps in. He played the game on all consoles linked to PSN, but also PSTV (we'll see why later). And along his vast gaming and console experience, he helped us get a much better look at these consoles, for which at first glance, might look irrelevant.

We'll begin with PSP. Yes, it has a couple crash spots :

• During the world map screen, with the Ngapokos flying up and firework being set off, the melody in the background glitches a little bit, and a random Wind Ring firing sound plays. That behavior almost systematically causes a crash the moment it plays. Thankfully, it can be avoided by simply pressing onwards. ( & ().
• Right before the Pamela fight cutscene begins, so when the screen entirely fades to white after loading, the game can just hang indefinitely. Unfortunately, as far as we know, this one is both likely and unavoidable. This, right before a pretty RNG section of the game... not a very enticing console to play on then. But obviously, it'll remain allowed, as not getting any crashes translate in having a perfectly normal and healthy run. () BUT. Bobby showed to light that these issues don't happen on the Japanese version. So you might want to play on that. () Also, it's not quite the original Japanese version. The Karal cutscene different test showed it was more akin to the Family version. (). More testing would need to be made, however. Could be its own different thing.

As for PSVita, it is reported to be devoid of these crashes.

But now for the shocking revelation...

Both of these have loads THAT ARE ALMOST JUST AS FAST AS PSTV, WHAAAAAT. Without input lag too ! ...Wow. Well, guess they suddenly aren't useless anymore, huh. To say this was in front of our eyes. And we were considering banning them...

On the other hand, we learn that PS3 has a rather bad time competing. This isn't necessarily a very telling comparison, but Bobby insists that it's the same deal with boss and book loading-times ().

So yea, what a gift. These consoles, plus a cheap version of the game, seem to be a very reasonable way to run. So don't ever neglect them.

Besides, they might have other secrets we don't know about. Could the distributed game versions of PSN stand out from the originals ? Is there talk to be made about other crashes, glitches ? We'll never know for sure without playing them extensively. Granted, that's a treatment that still has yet to be given to basically any other versions and consoles for DtP, aside from PS1 and USA, my field of play and research for years.

Will update the main post with the new regulations later. (done)

Update, what Amoser said from Discord :

" Right, so I should probably mention that, for the fast disc speed, we've tested RetroArch with the two Beetle PSX cores, and we've tested the standalone version of DuckStation... but someone has actually ported DuckStation to the Libretro framework, so it's also possible to use RetroArch with a DuckStation core. We haven't tested that particular configuration, though.

So if you can, I recommend sticking with either the standalone version of DuckStation or RetroArch with Beetle PSX or Beetle PSX HW. That said, if there's some significant benefit to using DuckStation as a RetroArch core, it wouldn't be a problem to test that out; as far as I know, though, it still has some limitations compared to the two configurations we already allow.

(Although in terms of load times, it's probably fine, since reading from the disc should be exactly the same code as in the standalone DuckStation, but I'd hate to have a run be invalidated in the off-chance that doing it this way turns out to be a tiny bit faster than real hardware, or something like that) "

So this setup won't exactly be allowed for now.

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.

Had to make a couple technical changes and updates. Namely, extra 3 doesn't have any gems in it, so it can be considered like a normal stage. I created two sub-categories for extra 1, each with their own timing methods. Rules have also been updated to accomodate for this.

I've also realized that every boss and extra 3 have the 100% tab available. I do not know of a way to limit this, as it probably is a limitation of the website as a whole.

I mean, I would never disagree with you, IGT is the superior way to play this stage. Game versions, console setups don't matter as everyone would be on the same page.

The problem I believe we're discussing is the complicated case of adding Balue's Tower as an IL amidst the not-yet-created-nor-defined ILs of this game. Cause there clearly are two ways to go on about implementing it, the IGT or RTA way.

The former stays true to the stage's legacy and roots. Just record the run and it's done. Basically what it currently is. Timing it the other way would break its soul completely, on top of the added run time consisting of loading-times, cutscene skips and door entering. Wow fun material to play with.

The only upside is that it would be handy for 100%NG+runners (or non-existent categories like all visions, for the any% part) because they could then directly compare their full-game performance to it. And ideally, the way it is played in a full run would be compatible with its ILs variant. Which was my idea behind consistency argument.

But Balue's Tower challenges that. You can't satisfy both timing methods in one ruleset due to its timer component. And we can't just deny the stage's IGT either.

I think we could satisfy everyone by having a Balue's Tower entry, that is divided in two branches, IGT and RTA respectively. I've just learnt how to make that work, which will definitely be handy. It sure feels a bit redundant, and honestly kind of useless, I doubt many people would submit runs for it cause it's just almost completely similar to the IL. But there'll be that area of emptiness if we leave it out, so...

I would be for satisfying both sides, but if there had to be only one, it goes without saying it'll be the IGT one. It would be headachingly wrong to not have that in our board anyways.

EoD's timed extras have the same problem actually, I'll fix that soon enough

If you want to participate to its conception, I would suggest to join in the Discord server and discuss it directly there. It's a bit more practical. Though when the offiial src forum post will get made, I'll recommend to summarize your stance or ideas there.

We can only add such big things to our board by making public announcements, which includes the server as it's where most people are (don't read most active) and things happen nowadays

Assuming we add ILs first, I'm not sure if full visions clears can be implemented at the same time, due to src's limited leaderboard setting up system that basically forces one IL setup else it will look super messy