Hello PracticalTAS I have a suggestion on how to nerf Box controllers in an appropriate way which I think would make all parties happey. Could you let me know what you think?
* Character Select Screen clause: When the Melee character select screen is active on the screen, the controller will automatically select your cursor and hover it over the "Ganondorf" portrait, then emulate an A press. This will occur any time the box player selects any other character aside from Ganondorf, but in no other instances, so the player can change game settings, in-game tags, costumes, and team toggle without any interference.
Dearest DarkGenex, I hope this finds you well. As you as a tournament organizer know, the controller ruleset proposal team has no power to enforce these rules or require that TOs use them exactly as-is. Additionally, the ruleset proposal is entirely firmware-side and has no ability to impact game state such as requiring a player to select a specific character. You are welcome to apply the CSS clause at your events and report back to us with your results.
Sincerely, PracticalTAS
It is the year 20xx. Every player uses a boxx and plays Ganondorf. Matches are decided by port priority because the player with priority can get out their taunt first, dealing unrecoverable damage to the opponent's mental.
In the event that the travel time and timing lockout rules become widely adopted by TOs, is there a plan to add these nerfs to UCF so they become standardized and applied equally to all controllers/firmwares, regardless of if a GameCube or rectangle controller is used? If not, for what reason was the decision made to include more lenient 1.0 cardinals in UCF instead of enforcing .9875 cardinals for rectangles or in UCF?
No, UCF will not add these lockouts game-side. They would take a massive amount of expertise that we don't have to implement, only to impact 0.001% or less of the gcc/gcc-like player base. Nearly every lockout we're including will have a tighter window than the fastest gcc players we had benchmarking those motions.
Re 1.0, I've responded elsewhere in the thread but 1) 1.0 is more accessible on some OEMs and gcc-likes than others and 2) one of the principles of UCF is not making something that's possible in vanilla Melee impossible. Parity with boxes without needing to add another nerf is a bonus, not the primary goal.
I dont know how easily you will be able to answer this since you aren't directly involved in either of these projects, but do you plan to try and make UCF 0.84 be integrated into slippi and uncle punch at some point?
0.84 is already available on Slippi Nintendont, andI have proposed to Fizzi that 0.84 be the default choice on Slippi online and future releases of Slippi Nintendont (it's ultimately his choice but I believe that we're aligned and this will occur). Integration into Training Mode is a stretch goal that I think we'd need UP's help with, and he's been inactive recently.
I think having it be default on slippi is the best way to have this spread considering that's how almost all people are playing and practicing now. Good work on all this!
Why force 1.00 instead of forcing 0.9875? Put differently, why do the option that makes the game less vanilla when there was an equally viable option that would result in things basically staying the same but more consistent?
In general, one of the tenets of UCF that we've tried to adhere to is not making something that's possible in vanilla Melee impossible with UCF. This means leaving 1.0 available, but also doesn't mean making 0.9875 completely impossible. A blanket nerf across the whole game, even it's minor, subjectively feels quite bad to force. Also, it's actually very possible to hit 1.0 cardinals reasonably often with a notch - I once tested this and was able to hit 1.0 about 40% of the time, though of course that notch has degraded now. It's also very possible to have a stickbox that's more likely to hit 1.0 than another. In other words, 1.0 isn't equally accessible to everyone, so UCF 0.84 is making it equally accessible to everyone.
I think it's circular to say that it's about the tenets of the project since my point is really that the circumstances ought to result in a reconsideration of the tenets of the project. Nobody - *nobody* - is hitting 1.000 with any consistency on an OEM, so you're really talking about shifting the default from something that is standard to every controller to something that is only consistent on modified controllers.
Notches should've never been legal to begin with, but that's a separate conversation.
There has been a lot of belly-aching and complaining about the travel-time nerf. It is difficult for me to discern who has valid complaints about it rather than catastrophic exaggerations.
Could you provide a low- level explanation of how the travel time nerf works, and an example of a currently abused boxx technique that would be banned by this nerf? If possible, comparisons of this technique on GCC would be useful.
When you press a button on a box that controls the control stick, on the very next millisecond the box is outputting a 1.0 cardinal input to melee. We have benchmarked and found that this is roughly 5 ms faster than you'd get to the dash threshold (0.8) on a gamecube controller or gcc-like controller with a physical analog stick. Similarly, when releasing the button, on the very next millisecond you're back to a 0 input. Since most players return to neutral by releasing the stick and allowing the spring to propel it back to 0, this takes around 9-10 ms longer on a stick. This actuation speed advantage manifests itself in gameplay as a reaction speed buff - the same user will have a higher reaction techchase rate, faster dashdance away from an opponent's move, etc.
Travel time simulation does not ban any specific techniques, it instead forces the stick output to sweep from 0 to 1, touching some intermediate values along the way, before arriving at 1.0 6 ms later or at 0 12 ms later. This neutralizes the actuation speed advantage of a box.
[This](https://imgur.com/P3qSxJo) is a polling issue caused by the travel time nerfs. It's a concrete example of an issue unique to travel time nerfed boxes (on a controller, you would be able to feel the stick and not press B until it's in the correct position). I don't think PTAS has ever acknowledged that such issues are potentially problematic.
IMO this kind of problem is very much on purpose. If you were playing on a GCC and you did those inputs (i.e. press backward, let go of the stick, press B) too quickly, you would side B to your death. You would NOT "feel the stick" because your thumb is not on the stick, in order to return to neutral, you release the stick entirely and simply wait for the springs to bring it to neutral for you. The GCC user has to consciously delay their B press, and now digital controller users have to do the same. That's fair.
TLDR sometimes everyone accidentally side Bs to their death and that's Melee.
That would be true, if this was turnaround neutral B. This is let go -> up-B. You feel the stick going up.
Edited to add: They actually added turnaround neutral B coordinate with the nerfs, due to their (imo misplaced) disdain for non dedicated modifiers. This along with a few other features of the nerf-patch actually leads me to the opinion that this buffs spacies and Sheik. Free turnaround neutral B, free dashback out of crouch, 23 degrees wavedash. This comes at the cost of stupid polling issues like shown in the clip above, and the controller just feeling a lot worse to use.
I see, I misunderstood the inputs a bit. But my main point is that you won't SD like this if you just press B one or two frames later. That slight difference in timing, while being unnatural and confusing to a box player, limits box players to inputs that can actually be done on GCC (which is the whole goal).
Players *will* need to partially relearn the game, and their will be a time during which that adjustment will really hurt box players. But they will learn given a few months and then we will know for a fact that box players aren't doing anything that can't be done on a standard controller.
Hmm, in my honest and apparently controversial opinion, it's not a reasonable goal to have box-players do *nothing* that standard controllers can't. As it is right now, standard controllers do plenty things that boxes can't do, including really crucial things like optimal angles for recovery. The idea of current box balancing is that consistency comes at the cost of optimality. It's so fundamentally different from standard controllers that balance on each individual aspect just isn't feasible, but an overall balance across aspects is.
I can respect that some people feel like certain aspects are overtuned on box-controllers right now, but I simply can't respect the process for rolling out the proposed nerfs, and I very strongly disagree with the ways it is being nerfed. When it seems to me that it actually buffs spacies at the cost of making the controller feel much worse to use, it's hard to accept that the ruleset team is both competent and not spiteful. I would think that they either know what they are doing and lying about it, or they don't know, and thus they aren't competent enough to implement this in the first place.
Have any of the nerfs changed the way techskill is performed on the b0xx? We've gone 3 years of 'this is how you do x', if you guys alter anything you should probably include how it's done on the new patch. I had to find out from someone else that we now do the old ez version of ledgedashing (MX and down+in) instead of the hard version that gave more galint. Also heard that moonwalking was changed/nerfed? Seems odd.
Neutral SOCD impacts pretty much any technique where players depended on being able to press one direction without releasing the opposite. This includes mod 1.0 ledgedash (which I find difficult to believe is "hard"), float cancels, drifting, dashdancing, and possibly more depending on your specific use cases. Travel time will impact the timing of your button presses but shouldn't change their nature. The lockouts will impact you or not depending on whether you were using the motions that are now prohibited.
TAS moonwalk is still possible despite travel time and neutral SOCD since it's a 2 frame input.
At this time I consider UCF to be feature-complete and don't expect any future changes. I'm not ideologically opposed to a vertical throw range fix or a c-stick ledgefall fix, but these are outside the mandate of UCF and would have to be considered as a separate fix instead of being packaged with UCF (and aren't going to be pushed for by me). This is similar to how the polling drift fix isn't part of UCF but is often used alongside it.
Having talked a bit of shit on ult players and the like in the past, I vividly remember the humbling experience of popping in the Smash 64 remix discord and asking if there was a mod to use cstick and getting absolutely dunked on lmao
I’m not an ICs main or rectangle user so it doesn’t affect me either way, but would the control stick output fuzzing make it so some ICs desyncs are inconsistent? Or are the ranges on the legal ones large enough that the fuzzing won’t cause any random misses.
The ICs desync ranges are all single-unit inputs that become at best 50% chances with the nerf firmware. For the desyncs where the other 50%+ is a bad option (for example, both climbers fsmash in neutral), the coordinates have been left available for use. For the desyncs where the other 50%+ is a good option (for example, both climbers bair), the coordinates that desync plus the coordinates that when targeted can fuzz to the desync coordinates are banned.
Hi PTAS, love your work
I was wondering if you were looking at addressing accessibility to UCF and UCF patches. My local has been using a mix of setups with random versions of UCF and when researching to figure it all out, I had a hard time figuring out what was up to date, what actually changed, and where to find files.
I still don't know if UCF 0.8, which shows up on character select screen, is different than UCF 0.84, and how this differs from other setups that have UCF 0.73.
Yes, this has been a priority of mine recently.
As of now, UCF 0.84 is available as a UCF option under Slippi Nintendont 1.11.1 (please upgrade from 1.11.0, the implementation there is bugged). I have proposed to Fizzi that 0.84 be the default choice on Slippi online and future releases of Slippi Nintendont (it's ultimately his choice but I believe that we're aligned and this will occur). For cubes, gci files can be found [here](https://github.com/practicaltas/melee-gci-compiler/releases/tag/ucf0.84_2023-11-10). I'll also be making a Smashboards landing page as a permanent home with these details soon.
UCF 0.84 adds several new features relative to 0.8, as seen in the OP of this post. 0.8 adds wiggle out of tumble fix relative to 0.73. I highly highly recommend standardizing to 0.84 everywhere.
Unfortunately at this time we haven't been able to provide Greg Turbo with a nerf package that he can easily integrate into the frame1 firmware. It's our top priority right now though and hopefully you'll see movement on this soon.
Hello PTAS,
Sorry for the late question, I was busy yesterday(at a melee tournament of all things lol) and was unable to ask my questions. Hopefully, you'll still respond. My name is Robbie; I go by RROB | Kirbstomp. I have been playing melee since 2015. For the first 5 years, I played on GCC, and in the Fall of 2020, I switched to Boxx R2. I have been playing on it for 3 years consistently. As someone who has been on the PR in their state with both types of controllers, I can speak intelligently on the subject of Boxx legality. I appreciate everything you have done for the melee community, and I hope that we can all continue to build a great competitive scene together, but I want to be clear: I am NOT in support of these nerfs, and I don't think that the current rectangle controller ruleset needs to be changed.
With that said, since this is AMA format, there are a few questions I have for you regarding the proposed nerfs.
\- If digital controllers are so broken, why did no rectangle players make the top 8 at Big House 11? Surely a controller that is so broken that it needs to be patched would produce better results? Look at Steve in Ultimate... If there is a press-to-win button on the current layout, I'd like to know about it because I've been having a hard time finding it. At the end of the day, melee is melee, it doesn't matter if your inputs are digital or analog, you still have to beat your opponent. Saying that X controller is broken is taking away all the hard work your opponent has to put in to beat you. It's a john just like any other.
\- What is your opinion on the controller lottery?
For Reference Here Is Mine: A lot of the people speaking out against the current wave of new controllers are people who have enjoyed what I call "controller privilege". Players who have been in the scene for years and already have a fleet of OEMs ready on deck. Or even worse, the biggest antagonists to the digital controller movement, top players like Mango and Plup who, thanks to their fame and sponsors, have never had to worry about where their next controller comes from. It makes sense why top players who are given **priority treatment** in controller queues would prefer a world where they are automatically given an upper hand due to their controller. You mention in another comment:
>I don't think it's fair to be able to switch controllers and immediately get an advantage in tech chasing, dash dancing, and more just because the game was not designed with the new controller in mind.
Well, guess what, this is already the world we live in. Phobs, goomwaves, notches, z jump, trigger plugs, general stick box diversity... the customization options and variances in GameCube controller quality are endless. Box-style controllers **bring more consistency** to the controller meta. In a community with as little funding as Melee, the majority of players can't afford to spend hundreds of dollars on a nice controller. On top of that, controllers get worn with use, and the decently manufactured versions are no longer in production. A new player trying to find a decent OEM in the current market is out of luck, and that's assuming they even know what to look for. Yet here we have people telling us that the boxx controller is what's broken... I see box-style controllers as the thing that allows Melee to live forever. I see it as the great equalizer to the controller lottery. I see it as the future, and I see this patch as a scared attempt at maintaining the current broken system.
\- Have you ever played on a rectangle controller? What about the rest of the team proposing these nerfs? From this comment you made on this post:
>This includes mod 1.0 ledgedash (which I find difficult to believe is "hard")
It sounds to me like your team is an echo chamber filled with people who don't play on the controller. In all honesty, this comment rubs me the wrong way, and in my eyes devalues a lot of your arguments because it demonstrates how truly jaded you are on the subject. Diminishing your opponent's hard work simply because the input method they use is different will only serve to fill your ego and worsen your performance. Assuming there are no macros(which are illegal already) inputs on the box are just as difficult as the controller. You still have to put in all the ledge dash inputs(drop, jump, down, in, air dodge). Just because a controller is digital doesn't mean your inputs will be 100 percent accurate. Human error will still exist, and playing on digital controllers tends to exacerbate mistakes when they are made(1.0 digital input is a double-edged sword). Just because I play on a box controller now doesn't mean the game is any easier than it was when I played on a game cube controller.
\- There are plenty of top players that have switched to boxx, just to later switch back (Joshman, Leffen, etc). Have you ever honestly considered that the GCC is the better controller to play on? It's almost like the game was made to be played on it! It's crazy how intuitive it is in comparison to the Boxx. DI, recovery, character control, it all makes so much sense! GCC controllers are broken, why don't we also patch them to be equivalent to boxx controllers? After all, it's only fair that we all are on an equal playing field... /s
\- How would you respond if I asked you to change the way your controller worked today? All the training you have done up till now is out the window, and you have to start from scratch, clueless as to what practiced tech will no longer work the same. How would that make you feel? Oh and by the way, all your wins up till now don't count because the controller you were using was invalidated after the fact.
\- When will the goalposts stop getting moved? When Hax first proposed the box ruleset years ago, people accepted it. Now boxx players have started taking sets and people are blaming the controller. Let's say this patch goes through. When we adjust and start taking sets again are you gonna make it an 8 ms travel time? 10 after a boxx player wins a major? If we don't want digital controllers that is a different discussion (and one that I am slightly more receptive to), but to continually change the expectation is unfair to those of us who have invested time and money in these controllers.
Getting down to the nitty-gritty, I'll go through the proposed nerfs and share my opinion on them.
Neutral SOCD (both x- and y-axis) to prevent easy, instant changes of direction
\-This is the only change on the proposed ruleset I'd even consider. However, according to the Boxx manifesto, this makes empty pivots too easy. So it also has its drawbacks and still needs to be evaluated honestly by the larger player base
Limits on modifier buttons including a ban on L/R changing control stick output
\- Not a fan. As long as the GCC can hit the same coordinates then who cares what combination of buttons a box player has to press to achieve it?
Travel time simulation equal to the input speed of very fast analog sticks
Control stick output fuzzing which has almost no effect on the vast majority of gameplay but prevents consistent targeting of single coordinates
Limits on available target coordinates/angles that are difficult to consistently hit quickly on GCC-like controllers, such as Peach’s 2-frame no-setup Parasol Dash
\- Hard no for all three of these. This is removing one of the only benefits that a digital controller has, the digital aspect. The "buffs" that these nerfs are challenging are just features of a digital controller. If we don't want digital controllers to be legal, then that is a discussion separate from this one. On top of that, with notches players can pick any coordinate they want. So why limit what inputs digital can do? Lastly, according to your comments in this thread, you base your travel time on the average player. Why do you assume no box player would be better than average? How will any boxx player ever compete at a high level if we can only do our inputs like an average player?
Timing lockouts to prevent rapid burst SDI and instant pivot/crouch tilts
\- Wizzrobe's SDI is better than any box-style player. And Syrox would regularly pivot/crouch tilt on GCC. This tech is not about the controller, it's about the player and how well-practiced they are.
In closing, it would be ignorant of me to say that there are no differences between rectangle and GCC. Some actions are easier on digital controllers, just like some actions are easier on GCC. The basic fact that there are differences in input methods, doesn't mean that one is better than the other. Melee is decided by the player, not the controller. These proposed nerfs serve to make box-style controllers harder than they already are, simply because the people proposing them think they know more than everyone else who plays this game. There is no need for a change to Boxx, free Melee
Hi Robbie
* If digital controllers are so broken, why did no rectangle players make the top 8 at Big House 11?
I would say because comparatively few people have switched over at the top level. The best players in the world have been playing on gcc for a decade or two. A controller does not need to be broken to be clearly better than another. On top of that, not knowing whether TOs would ban boxes probably contributed.
* What is your opinion on the controller lottery?
Personally I think as long as a good OEM is a reliable choice, the controller lottery is in an infinitely better state than it was before UCF. Your average player does not need a modded phob to compete. Similarly, you're talking about boxes as though we're banning them, which we're not.
* Have you ever played on a rectangle controller?
I have not, but we have multiple team members who do. They challenged and questioned us along the way, and I believe the resulting ruleset is better for that. It was by no means an echo chamber. As for my comment on mod 1.0 ledgedash, I stand by it. I don't believe that it was at all necessary to change how modifiers work for this one interaction to get some goldilocks technique for ledgedashing that isn't too easy and isn't too hard. There are multiple ways to ledgedash on the nerf firmware that are unchanged from pre-nerf after accounting for travel time (not nsocd or fuzzing, just travel time).
* Have you ever honestly considered that the GCC is the better controller to play on?
I think that the two controllers have advantages and disadvantages relative to each other, but un-nerfed rectangle controllers' advantages outweigh gccs on aggregate. The gap to me primarily comes from, as mentioned, most top players having a decade head start on gcc. In the mid level you see way more players switching and improving than among those who are already at the top.
* Neutral SOCD
The manifesto is outdated and there are several empty pivot methods that are equally easy on 2ip. 2ip has an equivalent or better technique to almost everything NSOCD was thought to be too good for, and the handful of exceptions are outweighed by the huge area where 2ip is better.
* Limits on modifiers
/r/SSBM/comments/17t2g9y/hi_im_practicaltas_and_i_lead_a_group_proposing_a/k8ux1k9/
* As long as the GCC can hit the same coordinates then who cares what combination of buttons a box player has to press to achieve it?
This is more about lockouts and banned regions, but I strongly disagree here. Especially with internal coordinates, boxes can reliably get to some states multiple frames faster than even the fastest gcc, and do so more reliably. This is a massive advantage that manifests itself in the form of pivot tilts in neutral, optimal wavedash and ledgedash angles, and, less obviously, an actuation speed advantage that serves as a blanket buff to reaction speed across the board.
* Hard no for all three of these.
Travel time - as mentioned above, a clear, measurable, and universal improvement to your reaction time simply because you switched from a stick to a button. Obviously it's the hardest pill to swallow since it's the nerf with the fewest relative upsides, but the advantage is undeniable, replicable, and seen even in the fgc where leverless controllers are taking over. Melee is an analog game and the gcc should always be our benchmark.
Fuzzing - we added fuzzing to the test firmware and nobody noticed for days. The only people who hate it after using it were trying to take advantage of pinpoint coordinate precision in a way that is obviously unfair.
Limits on available coordinates/angles - I think you'll notice that boxx and frame1, among others, don't leave certain angles available because their manufacturers knew that full access to the entire analog range is too good on a rectangle. Where we disagree is in degree, not kind. And as a ruleset we can standardize across the board, since the current situation was the wild west with players ignoring the self-imposed limits since they weren't written down (or if they were, they weren't enforced).
* Lastly, according to your comments in this thread, you base your travel time on the average player. Why do you assume no box player would be better than average?
That's incorrect, we based our travel time on the fastest inputs, not the average player. This is already a favorable comparison for rectangles, since the fastest analog stick presses are inaccurate to the point of being able to leave the y-deadzone, which is not a risk for a button no matter how fast you press it.
* Wizzrobe's SDI is better than any box-style player. And Syrox would regularly pivot/crouch tilt on GCC.
Wizzrobe's SDI is better than what rectangle players currently use, not what they're capable of. There are known techniques for boxes to get 3 SDI in 3 frames, 4 SDI in 7 frames, and 5 SDI in 8 frames, all of which are beyond Wizzrobe's capabilities. I believe these techniques aren't widely used because rectangle players know that they're too good and were hoping they would avoid a ban on them by not spreading the word about them. These are what our bans target, not the average player performing average SDI. As for pivot and crouch tilts, our lockouts target the fastest possible human benchmarks - we asked for players who were confident in their speed to send us replay files of them performing these actions, with the result almost always being that they were slower on gcc than what our lockout prevented on rectangle.
* Conclusion
I respectfully disagree with your view, and your disparagement of our team. I think gccs have advantages over rectangle controllers, but I also think that un-nerfed rectangle controllers have more and greater advantages over gccs, and that every single one of our choices for this ruleset is justifiable.
> I believe these techniques aren't widely used because rectangle players know that they're too good and were hoping they would avoid a ban on them by not spreading the word about them
what
If this actually goes thru, please include a WASD style firmware for the boxes as any of us who don't use standard layout box firmware are basically stuck not being able to play in a legal capacity
I'd certainly like for the team to make that available, it's just a matter of time required vs available vs other priorities. The nerfed HayBox firmware is open source and in the worst case scenario a knowledgeable user can apply a WASD style layout to it.
Is there a "polling luck" issue for tap jumping with Peach similar to the dashback issue?
With Peach you can enter float by tilting the control stick up. So if I want to tap jump with Peach, but the game reads my control stick halfway to the gate I could get a float by accident due to polling right?
If so, will this get addressed in future updates?
There is not. The control stick range that floats with up is the same range that double jumps, and is only possible to use when double jump has been turned off because you tilted slightly up for several frames. You can only get a float by accident if you performed an input that wouldn't double jump with any other character.
To what degree do you think these nerfs will address the stigma against box controllers?
Additionally, do you expect these nerfs to have a stastically significant impact on box-player performance? If so, to what degree and on what time-span?
I understand this is a very non-technical question that is impossible to answer with certainty, Im only looking for your perspective
edit: Change to second question
I think it'll be a small but clear net improvement. Of course there will be players who can't be reasoned with, but imo most people will be able to tell that box controllers have been nerfed.
I don't expect a significant change in the average box player's results beyond the initial adjustment period. I think that players who depend more on the pieces we're banning (2ip, mod 1.0 ledgedash, etc) will have longer adjustment periods though.
Thoughts on having the game enforce the rules rather than the controller? Ex. If any controller were to try to break any of the rules in place for a boxx type controller for it to be nerfed equally, such as a player using wonky asdi on analog to be held to the same nerfs implemented on firmware used by digital controllers
As mentioned elsewhere, this requires very specialized expertise that we don't currently have available, and will impact maybe 0.001% of the gcc/gcc-like playerbase. Not to mention, many of the nerfs are impossible to enforce in a reasonable way on a gamecube: at the gamecube's polling rate, travel time on a box would be random; the cube itself has no way to know for certain whether a controller is a box or a gcc and so doesn't know whether to ban certain coordinates; and some bans such as neutral socd and modifier changes must be controller side since the gamecube has no knowledge of those inputs.
No, we consider notches to have been in widespread use for far too long to be sensible to ban, and too time-consuming to regulate in any reasonable capacity at the major level. Even with the proposal as written, we aren't expecting TOs to manually look at anyone's controller.
ngl it's pretty disappointing that these are the reasons. Notches are very clear, you can just look at the controller (unlike box software). I really don't see how this would be a burden to enforce. And them being in use for too long really shouldn't matter...
Personally I think it's impossible to reasonably look at a notch and be able to confidently say "this is illegal" in a way that can be unambiguously written down and feasibly applied everywhere. The gray area is just too large.
I’m sure there would be edge cases but I feel like 99% of notches you would question are obviously custom notches. To me it’s frustrating that we’re all acknowledging that it’s cheating and everyone does it, but we won’t ban it because maybe we can’t 100% guarantee that we cover every single situation. If it was banned the vast majority of players would just swap to an unmodified shell.
Personally I consider notches to be on par with other easy hardware modifications such as removing a spring or filing down your buttons, not cheating. I also don't think it's fair to say "just swap your shell", that's requiring a giant proportion of the community to change their hardware.
I feel like notches have a way bigger impact on gameplay than button/trigger mods and are worth treating separately. Also don’t think it’s unreasonable at all to tell people to swap shells if we’re considering notching a basic hardware mod.
Regardless, I’ve said my piece on this and I fundamentally disagree with a lot of what you’re saying but ty for responding.
I think removing a spring is on a different level than those 2 other things, it genuinely only requires the appropriate screwdriver, and there is no way to fuck it up so bad that you make your controller worse or unusable as a result.
Having notches being legal requires a bigger portion of the community to pay controller modders to mod their OEMs if they want to be on the same level as the competition. Plus, now you need to pay for OEM + mods instead of just an OEM.
If we're going to value how much of a hassle implies each scenario for the player base, then clearly removing notches is the way to go.
could you elaborate on this? how can it be ambiguous when all controller shells look the same? if you see a notch that isn't OEM, that's illegal, right? i'm not seeing where the gray area is
Consider some players have, through multiple years of use and without ever putting them to a file, ground their control stick rims down [entirely to a circle](https://twitter.com/MNMattt/status/1279209068201152512). In the same way, it's entirely possible to create a notch through hitting the same point enough times through gameplay. At what point does that notch become illegal? Can you define that? Does it ever become illegal if the player didn't intentionally make it? If not, what makes it different from a notch that looks identical but was man-made? If I wear my shell down enough, can I get dq'd from an event even though it was legal last week and the only thing that touched it since was the control stick?
Can you write any of this down in a way that's more solid than "Notches are banned, and I know a notch when I see one"? And if you can, can you expect a TO or a pool captain to enforce it, repeatably?
i think this thought experiment falls apart when there isn't a single instance of this ever happening intentionally or not. people do grind down their rims, yes, but nobody has ever slapped the same spot on their controller for hours and hours and hours to make a "notch" and i think it's disingenuous to consider that a possibility.
i think that a deliberate notch is apparent. they don't appear as regular wear. if there is a single case of this happening, then perhaps comes the time to reiterate rules, but it has literally never happened before...
edit: to clarify my stance on your other question, regular wear is fine. it's the deliberate wearing of specific locations that notches come from, and that would be banned. considering it has NEVER HAPPENED where someone's gate is worn exactly on the wavedash coordinates just from regular play, i don't know why you'd even consider that. everyone uses external tools to accomplish this.
Just because you've never seen it doesn't mean it's never happened.
Beyond not thinking that it's possible to regulate them, I also don't think notches are a problem or worth banning even if they were regulatable.
if you want to suggest so strongly that it happens, without a modicum of evidence to prove it, then i have nothing else to say... i'd prefer rulesets to be written by someone who is grounded in reality where notches don't spontaneously occur from years of gameplay.
thanks for answering my questions!
The gate can deform in such a way you have access to values that are notched for, primarily the diags being deformed shielddrop notches being a common one (very uncommen to be notched for nowadays with UCF but it's the most commen example.)
That said, there is no way to supply evidence of this cause one could always argue this was modified via an external tool. Can a controller consistantly degrade to give access to Y+/-3000 ? No. The problem then becomes, where do you draw the line that isn't left open to interpretation? Also if those were banned, should digitals be limited to only rim and diag values? Or should the fuzzin be a grid of 2in and 10rim?
There’s no shot anyone has notches that look like they do on my gcc from normal wear and tear lol. You’ve spent too long debating abstract arguments in discord.
What fantasy land are you describing where people are manually wearing down wavedash notches into their shell through gameplay? Even if a TO is somehow too braindead to identify a non-OEM notch, there is no downside to enforcing the most strict interpretation of the rule. If someone has anything even remotely approaching a notch, then all they have to do is replace their faceplate with a stock one.
I absolutely think it's fine to sacrifice the incredibly small number of players with very worn down controllers at the altar of banning notches
Also, if you think about it, a worn down gate is kind of the antithesis of a notch
Have you considered a rule like "each stick is allowed a max of 8 notches" (because OEMs are made with 8 notches). A rounded stick (0 notches) or deformed notch from wear and tear due to gameplay is legal but you cannot have any additional notches for firefox angles etc.
If a TO can pinpoint a specific coordinate region on the controller it's a notch. Card game tournaments do perfectly fine DQing people for marked cards/sleeves using the same method (if the TO can cut the deck to a specific card, that card is marked)
I don't think it's a big ask for pool captains to say no to notched controllers. There is no such thing and there has never been such a thing as a "naturally notched" controller, it's extremely easy to see if someone has done it. With the emphasis on making sure Melee isn't pay to win, or that people who have more expensive controllers can't make the game easier to play, I'm really disappointed that no plans to ban them is being even considered.
People shouldn't be able to buy a way to make the game easier, or to make THEM AS A PLAYER more consistent. Controller tech should only go in the direction of making the CONTROLLER more consistent, not the player (as notches do).
Genuinely curious, do you volunteer at events? There are already a lot of asks of pool captains, I think adding on inspecting controls and arguing with sweaties about whether that little nick that "totally got there by accident" is legal or not is actually a big one.
Okay, sure, but by that logic any form of box controller should be totally banned as well. Those are a way bigger issue for improving player skill and consistency than notches ever will be.
I’m not very knowledgeable about controller stuff, can you explain why notches are such a big deal? My friends who take melee seriously all did their own notches. What kind of specialized knowledge do they require that makes them an unfair advantage? Would I not be capable of taking my OEM controller and carving notches with a file myself?
If they don’t require secret knowledge and I can add them in my garage, why are they more problematic than, say, taking the springs out of the triggers?
Notches allow you to hit precise analog angles with no risk. Max angle wavedashes without risk of airdodging straight and max angle shallow/steep firefox angles without the risk of going straight are the two biggest examples. There's no reason you should be able to do this. The knowledge required to do it doesn't matter.
And UCF takes away the risk of side dodging instead of shield dropping and dashback polling. Notches are just another tool to help the player do what they want to do.
My question is how "pay to win" is it? I've seen on here that it is both prohibitively expensive, and also that it's not hard to learn how to do yourself.
Notching your own controller is so easy. You need a triwing screwdriver, a jewelry file and a out an hour of your time.
It's a ~$10 investment and not difficult as long as you are patient.
Note that I’m not talking about shield drop notches because there are vanilla gccs whose notches align with the shield drop values.
Again it’s not about being p2w.
Personally I think it's impossible to reasonably look at a notch and be able to confidently say "this is illegal" in a way that can be unambiguously written down and feasibly applied everywhere. The gray area is just too large.
Not to open a can of worms but notching your controller yourself is about as hard as soft modding your Wii so you can load ucf. I don't agree that only $200+ controllers can be notched reliably.
I still think there's an argument for banning them but I don't think it's accessibility.
It has been so good for my mental health to read this comment and be reminded that the competitive community is in saner and more capable hands than those of the average /r/ssbm commenter.
When it comes to these rulesets, from my understanding, it is to limit the performance of a box controller to perform at an equal level to a GCC to create an "equal playing field". Such as restricting SDI to the peak level of a GCC.
I can sympathize with these concerns since these are actions that would be extremely difficult for a GCC player to perform.
What I fail to understand is the imposed restrictions on box configuration (not allowing L/R to be used as modifiers). This doesn't nerf the potential of the box controller but the user - those that have been playing under these configurations for nearly 6 years. What is your response to this?
There are two reasons to remove L/R as non-dedicated modifiers.
The first is that gcc users are not able to choose or ignore their notches based on the buttons they're pressing, so we felt that it was unfair for a box player to change their angles based on buttons pressed as well. The only remaining non-dedicated modifiers are b, which is not permitted to change angles, and the c buttons, which we left in as a legacy choice for people with limited hardware (only allowed with <=2 modifiers) and don't have any abuse cases when it comes to pressing a c direction and a control stick direction at the same time.
The second comes with travel time. If travel time is applied, and pressing L or R changes the angle that you're pressing, then your angle will be moving on the same frame that the game is polling your controller for your wavedash angle. Thus, the output angle is entirely random from your perspective (though it truly depends on the number of milliseconds between the button being pressed and the controller being polled). We felt that this was highly undesirable behavior.
Part of my issue is that box controllers are already limited on achieving angles and there is an assumption that all box controllers achieve angles through dedicated modifiers.
My (custom) controller in particular, doesn't have a modifier button but instead has 6 directional buttons. In order to achieve certain angles, it's necessary to use other buttons (L/R) as modifiers. Even though, my particular situation is an edgecase, I do know many box users do use L/R as a modifier.
I just have trouble seeing the purpose of this change other than to make things more difficult for box users - especially those that have been playing with these configurations for years. From the perspective of a GCC player or spectator it would be impossible for them to tell whether this restriction was in place.
I would ask for sympathy for those that are actually affected by some of these changes. Some of these changes have negligible effects on actual gameplay but severe downstream effects on box users.
Sorry but a controller with 6 directional buttons is not something we'd consider legal under the rules, as it violates 1:1 mapping with an analog controller. 1:1 is one of the core tenets that underpin this entire ruleset and removing it would radically change it from top to bottom.
I'm sympathetic to players that have been able to play on certain layouts or with certain options that are no longer available under the new rules, but "it used to be legal" is simply not a justification for keeping something legal. We didn't anchor the proposal to what box players are used to, we anchored it to what we felt was fair to bring parity with gcc-like controllers.
Not allowing 6 directional buttons makes zero sense to me. I don't understand how 4 directional buttons is closer to a 1:1 map of an analog stick. There are 360 degrees in a control stick.
Not PTas, but 4 buttons makes sense in my brain as a "direct" mapping of the maximum points of either axis. Each axis (X and Y) has a positive and negative maximum, and 4 buttons would map to those X+, X-, Y+, Y-.
Basically the 4 cardinal directions and then two additional buttons for walking left and right. Without getting into the specific values:
Up (in utilt range),
Down,
Full Left (Dash),
Full Right (Dash),
Half Left (Walk),
Half Right (Walk)
I think it's pretty clear that your half walk buttons are on the same axis as your dash buttons, and your comment above about there being 360 degrees on a control stick doesn't justify their legality. One or both can be pretty reasonably changed to modifiers that, when pressed along with a dash button, output the same coordinate they used to.
Well the 1:1 mapping still doesn't make sense because an analog touches all 360 degrees and everything in between.
Regardless, I don't understand the rational that I would need to change my "walk" buttons to modifiers just to satisfy some arbitrary rules of how directional buttons should be mapped. I don't see how this restriction is warranted and how it accomplishes anything.
Box controller must always use 4 cardinals until the end of time now? These types of restrictions put a lot of limitations on future iterations and innovations of controllers going forward.
After having spoken with the team about this, I think my main concern is being able to have walk buttons and dedicated modifiers at the same time. It's not something we'd have ready for the initial release of the ruleset, but I can see a later revision allowing, for instance, 2 partial input buttons per axis as long as they adhered to legal coordinate rules, used additive neutral socd, and applied input fuzzing as described in the proposal. We also would probably be fine with a "low resolution analog stick" which is a single actuator that outputs a limited set of coordinates (again adhering to the above rules). Analog buttons are already legal. I think the rules as written can and should evolve as (but not before) new ways to play are developed.
This depends on your technique. If you are holding left and want to dash right, the average gcc player probably gets from gate to gate in 8 to 12 ms depending on whether they are trying to reactively move as fast as possible or time a dashdance without expending unnecessary energy. On a box, that number is 6 ms if you release left before pressing right, and 6 ms + the amount of time you're still holding left after you press right if you press right before releasing left.
With the development of the adapter that gives xinput controllers usage in gc, do you see these rules (and the traditional rules already in place) having to be changed in the future? See @RobertDaleSmith on twitter for the deets on that, but it gives most usb controllers access on GameCube and Wii
It (mildly) nerfs chain grabs relative to someone playing against the average OEM yes, but in the grand scheme of things it's quite a minor difference. For example Peach uthrow against port 4 Fox at 0% doesn't combo into dsmash at 0%, but [does combo again after 1 (inescapable) pummel](https://twitter.com/Violent_Lee/status/1537677705151275009).
In the grand scheme of things, enabling consistent dash back is a significantly larger balance change but was fairly universally seen as worth it because failing to hit your dash backs through no fault of your own feels very bad. I consider 1.0 to be similar but to a smaller degree.
1.0 cardinal isn't new, some OEM controllers can hit it naturally. UCF is meant to flatten inconsistencies between random controllers to avoid the "controller lottery", and since 1.0 cardinals are technically achievable on a normal, unmodded controller, this changes very little assuming the best players spend the time seeking out the best possible controllers (which they did in the pre-UCF days).
* Did you account for the inherent drawbacks of a digital controller when deciding on nerfs (less available angles, limited drift options, only a few WD lengths etc.)?
* When nerfing digital controllers what top-level players on digital controllers had direct input? The only one I've seen who is fully supportive is Swift.
* I've seen multiple top players say the travel time ruins digital controllers for them and they are considering quitting melee if it goes through. The obsession with GCC parity seems like it is outweighing practical implications of this change. I haven't seen anyone argue digital controllers are OP because you can move the stick faster and you are already nerfing SDI. Is it really worth alienating part of the player base and potentially reducing player count to add 6-12 ms of lag in the pursuit of "parity"?
* Yes, of course. Even now there are plenty of things a box controller can do better than a gcc, or as good as the best players on gcc. The goal isn't parity in every little aspect, but parity overall with trade-offs.
* We have had a discord server for over a year where players have had the opportunity to provide feedback (and for the past several months, test the firmware). Not saying that the players endorse or are even ok with the end result, but the following notable box players and box-using TOs are in that server: Zuppy, Pipsqueak, Swift, Joey Donuts, gahtzu, kins0, McCloud, DarkHero (recently added), dhir, unsure (recently added). This has been a long time coming and the players have been given a lot of opportunity to provide feedback.
* I would say that's a particularly loaded question. I don't think it's fair to be able to switch controllers and immediately get an advantage in tech chasing, dash dancing, and more just because the game was not designed with the new controller in mind. Ultimately, the final decision rests with TOs, and they will have to decide whether to use the rules at their events knowing what impact it'll have on their players. I'm not a TO, I'm not a controller modder, I'm not a top player, I'm about as impartial as you can possibly get when it comes to this.
The feedback, in general, is between strongly negative and "I don't like it but I can live with it". This isn't intended to be calibrated to how strongly box players react to it, because then they would be incentivized to overreact in the hope of getting the whole thing cancelled. We believe that the proposal as written is worthy of bringing to the TOs, and it's their call whether or not to use it at their events.
My uneducated opinion is that the travel time nerf is the only misstep here. I think you are undervaluing maintaining a fun to use, durable, reliable controller for the game and overvaluing the "technically" correct decision.
I think the negative impacts on the scene of a travel time nerf far outweigh the potential unfair advantage digital controller players get from an instant travel time. As a F1 player I haven't had a chance to test it so it's possible I'm overreacting but I am concerned after seeing the responses of a few top players I follow. This change has the potential to lose a number of players, myself included pending testing. My last local was about 50% digital controllers, and I wonder how many of these players will move to another game if all these changes go through.
I respect the work you've put into this proposal and hope I am incorrect.
> I think you are undervaluing maintaining a fun to use, durable, reliable controller for the game and overvaluing the "technically" correct decision.
Why is the subjective fun of a 3rd party controller more important than the competitive integrity of the game?
I didn't say it was more important. Both things are important and you need to find the right balance. If we only cared about the competitive integrity of playing melee exactly how it was designed we wouldn't allow UCF, Slippi, Phobs, Z-jump, or notches.
Keeping the game fun and accessible for a portion of the community is a valid goal. Especially for a 20+ year old game that doesn't have a massive influx of new players.
> I haven't seen anyone argue digital controllers are OP because you can move the stick faster
search this reddit for "travel time" if you want to see quite a lot of people arguing this
not pTAS, obviously, but the travel time nerf has a tendency to draw out extremely strong initial reactions from people and then not actually be nearly as noticeable as they thought it would be. outside of that aspect, yes, if people feel alienated by parity, then it's worth alienating them
Agreed. Making box controllers as similar to a GCC is just not practical/necessary on all levels. There is a severe cost on that of the box user to have to deal with arbitrary/artificial nerfs.
Keeping these rulesets pointing towards the more noticeable and isolated effects of box controller gameplay (SDI nerfs, angle limitations) makes more sense to me.
I'm seeing this AMA late, but I really hope you get back to me! Most of my interest is from the UCF update and not the digital controller proposals.
1) The UCF code is a black box for 99.9% of players. Will your team be providing any code documentation beyond just stating your general intentions? I strongly believe the community should be able to know the algorithms used for things like shield drop modifications or input correction.
2) At local tournaments, it's been my experience that on the current version of UCF, the most overwhelming source of OEM controller issues are snapback related. Is there any plan to address snapback within UCF?
3) UCF is considered a software-level mod for fixing controller input discrepancies. Do you believe a software approach to these problems is better than a hardware approach? If so, why?
4) The [team mentioned for this proposal](https://twitter.com/PracticalTAS/status/1718689687697498158) is missing most of the members from the original UCF release (IE, tauKhan, Kadano). Do these people have any involvement/stance on UCF 0.84?
1. On top of the compiled gecko codes being open source as Frost mentioned, the source code for UCF can be found [here](https://github.com/AltimorTASDK/ucf/tree/master/src) and I plan on making a documentation page available on smashboards in a more human readable format.
2. Unfortunately we don't have a reliable way to fix snapback on the game side since the gamecube/wii doesn't poll the controller often enough to accurately determine what is snapback and what looks like snapback but isn't. I believe it needs to be done controller-side to be done properly.
3. I much prefer UCF for fixes that are possible to be done game-side, yes. Making a change without requiring your players to do anything is highly preferable to the alternative.
4. All the other members of the original team are inactive now. We discussed most of the changes that eventually made to 0.84 2+ years ago (all except the SDI frame 1 fix, which was brought to my attention by Altimor later) and were aligned on their inclusion. I've kept them up to date on the changes as they were implemented, and to the best of my knowledge their stance remains in favor of the new version.
Heyo, I'm Frost. Not PTAS but also part of the ruleset team. Despite not being him, I think I can answer some of these and pass along others to TAS.
1. The UCF Code is hosted here: [https://github.com/practicaltas/melee-gci-compiler](https://github.com/practicaltas/melee-gci-compiler)
2. There's no way to correct for snapback without significantly re-working the game engine or making non-stealth toggles. Fixing snapback is likely out of the scope.
3. I'll ping him on this
4. I cannot speak for the others, but I do approve of the UCF 0.84 methodology - which is to never make inaccessible something that is already accessible.
How much contact has there been with Hitbox developers in regards to these proposed rule changes and nerfs on Smashbox? Does it look like it will mostly just come to locking out certain input values on their customization software for Melee profiles or has nothing that specific come of it yet?
Additionally is there any plans to create a branch of the firmware that does not rely on c stick modifiers to reach additional angles? Or is that far enough down the priority list to effectively be non-existent for the forseeable future?
We've been in contact with them and will provide them the same spec as the Frame1 team to ensure that they can apply the nerfs within their firmware. I'm not sure what the end result would look like on their side.
It's not high on the priority list but I don't think it's unreasonable to want one that works similar to the standard smashbox setup. In the worst case scenario the firmware is open source and it shouldn't be too hard for a motivated community member to DIY, but I hope it doesn't have to come to that (unless said community member wants this done, like, within the week).
Breaks stealth unfortunately. UCF is meant to be useable everywhere, and any method of toggling anything is a risk that some TOs won't be willing to take.
Couldn’t you just have it be a 20XX type command on the CSS where you press dpad down + X/Y or something to swap X/Y and Z? Wouldn’t that not break stealth?
I am absolutely against toggles in any way, especially ones that can be turned on or off by accident. We don't need 1) blatantly obvious ways for someone to test whether UCF is active on a tournament setup and 2) an opportunity for players to blame us if they accidentally turned the toggle off, forgot to turn it on, or accidentally turned it on because they didn't know it was an option. UCF is meant to be universal and apply to everyone equally, even players who have no idea that it's active.
To Nintendo, yes. One modifies their IP, the other doesn't. One is the responsibility of the (possibly officially licensed) tournament organizer, the other isn't.
With the legality of controllers like phobs/goomwaves do you think we have dug ourselves back in the hole we were in before UCF? As in, controllers feel more like a lottery/luck?
It basically is luck because information about which modders are actually good is hidden in a discord that is only posted in one place tbst doesn’t have a lot of visibility.
Everyone’s seen how top players pick a modder and get screwed, and they have more info than we do about who is good.
As u/DreadPirateAlan said, it's not easy and nobody's paying us for this. On the other side, controller modding and manufacturing are both (probably) million dollar industries and the professionals there have a monetary incentive to move fast and encourage TOs not to look too hard at what they're doing as long as they're not blatantly breaking the rules as currently written.
Yes. Neutral SOCD is meant to prevent easy, instant changes of direction, but has absolutely no impact on an initial dash from neutral. Travel time has been calibrated based on multiple high-resolution tests, all of which have confirmed that there's roughly 5 ms (1/3rd of a frame) of advantage to pressing a button relative to pressing a stick past the dash threshold.
could there be changes to the amount of time of the timing lockouts? I find 8f for pivot dtilt too slow, my record on gcc is 5f from the pivot input -> dtilt input, and i can somewhat consistently get 6f. on frame1 i also get 5-6f between pivot and dtilt input on a pivot dtilt.
The dtilt lockout in particular is poorly written and I need to fix it. On the firmware side you are locked out from the dtilt-from-neutral range for 8 frames, but if you crouch for 4 frames you disable control stick dsmash and instead dtilt from the dsmash-from-neutral range. So while the lockout prevents you from sending specific coordinates to the game for 8 frames, the coordinates it allows still let you dtilt within 5 frames.
ohh ok ty! yeah then it makes a lot of sense. doing tilt input to instantly dtilt would be insanely hard to do on gcc and much easier on box controllers
Hi PTas! Your episode on GGRadio melee was superb, thank you for being awesome yourself and everything you do! I think the proposal is great and look forward to the growth these kinds of conversations promote in the community
Shield dropping is already so ridiculously lenient compared to vanilla, why would you possibly need to make it more lenient? We now have the ability to calibrate notches (either through the game itself or through controllers like phobs), so there is no downside to using this method instead. With notch calibration and vanilla shield drop ranges, all GCCs will be on an even playing field while bringing them more in line with vanilla. I already notice issues with being able to angle my shield down+forward/backward while on plats because of UCF; there is no reason to make this even worse as well as dumbing down the mechanic further. Shield dropping on vanilla was never some super imprecise input, even when you had perfect notches.
The new shield drop change is specifically for OEMs that shield tilt at the notch when they intend to shield drop even with UCF 0.8 - if you instead have trouble intentionally shield tilting on current slippi you would find the same on vanilla. We applied the tilt intent algorithm to the new range and required being in the range for 2+ frames, both to minimize the impact on existing attempts to shield tilt and prevent any change from occurring for people who are currently able to shield drop. I think you'll find after testing that the impact is far less than you think it could be.
I get that the intent is to help OEMs, but unless I'm mistaken this change is applying to all GCCs, right? If you're using an OEM you should either be notching your controller or calibrating it in the game menu before playing. Can you give a good reason why we still need expanded shield drop ranges? If you were at least opposed to notching then that would make a little more sense, but you don't even want to ban firefox notches...
For people using phobs where the notches are calibrated accurately, the map you provided [here](https://twitter.com/PracticalTAS/status/1723459584122061193) suggests that even if I don't reach the notch, if I'm trying to angle my shield from the side I will constantly be accidentally shield dropping. I don't see how a 2f limit helps either since obviously I will be staying in that range for multiple frames. The entire yellow area will now be off limits for this kind of angling, not to mention you're just making the mechanic of shield dropping way too easy overall.
This is all such a messy solution, and if there were no better alternative I wouldn't care, but notch calibration allows for a very elegant solution that utilizes the games natural shield drop values to be used.
Yes, the vast majority of controllers should be able to consistently dash back out of crouch given enough practice with the motion. The main exceptions will be very old controllers that are also failing in other ways.
Asking late but how is ~~input delays~~ travel time going to be implemented? Is it just some interpolation between the two points? If it's interpolated, will it be a linear or closer to an accelerated interpolation? Is there a minimum/maximum speed at which interpolation must be done? If your input changes for some reason in the middle of a motion, does the interpolation algorithm restart from the last interpolated point you were at?
Is there a difference in travel time for a full left to full right motion vs a left to neutral or a left to slightly less left? Is this a linear relationship between distance?
Does implementing buttons for an analog joystick on the same "plane/face" allow or disallow paddles on a GCC or other pad style controller? Example: up and right controlled on rear right hand paddles and down/left on rear left hand paddles. These *could be* viewed as same face, but definitely not as same plane. If they were implemented as buttons on the grip rather than paddles, would it change the ruling?
A logical extreme of the rules, but does having buttons on a spherical surface count as same plane or no? If it's accessed on a ball held in one hand with positions that are non-planar to each other, how do the rules affect this?
Edit: What is the reasoning behind fuzzing being 50%/25% and 25%/12.5%/6.25%? Is there measured statistical evidence for the distribution of analog sticks on notches? If so, are these published or available with the testing methods anywhere? Also I might have missed it, but are Phob notch calibrations held to the same output fuzzing standard that box controllers are?
Interpolation between start and end with a defined length of time for the jump. Currently linear but we are investigating accelerating cubically instead. Speed is defined indirectly by the time requirement. Input change in the middle of the motion results in a new motion from the currently interpolated point.
Full left to full right has a faster minimum than left to neutral or left to slightly less left but in practice will be slower because full left to full right will usually be interpreted as full left to neutral to full right due to nsocd (ie rewarding players who are more accurate with the release + press).
Paddles are allowed in general as long as you don't violate 1:1. For c-paddles that sounds fine to me, the final wording should allow it imo. Same for buttons.
Same plane rule will have a maximum angle deviation requirement to allow curved faces but not allow circumventing the rule by arguing that opposite sides of a sphere are the same plane. Final wording tbd but it'll probably be around 10 degrees.
Fuzzing reasoning is primarily for ease of calculation on low power devices (minimizing number of cycles needed). When I notched my 1.0 cardinal I approximately got 30/40/30 so 50/25 is close enough and is implemented as rng with 1+2+1=4 buckets. 25/12.5/6.25 is similarly 1+2+1+2+4+2+1+2+1 = 16 buckets and trivializes to 50/25 when calculating on one axis. No published notch evidence unfortunately. Phob calibration does not have fuzzing enforced as they are analog inputs and physical notches.
Thanks for the reply! I don't remember what it said in the doc, but is it planned to address Phob and analog calibration fuzzing to maintain parity between stick and button ruleset implementations?
There are limits on the size an individual coordinate can change via phob recalibration to prevent targeting individual coordinates in the same way fuzzing prevents targeting individual coordinates on a rectangle. Different implementation but same intent.
They're separate fixes, but I recommend that polling drift fix is used and have [included it](https://github.com/practicaltas/melee-gci-compiler/blob/main/ucf0.84/ucf_data/ntsc1.02/polling_drift_fix.mgc) in my UCF 0.84 memory card.
[Here you go](https://twitter.com/PracticalTAS/status/1619243481721110529).
* Yellow = 1.0 on UCF 0.84
* Red = 0.9875 on UCF 0.84
Vanilla 1.0 is the bright yellow dot, plus the dark yellow dots on the exact same row as it (a 1-unit-high line)
Why not make the rule be: digitals are banned, purchase an ergonomic analog controller instead?
Why 1.0 cardinals? This is just a balance patch. There’s no reason to artificially make everyone faster after 20 years.
not ptas but a lot of controllers (oem and phob/goomwave/rectangles) output 1.0 cardinals, its more for standardization than pushing the limits of the game or whatever. a lot of ppl are already using 1.0 so its only making the .9875 controllers faster (and even then the difference is so negligible it barely makes a difference in regular gameplay)
Re banning boxes: There are legitimate accessibility reasons for keeping box controllers legal. We don't want to give people no choice but leaving the community if we have the option to let them keep using the hardware they're comfortable with. And even without that necessity, I don't begrudge anyone who decided that gcc-style controllers weren't for them.
Re 1.0: /r/SSBM/comments/17t2g9y/hi_im_practicaltas_and_i_lead_a_group_proposing_a/k8ua4w6/
Just what melee needs, to be a more expensive, harder to get into hobby, while alienating the many people who play on digital controllers already. Brilliant.
I really wish that the dbooc fix went further. I don't think this is going to move the needle in terms of offering consistency to dbooc across all controllers.
Having given top players the code for the additional dbooc frame window, and having heard their feedback that it makes dbooc too easy to the point where they were still dashing back with intentionally poor inputs, I think going any further is going too far.
I don't see an issue with erring on the side of it being too easy rather than too hard. Shield drops are incredibly easy nowadays when they used to be much more controller-dependent. I can shield drop with near 100% success now, when that would've been a pipe dream 10 years ago. And this is due almost entirely to UCF
You could shield drop with near 100% accuracy until you wore down your notch, prior to UCF. Ignoring bad polls, a practiced player can already dbooc with near 100% accuracy.
> You could shield drop with near 100% accuracy until you wore down your notch, prior to UCF
I'm talking about an unmodded controller without notches. Unless we just want to require everyone to get notches now?
> Ignoring bad polls, a practiced player can already dbooc with near 100% accuracy
"Ignoring bad polls" is doing some heavy lifting there.
I'm sure you have actual stats on this, from the sounds of it there was a lot of testing the changes behind the scenes. What are the actual success rates for dbooc in vanilla vs. UCF 0.84. How are the success rates affected by having an unmodded controller vs. notched vs. rectangle vs. whatever else?
One of the primary motivations for UCF was that depending on the orientation of your stickbox your standard controller diagonal notch could give you a 100% success rate on Axe/Sung shield drops or near 0%.
We had players test on OEM with a 95%-98% success rate, which is consistent with somewhere between the majority and all failures occurring due to the bad polls that 0.84 fixes. When I say ignoring bad polls, that's what I mean.
Given the right motion and speed, shield drops and dbooc on 0.84 should be equally reliable assuming you have a half-decent controller. The difference is that most players don't currently know whether their dboocs are failing due to polling or due to not performing the motion fast enough.
I'm a bit confused. So the 95-98% success rate is for shield drops on an OEM with UCF 0.84? And how does that success rate compare to the success rate for dbooc under the same conditions?
Do you think the scene needs a new central organizing body to better coordinate between the different facets of the community?
It feels to me like several recent events in the scene would have been better handled if there was a central authority instead of it just being an open season shouting match here on reddit or Twitter.
In general the various stakeholders in the community already work as a loose organizing body. Something more formal could be good, but I think that the forces which lead to a central organizing body, such as developer support or other monetary incentive to work collectively, are not present in the Smash community. So we work with what we've got.
No, but we have discussed re-allowing certain aspects that the current rules ban (for instance, a foot pedal) at a TO's discretion for handicap accessibility reasons.
I don't think the box needs any more nerfs than what Hax has already done, but do you seriously not see the problem with creating such a huge divide with the firmwares, where some events will be running nerfed firmware and others wont?
Is there a reason to enforce neutral SOCD outside of "make the boxx less comfortable to use"? It doesn't change the parity with GCC at all, it just trades a button press for a button lift on most tech.
Our hands have stronger muscles to contract than extend, so "Last Input" SOCD is often preferred for comfort. Enforcing neutral SOCD feels spiteful, rather than banning techniques that are "GCC impractical" it just makes rectangles worse to use.
Enforcement of neutral SOCD is intended to slow down and make more difficult the instant, easy changes of direction that are practically the hallmark of 2ip box play. While it's arguable that NSOCD is worse than a gcc stick in some (not many) aspects, it's quite clear that 2ip SOCD is significantly stronger from top to bottom. It's not spite, though.
I installed the nerfs on the test haybox to my LBX and really feel good about them thanks so much for your team's work.
My question is if I am using the nerfed firmware does using a setup using UCF with the nerfs additionally affect my controller?
Lots of respect for what you're doing but I can't help but feel like the melee community really rushed into accepting Boxx type controllers too quickly, and that all these nerfs are things that should have been there from the start as opposed to being added in a trickle afterwards. It gives me a somewhat uneasy feeling that what feels like clear-cut cases like travel time simulation are only being implemented now
Great work, though
I have to say that the socd rules are always set to the same for x and y, but in reality the reasoning *always* has only to do with x axis shenanigans.
Do you have reasoning for the socd specifics applying to the y axis, with specific examples? I'd be very interested to hear, if so!
The main thing socd on y axis affects is causing misinputs when you are recovering and try to press up b while accidentally still holding down with your left hand. This isn't a big deal at all, despite being something impossible to fuck up on a controller, but it is, in my (obviously limited as I am but one person) experience, literally the only time y axis socd ever does anything. It seems like recency priority socd for y axis wouldn't actually cause any issues. Additionally, it is trivial to apply different socd rules to the x and y axis inputs, so arbitrarily making them the same seems... Incredibly arbitrary.
> Proof: https://twitter.com/PracticalTAS/status/1723430893593772166
I don't think you needed to prove that you're practicaltas lol, we know your account, and it's 8 years old
Hello PracticalTAS I have a suggestion on how to nerf Box controllers in an appropriate way which I think would make all parties happey. Could you let me know what you think? * Character Select Screen clause: When the Melee character select screen is active on the screen, the controller will automatically select your cursor and hover it over the "Ganondorf" portrait, then emulate an A press. This will occur any time the box player selects any other character aside from Ganondorf, but in no other instances, so the player can change game settings, in-game tags, costumes, and team toggle without any interference.
Dearest DarkGenex, I hope this finds you well. As you as a tournament organizer know, the controller ruleset proposal team has no power to enforce these rules or require that TOs use them exactly as-is. Additionally, the ruleset proposal is entirely firmware-side and has no ability to impact game state such as requiring a player to select a specific character. You are welcome to apply the CSS clause at your events and report back to us with your results. Sincerely, PracticalTAS
[удалено]
Nah it's not that serious, DarkGenex is my friend lol
It is the year 20xx. Every player uses a boxx and plays Ganondorf. Matches are decided by port priority because the player with priority can get out their taunt first, dealing unrecoverable damage to the opponent's mental.
In the event that the travel time and timing lockout rules become widely adopted by TOs, is there a plan to add these nerfs to UCF so they become standardized and applied equally to all controllers/firmwares, regardless of if a GameCube or rectangle controller is used? If not, for what reason was the decision made to include more lenient 1.0 cardinals in UCF instead of enforcing .9875 cardinals for rectangles or in UCF?
No, UCF will not add these lockouts game-side. They would take a massive amount of expertise that we don't have to implement, only to impact 0.001% or less of the gcc/gcc-like player base. Nearly every lockout we're including will have a tighter window than the fastest gcc players we had benchmarking those motions. Re 1.0, I've responded elsewhere in the thread but 1) 1.0 is more accessible on some OEMs and gcc-likes than others and 2) one of the principles of UCF is not making something that's possible in vanilla Melee impossible. Parity with boxes without needing to add another nerf is a bonus, not the primary goal.
I dont know how easily you will be able to answer this since you aren't directly involved in either of these projects, but do you plan to try and make UCF 0.84 be integrated into slippi and uncle punch at some point?
0.84 is already available on Slippi Nintendont, andI have proposed to Fizzi that 0.84 be the default choice on Slippi online and future releases of Slippi Nintendont (it's ultimately his choice but I believe that we're aligned and this will occur). Integration into Training Mode is a stretch goal that I think we'd need UP's help with, and he's been inactive recently.
I think having it be default on slippi is the best way to have this spread considering that's how almost all people are playing and practicing now. Good work on all this!
Why force 1.00 instead of forcing 0.9875? Put differently, why do the option that makes the game less vanilla when there was an equally viable option that would result in things basically staying the same but more consistent?
In general, one of the tenets of UCF that we've tried to adhere to is not making something that's possible in vanilla Melee impossible with UCF. This means leaving 1.0 available, but also doesn't mean making 0.9875 completely impossible. A blanket nerf across the whole game, even it's minor, subjectively feels quite bad to force. Also, it's actually very possible to hit 1.0 cardinals reasonably often with a notch - I once tested this and was able to hit 1.0 about 40% of the time, though of course that notch has degraded now. It's also very possible to have a stickbox that's more likely to hit 1.0 than another. In other words, 1.0 isn't equally accessible to everyone, so UCF 0.84 is making it equally accessible to everyone.
To add this, you can and people have modified pots to hit 1.0.
What does pots refer to in this context, is that an acronym?
potentiometers, a small electrical component
I think it's circular to say that it's about the tenets of the project since my point is really that the circumstances ought to result in a reconsideration of the tenets of the project. Nobody - *nobody* - is hitting 1.000 with any consistency on an OEM, so you're really talking about shifting the default from something that is standard to every controller to something that is only consistent on modified controllers. Notches should've never been legal to begin with, but that's a separate conversation.
There has been a lot of belly-aching and complaining about the travel-time nerf. It is difficult for me to discern who has valid complaints about it rather than catastrophic exaggerations. Could you provide a low- level explanation of how the travel time nerf works, and an example of a currently abused boxx technique that would be banned by this nerf? If possible, comparisons of this technique on GCC would be useful.
When you press a button on a box that controls the control stick, on the very next millisecond the box is outputting a 1.0 cardinal input to melee. We have benchmarked and found that this is roughly 5 ms faster than you'd get to the dash threshold (0.8) on a gamecube controller or gcc-like controller with a physical analog stick. Similarly, when releasing the button, on the very next millisecond you're back to a 0 input. Since most players return to neutral by releasing the stick and allowing the spring to propel it back to 0, this takes around 9-10 ms longer on a stick. This actuation speed advantage manifests itself in gameplay as a reaction speed buff - the same user will have a higher reaction techchase rate, faster dashdance away from an opponent's move, etc. Travel time simulation does not ban any specific techniques, it instead forces the stick output to sweep from 0 to 1, touching some intermediate values along the way, before arriving at 1.0 6 ms later or at 0 12 ms later. This neutralizes the actuation speed advantage of a box.
[This](https://imgur.com/P3qSxJo) is a polling issue caused by the travel time nerfs. It's a concrete example of an issue unique to travel time nerfed boxes (on a controller, you would be able to feel the stick and not press B until it's in the correct position). I don't think PTAS has ever acknowledged that such issues are potentially problematic.
IMO this kind of problem is very much on purpose. If you were playing on a GCC and you did those inputs (i.e. press backward, let go of the stick, press B) too quickly, you would side B to your death. You would NOT "feel the stick" because your thumb is not on the stick, in order to return to neutral, you release the stick entirely and simply wait for the springs to bring it to neutral for you. The GCC user has to consciously delay their B press, and now digital controller users have to do the same. That's fair. TLDR sometimes everyone accidentally side Bs to their death and that's Melee.
That would be true, if this was turnaround neutral B. This is let go -> up-B. You feel the stick going up. Edited to add: They actually added turnaround neutral B coordinate with the nerfs, due to their (imo misplaced) disdain for non dedicated modifiers. This along with a few other features of the nerf-patch actually leads me to the opinion that this buffs spacies and Sheik. Free turnaround neutral B, free dashback out of crouch, 23 degrees wavedash. This comes at the cost of stupid polling issues like shown in the clip above, and the controller just feeling a lot worse to use.
I see, I misunderstood the inputs a bit. But my main point is that you won't SD like this if you just press B one or two frames later. That slight difference in timing, while being unnatural and confusing to a box player, limits box players to inputs that can actually be done on GCC (which is the whole goal). Players *will* need to partially relearn the game, and their will be a time during which that adjustment will really hurt box players. But they will learn given a few months and then we will know for a fact that box players aren't doing anything that can't be done on a standard controller.
Hmm, in my honest and apparently controversial opinion, it's not a reasonable goal to have box-players do *nothing* that standard controllers can't. As it is right now, standard controllers do plenty things that boxes can't do, including really crucial things like optimal angles for recovery. The idea of current box balancing is that consistency comes at the cost of optimality. It's so fundamentally different from standard controllers that balance on each individual aspect just isn't feasible, but an overall balance across aspects is. I can respect that some people feel like certain aspects are overtuned on box-controllers right now, but I simply can't respect the process for rolling out the proposed nerfs, and I very strongly disagree with the ways it is being nerfed. When it seems to me that it actually buffs spacies at the cost of making the controller feel much worse to use, it's hard to accept that the ruleset team is both competent and not spiteful. I would think that they either know what they are doing and lying about it, or they don't know, and thus they aren't competent enough to implement this in the first place.
Have any of the nerfs changed the way techskill is performed on the b0xx? We've gone 3 years of 'this is how you do x', if you guys alter anything you should probably include how it's done on the new patch. I had to find out from someone else that we now do the old ez version of ledgedashing (MX and down+in) instead of the hard version that gave more galint. Also heard that moonwalking was changed/nerfed? Seems odd.
Neutral SOCD impacts pretty much any technique where players depended on being able to press one direction without releasing the opposite. This includes mod 1.0 ledgedash (which I find difficult to believe is "hard"), float cancels, drifting, dashdancing, and possibly more depending on your specific use cases. Travel time will impact the timing of your button presses but shouldn't change their nature. The lockouts will impact you or not depending on whether you were using the motions that are now prohibited. TAS moonwalk is still possible despite travel time and neutral SOCD since it's a 2 frame input.
What features if any do you personally want to see added to ucf in the future and how likely do you think it is that each makes it in?
At this time I consider UCF to be feature-complete and don't expect any future changes. I'm not ideologically opposed to a vertical throw range fix or a c-stick ledgefall fix, but these are outside the mandate of UCF and would have to be considered as a separate fix instead of being packaged with UCF (and aren't going to be pushed for by me). This is similar to how the polling drift fix isn't part of UCF but is often used alongside it.
I want uptilts banned. 0% chance. Removing cstick ASDI: 0.1% chance.
It all wraps back around to the beginning and the cstick is the cheater stick again
Having talked a bit of shit on ult players and the like in the past, I vividly remember the humbling experience of popping in the Smash 64 remix discord and asking if there was a mod to use cstick and getting absolutely dunked on lmao
Funny enough that did get added to remix eventually, I think starting with 1.3
dude, I remember being like 13 years old in 2007 complaining to my friend that he was using the C-stick for smash attacks, rather than the A-button
Can you provide a visualization of the Shield Drop Range increase?
Here you go: https://twitter.com/PracticalTAS/status/1723459584122061193
I’m not an ICs main or rectangle user so it doesn’t affect me either way, but would the control stick output fuzzing make it so some ICs desyncs are inconsistent? Or are the ranges on the legal ones large enough that the fuzzing won’t cause any random misses.
The ICs desync ranges are all single-unit inputs that become at best 50% chances with the nerf firmware. For the desyncs where the other 50%+ is a bad option (for example, both climbers fsmash in neutral), the coordinates have been left available for use. For the desyncs where the other 50%+ is a good option (for example, both climbers bair), the coordinates that desync plus the coordinates that when targeted can fuzz to the desync coordinates are banned.
Hi PTAS, love your work I was wondering if you were looking at addressing accessibility to UCF and UCF patches. My local has been using a mix of setups with random versions of UCF and when researching to figure it all out, I had a hard time figuring out what was up to date, what actually changed, and where to find files. I still don't know if UCF 0.8, which shows up on character select screen, is different than UCF 0.84, and how this differs from other setups that have UCF 0.73.
Yes, this has been a priority of mine recently. As of now, UCF 0.84 is available as a UCF option under Slippi Nintendont 1.11.1 (please upgrade from 1.11.0, the implementation there is bugged). I have proposed to Fizzi that 0.84 be the default choice on Slippi online and future releases of Slippi Nintendont (it's ultimately his choice but I believe that we're aligned and this will occur). For cubes, gci files can be found [here](https://github.com/practicaltas/melee-gci-compiler/releases/tag/ucf0.84_2023-11-10). I'll also be making a Smashboards landing page as a permanent home with these details soon. UCF 0.84 adds several new features relative to 0.8, as seen in the OP of this post. 0.8 adds wiggle out of tumble fix relative to 0.73. I highly highly recommend standardizing to 0.84 everywhere.
This helps a ton, thank you and thanks for all you do.
[удалено]
Unfortunately at this time we haven't been able to provide Greg Turbo with a nerf package that he can easily integrate into the frame1 firmware. It's our top priority right now though and hopefully you'll see movement on this soon.
Hello PTAS, Sorry for the late question, I was busy yesterday(at a melee tournament of all things lol) and was unable to ask my questions. Hopefully, you'll still respond. My name is Robbie; I go by RROB | Kirbstomp. I have been playing melee since 2015. For the first 5 years, I played on GCC, and in the Fall of 2020, I switched to Boxx R2. I have been playing on it for 3 years consistently. As someone who has been on the PR in their state with both types of controllers, I can speak intelligently on the subject of Boxx legality. I appreciate everything you have done for the melee community, and I hope that we can all continue to build a great competitive scene together, but I want to be clear: I am NOT in support of these nerfs, and I don't think that the current rectangle controller ruleset needs to be changed. With that said, since this is AMA format, there are a few questions I have for you regarding the proposed nerfs. \- If digital controllers are so broken, why did no rectangle players make the top 8 at Big House 11? Surely a controller that is so broken that it needs to be patched would produce better results? Look at Steve in Ultimate... If there is a press-to-win button on the current layout, I'd like to know about it because I've been having a hard time finding it. At the end of the day, melee is melee, it doesn't matter if your inputs are digital or analog, you still have to beat your opponent. Saying that X controller is broken is taking away all the hard work your opponent has to put in to beat you. It's a john just like any other. \- What is your opinion on the controller lottery? For Reference Here Is Mine: A lot of the people speaking out against the current wave of new controllers are people who have enjoyed what I call "controller privilege". Players who have been in the scene for years and already have a fleet of OEMs ready on deck. Or even worse, the biggest antagonists to the digital controller movement, top players like Mango and Plup who, thanks to their fame and sponsors, have never had to worry about where their next controller comes from. It makes sense why top players who are given **priority treatment** in controller queues would prefer a world where they are automatically given an upper hand due to their controller. You mention in another comment: >I don't think it's fair to be able to switch controllers and immediately get an advantage in tech chasing, dash dancing, and more just because the game was not designed with the new controller in mind. Well, guess what, this is already the world we live in. Phobs, goomwaves, notches, z jump, trigger plugs, general stick box diversity... the customization options and variances in GameCube controller quality are endless. Box-style controllers **bring more consistency** to the controller meta. In a community with as little funding as Melee, the majority of players can't afford to spend hundreds of dollars on a nice controller. On top of that, controllers get worn with use, and the decently manufactured versions are no longer in production. A new player trying to find a decent OEM in the current market is out of luck, and that's assuming they even know what to look for. Yet here we have people telling us that the boxx controller is what's broken... I see box-style controllers as the thing that allows Melee to live forever. I see it as the great equalizer to the controller lottery. I see it as the future, and I see this patch as a scared attempt at maintaining the current broken system. \- Have you ever played on a rectangle controller? What about the rest of the team proposing these nerfs? From this comment you made on this post: >This includes mod 1.0 ledgedash (which I find difficult to believe is "hard") It sounds to me like your team is an echo chamber filled with people who don't play on the controller. In all honesty, this comment rubs me the wrong way, and in my eyes devalues a lot of your arguments because it demonstrates how truly jaded you are on the subject. Diminishing your opponent's hard work simply because the input method they use is different will only serve to fill your ego and worsen your performance. Assuming there are no macros(which are illegal already) inputs on the box are just as difficult as the controller. You still have to put in all the ledge dash inputs(drop, jump, down, in, air dodge). Just because a controller is digital doesn't mean your inputs will be 100 percent accurate. Human error will still exist, and playing on digital controllers tends to exacerbate mistakes when they are made(1.0 digital input is a double-edged sword). Just because I play on a box controller now doesn't mean the game is any easier than it was when I played on a game cube controller. \- There are plenty of top players that have switched to boxx, just to later switch back (Joshman, Leffen, etc). Have you ever honestly considered that the GCC is the better controller to play on? It's almost like the game was made to be played on it! It's crazy how intuitive it is in comparison to the Boxx. DI, recovery, character control, it all makes so much sense! GCC controllers are broken, why don't we also patch them to be equivalent to boxx controllers? After all, it's only fair that we all are on an equal playing field... /s \- How would you respond if I asked you to change the way your controller worked today? All the training you have done up till now is out the window, and you have to start from scratch, clueless as to what practiced tech will no longer work the same. How would that make you feel? Oh and by the way, all your wins up till now don't count because the controller you were using was invalidated after the fact. \- When will the goalposts stop getting moved? When Hax first proposed the box ruleset years ago, people accepted it. Now boxx players have started taking sets and people are blaming the controller. Let's say this patch goes through. When we adjust and start taking sets again are you gonna make it an 8 ms travel time? 10 after a boxx player wins a major? If we don't want digital controllers that is a different discussion (and one that I am slightly more receptive to), but to continually change the expectation is unfair to those of us who have invested time and money in these controllers. Getting down to the nitty-gritty, I'll go through the proposed nerfs and share my opinion on them. Neutral SOCD (both x- and y-axis) to prevent easy, instant changes of direction \-This is the only change on the proposed ruleset I'd even consider. However, according to the Boxx manifesto, this makes empty pivots too easy. So it also has its drawbacks and still needs to be evaluated honestly by the larger player base Limits on modifier buttons including a ban on L/R changing control stick output \- Not a fan. As long as the GCC can hit the same coordinates then who cares what combination of buttons a box player has to press to achieve it? Travel time simulation equal to the input speed of very fast analog sticks Control stick output fuzzing which has almost no effect on the vast majority of gameplay but prevents consistent targeting of single coordinates Limits on available target coordinates/angles that are difficult to consistently hit quickly on GCC-like controllers, such as Peach’s 2-frame no-setup Parasol Dash \- Hard no for all three of these. This is removing one of the only benefits that a digital controller has, the digital aspect. The "buffs" that these nerfs are challenging are just features of a digital controller. If we don't want digital controllers to be legal, then that is a discussion separate from this one. On top of that, with notches players can pick any coordinate they want. So why limit what inputs digital can do? Lastly, according to your comments in this thread, you base your travel time on the average player. Why do you assume no box player would be better than average? How will any boxx player ever compete at a high level if we can only do our inputs like an average player? Timing lockouts to prevent rapid burst SDI and instant pivot/crouch tilts \- Wizzrobe's SDI is better than any box-style player. And Syrox would regularly pivot/crouch tilt on GCC. This tech is not about the controller, it's about the player and how well-practiced they are. In closing, it would be ignorant of me to say that there are no differences between rectangle and GCC. Some actions are easier on digital controllers, just like some actions are easier on GCC. The basic fact that there are differences in input methods, doesn't mean that one is better than the other. Melee is decided by the player, not the controller. These proposed nerfs serve to make box-style controllers harder than they already are, simply because the people proposing them think they know more than everyone else who plays this game. There is no need for a change to Boxx, free Melee
Hi Robbie * If digital controllers are so broken, why did no rectangle players make the top 8 at Big House 11? I would say because comparatively few people have switched over at the top level. The best players in the world have been playing on gcc for a decade or two. A controller does not need to be broken to be clearly better than another. On top of that, not knowing whether TOs would ban boxes probably contributed. * What is your opinion on the controller lottery? Personally I think as long as a good OEM is a reliable choice, the controller lottery is in an infinitely better state than it was before UCF. Your average player does not need a modded phob to compete. Similarly, you're talking about boxes as though we're banning them, which we're not. * Have you ever played on a rectangle controller? I have not, but we have multiple team members who do. They challenged and questioned us along the way, and I believe the resulting ruleset is better for that. It was by no means an echo chamber. As for my comment on mod 1.0 ledgedash, I stand by it. I don't believe that it was at all necessary to change how modifiers work for this one interaction to get some goldilocks technique for ledgedashing that isn't too easy and isn't too hard. There are multiple ways to ledgedash on the nerf firmware that are unchanged from pre-nerf after accounting for travel time (not nsocd or fuzzing, just travel time). * Have you ever honestly considered that the GCC is the better controller to play on? I think that the two controllers have advantages and disadvantages relative to each other, but un-nerfed rectangle controllers' advantages outweigh gccs on aggregate. The gap to me primarily comes from, as mentioned, most top players having a decade head start on gcc. In the mid level you see way more players switching and improving than among those who are already at the top. * Neutral SOCD The manifesto is outdated and there are several empty pivot methods that are equally easy on 2ip. 2ip has an equivalent or better technique to almost everything NSOCD was thought to be too good for, and the handful of exceptions are outweighed by the huge area where 2ip is better. * Limits on modifiers /r/SSBM/comments/17t2g9y/hi_im_practicaltas_and_i_lead_a_group_proposing_a/k8ux1k9/ * As long as the GCC can hit the same coordinates then who cares what combination of buttons a box player has to press to achieve it? This is more about lockouts and banned regions, but I strongly disagree here. Especially with internal coordinates, boxes can reliably get to some states multiple frames faster than even the fastest gcc, and do so more reliably. This is a massive advantage that manifests itself in the form of pivot tilts in neutral, optimal wavedash and ledgedash angles, and, less obviously, an actuation speed advantage that serves as a blanket buff to reaction speed across the board. * Hard no for all three of these. Travel time - as mentioned above, a clear, measurable, and universal improvement to your reaction time simply because you switched from a stick to a button. Obviously it's the hardest pill to swallow since it's the nerf with the fewest relative upsides, but the advantage is undeniable, replicable, and seen even in the fgc where leverless controllers are taking over. Melee is an analog game and the gcc should always be our benchmark. Fuzzing - we added fuzzing to the test firmware and nobody noticed for days. The only people who hate it after using it were trying to take advantage of pinpoint coordinate precision in a way that is obviously unfair. Limits on available coordinates/angles - I think you'll notice that boxx and frame1, among others, don't leave certain angles available because their manufacturers knew that full access to the entire analog range is too good on a rectangle. Where we disagree is in degree, not kind. And as a ruleset we can standardize across the board, since the current situation was the wild west with players ignoring the self-imposed limits since they weren't written down (or if they were, they weren't enforced). * Lastly, according to your comments in this thread, you base your travel time on the average player. Why do you assume no box player would be better than average? That's incorrect, we based our travel time on the fastest inputs, not the average player. This is already a favorable comparison for rectangles, since the fastest analog stick presses are inaccurate to the point of being able to leave the y-deadzone, which is not a risk for a button no matter how fast you press it. * Wizzrobe's SDI is better than any box-style player. And Syrox would regularly pivot/crouch tilt on GCC. Wizzrobe's SDI is better than what rectangle players currently use, not what they're capable of. There are known techniques for boxes to get 3 SDI in 3 frames, 4 SDI in 7 frames, and 5 SDI in 8 frames, all of which are beyond Wizzrobe's capabilities. I believe these techniques aren't widely used because rectangle players know that they're too good and were hoping they would avoid a ban on them by not spreading the word about them. These are what our bans target, not the average player performing average SDI. As for pivot and crouch tilts, our lockouts target the fastest possible human benchmarks - we asked for players who were confident in their speed to send us replay files of them performing these actions, with the result almost always being that they were slower on gcc than what our lockout prevented on rectangle. * Conclusion I respectfully disagree with your view, and your disparagement of our team. I think gccs have advantages over rectangle controllers, but I also think that un-nerfed rectangle controllers have more and greater advantages over gccs, and that every single one of our choices for this ruleset is justifiable.
> I believe these techniques aren't widely used because rectangle players know that they're too good and were hoping they would avoid a ban on them by not spreading the word about them what
If this actually goes thru, please include a WASD style firmware for the boxes as any of us who don't use standard layout box firmware are basically stuck not being able to play in a legal capacity
I'd certainly like for the team to make that available, it's just a matter of time required vs available vs other priorities. The nerfed HayBox firmware is open source and in the worst case scenario a knowledgeable user can apply a WASD style layout to it.
Is there a "polling luck" issue for tap jumping with Peach similar to the dashback issue? With Peach you can enter float by tilting the control stick up. So if I want to tap jump with Peach, but the game reads my control stick halfway to the gate I could get a float by accident due to polling right? If so, will this get addressed in future updates?
There is not. The control stick range that floats with up is the same range that double jumps, and is only possible to use when double jump has been turned off because you tilted slightly up for several frames. You can only get a float by accident if you performed an input that wouldn't double jump with any other character.
To what degree do you think these nerfs will address the stigma against box controllers? Additionally, do you expect these nerfs to have a stastically significant impact on box-player performance? If so, to what degree and on what time-span? I understand this is a very non-technical question that is impossible to answer with certainty, Im only looking for your perspective edit: Change to second question
I think it'll be a small but clear net improvement. Of course there will be players who can't be reasoned with, but imo most people will be able to tell that box controllers have been nerfed. I don't expect a significant change in the average box player's results beyond the initial adjustment period. I think that players who depend more on the pieces we're banning (2ip, mod 1.0 ledgedash, etc) will have longer adjustment periods though.
Thoughts on having the game enforce the rules rather than the controller? Ex. If any controller were to try to break any of the rules in place for a boxx type controller for it to be nerfed equally, such as a player using wonky asdi on analog to be held to the same nerfs implemented on firmware used by digital controllers
As mentioned elsewhere, this requires very specialized expertise that we don't currently have available, and will impact maybe 0.001% of the gcc/gcc-like playerbase. Not to mention, many of the nerfs are impossible to enforce in a reasonable way on a gamecube: at the gamecube's polling rate, travel time on a box would be random; the cube itself has no way to know for certain whether a controller is a box or a gcc and so doesn't know whether to ban certain coordinates; and some bans such as neutral socd and modifier changes must be controller side since the gamecube has no knowledge of those inputs.
What is your favorite meal?
I love me a good smoked salmon eggs benedict.
B_TAS (Based_TAS)
At any point was there discussion around banning notches?
No, we consider notches to have been in widespread use for far too long to be sensible to ban, and too time-consuming to regulate in any reasonable capacity at the major level. Even with the proposal as written, we aren't expecting TOs to manually look at anyone's controller.
ngl it's pretty disappointing that these are the reasons. Notches are very clear, you can just look at the controller (unlike box software). I really don't see how this would be a burden to enforce. And them being in use for too long really shouldn't matter...
Personally I think it's impossible to reasonably look at a notch and be able to confidently say "this is illegal" in a way that can be unambiguously written down and feasibly applied everywhere. The gray area is just too large.
I’m sure there would be edge cases but I feel like 99% of notches you would question are obviously custom notches. To me it’s frustrating that we’re all acknowledging that it’s cheating and everyone does it, but we won’t ban it because maybe we can’t 100% guarantee that we cover every single situation. If it was banned the vast majority of players would just swap to an unmodified shell.
Personally I consider notches to be on par with other easy hardware modifications such as removing a spring or filing down your buttons, not cheating. I also don't think it's fair to say "just swap your shell", that's requiring a giant proportion of the community to change their hardware.
I feel like notches have a way bigger impact on gameplay than button/trigger mods and are worth treating separately. Also don’t think it’s unreasonable at all to tell people to swap shells if we’re considering notching a basic hardware mod. Regardless, I’ve said my piece on this and I fundamentally disagree with a lot of what you’re saying but ty for responding.
I agree with PTas on pretty much all of his points but I respect your argument and the way you communicate. Cheers.
I think removing a spring is on a different level than those 2 other things, it genuinely only requires the appropriate screwdriver, and there is no way to fuck it up so bad that you make your controller worse or unusable as a result.
Having notches being legal requires a bigger portion of the community to pay controller modders to mod their OEMs if they want to be on the same level as the competition. Plus, now you need to pay for OEM + mods instead of just an OEM. If we're going to value how much of a hassle implies each scenario for the player base, then clearly removing notches is the way to go.
Notching your controller is not easy hardware modification lmao
could you elaborate on this? how can it be ambiguous when all controller shells look the same? if you see a notch that isn't OEM, that's illegal, right? i'm not seeing where the gray area is
Consider some players have, through multiple years of use and without ever putting them to a file, ground their control stick rims down [entirely to a circle](https://twitter.com/MNMattt/status/1279209068201152512). In the same way, it's entirely possible to create a notch through hitting the same point enough times through gameplay. At what point does that notch become illegal? Can you define that? Does it ever become illegal if the player didn't intentionally make it? If not, what makes it different from a notch that looks identical but was man-made? If I wear my shell down enough, can I get dq'd from an event even though it was legal last week and the only thing that touched it since was the control stick? Can you write any of this down in a way that's more solid than "Notches are banned, and I know a notch when I see one"? And if you can, can you expect a TO or a pool captain to enforce it, repeatably?
i think this thought experiment falls apart when there isn't a single instance of this ever happening intentionally or not. people do grind down their rims, yes, but nobody has ever slapped the same spot on their controller for hours and hours and hours to make a "notch" and i think it's disingenuous to consider that a possibility. i think that a deliberate notch is apparent. they don't appear as regular wear. if there is a single case of this happening, then perhaps comes the time to reiterate rules, but it has literally never happened before... edit: to clarify my stance on your other question, regular wear is fine. it's the deliberate wearing of specific locations that notches come from, and that would be banned. considering it has NEVER HAPPENED where someone's gate is worn exactly on the wavedash coordinates just from regular play, i don't know why you'd even consider that. everyone uses external tools to accomplish this.
Just because you've never seen it doesn't mean it's never happened. Beyond not thinking that it's possible to regulate them, I also don't think notches are a problem or worth banning even if they were regulatable.
if you want to suggest so strongly that it happens, without a modicum of evidence to prove it, then i have nothing else to say... i'd prefer rulesets to be written by someone who is grounded in reality where notches don't spontaneously occur from years of gameplay. thanks for answering my questions!
The gate can deform in such a way you have access to values that are notched for, primarily the diags being deformed shielddrop notches being a common one (very uncommen to be notched for nowadays with UCF but it's the most commen example.) That said, there is no way to supply evidence of this cause one could always argue this was modified via an external tool. Can a controller consistantly degrade to give access to Y+/-3000 ? No. The problem then becomes, where do you draw the line that isn't left open to interpretation? Also if those were banned, should digitals be limited to only rim and diag values? Or should the fuzzin be a grid of 2in and 10rim?
Just say that in the first place then.
The original question was "was there discussion around banning notches?", not "do you personally think notches should be banned?"
There’s no shot anyone has notches that look like they do on my gcc from normal wear and tear lol. You’ve spent too long debating abstract arguments in discord.
What fantasy land are you describing where people are manually wearing down wavedash notches into their shell through gameplay? Even if a TO is somehow too braindead to identify a non-OEM notch, there is no downside to enforcing the most strict interpretation of the rule. If someone has anything even remotely approaching a notch, then all they have to do is replace their faceplate with a stock one.
I absolutely think it's fine to sacrifice the incredibly small number of players with very worn down controllers at the altar of banning notches Also, if you think about it, a worn down gate is kind of the antithesis of a notch
Have you considered a rule like "each stick is allowed a max of 8 notches" (because OEMs are made with 8 notches). A rounded stick (0 notches) or deformed notch from wear and tear due to gameplay is legal but you cannot have any additional notches for firefox angles etc. If a TO can pinpoint a specific coordinate region on the controller it's a notch. Card game tournaments do perfectly fine DQing people for marked cards/sleeves using the same method (if the TO can cut the deck to a specific card, that card is marked)
I don't think it's a big ask for pool captains to say no to notched controllers. There is no such thing and there has never been such a thing as a "naturally notched" controller, it's extremely easy to see if someone has done it. With the emphasis on making sure Melee isn't pay to win, or that people who have more expensive controllers can't make the game easier to play, I'm really disappointed that no plans to ban them is being even considered. People shouldn't be able to buy a way to make the game easier, or to make THEM AS A PLAYER more consistent. Controller tech should only go in the direction of making the CONTROLLER more consistent, not the player (as notches do).
Genuinely curious, do you volunteer at events? There are already a lot of asks of pool captains, I think adding on inspecting controls and arguing with sweaties about whether that little nick that "totally got there by accident" is legal or not is actually a big one.
Okay, sure, but by that logic any form of box controller should be totally banned as well. Those are a way bigger issue for improving player skill and consistency than notches ever will be.
Correct!
I’m not very knowledgeable about controller stuff, can you explain why notches are such a big deal? My friends who take melee seriously all did their own notches. What kind of specialized knowledge do they require that makes them an unfair advantage? Would I not be capable of taking my OEM controller and carving notches with a file myself? If they don’t require secret knowledge and I can add them in my garage, why are they more problematic than, say, taking the springs out of the triggers?
Notches allow you to hit precise analog angles with no risk. Max angle wavedashes without risk of airdodging straight and max angle shallow/steep firefox angles without the risk of going straight are the two biggest examples. There's no reason you should be able to do this. The knowledge required to do it doesn't matter.
And UCF takes away the risk of side dodging instead of shield dropping and dashback polling. Notches are just another tool to help the player do what they want to do. My question is how "pay to win" is it? I've seen on here that it is both prohibitively expensive, and also that it's not hard to learn how to do yourself.
Notching your own controller is so easy. You need a triwing screwdriver, a jewelry file and a out an hour of your time. It's a ~$10 investment and not difficult as long as you are patient.
Note that I’m not talking about shield drop notches because there are vanilla gccs whose notches align with the shield drop values. Again it’s not about being p2w.
Personally I think it's impossible to reasonably look at a notch and be able to confidently say "this is illegal" in a way that can be unambiguously written down and feasibly applied everywhere. The gray area is just too large.
Not to open a can of worms but notching your controller yourself is about as hard as soft modding your Wii so you can load ucf. I don't agree that only $200+ controllers can be notched reliably. I still think there's an argument for banning them but I don't think it's accessibility.
man idk i have a 3rd party shell i’ve never notched and there’s clear wavedash notches carved into it from me slamming my stick
Do you mean warped? Because there's no way you're getting natural notches.
This is a pretty infuriating response imho. You can replace notches with digital controllers here and it makes just as much sense.
It has been so good for my mental health to read this comment and be reminded that the competitive community is in saner and more capable hands than those of the average /r/ssbm commenter.
When it comes to these rulesets, from my understanding, it is to limit the performance of a box controller to perform at an equal level to a GCC to create an "equal playing field". Such as restricting SDI to the peak level of a GCC. I can sympathize with these concerns since these are actions that would be extremely difficult for a GCC player to perform. What I fail to understand is the imposed restrictions on box configuration (not allowing L/R to be used as modifiers). This doesn't nerf the potential of the box controller but the user - those that have been playing under these configurations for nearly 6 years. What is your response to this?
There are two reasons to remove L/R as non-dedicated modifiers. The first is that gcc users are not able to choose or ignore their notches based on the buttons they're pressing, so we felt that it was unfair for a box player to change their angles based on buttons pressed as well. The only remaining non-dedicated modifiers are b, which is not permitted to change angles, and the c buttons, which we left in as a legacy choice for people with limited hardware (only allowed with <=2 modifiers) and don't have any abuse cases when it comes to pressing a c direction and a control stick direction at the same time. The second comes with travel time. If travel time is applied, and pressing L or R changes the angle that you're pressing, then your angle will be moving on the same frame that the game is polling your controller for your wavedash angle. Thus, the output angle is entirely random from your perspective (though it truly depends on the number of milliseconds between the button being pressed and the controller being polled). We felt that this was highly undesirable behavior.
Part of my issue is that box controllers are already limited on achieving angles and there is an assumption that all box controllers achieve angles through dedicated modifiers. My (custom) controller in particular, doesn't have a modifier button but instead has 6 directional buttons. In order to achieve certain angles, it's necessary to use other buttons (L/R) as modifiers. Even though, my particular situation is an edgecase, I do know many box users do use L/R as a modifier. I just have trouble seeing the purpose of this change other than to make things more difficult for box users - especially those that have been playing with these configurations for years. From the perspective of a GCC player or spectator it would be impossible for them to tell whether this restriction was in place. I would ask for sympathy for those that are actually affected by some of these changes. Some of these changes have negligible effects on actual gameplay but severe downstream effects on box users.
Sorry but a controller with 6 directional buttons is not something we'd consider legal under the rules, as it violates 1:1 mapping with an analog controller. 1:1 is one of the core tenets that underpin this entire ruleset and removing it would radically change it from top to bottom. I'm sympathetic to players that have been able to play on certain layouts or with certain options that are no longer available under the new rules, but "it used to be legal" is simply not a justification for keeping something legal. We didn't anchor the proposal to what box players are used to, we anchored it to what we felt was fair to bring parity with gcc-like controllers.
Not allowing 6 directional buttons makes zero sense to me. I don't understand how 4 directional buttons is closer to a 1:1 map of an analog stick. There are 360 degrees in a control stick.
Not PTas, but 4 buttons makes sense in my brain as a "direct" mapping of the maximum points of either axis. Each axis (X and Y) has a positive and negative maximum, and 4 buttons would map to those X+, X-, Y+, Y-.
What exactly are your 6 directional buttons?
Basically the 4 cardinal directions and then two additional buttons for walking left and right. Without getting into the specific values: Up (in utilt range), Down, Full Left (Dash), Full Right (Dash), Half Left (Walk), Half Right (Walk)
I think it's pretty clear that your half walk buttons are on the same axis as your dash buttons, and your comment above about there being 360 degrees on a control stick doesn't justify their legality. One or both can be pretty reasonably changed to modifiers that, when pressed along with a dash button, output the same coordinate they used to.
Well the 1:1 mapping still doesn't make sense because an analog touches all 360 degrees and everything in between. Regardless, I don't understand the rational that I would need to change my "walk" buttons to modifiers just to satisfy some arbitrary rules of how directional buttons should be mapped. I don't see how this restriction is warranted and how it accomplishes anything. Box controller must always use 4 cardinals until the end of time now? These types of restrictions put a lot of limitations on future iterations and innovations of controllers going forward.
After having spoken with the team about this, I think my main concern is being able to have walk buttons and dedicated modifiers at the same time. It's not something we'd have ready for the initial release of the ruleset, but I can see a later revision allowing, for instance, 2 partial input buttons per axis as long as they adhered to legal coordinate rules, used additive neutral socd, and applied input fuzzing as described in the proposal. We also would probably be fine with a "low resolution analog stick" which is a single actuator that outputs a limited set of coordinates (again adhering to the above rules). Analog buttons are already legal. I think the rules as written can and should evolve as (but not before) new ways to play are developed.
With the travel time nerfs, what is the timing difference going from dash left to dash right on box vs gcc?
This depends on your technique. If you are holding left and want to dash right, the average gcc player probably gets from gate to gate in 8 to 12 ms depending on whether they are trying to reactively move as fast as possible or time a dashdance without expending unnecessary energy. On a box, that number is 6 ms if you release left before pressing right, and 6 ms + the amount of time you're still holding left after you press right if you press right before releasing left.
With the development of the adapter that gives xinput controllers usage in gc, do you see these rules (and the traditional rules already in place) having to be changed in the future? See @RobertDaleSmith on twitter for the deets on that, but it gives most usb controllers access on GameCube and Wii
No, I would say that the adapter would need to run firmware compliant with the rules in order to be useable in tournaments.
do you believe in life after love?
I can feel something inside me say, "I really don't think you're strong enough, no"
Doesn't 1.0 Cardinal Nerf Peaches chain grab? It seems like a pretty big balance change for no reason.
It (mildly) nerfs chain grabs relative to someone playing against the average OEM yes, but in the grand scheme of things it's quite a minor difference. For example Peach uthrow against port 4 Fox at 0% doesn't combo into dsmash at 0%, but [does combo again after 1 (inescapable) pummel](https://twitter.com/Violent_Lee/status/1537677705151275009). In the grand scheme of things, enabling consistent dash back is a significantly larger balance change but was fairly universally seen as worth it because failing to hit your dash backs through no fault of your own feels very bad. I consider 1.0 to be similar but to a smaller degree.
1.0 cardinal isn't new, some OEM controllers can hit it naturally. UCF is meant to flatten inconsistencies between random controllers to avoid the "controller lottery", and since 1.0 cardinals are technically achievable on a normal, unmodded controller, this changes very little assuming the best players spend the time seeking out the best possible controllers (which they did in the pre-UCF days).
* Did you account for the inherent drawbacks of a digital controller when deciding on nerfs (less available angles, limited drift options, only a few WD lengths etc.)? * When nerfing digital controllers what top-level players on digital controllers had direct input? The only one I've seen who is fully supportive is Swift. * I've seen multiple top players say the travel time ruins digital controllers for them and they are considering quitting melee if it goes through. The obsession with GCC parity seems like it is outweighing practical implications of this change. I haven't seen anyone argue digital controllers are OP because you can move the stick faster and you are already nerfing SDI. Is it really worth alienating part of the player base and potentially reducing player count to add 6-12 ms of lag in the pursuit of "parity"?
* Yes, of course. Even now there are plenty of things a box controller can do better than a gcc, or as good as the best players on gcc. The goal isn't parity in every little aspect, but parity overall with trade-offs. * We have had a discord server for over a year where players have had the opportunity to provide feedback (and for the past several months, test the firmware). Not saying that the players endorse or are even ok with the end result, but the following notable box players and box-using TOs are in that server: Zuppy, Pipsqueak, Swift, Joey Donuts, gahtzu, kins0, McCloud, DarkHero (recently added), dhir, unsure (recently added). This has been a long time coming and the players have been given a lot of opportunity to provide feedback. * I would say that's a particularly loaded question. I don't think it's fair to be able to switch controllers and immediately get an advantage in tech chasing, dash dancing, and more just because the game was not designed with the new controller in mind. Ultimately, the final decision rests with TOs, and they will have to decide whether to use the rules at their events knowing what impact it'll have on their players. I'm not a TO, I'm not a controller modder, I'm not a top player, I'm about as impartial as you can possibly get when it comes to this.
[удалено]
The feedback, in general, is between strongly negative and "I don't like it but I can live with it". This isn't intended to be calibrated to how strongly box players react to it, because then they would be incentivized to overreact in the hope of getting the whole thing cancelled. We believe that the proposal as written is worthy of bringing to the TOs, and it's their call whether or not to use it at their events.
My uneducated opinion is that the travel time nerf is the only misstep here. I think you are undervaluing maintaining a fun to use, durable, reliable controller for the game and overvaluing the "technically" correct decision. I think the negative impacts on the scene of a travel time nerf far outweigh the potential unfair advantage digital controller players get from an instant travel time. As a F1 player I haven't had a chance to test it so it's possible I'm overreacting but I am concerned after seeing the responses of a few top players I follow. This change has the potential to lose a number of players, myself included pending testing. My last local was about 50% digital controllers, and I wonder how many of these players will move to another game if all these changes go through. I respect the work you've put into this proposal and hope I am incorrect.
> I think you are undervaluing maintaining a fun to use, durable, reliable controller for the game and overvaluing the "technically" correct decision. Why is the subjective fun of a 3rd party controller more important than the competitive integrity of the game?
I didn't say it was more important. Both things are important and you need to find the right balance. If we only cared about the competitive integrity of playing melee exactly how it was designed we wouldn't allow UCF, Slippi, Phobs, Z-jump, or notches. Keeping the game fun and accessible for a portion of the community is a valid goal. Especially for a 20+ year old game that doesn't have a massive influx of new players.
> I haven't seen anyone argue digital controllers are OP because you can move the stick faster search this reddit for "travel time" if you want to see quite a lot of people arguing this
not pTAS, obviously, but the travel time nerf has a tendency to draw out extremely strong initial reactions from people and then not actually be nearly as noticeable as they thought it would be. outside of that aspect, yes, if people feel alienated by parity, then it's worth alienating them
Agreed. Making box controllers as similar to a GCC is just not practical/necessary on all levels. There is a severe cost on that of the box user to have to deal with arbitrary/artificial nerfs. Keeping these rulesets pointing towards the more noticeable and isolated effects of box controller gameplay (SDI nerfs, angle limitations) makes more sense to me.
I'm seeing this AMA late, but I really hope you get back to me! Most of my interest is from the UCF update and not the digital controller proposals. 1) The UCF code is a black box for 99.9% of players. Will your team be providing any code documentation beyond just stating your general intentions? I strongly believe the community should be able to know the algorithms used for things like shield drop modifications or input correction. 2) At local tournaments, it's been my experience that on the current version of UCF, the most overwhelming source of OEM controller issues are snapback related. Is there any plan to address snapback within UCF? 3) UCF is considered a software-level mod for fixing controller input discrepancies. Do you believe a software approach to these problems is better than a hardware approach? If so, why? 4) The [team mentioned for this proposal](https://twitter.com/PracticalTAS/status/1718689687697498158) is missing most of the members from the original UCF release (IE, tauKhan, Kadano). Do these people have any involvement/stance on UCF 0.84?
1. On top of the compiled gecko codes being open source as Frost mentioned, the source code for UCF can be found [here](https://github.com/AltimorTASDK/ucf/tree/master/src) and I plan on making a documentation page available on smashboards in a more human readable format. 2. Unfortunately we don't have a reliable way to fix snapback on the game side since the gamecube/wii doesn't poll the controller often enough to accurately determine what is snapback and what looks like snapback but isn't. I believe it needs to be done controller-side to be done properly. 3. I much prefer UCF for fixes that are possible to be done game-side, yes. Making a change without requiring your players to do anything is highly preferable to the alternative. 4. All the other members of the original team are inactive now. We discussed most of the changes that eventually made to 0.84 2+ years ago (all except the SDI frame 1 fix, which was brought to my attention by Altimor later) and were aligned on their inclusion. I've kept them up to date on the changes as they were implemented, and to the best of my knowledge their stance remains in favor of the new version.
Heyo, I'm Frost. Not PTAS but also part of the ruleset team. Despite not being him, I think I can answer some of these and pass along others to TAS. 1. The UCF Code is hosted here: [https://github.com/practicaltas/melee-gci-compiler](https://github.com/practicaltas/melee-gci-compiler) 2. There's no way to correct for snapback without significantly re-working the game engine or making non-stealth toggles. Fixing snapback is likely out of the scope. 3. I'll ping him on this 4. I cannot speak for the others, but I do approve of the UCF 0.84 methodology - which is to never make inaccessible something that is already accessible.
How much contact has there been with Hitbox developers in regards to these proposed rule changes and nerfs on Smashbox? Does it look like it will mostly just come to locking out certain input values on their customization software for Melee profiles or has nothing that specific come of it yet? Additionally is there any plans to create a branch of the firmware that does not rely on c stick modifiers to reach additional angles? Or is that far enough down the priority list to effectively be non-existent for the forseeable future?
We've been in contact with them and will provide them the same spec as the Frame1 team to ensure that they can apply the nerfs within their firmware. I'm not sure what the end result would look like on their side. It's not high on the priority list but I don't think it's unreasonable to want one that works similar to the standard smashbox setup. In the worst case scenario the firmware is open source and it shouldn't be too hard for a motivated community member to DIY, but I hope it doesn't have to come to that (unless said community member wants this done, like, within the week).
Z remap?
Breaks stealth unfortunately. UCF is meant to be useable everywhere, and any method of toggling anything is a risk that some TOs won't be willing to take.
Couldn’t you just have it be a 20XX type command on the CSS where you press dpad down + X/Y or something to swap X/Y and Z? Wouldn’t that not break stealth?
I am absolutely against toggles in any way, especially ones that can be turned on or off by accident. We don't need 1) blatantly obvious ways for someone to test whether UCF is active on a tournament setup and 2) an opportunity for players to blame us if they accidentally turned the toggle off, forgot to turn it on, or accidentally turned it on because they didn't know it was an option. UCF is meant to be universal and apply to everyone equally, even players who have no idea that it's active.
Unfortunate but understandable.
Is there a difference in "breaking stealth" when it comes to a GCC z-remap vs a non-disclosed rewire on a rectangle style controller?
To Nintendo, yes. One modifies their IP, the other doesn't. One is the responsibility of the (possibly officially licensed) tournament organizer, the other isn't.
yeah unfortunately the z-remap / stealth stuff is 100% a nintendo issue
who is the group/team?
https://twitter.com/PracticalTAS/status/1718689687697498158
With the legality of controllers like phobs/goomwaves do you think we have dug ourselves back in the hole we were in before UCF? As in, controllers feel more like a lottery/luck?
No. I think as long as a reliable OEM is a viable option, we are in an infinitely better position than we were before UCF.
Getting a good phob or goomwave (fresh pots & heartbeat on legal firmware) isn't a matter of luck.
It basically is luck because information about which modders are actually good is hidden in a discord that is only posted in one place tbst doesn’t have a lot of visibility. Everyone’s seen how top players pick a modder and get screwed, and they have more info than we do about who is good.
Why did it take so long for the box ruleset to get proposed?
As u/DreadPirateAlan said, it's not easy and nobody's paying us for this. On the other side, controller modding and manufacturing are both (probably) million dollar industries and the professionals there have a monetary incentive to move fast and encourage TOs not to look too hard at what they're doing as long as they're not blatantly breaking the rules as currently written.
it's a hard problem to solve and it's been entirely dependent on highly specialized free labor
6ms sounds like a lot for travel time simulation. Is this really necessary when neutral SOCD is already a thing?
Yes. Neutral SOCD is meant to prevent easy, instant changes of direction, but has absolutely no impact on an initial dash from neutral. Travel time has been calibrated based on multiple high-resolution tests, all of which have confirmed that there's roughly 5 ms (1/3rd of a frame) of advantage to pressing a button relative to pressing a stick past the dash threshold.
Interesting... Would the neutral SOCD only kick in after 6ms as well then? If it's just a normal buffer then I suppose this would be the case.
Not PTAS but 6ms is still really good in comparison to GCC.
could there be changes to the amount of time of the timing lockouts? I find 8f for pivot dtilt too slow, my record on gcc is 5f from the pivot input -> dtilt input, and i can somewhat consistently get 6f. on frame1 i also get 5-6f between pivot and dtilt input on a pivot dtilt.
The dtilt lockout in particular is poorly written and I need to fix it. On the firmware side you are locked out from the dtilt-from-neutral range for 8 frames, but if you crouch for 4 frames you disable control stick dsmash and instead dtilt from the dsmash-from-neutral range. So while the lockout prevents you from sending specific coordinates to the game for 8 frames, the coordinates it allows still let you dtilt within 5 frames.
ohh ok ty! yeah then it makes a lot of sense. doing tilt input to instantly dtilt would be insanely hard to do on gcc and much easier on box controllers
Hi PTas! Your episode on GGRadio melee was superb, thank you for being awesome yourself and everything you do! I think the proposal is great and look forward to the growth these kinds of conversations promote in the community
Thank you for the kind words :)
Does the travel time simulation rule also affect dpad/arcade stick type digital controllers?
Yes if the dpad or arcade stick is digital (only outputs 0, 1, or -1 on a given axis)
Shield dropping is already so ridiculously lenient compared to vanilla, why would you possibly need to make it more lenient? We now have the ability to calibrate notches (either through the game itself or through controllers like phobs), so there is no downside to using this method instead. With notch calibration and vanilla shield drop ranges, all GCCs will be on an even playing field while bringing them more in line with vanilla. I already notice issues with being able to angle my shield down+forward/backward while on plats because of UCF; there is no reason to make this even worse as well as dumbing down the mechanic further. Shield dropping on vanilla was never some super imprecise input, even when you had perfect notches.
The new shield drop change is specifically for OEMs that shield tilt at the notch when they intend to shield drop even with UCF 0.8 - if you instead have trouble intentionally shield tilting on current slippi you would find the same on vanilla. We applied the tilt intent algorithm to the new range and required being in the range for 2+ frames, both to minimize the impact on existing attempts to shield tilt and prevent any change from occurring for people who are currently able to shield drop. I think you'll find after testing that the impact is far less than you think it could be.
I get that the intent is to help OEMs, but unless I'm mistaken this change is applying to all GCCs, right? If you're using an OEM you should either be notching your controller or calibrating it in the game menu before playing. Can you give a good reason why we still need expanded shield drop ranges? If you were at least opposed to notching then that would make a little more sense, but you don't even want to ban firefox notches... For people using phobs where the notches are calibrated accurately, the map you provided [here](https://twitter.com/PracticalTAS/status/1723459584122061193) suggests that even if I don't reach the notch, if I'm trying to angle my shield from the side I will constantly be accidentally shield dropping. I don't see how a 2f limit helps either since obviously I will be staying in that range for multiple frames. The entire yellow area will now be off limits for this kind of angling, not to mention you're just making the mechanic of shield dropping way too easy overall. This is all such a messy solution, and if there were no better alternative I wouldn't care, but notch calibration allows for a very elegant solution that utilizes the games natural shield drop values to be used.
Does this mean I can actually dash back techchase out of crouch without being blocked by a paywall??!
Probably not, but it will mean that failures to dbooc are skill issue rather than luck issue
Yes, the vast majority of controllers should be able to consistently dash back out of crouch given enough practice with the motion. The main exceptions will be very old controllers that are also failing in other ways.
Sick thanks :)
Asking late but how is ~~input delays~~ travel time going to be implemented? Is it just some interpolation between the two points? If it's interpolated, will it be a linear or closer to an accelerated interpolation? Is there a minimum/maximum speed at which interpolation must be done? If your input changes for some reason in the middle of a motion, does the interpolation algorithm restart from the last interpolated point you were at? Is there a difference in travel time for a full left to full right motion vs a left to neutral or a left to slightly less left? Is this a linear relationship between distance? Does implementing buttons for an analog joystick on the same "plane/face" allow or disallow paddles on a GCC or other pad style controller? Example: up and right controlled on rear right hand paddles and down/left on rear left hand paddles. These *could be* viewed as same face, but definitely not as same plane. If they were implemented as buttons on the grip rather than paddles, would it change the ruling? A logical extreme of the rules, but does having buttons on a spherical surface count as same plane or no? If it's accessed on a ball held in one hand with positions that are non-planar to each other, how do the rules affect this? Edit: What is the reasoning behind fuzzing being 50%/25% and 25%/12.5%/6.25%? Is there measured statistical evidence for the distribution of analog sticks on notches? If so, are these published or available with the testing methods anywhere? Also I might have missed it, but are Phob notch calibrations held to the same output fuzzing standard that box controllers are?
Interpolation between start and end with a defined length of time for the jump. Currently linear but we are investigating accelerating cubically instead. Speed is defined indirectly by the time requirement. Input change in the middle of the motion results in a new motion from the currently interpolated point. Full left to full right has a faster minimum than left to neutral or left to slightly less left but in practice will be slower because full left to full right will usually be interpreted as full left to neutral to full right due to nsocd (ie rewarding players who are more accurate with the release + press). Paddles are allowed in general as long as you don't violate 1:1. For c-paddles that sounds fine to me, the final wording should allow it imo. Same for buttons. Same plane rule will have a maximum angle deviation requirement to allow curved faces but not allow circumventing the rule by arguing that opposite sides of a sphere are the same plane. Final wording tbd but it'll probably be around 10 degrees. Fuzzing reasoning is primarily for ease of calculation on low power devices (minimizing number of cycles needed). When I notched my 1.0 cardinal I approximately got 30/40/30 so 50/25 is close enough and is implemented as rng with 1+2+1=4 buckets. 25/12.5/6.25 is similarly 1+2+1+2+4+2+1+2+1 = 16 buckets and trivializes to 50/25 when calculating on one axis. No published notch evidence unfortunately. Phob calibration does not have fuzzing enforced as they are analog inputs and physical notches.
Thanks for the reply! I don't remember what it said in the doc, but is it planned to address Phob and analog calibration fuzzing to maintain parity between stick and button ruleset implementations?
There are limits on the size an individual coordinate can change via phob recalibration to prevent targeting individual coordinates in the same way fuzzing prevents targeting individual coordinates on a rectangle. Different implementation but same intent.
Will the [polling drift](https://www.youtube.com/watch?v=ew6XL5Pq8jc) be fixed in this version of UCF?
They're separate fixes, but I recommend that polling drift fix is used and have [included it](https://github.com/practicaltas/melee-gci-compiler/blob/main/ucf0.84/ucf_data/ntsc1.02/polling_drift_fix.mgc) in my UCF 0.84 memory card.
Why not include it in UCF?
Can you show us a layout of the new 1.0 cardinals?
[Here you go](https://twitter.com/PracticalTAS/status/1619243481721110529). * Yellow = 1.0 on UCF 0.84 * Red = 0.9875 on UCF 0.84 Vanilla 1.0 is the bright yellow dot, plus the dark yellow dots on the exact same row as it (a 1-unit-high line)
Broken link for me. Could be a Twitter/X thing.
Oops sorry, I messed up the paste. Fixed, please try again.
Why not make the rule be: digitals are banned, purchase an ergonomic analog controller instead? Why 1.0 cardinals? This is just a balance patch. There’s no reason to artificially make everyone faster after 20 years.
not ptas but a lot of controllers (oem and phob/goomwave/rectangles) output 1.0 cardinals, its more for standardization than pushing the limits of the game or whatever. a lot of ppl are already using 1.0 so its only making the .9875 controllers faster (and even then the difference is so negligible it barely makes a difference in regular gameplay)
Re banning boxes: There are legitimate accessibility reasons for keeping box controllers legal. We don't want to give people no choice but leaving the community if we have the option to let them keep using the hardware they're comfortable with. And even without that necessity, I don't begrudge anyone who decided that gcc-style controllers weren't for them. Re 1.0: /r/SSBM/comments/17t2g9y/hi_im_practicaltas_and_i_lead_a_group_proposing_a/k8ua4w6/
Just what melee needs, to be a more expensive, harder to get into hobby, while alienating the many people who play on digital controllers already. Brilliant.
I really wish that the dbooc fix went further. I don't think this is going to move the needle in terms of offering consistency to dbooc across all controllers.
Having given top players the code for the additional dbooc frame window, and having heard their feedback that it makes dbooc too easy to the point where they were still dashing back with intentionally poor inputs, I think going any further is going too far.
I don't see an issue with erring on the side of it being too easy rather than too hard. Shield drops are incredibly easy nowadays when they used to be much more controller-dependent. I can shield drop with near 100% success now, when that would've been a pipe dream 10 years ago. And this is due almost entirely to UCF
You could shield drop with near 100% accuracy until you wore down your notch, prior to UCF. Ignoring bad polls, a practiced player can already dbooc with near 100% accuracy.
> You could shield drop with near 100% accuracy until you wore down your notch, prior to UCF I'm talking about an unmodded controller without notches. Unless we just want to require everyone to get notches now? > Ignoring bad polls, a practiced player can already dbooc with near 100% accuracy "Ignoring bad polls" is doing some heavy lifting there. I'm sure you have actual stats on this, from the sounds of it there was a lot of testing the changes behind the scenes. What are the actual success rates for dbooc in vanilla vs. UCF 0.84. How are the success rates affected by having an unmodded controller vs. notched vs. rectangle vs. whatever else?
One of the primary motivations for UCF was that depending on the orientation of your stickbox your standard controller diagonal notch could give you a 100% success rate on Axe/Sung shield drops or near 0%. We had players test on OEM with a 95%-98% success rate, which is consistent with somewhere between the majority and all failures occurring due to the bad polls that 0.84 fixes. When I say ignoring bad polls, that's what I mean. Given the right motion and speed, shield drops and dbooc on 0.84 should be equally reliable assuming you have a half-decent controller. The difference is that most players don't currently know whether their dboocs are failing due to polling or due to not performing the motion fast enough.
I'm a bit confused. So the 95-98% success rate is for shield drops on an OEM with UCF 0.84? And how does that success rate compare to the success rate for dbooc under the same conditions?
Do you think the scene needs a new central organizing body to better coordinate between the different facets of the community? It feels to me like several recent events in the scene would have been better handled if there was a central authority instead of it just being an open season shouting match here on reddit or Twitter.
In general the various stakeholders in the community already work as a loose organizing body. Something more formal could be good, but I think that the forces which lead to a central organizing body, such as developer support or other monetary incentive to work collectively, are not present in the Smash community. So we work with what we've got.
Is limiting box to only individuals with disability something that's being considered
No, but we have discussed re-allowing certain aspects that the current rules ban (for instance, a foot pedal) at a TO's discretion for handicap accessibility reasons.
I'm thinking of Chillin's situation as well, or those similar, using one-handed controllers(should Chillin ever return to competition)
Do you prefer soft or hard boiled eggs?
Yes
I don't think the box needs any more nerfs than what Hax has already done, but do you seriously not see the problem with creating such a huge divide with the firmwares, where some events will be running nerfed firmware and others wont?
Yes, that's why I've sent this proposal to every major organizer and hope that they all implement it together.
Is there a reason to enforce neutral SOCD outside of "make the boxx less comfortable to use"? It doesn't change the parity with GCC at all, it just trades a button press for a button lift on most tech. Our hands have stronger muscles to contract than extend, so "Last Input" SOCD is often preferred for comfort. Enforcing neutral SOCD feels spiteful, rather than banning techniques that are "GCC impractical" it just makes rectangles worse to use.
Enforcement of neutral SOCD is intended to slow down and make more difficult the instant, easy changes of direction that are practically the hallmark of 2ip box play. While it's arguable that NSOCD is worse than a gcc stick in some (not many) aspects, it's quite clear that 2ip SOCD is significantly stronger from top to bottom. It's not spite, though.
I installed the nerfs on the test haybox to my LBX and really feel good about them thanks so much for your team's work. My question is if I am using the nerfed firmware does using a setup using UCF with the nerfs additionally affect my controller?
Lots of respect for what you're doing but I can't help but feel like the melee community really rushed into accepting Boxx type controllers too quickly, and that all these nerfs are things that should have been there from the start as opposed to being added in a trickle afterwards. It gives me a somewhat uneasy feeling that what feels like clear-cut cases like travel time simulation are only being implemented now Great work, though
I have to say that the socd rules are always set to the same for x and y, but in reality the reasoning *always* has only to do with x axis shenanigans. Do you have reasoning for the socd specifics applying to the y axis, with specific examples? I'd be very interested to hear, if so! The main thing socd on y axis affects is causing misinputs when you are recovering and try to press up b while accidentally still holding down with your left hand. This isn't a big deal at all, despite being something impossible to fuck up on a controller, but it is, in my (obviously limited as I am but one person) experience, literally the only time y axis socd ever does anything. It seems like recency priority socd for y axis wouldn't actually cause any issues. Additionally, it is trivial to apply different socd rules to the x and y axis inputs, so arbitrarily making them the same seems... Incredibly arbitrary.
> Proof: https://twitter.com/PracticalTAS/status/1723430893593772166 I don't think you needed to prove that you're practicaltas lol, we know your account, and it's 8 years old