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

Well, this is the rules for our particular board, it doesn't have to be a world encompassing measure, and people as just as justified to define stuff the way they want, or even create completely different leaderboards elsewhere. We can't be tyrants even if we wanted to So there are no fundamental reason why we can't do as we please, which here, would be to be consistent It's also not like we make our times incompatible with those outside the src community, especially so if we apply those changes I mentioned earlier

And I definitely get what you mean by the ambiguity part. But unfortunately, the situation is already very confusing as it is. What you think is the old "world record" 1:42 is actually a run that uses the clock trick exploit, which some players might feel is illegitimate (which is fair, as we're "cheating" the clock and skipping portions of the stage). Also they're playing with a controller while I did so on keyboard. To me both play differently enough that I consider both of our times simply not being compatible. And some people, again, might not find much value in runs not playing on the official means of inputs (much as emulators aren't always appreciated as their real hardware counterpart, depending on the games. As an anecdote, when I had uploaded my 1:47 on youtube, it's made its tour on the server. While it definitely was of a shock to people, a couple weren't exactly enticed with the fact it got achieved on emulator).

As you can see, the real "world record" of Balue's Tower can very well be a ton of things. Which is why the term should probably not be excessively employed anyways (also because the term lost a some of its actual worth. It's easier than ever to get one, due to the popularization of speedrunning). First place is a much simpler and safer term in general

What would you consider is the legit, pristine world record setting ? I'd personally say, original game played on original console and controller, that neither uses any clock tricks nor pauses. Following this, I think the record would still be detained by this person . NOT the 1:42 time

So yeah...

Oh, the IL idea goes without saying. You just illustrated it perfectly. It's honestly a barely explored area. I'm all for adding it, but we're gonna need to determine how to time them first before doing anything else

The time can "easily" be improved to a sub 40. Which I would've already gotten if it wasn't for a mental block on the hardest trick... Relax though, I'm not gonna allow myself to spend any amount of time near the one I have to get my any% time. Actually if I like can't beat it within 30 minutes it'll probably be the end of it to me cause I'm just so much busy

Edit : Did a short save-state attempt, it's possible to get sub 2 min (using the second clock trick, though... not entirely sure if possible without)

Sure, one sec

Done. There might be a day where we add normal vision ILs, and when the day comes we might have to change the way the Extra vision is set up like, following the way the timed extras of EoD are managed. Switching to RTA timing for instance, but keeping the in-game time as additional board info Might also make it so you're allowed to pause again

Be sure to send something decently good there otherwise I'll come in and show you how it's done :evil_grin: