Legality Update on Controller Legality Discussion

[DarkDragoon]

THIS IS NOT AN ANNOUNCEMENT REGARDING A COMPLETED VOTE OR RULESET CHANGE ON CONTROLLER LEGALITY

Since the Melee Competition Committee started voting on ruleset amendment submissions a few weeks ago, one (of several) questions that has been on many people’s minds were those rules surrounding Box/Alternatively-styled controllers. As the ruleset presently stands, those styles of controllers would not be allowed, and the Competition Committee is very much aware of the popular opinion against that ruling. As such, we have received a couple proposals for rule changes for Section 3.1.11, and the discussion on those rules are starting up again.

The Competition Committee is indeed working towards a vote on Custom Controllers.

Used as the “starting point” for the discussion is the very well written amendment proposal authored by Squibble & NFreak whose ruleset change would be as follows:

3.1.11. Permitted Controllers

All controllers must fit within the following criteria:

• Macros are not allowed on any controller.
• Turbo buttons are not allowed on any controller.
• No single button input can have multiple separate possible outputs.
• There must be only one physical analog input on a controller to output any specific analog value.
• For controllers that utilize modifiers for analog values, only the magnitude can be modified, not the direction.
• Hardware modifications are legal so long as they do not violate any other rule.
• Case modifications and aesthetic mods are legal.

In addition, the following rules of enforcement apply:

• If a player suspects their opponent of cheating, they can request for a TO to inspect the opponent’s controller. The TO is not required to abide by this request.
• If a Game or Set cannot be played out in full due to a controller malfunction which cannot be fixed in a timely manner, and the player using this controller does not have a replacement controller readily available, the player will be disqualified.
• TOs reserve the right to decide on a legal set of restrictions for programmable controllers so long as they can electronically verify these settings. Unverifiable controllers may be banned at the TO’s discretion.

NFreak & Squibble submitted this amendment on along with several pages of informational and supporting documentation that will be considered when voting does happen, but there are still some concerns that the Competition Committee wants addressed. They wish to hear ideas on how to resolve some of the following concerns in a ruleset before bringing it to a vote, in hopes that having the most fair and comprehensive ruleset possible will have an agreeable outcome for everyone involved.

Main Concerns:

• Regarding SOCD (Simultaneous Opposite Cardinal Direction) Handling:
  • The ruling the panel wishes to enforce is currently unwritten. When SOCD situations arise, the solution the panel will agree to is that the second input will be registered if and only if it is input after the first input is fully released. A one frame buffer window will be allowed. If the first input is still registering, the second input will not be registered unless removed and input after the first is released.
    • The reason for this over “Second input is ignored until first is released” is that it does not allow for an unlimited buffer window to input the second direction.

• A maximum number of analog direction modifiers must be specified; this requires a full understanding of what analog direction modifiers do for each controller.

• Maximum values on the X and Y axes must not confer an unfair advantage on box controllers over the GCC. Two factors must be taken into account here: one, the maximum value that the GCC can input in a given cardinal direction, and two: the maximum X and Y values that can be input due to the octagonal gate on the GCC. Box controllers must have digital values that are not impossible on the GCC.

• Some sort of provision must exist such that the left hand cannot perform functions that the right hand would normally perform on the GCC, and vice versa. This issue is in reference to the possibility that a button could exist, mapped to c-stick down, to always buffer ASDI down in the event that the player is hit. We want to avoid the situation where a box creator puts a ‘c-stick down’ button within range of the left pinky (as an example) that can be depressed without affecting the abilities to perform other actions. This is not currently specific and more information needs to be provided in order to create this provision.

• A verification method must exist for Tournament Organizers to easily and uniformly check values for all controllers, regardless of controller design or creator. Whether it’s Hax’s boxx, the Smashbox, the Smash Stick, or any other product that may spring up, creators are responsible for creating a uniform program (collaboratively or with a 3rd party) allowing TOs to verify values not just for their controller, but others on the marketplace as well.

• In order for a controller to be considered legal, technical documentation detailing its design and the values assigned to each of its inputs must be made publicly available to TOs on request.

These concerns have already been shared with the B0XX and SmashBox teams to get their feedback, but due to the homebrew nature of many custom controllers we wanted to make sure the people also had some idea of what is going on at the moment and if you have any feedback or suggestions, please feel free to discuss it in this thread for maximum visibility to the Competition Committee, or submit it formally as an amendment if you think it covers everything!

 

[TheBlackHombre]

I'm one of the creators of the Smash Stick. Please watch our legality video talking about analog to digital converted buttons. The goal was to educate the community about alternate controllers and clear up common misconceptions. https://www.youtube.com/watch?v=9SKTBu9mNhc

Topics talked about in the video:

• Digital vs Analog
  
• ADC buttons
• SOCD
• Modifiers
• Notches
• Single Value Precision
• GCC methods used to reach single value precision
  
• "SDI Button"

The video breaks down very technical information into layman's terms. I'm currently at work so I can't give a fully detailed post. But I believe this video is a MUST WATCH for the community.

 

[PracticalTAS]

Legalizing box-style controllers, especially ones with digital-to-analog conversion, requires making a few concessions (this is not an exhaustive list):

• D2A controllers can guarantee a successful dash back at a rate of 100%, without affecting intended tilt turns (UCF can't guarantee this, but we can get close)
• D2A controllers can guarantee wiggle out of tumble (not implemented in UCF, but can be considered)
• D2A controllers can guarantee 1.0 dashes (not implemented in UCF, but possible to include)
• D2A controllers probably have superior SDI (simply due to travel time requirements of a stick)
  
• D2A controllers have consistent angles (up to and including "perfect" angles that GCCs can't be consistent at in vanilla Melee)

Are these insurmountable advantages? No. Are they worth noting? Absolutely. Are they worth living with, given the accessibility benefits they provide, especially to players who can't use Gamecube controllers? Probably.

I haven't yet made my mind up on box controllers. Above all, I want everyone who joins the conversation to be informed.

 

[InfinityCollision]

Maximum values on the X and Y axes must not confer an unfair advantage on box controllers over the GCC. Two factors must be taken into account here: one, the maximum value that the GCC can input in a given cardinal direction, and two: the maximum X and Y values that can be input due to the octagonal gate on the GCC. Box controllers must have digital values that are not impossible on the GCC.

To my knowledge, extreme X/Y values confer no advantage whatsoever within Melee. A direct left or right input of magnitude 127 does not run any faster than one of magnitude 80 - within the game itself, both are treated as having magnitude 1.0. If this was a poorly designed attempt at limiting such potential (minor) advantages, an alternate approach is instead required: the controller would have to send inputs in such a way that directional inputs do not (consistently) occur precisely on-axis. There are several potential solutions here, though the exact implementation is preferably left to the discretion of the manufacturers. As PTAS noted above, the inclusion of such a clause is also partially contingent on other possibilities such as enabling GCCs to execute 1.0 inputs with comparable consistency.

Some sort of provision must exist such that the left hand cannot perform functions that the right hand would normally perform on the GCC, and vice versa. This issue is in reference to the possibility that a button could exist, mapped to c-stick down, to always buffer ASDI down in the event that the player is hit.

This clause does not appear to adequately consider parallels for the GCC such as alternative grips.

While not technically within the scope of the committee's purview, I would also encourage the committee to approach these rules in such a way as to precisely address potential concerns while minimizing conflicts with rulesets and technical requirements for other games. Input mappings and engines vary widely within the Smash franchise, let alone outside it. Many of the issues at hand are exclusive to Melee, yet anyone who plays multiple games on a box/stick would need to remain conscious of the needs of each game and potentially (for boxes) have multiple profiles loaded to accommodate them.

 

[Basod]

Does this mean that 3rd party controllers will be legal to use? My apologizes if this is the wrong place to ask.

 

[Romans]

Would this allow for Gamecube controllers with swapped input locations? (Such as grab on X and jump on L trigger)
Or even something like replacing the c-stick with tilts?

 

[Bones0]

I hope people aren't seriously considering trying to devise a list of criteria to restrict unofficial controller usage. There's unlimited variables that would have to be accounted for and there's no way a list of even 100 rules could be specific and restrictive enough to allow fair controllers. There's tons of very simple ideas that follow all of the current criteria that utterly destroy any semblance of fairness (ignoring for the moment that even the current box controllers already do this).

 

[Sir_Slice]

I like where the conversation is heading... it may take years for some sort of compromise to be made, but obviously its for the benefit of the game and all of its players. I think a joystick of some sort would be necessary and also the equal means of buffering inputs.

 

[TobiasXK]

i'll get back to this, but i'm not sure this is a reasonable approach. the core idea of having a set of restrictions & specifications within which anyone can create a legal custom controller makes sense, but it's not a practical option imo. the granularity required would be incredible, for one thing—and overly complex rulesets that try to avoid containing loopholes sort of motivate people to find the loopholes & exploit them. plus, it's an approach that would require a lot of time for iteration, meaning we're accepting failures & committing to frequent retooling, when this has already been hard enough to even just get started.

but more importantly, the implicit goal of allowing the widest possible variety of custom controllers seems like a false target to begin with—i've never over the years seen a significant push within the community to allow arbitrary customizations or mods, and we had a fairly consistent ban on all electronic or functionality mods of any kind.

rather, the primary motivator behind the controller legality discussion based on what i've seen within the scene online seems to be physical accessibility/nondiscrimination - allowing players with disabilities or ergonomic needs or preferences to still be able to compete using controllers that are alternative to the 1st-party Gamecube controller.

from that standpoint, i think we should be looking to be specifically inclusive rather than meticulously exclusive. it would allow us to meet the goal of viable competition-legal controller alternatives, while being conservative enough to avoid:
1] altering competition excessively when the demand is only for improved accessibility
2] designing a system for validating the functionality of an infinite variety of custom controllers
3] all of the problems associated with requiring active TO enforcement

we could knock out easy includes like "controllers which replicate 1-to-1 (analog-to-analog & digital-to-digital) the functions of the GCC with no additions", to allow for form-factor changes (e.g. fightstick-style with true analog joystick) & button remaps.

and we'd work with teams like B0XX & SmashBox (& possibly a couple others, per community demand) to come up with specifications (& if they have easily-modifiable functionality via codeset or similar, validation methods) for those specific products.

more thoughts later.

 

[SmashBoxDevs]

Hi guys, official Smash Box here.

I'm down to work with you guys. I haven't actually been informed of any of this at all. My first time seeing any of this was a twitter post forwarded to me from someone else. Also, Shi Deng is the only person of authority whom we've talked to thus far. We had a talk with Kotaku recently for an article, too. So far these are the only people who have actually contacted us regarding actual controller talk. No one on YouTube has ever asked us for comments. I mean, we have a public email at on our page (hitboxes at gmail) or you can personally email me at SmashBoxDevs at gmail. I also welcome you guys to come spy on us in our discord.

I don't think the approach of saying "What are things we could possibly see and how do we ban them" is a practical approach. I think the approach of "What can you actually do right now, and where does that lead?" is a much better start. Simply because we can actually enumerate the things that are possible. I'm speaking mostly for Smash Box, but a lot of what I believe applies to smash stick, other box controllers, and even case mods.

So, yeah, ask away and I'll tell you what our controller does and we can hash out where it leads.

I'll start: if there's a unilateral ban on digital button press to analog stick conversion, there's not much that can be said for any alternative controller - including "form factor" mods like the Smash Stick. Unless there's a physical mechanism (like a control stick or shoulder buttons) connected to the same spec potentiometers there's always going to be some sort of translation to analog data sent as gamecube controller data. For Smash Box - button presses are sent as discrete values mapped to the analog stick and for Smash Stick, their own internal sensor values are translated to the same kind of data. So this needs to definitely be a point people can agree on - you have to be okay with a conversion of a button press (or lever movement) to an analog signal. Then provisions start, then you can do the "what if" scenarios - that will lead either to concessions that need to be made or the conclusion that no concessions or changes can ever satisfactorily lead to a fair controller.

That being said, here's my opinion on Smash Box, Smash Stick, and other alternatives that have some sort of digital to analog conversion or analog to analog translation for different sensors of different resolutions versus the GCC. Keyboard style controls should be allowed to be used for analog control (analog stick, c-stick, shoulder buttons). What controllers should not be able to do is have a button that performs multiple movements or a range of movements on one button press and should not have internal memory states that remember what the physical controller was doing previously (ie, your controller performs a different action if you were previously holding a certain button - like a shine button or a dash dance button) There are fine points that arise from this for the analog stick and for the triggers. These are the points we can hash out one at a time. On top of that, at the very least with Smash Box - these are things we can make concessions for. As some of you may be aware, we have a verifier almost ready for actual tournament usage. That verifier checks things like range of movements, allowable button mappings, and allowable options with a single button click. These kind of discussions lead directly into the kind of things that the verifier can automatically check.

 

[-ACE-]

Once again the community recklessly downplays the negative effects of allowing all case modifications, ignorantly (or perhaps just shamelessly) saying "all notches are basically the same and yield similar advantages".

The lack of involvement of the community in regard to controller legality led to many top players using case mods, and once a lot of top players start doing something, there's no turning back, no matter how the unopposed decision concerning legality affects the game.

 

[Bones0]

Hi guys, official Smash Box here.

I'm down to work with you guys. I haven't actually been informed of any of this at all. My first time seeing any of this was a twitter post forwarded to me from someone else. Also, Shi Deng is the only person of authority whom we've talked to thus far. We had a talk with Kotaku recently for an article, too. So far these are the only people who have actually contacted us regarding actual controller talk. No one on YouTube has ever asked us for comments. I mean, we have a public email at on our page (hitboxes at gmail) or you can personally email me at SmashBoxDevs at gmail. I also welcome you guys to come spy on us in our discord.

I don't think the approach of saying "What are things we could possibly see and how do we ban them" is a practical approach. I think the approach of "What can you actually do right now, and where does that lead?" is a much better start. Simply because we can actually enumerate the things that are possible. I'm speaking mostly for Smash Box, but a lot of what I believe applies to smash stick, other box controllers, and even case mods.

So, yeah, ask away and I'll tell you what our controller does and we can hash out where it leads.

I'll start: if there's a unilateral ban on digital button press to analog stick conversion, there's not much that can be said for any alternative controller - including "form factor" mods like the Smash Stick. Unless there's a physical mechanism (like a control stick or shoulder buttons) connected to the same spec potentiometers there's always going to be some sort of translation to analog data sent as gamecube controller data. For Smash Box - button presses are sent as discrete values mapped to the analog stick and for Smash Stick, their own internal sensor values are translated to the same kind of data. So this needs to definitely be a point people can agree on - you have to be okay with a conversion of a button press (or lever movement) to an analog signal. Then provisions start, then you can do the "what if" scenarios - that will lead either to concessions that need to be made or the conclusion that no concessions or changes can ever satisfactorily lead to a fair controller.

That being said, here's my opinion on Smash Box, Smash Stick, and other alternatives that have some sort of digital to analog conversion or analog to analog translation for different sensors of different resolutions versus the GCC. Keyboard style controls should be allowed to be used for analog control (analog stick, c-stick, shoulder buttons). What controllers should not be able to do is have a button that performs multiple movements or a range of movements on one button press and should not have internal memory states that remember what the physical controller was doing previously (ie, your controller performs a different action if you were previously holding a certain button - like a shine button or a dash dance button) There are fine points that arise from this for the analog stick and for the triggers. These are the points we can hash out one at a time. On top of that, at the very least with Smash Box - these are things we can make concessions for. As some of you may be aware, we have a verifier almost ready for actual tournament usage. That verifier checks things like range of movements, allowable button mappings, and allowable options with a single button click. These kind of discussions lead directly into the kind of things that the verifier can automatically check.

No one has contacted you because, to be blunt, you are not part of the community. You are a separate entity outside of the community attempting to sell their controller (your username being "SmashBoxDevs" makes this a little too on the nose). Not trying to **** on you, selling a new controller is as noble a cause as any capitalist endeavor, and I say that with no sarcasm or malice. However, while I see no issue with you providing information to people or seeking feedback, it's kind of concerning how much you're trying to involve yourself in the discussion about what our community should actually value. The fact that you keep going to Kotaku about your product to essentially (in my view) stir up drama is really annoying and not helpful at all as it makes it difficult to gauge where people's opinions are actually at.

For the most part, I think everyone gets how your controller works. The issues are much more fundamental: should we allow digital buttons for analog inputs and how can we logistically handle the issue of a brand new type of controller after 16 years of a single universal standard.

 

[SmashBoxDevs]

About that contact thing, solid discussions happen when information is reported directly from the source. I've named Shi Deng and Ian Walker because they are exactly the people who have asked me about the controller and how it would work for tournament settings. Shi Deng specifically was the driving force behind the development of a verifier after he invited us to talk about Smash Box. Such a utility has never existed for an FGC-specific controller but we're developing it strictly because of the community.

I also wouldn't be here if I wasn't trying to be more involved. If I'm not here talking to the people who have actual legality concerns then the only way information gets passed back and forth is entirely second-hand. I don't think I can make it anymore clear that I, more than anyone else at Hit Box, am committed to listening/addressing concerns and making concessions (changes to the controller firmware, software and verifier) specifically for legality concerns.

As for Kotaku - I didn't go to them, Ian Walker came to me. All he did was ask me specifically about controller malfunctions for Smash Boxes, and I gave him a full disclosure about the issues we've had and why. As for that statement about "Smash Box and B0XX have been contacted." I'm not sure who that was sent to but it certainly didn't get to me. There has not been any sort of two-way communication here.

Since I joined Hit Box a year ago, I've always pushed for transparency, and I've been giving it when asked. It's not just me trying to sell snake-oil here, I sincerely believe we can't make necessary, community-specific changes to this controller without talking about its goods and bads.

But yeah, let's get down to specifics. Like we both said, Bones0, a discussion should start with the fundamentals. Before I get into the nitty gritties for your considerations, I really want an answer from more people - is a digital to analog conversion simply out of the question of legality? Because if it is, no further concessions can be made on the part of the Smash Box. It's a keyboard controller - both digital to analog and SOCD cleaning must be a part of the product. The question is which implementations are fair and which aren't. After that, we can break down the digital to analog question into a few parts: how it affects control stick movement, it's use on triggers, and what restrictions should be made on mapping.

I will give general answers pertaining to alternative controllers but I'll also mention where Smash Box sits in those talking points. Just give me the word and I'll start blurting out English 102 papers on the topics; sources cited, double-spaced, MLA format and all of the other solid B+ necessities. Give me a starting point, boys.

 

[Bones0]

About that contact thing, solid discussions happen when information is reported directly from the source. I've named Shi Deng and Ian Walker because they are exactly the people who have asked me about the controller and how it would work for tournament settings. Shi Deng specifically was the driving force behind the development of a verifier after he invited us to talk about Smash Box. Such a utility has never existed for an FGC-specific controller but we're developing it strictly because of the community.

I also wouldn't be here if I wasn't trying to be more involved. If I'm not here talking to the people who have actual legality concerns then the only way information gets passed back and forth is entirely second-hand. I don't think I can make it anymore clear that I, more than anyone else at Hit Box, am committed to listening/addressing concerns and making concessions (changes to the controller firmware, software and verifier) specifically for legality concerns.

As for Kotaku - I didn't go to them, Ian Walker came to me. All he did was ask me specifically about controller malfunctions for Smash Boxes, and I gave him a full disclosure about the issues we've had and why. As for that statement about "Smash Box and B0XX have been contacted." I'm not sure who that was sent to but it certainly didn't get to me. There has not been any sort of two-way communication here.

Since I joined Hit Box a year ago, I've always pushed for transparency, and I've been giving it when asked. It's not just me trying to sell snake-oil here, I sincerely believe we can't make necessary, community-specific changes to this controller without talking about its goods and bads.

But yeah, let's get down to specifics. Like we both said, Bones0, a discussion should start with the fundamentals. Before I get into the nitty gritties for your considerations, I really want an answer from more people - is a digital to analog conversion simply out of the question of legality? Because if it is, no further concessions can be made on the part of the Smash Box. It's a keyboard controller - both digital to analog and SOCD cleaning must be a part of the product. The question is which implementations are fair and which aren't. After that, we can break down the digital to analog question into a few parts: how it affects control stick movement, it's use on triggers, and what restrictions should be made on mapping.

I will give general answers pertaining to alternative controllers but I'll also mention where Smash Box sits in those talking points. Just give me the word and I'll start blurting out English 102 papers on the topics; sources cited, double-spaced, MLA format and all of the other solid B+ necessities. Give me a starting point, boys.

I'm not sure if you're the person I'm discussing this with on Twitter, but I misinterpreted your first post as wondering why you weren't contacted with regards to this thread, not to the specific issues outlined in the first post, so that's my mistake. To clarify my point, all I was trying to say was that I think the main purpose of the thread is to discuss what should/shouldn't be legal, specifically related to the current suggestion on the table about what rules to have against custom controllers. I don't think it's appropriate for Smash Box, B0xx, or anyone with financial interests in the outcome of the debate to be discussing it or trying to sway opinions outside of providing basic information (which is mostly available online at this point anyway).

 

[Mr_towel_Man]

I hope people aren't seriously considering trying to devise a list of criteria to restrict unofficial controller usage. There's unlimited variables that would have to be accounted for and there's no way a list of even 100 rules could be specific and restrictive enough to allow fair controllers. There's tons of very simple ideas that follow all of the current criteria that utterly destroy any semblance of fairness (ignoring for the moment that even the current box controllers already do this).

You dont have to create 100+ rules but rather 10 smart and decisive ones to take out the unfair controllers

 

[Mithost]

No one has contacted you because, to be blunt, you are not part of the community. You are a separate entity outside of the community attempting to sell their controller (your username being "SmashBoxDevs" makes this a little too on the nose). Not trying to **** on you, selling a new controller is as noble a cause as any capitalist endeavor, and I say that with no sarcasm or malice. However, while I see no issue with you providing information to people or seeking feedback, it's kind of concerning how much you're trying to involve yourself in the discussion about what our community should actually value. The fact that you keep going to Kotaku about your product to essentially (in my view) stir up drama is really annoying and not helpful at all as it makes it difficult to gauge where people's opinions are actually at.

For the most part, I think everyone gets how your controller works. The issues are much more fundamental: should we allow digital buttons for analog inputs and how can we logistically handle the issue of a brand new type of controller after 16 years of a single universal standard.

I don't want to cause much of a stir, but who are you to choose who is and isn't a part of our community? I knew 'smash players are xenophobic' was a meme in the FGC and other esports communities but did you really have to confirm it like that?

I've seen you in the other ruleset discussion thread, and if you are willing to actually discuss the issues you have with alternative controllers in depth (and not ignore the counterpoints this time, still waiting for a response on why they are 'logistically impossible' in smash when FGC has been doing it for 15+ years), please do that instead of trying to discredit or silence one of the few people in a position to actually provide the information that needs to be laid out. SmashBoxDevs literally came here saying 'hey, we want to try to make this controller legal, what are your problems with it and what can we do to help?' and you are suggesting that they are not fit for discussion of that exact topic?

And if this is your approach/definition of discussing an important ruleset/community issue

"I walk the fine line between devil's advocate and trolling."

Please don't get in the way of the people trying to discuss this issue civilly.

 

[Mithost]

--messed up formatting, please ignore--

 

[Sdhy]

So by reading the proposed rules... there's nothing against ergonomic modifications? I might make my L-R buttons stick out more.

Also someone else's post on allowing people with disabilities, injuries or other preferences sounds like a good idea, too.

Hopefully different controllers / mods can be allowed without bringing in unfairly tas-like sdi's, a concern I glimpsed at in an article. lol.

 

[SmashBoxDevs]

I don't think it's appropriate for Smash Box, B0xx, or anyone with financial interests in the outcome of the debate to be discussing it or trying to sway opinions outside of providing basic information (which is mostly available online at this point anyway).

I think it's absolutely appropriate here. Since I'm fully in control of what goes in the firmware for the users, the customization software, the updater and the verifier for the TOs for Smash Box - there isn't a better place for me to hear what exactly it is that you guys want and whether or not I can accommodate them.

I'm not here to sell anything - that's Shawn and Dustin's job. I'm here to explain the underlying tech on the code level but also give you any information as reported to me from the 70 people who are already using one since I'm also the admin for our 200+ person discord server.

It really has gone like that over the past year - the users ask "Hey can you do this" and I will either say "Yeah I can swing that" or I refuse with an in-depth explanation. It can be the same for the tournament organizers of the community if they let it.

 

[NFreak]

Co-author here. I'm mostly staying out of the legality debate for mostly unrelated mental health concerns now that this has been submitted, but I want to provide some context due to some comments I've been seeing.

- Squible and I were not just throwing out arbitrary ideas. Due to hand health issues, we both practically require a box-style controller to play this game seriously. I've been using a Smashbox alpha build personally, while Squible uses a DIY box (I believe by SimpleControllers).

- I can't speak for Squible, but I don't agree with any of the provisions suggested by the 5. The SOCD change will make dash dancing next to impossible, the left hand / right hand thing is incredibly arbitrary and claw grip on a controller throws this argument out. That's my personal take on this.

- Analog to digital conversation is necessary in order for Smash Stick to be legal, as TheBlackHombre's video explains

- While we believe our amendment to be comprehensive, we accept that some changes will need to be made. It was not made to be overly technical and arbitrary, but rather to set a basic set of guidelines. Note that we say "any legal controller" must fit within the proposed guidelines - this is to prevent a monopoly on this sort of thing, allowing Smashbox, B0XX, Smash Stick, and any future projects to be potentially legal, as well as innovative GC controller mods / notches / etc.

- It's actually absurd that TOs are remaining silent on this. The public still doesn't know what happened at TBH7 (I was offered a private explanation, but I turned it down to distance myself from the issues at hand). The developers of all three heavy hitters right now (Hit Box, Hax + team, Alt Lab Controllers) are all easily reachable, and with how much drama this stuff is stirring up in the scene, radio silence is a killer.

Like I said I'm trying to stay out of this, so that's all I'll contribute to this thread. Dealing with this stuff is just awful for my well-being, and I've reacted in some very extreme ways I never want to feel again. If you guys as a community want to see these legalized, do what you can to contribute.

 

[InfinityCollision]

I'd like to chime in again on a subject NFreak briefly touched on:

Regarding SOCD (Simultaneous Opposite Cardinal Direction) Handling:
The ruling the panel wishes to enforce is currently unwritten. When SOCD situations arise, the solution the panel will agree to is that the second input will be registered if and only if it is input after the first input is fully released. A one frame buffer window will be allowed. If the first input is still registering, the second input will not be registered unless removed and input after the first is released.

If I understand this correctly, the desired implementation is that any opposing input is discarded entirely if the first input is not released on the following frame. If held any longer, releasing the first input while continuing to hold the second results in behavior equivalent to no input at all.

This is incredibly unintuitive and cumbersome for all involved. Such a system would harshly punish minor timing errors on even the most basic of movements. Players would have to take great care to ensure the first input is released prior to the second, or else attempt to mash out additional (and otherwise unnecessary) inputs. Both scenarios would have significant negative consequences, and execution of some already difficult input sequences could become nigh impossible. It's unreasonable to expect players to accept such a system, or for manufacturers to adopt it.

There are several ways one could theoretically approach the SOCD question. I wouldn't say that any of them are clearly superior in performance to the others, but with further consideration I believe the committee will find that traditional SOCD (opposing directions result in no/neutral input) adequately handles a variety of situations without rousing any special concerns or unduly burdening the player.

Additionally, this point has not received much attention:

A maximum number of analog direction modifiers must be specified; this requires a full understanding of what analog direction modifiers do for each controller.

