I will still argue that the quick rolljump cancels are still indicative of this type of button mapping and not something that could be done consistently for so long otherwise. If this were not the case we would be seeing some of the top keyboard players moving in this way by now. I certainly could be wrong there but I know that others who have put significant time into the game have attempted to move in such a manner. Also, having 100% consistency for a technique absolutely gets to a point of times that are not humanly possible. Will the best run be really freaking close eventually? Yes, but not quite there.

Trying to separate rolljumps from other parts of the run as less important feels folly. Whether it is as enjoyable or not, it is as much a part of the game as everything else and even a major part of the example moving through rooms creatively. If pay-to-win is a concern, isn't that already being done by using a setup that requires two peripherals instead of one? I'm not suggesting that using keyboard+controller should be banned, as the game naturally accepts both simultaneously and is thus perfectly valid- it is however a counterpoint to consider.

Lets say for argument then that this is continued to be allowed and/or a new category is made for it. What is stopping someone from using a method OTHER than the config file to macro roll and jump to a single button? For example, I could use antimicro or xpadder to map the two keyboard keys to right trigger on my 360 controller. The end result within the game is indistinguishable and it becomes even more of an impossible to enforce honor rule to only use it as a config.ini edit than banning it would be. You could even argue that any method of binding them to one key would have to be allowed, and that becomes very dangerous ground. If a "scripts" category is set up, what stops someone from making macros for every time they have to open the menu because menuing isn't fun to them? Yes, it is a far cry from the current issue at hand, but it could be set up easily and how would THAT be enforced? The whole situation has the potential to become incredibly messy.

If nothing else, any mapping that allows you to rolljump on one hand and attack on the other is going to easily allow you to quickly cancel any rolljumps that you successfully perform, so quick rolljump cancels are still not indicative of a mapping that binds multiple in-game functions to a single keystroke. Also, unless it's expected that any top run will ALWAYS have at least one rolljump that was messed up, then this does not "absolutely" get to the point of times that are not humanly possible otherwise.

Perhaps in a way having a keyboard and a controller is already a monetary concern as you say. Even so, the difference between a keyboard and controller versus a high end keyboard and controller will become that much more marked.

As for your last example, that last bit does indeed sound incredibly messy. I imagine though that menuing macros would be enforced exactly the same way you intend to manage enforcing them if they arise as an issue now - that is to say I don't think the last bit of that point is relevant to this discussion.

All of this is very simple. The game doesn't allowed it : don't The game allowed it : try Your motivation doesn't allowed you to respect it : move on

I play on keyboard because I can map it how I want but I don't think it's so much easier, I just know that mapping rolljump on one key is desrespecfully easier than any controller or keyboard mapping. If you just decided to map because you think it's the only way to beat keyboard, because anyway nobody can verify it, because the beauty of the movement is more important than the execution I think it's pretty sad.

You should play CS:GO with a controller and use wall hack and say it's the only way to beat all the keyboard no life user.

I respect all of what you did for the community but I just know that now I can't beat you because you think otherwise you can't beat me.

I don't think this is as clear-cut or as simple as you'd like to think. Part of the reason I've shared and even suggested the config edit to people is because I don't think there's anything wrong with it. As for whether the game allows it, again that's not so clear-cut in this case. Editing the controls through the included config file still results in something that is still completely accounted for in game:

https://gyazo.com/a9eda1440a5f9a14418b6fe401641d32

In fact, I'd argue that the most out of place thing with that screenshot is that it looks like switch item is unbound. In reality it's bound to caps lock, which simply doesn't show in the controls.

People are allowed to have opinions on what they'd like to see or not see in a community or a run, or even what they'd like to have a run be about. That's part of why this discussion is happening right now.

In regards to "beating people" I think you've misjudged me. While I did mention not wanting runs to be defined by high end mechanical keyboards, the reasoning behind it is defined by my apprehension at spending a lot of money (and others having to as well) just to make a technique easier. If all I cared about was beating people I could have stopped trying to improve months ago, and I wouldn't be running NG+ or Low% categories, which aren't even on the speedrun.com leaderboards. If you want some insight on how I think, read the two paragraphs below - they're an excerpt from the end of a private message sent to halfcoordinated when he approached me about a potential ban:

Truthfully, fighting to get my character to do what I'd like them to do has never been something I liked. If the technique ends up being banned from the speedrun.com leaderboards, while I might try runs with jump bound to spacebar and roll bound to c or v so the physical motions are close to what I'm used to, I doubt I'd have nearly as much fun knowing there exists a control setup that gives me more full control over the character.

I'm having trouble thinking of a way that fully articulates this last point in words, but I'll try anyways. Speedruns to me are about self improvement and having fun. I don't really want to stop using my controls configuration – not because it gives me an advantage over others, but because I know that it makes playing Momodora RUtM feel so much more smooth and thus so much more fun to me.

I only started to attempt roll jump in the spike portion after lubella after 50h and not even all the roll jump. And that was not fun indeed ! That's the point ! Why you could avoid all this first part of learning ? There is no difficultly remaining with this it's too easy to get a good time.

Oh you know what, I hate mashing and on Frida I'm pretty bad for this. I should use an autofire. Why not ? You know it's not fun at all for me. Comfort is great.

We ask all the community, everybody desapprove except you I don't know why we continue to argue against.

First, let me explain where I'm coming from. Developing mechanical skill at your game is and always has been an important part of becoming a better gamer. This is consistent across the spectrum of gaming, whether speedrunning, playing fighting games, or rhythm gaming. Part of what speedrunners are often lauded for -- to the limited degree that they are lauded -- is this mechanical skill and ability to use all in-game methods possible to improve their play. Part of what got me into speedrunning is watching someone play a game I love -- exactly the same game! -- but using their mechanical skill and knowledge to absolutely crush it.

In this spirit, I disagree with allowing any macros that cannot easily be achieved in-game, whether this means banning autohotkey scripts (e.g., for one button fairies or menuing) or config edits for double mapping your keys. If that is the way you prefer to play, then I wholeheartedly encourage you to do so in an environment in which you can double map your keys, turbo-roll, have one-button fairies, auto-menu, script frame-perfect charge shots, or invent anything else for every portion of the game for which mechanical skill can be circumvented by way of macros or scripting. But it is unfair to have those times compared to those of runners who are using zero macros (including double mapping) or other external game edits. This is a consistent and fair way to apply the principle and, in fact, I believe this would create a very interesting run to watch.

As for enforcement, that seems to be a trivial red herring. We already rely upon the honor system for the plethora of hacks and third party programs available, and as Luna mentioned, the game is equipped to display your controls when you start a run if you merely use the config edit, is it not?

I think those are all fair points, Kaho_TV. As for your last point though, unfortunately the game is not equipped to display all the inputs it's able to assign. Guess how many functions are bound to the same key in the screenshot below?

https://gyazo.com/fb98b4f7424bb3e89e332f0f9f960e87

The answer is exactly 0, but you'd never know that because there are plenty of keys that show up blank when assigned.

Realistically, I doubt that should be a problem. I have not known very many people to use the caps lock key, tilde key, or brackets or other punctuation keys for buttons that require heavy use (as much as the jump or roll key does in this game). You mentioned yourself that you'd just rebind to c or v -- two keys that show up without issue. However, if that is a concern, then "Keymapping for the 'jump' and 'roll' keys must be visible in-game as part of the highlight or submission" is a simple rule that is easily explained, followed, and enforced.

As for exploits beyond that, well, we have a fairly small and trustworthy community of runners for this game, as well as capable mods to review the submissions. If games such as Mario 64 and OoT can manage their leaderboards without people exploiting emulators or CE, I sincerely doubt we will have a problem if we establish a clear and reasonable ruleset.

Realistically you'd have to just make it so you're only allowed to use one key that doesn't show in game as there are other beneficial combinations other than roll + jump, but you are correct that despite limiting some options that the game unquestionably allows, catching config file edits would be easier in the event they end up being banned.

I can't claim to know how other leaderboards deal with verifying submissions, and I wouldn't rely on the size of the community as a gauge for whether or not the honor system is viable - Keep in mind the number of active runners has tripled (more than tripled?) since SGDQ, and may possibly see more sharp growth increases in the future. That said, if this community is going to rely solely or mostly on an honor system to deal with whatever rules it has, as a runner I can live with that as long as the rules are clear, well thought out, and established sooner rather than later. Nobody likes putting a lot of effort into a game after being told what they're doing is fine, only to be told it's not okay later.

Sorry for basically dropping out of the conversation here. Thanks to everyone that contributed at this point!

Thinking this over I'd like to propose a couple of changes:

Mapping multiple inputs to in-game inputs becomes banned. All future runs added to the leaderboard would require one of three things 1.) an input viewer, 2.) a handcam, or 3.) stop long enough on the keyboard controls on file creation for the verifier to pause and check the controls. If multiple in-game inputs show as blank on the keyboard controls screen, burden of proof will be on the player to prove they aren't bound to the same input. If your preferred control scheme results in two blank inputs showing, input viewer or handcam should probably be present in the first place.

