The debate and controversy currently raging through the community about controller mods has piqued my interest in forming a concise rule. You all as a community should do what you can to preserve the integrity of Melee, but this should never be your primary concern over the welfare of your players. However, I believe there is a way that you would be able to satisfy most people on both sides of the argument. It would also be quite convenient for your organizers to have something that could be easily referenced for setting the rules regarding controllers in their tournaments. I hope that those of you with a little more community participation than I do, compose your own rules based on what I’ve been able to work out.
The majority of the community seems to be behind Hax$’s controller mod and against a future of cheating macro controllers. Since the main concern of the mod is that it would create a dangerous precedent for abuse, a distinction must be made, and I believe that an unyielding distinction can be made.
As it is, the validity of your Melee gear seems to be up to human judgement. Unfortunately, that sort of arbitration will eventually invite controllers into your ranks that very few of you would accept as legitimate. So, it is very important that the wording in your law leaves as little to interpretation as possible.
This is what I’ve come up with so far:
Believe it or not, everything written after the second comma (the first 12 words) exists to prevent mash-out-of-shield abuse. I’ll explain the wording.
The “static bufferable output set” is a single group of outputs which can be offset by a single timer, all of which is static, meaning the outputs and the timer will never change given that input set. While buffers (timers) are utilized in the creation of macros, these rely on either multiple timers and sets, or they satisfy the 1-1 rule by computing dynamic values of the output set and/or timers. While it certainly would be much easier to say there should be no buffers at all, they are actually necessary to correct some inconsistencies.
An input set is the player physically changing the state of an analog device on the controller (such as depressing and releasing a button or moving a stick), which may take into consideration the “modifiers”, or physical state of the other analog units (such as whether or not another button is being held down).
For example, if I have buttons 1 2 and 3, that each individually output the commands “1”, “2”, and “3” respectively, when pressed, it would be legal to make button 3 output “4” when buttons 1 and 2 are being held down as modifiers. It would not be legal for the output to instead be “3”, “4”, “5”, and “6” as the number of outputs (4 total) exceeds the number of analog modifiers (3 total).
It is my belief that having another button for a function is always preferable to relying on modifiers to achieve that function. So there is really no harm in granting a group of outputs to be assigned to an input set, so long as it does not make mashing easier. For example, a controller with only 4 buttons like the Falcon Box actually has 2(2^4-2) = 28 possible input sets if I’m not mistaken, if you keep in mind that releasing a button is also considered a press. This can iron out the innate disadvantages of using these types of controllers and still get your perfect mangles.
The generally accepted “1-to-1” rule is actually very exploitable. For example, I could have a “M” button which I mash as quickly as possible in order to perform a macro which requires equal or fewer total inputs than the number times I mash. The importance of 1-to-1 really only exists for preventing an overwhelming number of inputs like an instant mash out of grab. The main prohibition of cheating is the prevention of dynamic outputs, that is, a button press set should always cause the exact same outputs to happen at the same time, every time.
The second part exists to prevent the creation of mash-out-of-grab cranks and the like. An analog unit is a moving part that must be a set distance away from other units (say, 2mm). Buttons are toggles, meaning they only have two analog states. A stick, on the other hand, could have thousands. Under this rule, you can’t assign an output which normally comes from a button on the GCC to a stick, because a stick is one analog unit with more input states than a button, but you could still assign a stick-based output to a button, as done on a device like the B0xx and smash box.
I wish you the best of luck at mending the rift and at getting made up as quickly as possible for the sake of equipment designers and the health of their customers, but also to be very careful to create something without oversights as probably exist in this draft, so that it does not need to be changed.
The majority of the community seems to be behind Hax$’s controller mod and against a future of cheating macro controllers. Since the main concern of the mod is that it would create a dangerous precedent for abuse, a distinction must be made, and I believe that an unyielding distinction can be made.
As it is, the validity of your Melee gear seems to be up to human judgement. Unfortunately, that sort of arbitration will eventually invite controllers into your ranks that very few of you would accept as legitimate. So, it is very important that the wording in your law leaves as little to interpretation as possible.
This is what I’ve come up with so far:
- Each input set may provide at most, one static bufferable output set, where the number of outputs in the output set does not exceed the number of analog modifiers in the input state set.
- An output may not be assigned to an analog unit with more input states than those which are present on the base model’s analog units responsible for that output.
Believe it or not, everything written after the second comma (the first 12 words) exists to prevent mash-out-of-shield abuse. I’ll explain the wording.
The “static bufferable output set” is a single group of outputs which can be offset by a single timer, all of which is static, meaning the outputs and the timer will never change given that input set. While buffers (timers) are utilized in the creation of macros, these rely on either multiple timers and sets, or they satisfy the 1-1 rule by computing dynamic values of the output set and/or timers. While it certainly would be much easier to say there should be no buffers at all, they are actually necessary to correct some inconsistencies.
An input set is the player physically changing the state of an analog device on the controller (such as depressing and releasing a button or moving a stick), which may take into consideration the “modifiers”, or physical state of the other analog units (such as whether or not another button is being held down).
For example, if I have buttons 1 2 and 3, that each individually output the commands “1”, “2”, and “3” respectively, when pressed, it would be legal to make button 3 output “4” when buttons 1 and 2 are being held down as modifiers. It would not be legal for the output to instead be “3”, “4”, “5”, and “6” as the number of outputs (4 total) exceeds the number of analog modifiers (3 total).
It is my belief that having another button for a function is always preferable to relying on modifiers to achieve that function. So there is really no harm in granting a group of outputs to be assigned to an input set, so long as it does not make mashing easier. For example, a controller with only 4 buttons like the Falcon Box actually has 2(2^4-2) = 28 possible input sets if I’m not mistaken, if you keep in mind that releasing a button is also considered a press. This can iron out the innate disadvantages of using these types of controllers and still get your perfect mangles.
The generally accepted “1-to-1” rule is actually very exploitable. For example, I could have a “M” button which I mash as quickly as possible in order to perform a macro which requires equal or fewer total inputs than the number times I mash. The importance of 1-to-1 really only exists for preventing an overwhelming number of inputs like an instant mash out of grab. The main prohibition of cheating is the prevention of dynamic outputs, that is, a button press set should always cause the exact same outputs to happen at the same time, every time.
The second part exists to prevent the creation of mash-out-of-grab cranks and the like. An analog unit is a moving part that must be a set distance away from other units (say, 2mm). Buttons are toggles, meaning they only have two analog states. A stick, on the other hand, could have thousands. Under this rule, you can’t assign an output which normally comes from a button on the GCC to a stick, because a stick is one analog unit with more input states than a button, but you could still assign a stick-based output to a button, as done on a device like the B0xx and smash box.
I wish you the best of luck at mending the rift and at getting made up as quickly as possible for the sake of equipment designers and the health of their customers, but also to be very careful to create something without oversights as probably exist in this draft, so that it does not need to be changed.
