Hello, I'd like to request the current supermod ("Bubble.") of the Outland leaderboard be removed and for me to be made a supermod. https://speedrun.com/Outland

Currently the other moderator, Pentaleks, is active in verifying runs, despite not running the game actively. He's happy to accept someone else to either be mod along with him or take over his position, but as a non-supermod, he doesn't have permission to do that. I reached out to the current supermod, Bubble., yesterday to see if he'd be willing to transfer ownership of the leaderboard. However, Pentaleks informs me that even back in 2016 Bubble. was inactive on the site, and Pentaleks had to reach out to an admin to get moderator status at that time. (Presumably, there's a record of that in this thread somewhere.) Given that Bubble. has not resurfaced in the nearly 3 years since then, I don't see a reason for them to continue to retain supermod status on the leaderboard, so I'd like to just expedite the process and replace them now.

(edit) Should also note that Bubble. has not logged onto the site since 2017 and hasn't submitted a run since January 2016. https://www.speedrun.com/user/Bubble.

Here's a screenshot of some Discord conversation between Pentaleks, Covert_Madness (another Outland runner), and I about this:

Since there was unanimous agreement on banning pre-run menu storage, we've gone ahead and made that change.

As far as videos are concerned, the discussion here seems pretty consistent with the opinions expressed on discord - one person feels that we should permit text-only submissions, and everyone else basically feels like there's no impetus to change. As such, it doesn't seem super likely that a change is justified. However, if anyone would like to express further thoughts, feel free.

Thank you all for your feedback. Based on this thread and the discussions in Discord, we settled on the following changes:

Any%: everything is allowed, including all forms of menu storage. (No, not jaunting.) Any% no MMS: new category, core duplication permitted, main menu storage prohibited. All Story Levels: main menu storage prohibited, otherwise same rules as before.

We've restructured the leaderboard in line with this categorization scheme, and also took the opportunity to merge NG and NG+ leaderboards for the same goal as subcategories. Any% runs which did not use main menu storage (including all historical runs from before the discovery of menu storage) were placed in the corresponding any% no MMS subcategory. Any% runs which did use main menu storage stayed in any%.

No changes have been made to all story levels runs, even those which did use main menu storage prior to the ban. We can continue the discussion on how these runs should be handled, but since confirmation storage is now permitted, the times are beatable and therefore we feel it's not necessary to invalidate all of them. We're open to the possibility of adjusting the times if the community supports that.

Unrelated to the big menu storage discussion, two other proposed rule changes have come up. This thread is for discussing these proposed changes.

BANNING PRE-RUN MENU STORAGE

The proposed change is to ban storing any menus before the start of a run. This makes it so that actions in one run can't affect a separate run, except through the intended New Game+ mechanics. This topic wasn't included in the other menu storage thread because it seems non-controversial.

This rule change will be implemented on August 7 if no one has any objections.

VIDEO EVIDENCE FOR SUBMISSIONS

This point was a little more contentious. A request was made to exempt some run submissions from the video proof requirement. The argument is that for runs below a certain rank threshold or time threshold, there's not always a vital need to absolutely ensure the validity of such times.

That said, we have had the current video requirement in place since the speedrun.com leaderboard was created in 2014. It doesn't seem to have caused much of a problem in the past, and recording your runs continues to become easier. This doesn't necessarily mean that no one has been affected by this requirement, though.

Unless there are strong arguments in favor of this proposal, no changes will be made.

Here are my thoughts:

• Any% should remain any%. Everything is permitted, including all forms of menu storage.
• ASL should ban main menu storage, including the HG cutscene skip. It's too ambiguous to try to permit one form of main menu storage but not others.
• I am ambivalent about confirmation storage in ASL. I generally don't care for tricks that obscure the gameplay completely, but the amount of time this would be used isn't enough for me to say I would never agree to allow it.
• I'm not totally sure we should bother creating "any% no main menu storage." Generally, I don't like to just split a category into two categories on the basis of a single trick or class of tricks. That said, this trick certainly results in a very different speedrun route, so the categories at least wouldn't be that redundant. I am most open to change my mind on this point.