I'm unsure as to the intent of this statement? Manuals and technical documentation would naturally (though perhaps not explicitly) disclose the maximum number of unique directional inputs as a consequence of explaining the unit's function. If the goal here is to limit the quantity of unique inputs an all-button controller can execute, then the committee is wasting their (and our) time. Pace of play, increasing input complexity/mechanical difficulty, and layout considerations naturally limit the player's ability to utilize increasing quantities of input combinations. The benefit to having a large number of available modifiers lies less in giving players additional inputs and more in giving players a range of options with which to address game- and character-specific needs in whatever way works best for the individual.

 

[SmashBoxDevs]

I don't really think that controllers should be option-selecting for the player based on the previous game state. The game itself should handle option selects, the controller should be blind to what the player is doing - it shouldn't try to guess what the player wants to do and then completing those inputs for them. Having a controller change its function like this requires having to remember the state of the previous frame. That's what the proposed SOCD cleaning in that first post is suggesting. Adding a one-frame buffer possibly requires two memory states and definitely requires a much larger flowchart of decisions than just reading two buttons and choosing one of them on the just-frame.

Option-selecting (ie, conditional inputs) are something that need to be scrutinized pass by pass so that the actual possible use cases can be enumerated. If you guys would like, I can actually tell you how all of the Smash Box's SOCD methods work. We actually have 4 separate methods, and they're axis-independent - the user can choose what SOCD cleaning method they want for both the X and Y axis. These are all verifiable/bannable on the TO end without requiring the user to change their firmware (they flip switches in the customizer instead). It goes against the core Hit Box philosophy of a totally blind controller, but we still implemented it after the first iteration of the verifier - players can choose to use it and TOs can choose to ban it.

If SOCD is really so contentious, and we need to examine memory states - then a complete description for the SOCD methods being implemented actually need to be thoroughly disclosed by anyone making an alternative controller. Pretty sure BlackHombre mentioned Neutral on SOCD for the C-stick group on the Smash Stick, and if SimpleControllers is still using our proof-of-concept Smash Box SOCD method (as described in the code they released), then SimpleControllers users are also using neutral on SOCD for both analog stick and C-stick. If you guys want a description of Neutral on SOCD, or first and second input overrides (new to Smash Box, and what hax is reported to be using) let me know. These are already implemented in Smash Box and I can give you a step-by-step rundown of how they work.

 

[KBK Kingkiller]

The one issue that doesn't seem to be being addressed is the extreme SDI plinking that is possible on Smash Box style controllers. Before I could ever support such a controller, I would have to see this addressed. Otherwise, a Smash Box style controller confers too much advantage. As a baseline, the GCC (with the exception of a few moves with abnormally long hitlag) is capable of plinking just under 1.5 SDI inputs and burst SDI (on a timing read) of 2.5 SDI inputs. For a lot of combos or multihit moves, 1.5 SDI pushes them to the edge of failure and 2.5 SDI breaks them. Since you can't plink 2.5 SDI, timing mixups exist that makes these things work much of the time. Examples include, Fox's upair, Fox's waveshine combos, many Falco combos and and Marth's FD combos (2.5 SDI doesn't get spacies out but it does force Marth to go for upair juggles instead of being able to force an edgeguard situation). There are numerous additional examples but these stand out the most to me since they are such clear and advantageous shifts for the Smash Box player. I don't think it is good that players would probably end up needing separate punish flowcharts for different controllers.

 

[Bones0]

The one issue that doesn't seem to be being addressed is the extreme SDI plinking that is possible on Smash Box style controllers. Before I could ever support such a controller, I would have to see this addressed. Otherwise, a Smash Box style controller confers too much advantage. As a baseline, the GCC (with the exception of a few moves with abnormally long hitlag) is capable of plinking just under 1.5 SDI inputs and burst SDI (on a timing read) of 2.5 SDI inputs. For a lot of combos or multihit moves, 1.5 SDI pushes them to the edge of failure and 2.5 SDI breaks them. Since you can't plink 2.5 SDI, timing mixups exist that makes these things work much of the time. Examples include, Fox's upair, Fox's waveshine combos, many Falco combos and and Marth's FD combos (2.5 SDI doesn't get spacies out but it does force Marth to go for upair juggles instead of being able to force an edgeguard situation). There are numerous additional examples but these stand out the most to me since they are such clear and advantageous shifts for the Smash Box player. I don't think it is good that players would probably end up needing separate punish flowcharts for different controllers.

Just to add to this, it's possible to get 3 SDI inputs all on a single shine, so DIing out of spacies' combos would become totally busted. It's important to remember this isn't quarter circle SDI, it's SDIing all in the same direction, so you go way further than anything even close to possible on a GCC.

 

[Gentlefox]

Just to add to this, it's possible to get 3 SDI inputs all on a single shine, so DIing out of spacies' combos would become totally busted. It's important to remember this isn't quarter circle SDI, it's SDIing all in the same direction, so you go way further than anything even close to possible on a GCC.