Next, misc categories are then created to allow roll+jump bound to a single input. For verification purposes, these categories would require showing the keyboard control screen on file creation long enough for the verifier to pause and see that roll and jump inputs ARE set to the same key (including possibly blanks). Runs already known to use this will be moved to these categories.

This should be easy enough to verify without putting undue burden on either end of verification. for clarification, the wait on the keyboard controls screen will probably only need to be half a second. Please give feedback with any thoughts and concerns regarding this potential resolution.

This sounds good to me. I think it clearly defines two different categories, as I personally feel they sound be. The verification for the no mapping input makes sense and shouldn't be hard for anyone to do.

This is mostly agreeable to me, but if we're going to set some rules, let's do it right and discuss some more topics in depth so people don't run into issues with the rules being unclear later.

First of all, a big part of the problem people seem to have with this technique is that you have to change the included configuration file to more freely rebind your in game controls. What happens if a later patch or some technique enables players to freely customize their controls 100% in game? At that point it would be unquestionably part of the game, but still against the rule being discussed here. Would runs that had multiple in game functions bound to a single input be merged back in, or kept separate because of this rule?

Also, what about changing what keys confirm and cancel are bound to in the config file? While not able to be seen in the controls dialogue in game, they can be freely changed to something that suits ease of play better through the configuration file. (In fact, by default they are set to be bound to the same inputs as other functions which vary slightly depending on whether you play on controller or keyboard). I assume that this would be the exception to the rule of having multiple in game functions bound to a single input, but would remapping those through the config file still be allowed?

I know that some people have bound functions to multiple buttons on controller using third party programs for the sake of making some tech easier. Some people in the discord groups have suggested remapping controller inputs to be emulated as keyboard keys, also for ease of use. They don't necessarily net you as big an advantage as a configuration edit, but they can still potentially give you one and are DEFINITELY outside the bounds of what the game allows since they require 3rd party software. Should these things be allowed or moved to a separate category? If the answer is “it depends” we should try to elaborate on what is and isn't okay now rather than later.

Finally, should we agree that all input methods are allowed as long as they don't enable autofire, macros, or multiple digital inputs in response to a single button's press, or are there some controllers that should be banned for other reasons? Honestly I can't think of any reason why some off brand controller or arcade stick would be disallowed other than the aforementioned reasons, but I figured I'd bring it up just in case.

Life did things and I kept forgetting to reply to this.

Basically though, what Tohloo said covers it pretty well. I had considered allowing multiple buttons for one function in specific cases for accessibility purposes, but it has too much potential for abuse and a solid rule of 1 button for 1 function per input device is best regardless of input method.

There are still two questions in my last post that have been partially addressed but not completely answered. In the event that some method is found or patched in to more freely change your controls in game, would the runs in the separate category be merged back in?

Also, should runs currently on the leaderboards that have a single function bound to multiple buttons on an input device be kept with the other runs or split off? Personally I have no issue with them staying right where they are and just letting this be a rule for the future, but I want the rules and results of this discussion to be crystal clear for everyone who stumbles across it.

"Personally I have no issue with them staying right where they are and just letting this be a rule for the future."

This sentence is fucking legendary.

Can modos can just make what was decided 3 week ago ?

In the unlikely event that the game was updated so that multiple functions could be bound to one input in-game, yes the categories would be merged back together.

Current runs would have to be split off for fairness. This change will probably be made soon, even if the timing will make me seem petty. I've procrastinated too much at this point.

At least the only run I still on the leaderboards that hasn't been updated to fit under the proposed new rules is the Any% normal run, so I guess thanks for giving me time to prove just how fast I can go without the exploit.

So to be clear then and reiterate what we've discussed here, one last time:

Runs that are known to have either multiple functions bound to a single input (with the exception of confirm / cancel which by default break this rule) OR a single function bound to multiple inputs per input device will be split off. Let's call the new ruleset "Ruleset A" and the old / split off ruleset "Ruleset B"

For Ruleset A, Any input device will be allowed as long as you adhere to the above rules and it does not don't enable autofire, macros, or multiple digital inputs in response to a single button's press. I'm not sure which of these additional restrictions (if any) should be lifted for ruleset B.

Third party software that allows you to map or remap inputs is also allowed as long as you adhere to the respective ruleset you intend to submit for.

In either ruleset, confirm and cancel may be remapped through the config.ini file as this is purely for convenience (doing so does not give you any additional buttons to mash text with or anything like that)

Does this appropriately summarize what we've discussed in this thread?

EDIT: When the change is actually made, don't forget to add showing off the controls for verification purposes. I've been pausing briefly at the start as well as showing them after I enter NG+. Personally I think either is fine, but I'd like to hear your thoughts.