Recently several new skips have been discovered in Bastion, all centering around the ability to "store" menus to use at a later time. The purpose of this thread is to determine whether these tricks will be permitted or not permitted in our various categories, and whether or not new categories should be created. Even if you have previously shared your thoughts in the Discord, please repeat them here so we have a formal record.

WHAT IS MENU STORAGE?

Bastion's user interface does weird things if you perform two different interactions with it on the same frame. Most commonly, on the main menu you can mouse over the "Story" mode option and press Escape and Enter simultaneously. The Escape action causes the game to send you back to the splash screen, while the Enter action loads the Story mode menu. These events both occur, so that you now have two menus open. Other menus in the game may be stored (effectively, duplicated) using similar techniques.

TYPES OF MENU STORAGE

There are three known types of menu storage that are useful to speedruns:

Main menu storage: as described above, you can duplicate the main menu by pressing Escape and Enter simultaneously while mousing over the Story option. If you are able to select "Story" > "Continue" while already in the game, you will be sent back to your respawn point from wherever you are, with any progress you had made preserved. While you are in this state, the main menu completely covers the screen and you cannot see gameplay at all.

Main menu storage with no background: this involves a more complicated setup than normal main menu storage. Exit your game, duplicate the main menu, select "Continue", then duplicate the main menu again. After you load into the game, wait until the Kid falls to the ground, then click "Continue" and after a brief moment press Enter. The result should be that you have the main menu covering the center third of the screen, with the sides both visible. This setup does not work in all circumstances and we're still researching why it works.

Confirmation storage: when leaving the Distillery with empty spirit slots, the game will want to ask if you are sure. Before it displays this confirmation, if you simultaneously click the Continue button and press Escape, it will present two confirmation screens. After confirming one of them, the game will allow you to move freely while keeping a confirmation dialog visible. While you are in this state, the entire screen is partially obscured by the transparent confirmation screen. This can remove certain affects applied to the Kid.

SPECIFIC APPLICATIONS OF MENU STORAGE

There are four specific applications of the menu storage techniques described above:

Hanging Gardens cutscene skip: after Hanging Gardens, you can set up main menu storage and "Continue" once to start the cutscene, then again to cause the game to skip. This saves around 8 seconds and is already known and used in all categories.

Tazal Terminals slowdown skips: confirmation storage can be used in Tazal Terminals to remove the slowdown effects applied on the last two screens of the level. You can use it on the Battering Ram screen to restore your rolls and exit without picking up the Ram; or you can use it on the last screen to regain normal speed, at the cost of taking triple damage. The former skip is thought to save around 10-20 seconds, while the latter saves around 40 seconds. You can do both slowdown skips, but storing two confirmation screens almost completely hides the gameplay.

Partial level skips: after picking up the core in a given level, you can "Continue" using a stored main menu to return to the Bastion with the cores still in your inventory. This saves varying amounts of time depending on which level, but requires you to reach the core with the center of the screen covered by the main menu.

Wharf District duplication: the same principle as partial level skips, but applied in the Wharf District area. Since you haven't reached the Bastion yet, the game respawns you on the same screen when you "Continue" instead of sending you to the Bastion. Again, requires you to play with the center of the screen covered by the main menu.

WHAT'S THE BIG DEAL?

Menu storage is kind of a Pandora's box, and there is great potential for it to alter our various categories in ways that makes them significantly less fun or less competitive. As an example, the fastest route might involve completing Wharf District 7 times, then finishing the game immediately. Even with less repetition of Wharf District, there's still a lot of potential for playing the game with the majority of the interesting action covered by the main menu. To many people, this doesn't seem particularly fun to play or to watch.

DISCUSSION SO FAR

These summaries are NOT intended to suggest we have already reached any decisions. They are simply summaries of discussion which has happened. All of the below topics, and any others you may think of, are available for discussion in this thread. Please share your thoughts accordingly.

Pure any% category: so far the community has generally expressed support for at least one category which permits all of the tech that we know about, including all forms of menu storage. It seems to make the most sense for this category to be called "any%" - complete the game as fast as possible with no restrictions.