First, yes, it's theoretically possible to burst 3 in the same direction on a box style controller, but I have tried and it's extremely difficult to hit. I generally get 3 in 6 or 7 frames which is a different story.

Secondly, "way further than anything possible on a GCC" is simply incorrect. Most people just suck at SDI on GCC. Since you brought up shine as an example (5-6 frames of SDIable hitlag) here's me getting 2.7 SDI in 4 frames on GCC and I barely even practice. That's less than a 10% difference in SDI distance between getting 3 in the same direction on box.

 

[Bones0]

First, yes, it's theoretically possible to burst 3 in the same direction on a box style controller, but I have tried and it's extremely difficult to hit. I generally get 3 in 6 or 7 frames which is a different story.

Secondly, "way further than anything possible on a GCC" is simply incorrect. Most people just suck at SDI on GCC. Since you brought up shine as an example (5-6 frames of SDIable hitlag) here's me getting 2.7 SDI in 4 frames on GCC and I barely even practice. That's less than a 10% difference in SDI distance between getting 3 in the same direction on box.

What inputs did you do?

 

[InfinityCollision]

There are a few different ways one might optimally approach SDI on a box, assuming use of traditional SOCD:

Burst SDI:

• Same direction
  • Input the intended direction with one hand, then swipe across the opposing button with the fingers on the other hand. Optimally, this can produce inputs on every other frame (up to 3 SDI inputs in 5f). Realistically I get 3 inputs in 6-7 frames. I'd estimate my success rate for a "perfect" set of three inputs with this method at maybe 5% in a vacuum; my rate of getting only two inputs is somewhat higher. Two fingers on the swipe seems to have the highest success rate for perfect input timing, so any input method designed to extend the burst sequence would compromise performance.
• Varied direction (QCSDI-esque)
  • If attempting to SDI in a roughly horizontal manner: input the intended primary direction with one hand, then swipe the vertical inputs with one finger. Bursting 3x inputs in 3-5 frames is possible here (4~5f typical). Upwards/downwards-focused SDI would need a modified technique that strikes left-right independently, which is significantly weaker (~7f typical). Values are subject to change based on layout (WASD style vs in-line ULDR vs in-line UDLR could all have different results).

Performance depreciates noticeably if one attempts to mash over a longer period, especially for QC-like inputs since you're less likely to get the initial cardinal input. Direct outwards SDI levels out just at just under 4f average intervals between mashed inputs, sweeping QCSDI also comes out to about 4f, and tapped QCSDI inputs (ex holding up and alternating left, right, left right...) degrade to 6~7f intervals.

This is all with two hands. One handed burst values are slightly weaker than swipes and comparable to individual strikes, with much lower potential over longer intervals.

Contrast with a GCC:

• Mashed QCSDI shows a significantly higher quantity of productive inputs than a box can realistically produce. Sufficiently determined mashers can achieve very high activation rates - the first video I found on Youtube using the IKD input tool showed peak activation of 12 SDI inputs over 15 frames, with multiple streaks of 100% activation over 4-6f. Even allowing for some inputs outside one's intended directions, that's quite comparable to the box's best burst input rates. In my own brief testing, which involved a more controlled approach in which I attempted to remain with a ~90 degree arc, I still maintained a 40%+ activation rate (2-3f intervals between SDI inputs) through extended mashing. That's better than I can currently attain via digital inputs, despite not using a GCC at all for some months prior.
• My burst QCSDI rates on a GCC are comparable to a box in both typical and peak performance.
  
• Gentlefox aptly demonstrated that a GCC is fully capable of achieving comparable results to a box's best possible outwards SDI, and did so in fewer frames than a box using SOCD requires to produce a marginally superior result. The faster GCC input would be less sensitive to timing, potentially granting it greater efficacy in real-world scenarios. A box user could attempt to replicate this approach by introducing a diagonal input at the end of the burst sequence; the resulting set of 3x inputs at the end would shift approximately the same distance as Gentlefox's input set above.

I got some similar results to Gentlefox's, one-handed (left, non-dominant):

Inputs here were right>up-right>down-right. I imagine I could do better with practice and/or my dominant hand. The stick used was moderately stiff, with no notches.

A key factor to bear in mind here is how traditional SOCD works: any opposing directional inputs result in a neutral value along that axis. This introduces a significant timing element that limits the player's ability to crank out large quantities of directional inputs in very short timeframes. Combined with practical execution constraints, I'm inclined to view concerns regarding SDI as overstated.

 

[Gentlefox]

What inputs did you do?

I flicked the stick to just above the 17 degree notch below Right and slide down to said notch. This gives me two SDI inputs. I then slid up to the 17 degree deviation above Right.

In clock notation it's like, 3 o'clock to 4 o'clock in one "swoop", and then up to 2 o'clock.