"Old any%" category: several runners expressed a preference for keeping a category which more closely resembles the current any% route. One such proposal would be to create "any% no main menu storage." On the one hand, this category might be more popular due to not involving effectively blind movement. On the other hand, it might simply stagnate. There's also a question of how older runs would be categorized. Additionally, "no main menu storage" would invalidate and obsolete effectively all of the top end runs in the current any% category. However, maybe that's not avoidable?

New intermediate category between any% and ASL: at least one runner proposed that the gap created in the absence of the current any% route could be filled via an alternative category, e.g. All Weapons or The Culture. So far these categories have not achieved much traction yet, but perhaps they'll pick up as any% gets shorter and shorter.

Ban partial level skips in ASL: the majority so far are in support of prohibiting partial level skips in ASL (via unspecified rules changes). Such skips are generally seen to go against the spirit of the category of completing all of the stages in the game. That said, banning specifically these skips without banning other forms of main menu storage could result in needlessly complex and confusing rules, creating ambiguity later on.

Hanging Gardens cutscene skip in ASL: banning one form of main menu storage in ASL may necessitate banning another form of it - the HG cutscene skip. Many runners expressed disapproval for banning this cutscene skip because everybody uses it, and all such times would either be invalidated, require grandfathering in, or need to be retimed according to some rule. None of these options seems particularly enticing. However, it might not be straightforward to craft an understandable rule that preserves this skip while banning partial level skips.

Keep Tazal Terminals slowdown skips in ASL: so far the general consensus favors allowing confirmation storage in ASL to permit TT slowdown skips. These skips do make the final stage somewhat difficult to play and watch, but they are generally seen as a cool new routing development and a legitimate method of going fast without violating the category's spirit.

I am mostly swayed by Sigma's and Hetfield's arguments, but I do want to raise a point about the nature of the thing we're discussing that I think is somewhat missed. The following is just copy-paste from some stuff I posted in the discord earlier:

[quote]Input devices are weird and the entire genesis of this discussion I think occurs because scrolls wheels are actually special and different Keys and buttons have distinct states of up, down, and held that games look for to determine whether to do a thing So our model for understanding these is basically, as long as the human is holding down the key/button, actions can be occurring - and we draw the line at, things shouldn't happen after the key/button is released Analog sticks are special and different because they don't actually provide an input event to the game the same way - instead, the game polls the analog stick position and decides a thing to do based on it (almost always movement, but in the case of bash for example it's aim) Mouse wheels are special and different because there's no button up event - just a series of repeated button presses And games handle this sort of thing very differently In Ori's case, it just straight up doesn't handle it, it doesn't even poll or look at the mouse wheel as far as we know So given all this, the reason I look at the scroll wheel with a questioning attitude is that we have to use software to transform those mouse wheel events into a completely different kind of event to get the game to register it successfully And of course, we have seen that since the transformation isn't perfect, if you do as Eli just mentioned - unlock the wheel on a G502 and scroll forever - you'll just start charging up charge flame instead of actually shooting So there is sort of a frontier being opened there when you say that that particular kind of remapping is allowed - it's a little special and different compared to other kinds of remapping[/quote]

(To add to these musings - another game I run, Bastion, has direct support for binding the mouse wheel to any of its functions. At runtime, each frame it checks to see if the mouse wheel moved during the last frame. If so, it considers that to be a "button pressed" event. This allows you to attain every-frame button presses as a first class function of the game. Ori doesn't have any similar support, so we have to use external software to turn the mouse wheel scrolling into something that "looks like" you're pressing a key.)

(edit - Actually I realize part of what I said in there is misleading/wrong. Actually the scroll wheel doesn't really provide inputs, it's just another axis of movement. Software can poll to detect a change on that axis and use that to trigger some event. Most scroll wheels "click" so it looks like discrete inputs, but it technically is just another axis, more like the analog stick than anything.)

That said, I'm backing off advocating for banning, as it seems like the arguments for banning don't support the likely cost to the community. On the one hand, we can take guidance from other competitive communities, some of which do ban things like this (with valid justifications). On the other hand, we're not talking about an unfair competitive advantage - that is, anybody has access to use a scroll wheel, they're not specialized or expensive hardware. We're talking about something that, to some of us, violates a spirit of speedrunning. But that said, speedrunning is primarily a hobby for fun and community, and maintaining the status quo here seems to be consistent with supporting those things.

I strongly, strongly recommend against using Steam's rebindings. It will introduce massive input latency and drops.

If you have some other method to remap your buttons, yes, that's permitted for both versions of Ori, as long as you don't create macros (i.e. any inputs have to happen only when you press a button, not later). That said, if you're trying to recreate the KBM method of having two C key binds, hold one and tap the other - this unfortunately does not work with the controller buttons.

As an aside, vanilla Ori is pretty dead at the moment - I would suggest picking up Definitive Edition if you can and trying that run instead. It's far more active, so there's more folks to help you out, and the new mechanics make double bashing significantly less important.

Seems like there was pretty clear consensus on this one, so we will not be changing the category definition. I'll lock this thread, as it has served its purpose.

We have added Glitchless Any% as a miscellaneous category on the leaderboard. The rules used are those from my definition above, plus door warping and rocket jumping are banned. Clipping through the narrow gap in Sorrow Pass is still banned.

Feel free to use this thread for discussion and feedback.

Door warping didn't exist at the time I made the glitchless rules, but it would definitely be banned. I'd personally consider it a "major" glitch as well.

Question for discussion: what glitches should we consider as "major" glitches for the purposes of defining a "no major glitches" category?

After some chat on Discord, we determined that there was some interest in creating a possible "no major glitches" category for Ori. However, in order to do this, we must reach some agreement on what constitutes a "major" glitch. The overall goals of this category are roughly as follows:

• Provide a less "broken" category of the game for people who want something closer to the intended experience.
• Provide a category that is substantially distinct from other categories of the game.
• Provide a category where movement optimization and basic gameplay are highlighted more than specific tricks.

In order to achieve these goals, some glitches will be disallowed. The question is, which glitches will we consider major? To start the discussion, here is a list of glitches which are and are not disallowed in my "glitchless" category. This is NOT a list of rules for the proposed "no major glitches" category.

DISALLOWED:

• Save glitches (saving and reloading to skip or regain control during a cutscene)
• Save anywhere (storing the ability menu and learning an ability to save without a Soul Link)
• Save drops (saving in midair to respawn Ori on lower ground)
• Teleport anywhere (storing the teleport menu to teleport without a Spirit Well)
• Keystone duplication (dying at a specific point to cause keystones to respawn in the world and in your inventory)
• Double bashing (performing two bashes two frames apart on the same enemy to follow it in midair)
• Out of bounds (anything that places Ori outside the clearly defined physical boundaries of the game world)
• Clipping through any solid object or boundary
• Using Bash to pass through the small gap in the rocks in Sorrow Pass

ALLOWED:

• Bash gliding (preserving the horizontal speed of a Bash by releasing all directional input)
• Dash gliding (same mechanism as Bash gliding, but with Dash followed by a jump)
• Disabling the UI (press alt-U)
• Moving enemies into advantageous positions using normal movement or Bash
• Using enemy projectiles or something other than the intended means (e.g. Stomp) to break a barrier
• Manipulating a level up to achieve a timely health/energy refill or damage enemies

It seems to be generally agreed that save glitches (i.e. using Rekindle or learning an ability to regain control during a cutscene) should NOT be considered a "major" glitch. However, please feel free to share your thoughts on any and all of these glitches. "Just go all the way glitchless" is a valid response.

Question for discussion: should the "all skills no OOB" category be changed to permit out of bounds and clips?

After some chat on Discord, we determined that there was some interest in creating a possible "no major glitches" category for Ori. At the same time, in order to differentiate all skills more strongly from this new category, we considered the possibility of changing "all skills no OOB" to permit out of bounds.

In answering this question, it is probably worth considering whether the resulting route would actually be substantially different from other routes of the game. For example, it's possible that permitting OOB might mean that the fastest way to beat the game is to return to Ginso at the end and OOB from there to the ending, as in any%. This might actually make the category worse. Of course, you may have other reasons why you feel this change should or should not be made.

"Don't change things" is a viable answer. If enough folks feel that the category is fine as it is, then no changes will be made. NOTE: teleport anywhere will be allowed in the category either way.

Yes, Brynhold, fronkey walk is allowed.

Okay, very slow follow-up, but thanks for all the thoughts everyone. In the end I decided that it's not currently worth pursuing an official glitchless category. However, that's not going to stop me from running such a category myself and just tracking my PBs, because I think this is the only way I'm still going to enjoy running this game.

Anyone else is welcome to invent their own arbitrary category, or you can follow the rules I'll be using for "glitchless", which are as follows:

• Save glitches are banned. (i.e. saving to skip a cutscene/event trigger)
• Save anywhere is banned.
• Save drops are banned. (i.e. using a save point or save anywhere in midair to drop Ori)
• Teleport anywhere is banned.
• Keystone duplication is banned.
• Double bashing is banned.
• Going out of bounds is banned.
• Clipping through any solid boundary is banned.
• Using Bash to pass through the small gap in the rocks in Sorrow Pass is banned. (just because it's ambiguous as to whether or not it could be considered a clip)
• Bash gliding and Dash gliding are ALLOWED.
• Disabling the UI is ALLOWED.
• Using the level up explosion to intentionally deal damage to enemies or objects is ALLOWED.
• Moving enemies around using Bash or normal movement is ALLOWED.
• Breaking walls and doors using alternative methods (e.g. enemy projectiles or Stomp) is ALLOWED.
• If a glitch or glitch-like trick isn't included in the above list, it is presumed to be banned.

Thanks for all the thoughts so far. I'm not going to be able to put much thought into this for the next week as I run RPGLB, but lots of people have given really good feedback on this. I'll respond with more of my thoughts when I get back. :)

There is no glitching involved in frog walk - it uses intended gameplay mechanics (enemy aggression, the Magnet ability, and the energy refill from leveling up) in a novel way to sequence break the game. The route will be substantially different regardless of frog walk (you will have to do all of Horu, for example), so personally I don't see "let's change things up" as a great reason to ban it. Iceless should also not be banned.

Double bashing, I understand if there will be some disagreement about this. My personal view is that double bashing is just a highly optimized use of a movement mechanic, consistent with the rules of its use. It's something that even a casual player can do accidentally, though they probably won't realize how to use it to their benefit. Much like with iceless, I also don't believe we should ban a trick just because it is intimidating to new players. There are tons of alternative strats available for every spot where a double bash is used in top level runs - what we need to do is properly educate people that these alternatives exist.

Leaderboard moderators who verify runs are expected to actually watch a run to verify that it adheres to the rules, yes. This applies regardless of the category.

Hey everyone,

A few conversations in people's streams and in Discord have led me to believe that there's sufficient interest in a "glitchless" category to warrant finally introducing one. The intent of this category would be to limit the use of unintended mechanics to those which are simply extensions of available movement options in game. Here's my proposal for things which would be banned under this category definition:

• No use of Rekindle or learning abilities to skip cutscenes.
• No storage of menus (i.e. save anywhere/teleport anywhere).
• No use of save drops.
• No duplication of items.
• No clips or out of bounds.

And here's a proposed list of things which would ¤not¤ be banned under this category definition:

• Disabling the UI.
• Bash gliding and dash gliding.
• Double bashing.
• Moving enemies into advantageous positions using normal movement or bash.
• Using enemy projectiles or something other than the intended means to break a barrier.
• Manipulating a level up to achieve a timely health/energy refill or damage an enemy.

Here are some specific tricks that would ¤NOT¤ be banned. This is not an exhaustive list, i.e. there might be stuff I forgot to include that would still be allowed:

• Frog walk
• Iceless
• Ginso corruption skip
• "Stompless" method of breaking the rocks above Kuro's head
• All forms of Sorrow Bash except the ones that involve save anywhere
• Both variants of frog juggle

So here are the two big questions:

1. Do you believe this category should exist/would you run this category?
2. Do you agree with the proposed category rules? If not, what modifications would you suggest?

(edit: emphasized that the list of tricks is stuff I would ¤NOT¤ ban)

You guys will want to discuss these things in the DE leaderboard forum, over here: http://speedrun.com/ori_de/forum

Thanks for taking us into consideration - we had venue stuff to sort out before we could announce dates. Good luck with NASA!