I heckin love these vids! They’re always in good faith, super informative, and well put together to where you can learn stuff that goes beyond melee, too!
I've noticed that I've been missing dash forwards (walk occurs instead) equally as often as dashbacks on the new UCF, and I have two possible theories -- assuming I'm not crazy. Please at least consider that what I'm saying might be true. 1. With a character like Sheik, because you want to "flick" the stick rather than "holding out" the input when you dashdance in order to perform her foxtrot dashdance without entering run, I've experienced issues that many other players wouldn't have happen to them, and maybe the new UCF has changed this from the previous version in some way, or that the 1.0 "clamping" code has messed with this in some way 2. The 1f buffer for executing a dash out of lag has possibly been removed or compromised in some way. I've been entering walk very often especially when trying to act out of lag, and it's possible that my previous muscle memory is producing different results. I've experienced this dashing issue on Dolphin and CRT with 0.84, and with the input integrity adapter I've ensured that visually my netplay setup's latency is extremely close to that of a CRT setup (within 2ms). I've also used various controllers (PhobGCC, OEM), with different stickbox springs in new-condition stickboxes as well as ensured the health of their potentiometers (for the PhobGCC, replicated the waveforms to that of a healthy OEM), yet still have had issues dashing. Some other various things I've felt have been off: Shielddropping, especially when using the buffer for doing so, seems to cause a spotdodge instead, especially when done out of shieldstun. Several other top players (Zain, Ginger, Krudo) have corroborated this, but obviously it's just our opinion. When trying to shield tilt, I've found that I've been rolling instead. Perhaps the old version of UCF made it easier to do so, and I've developed muscle memory according to that. Even if all of this is placebo and I'm completely wrong about everything, I would say it is extremely unwise and downright rude to enforce and switch to a new software right before the biggest tournament of the year, and have Slippi Dolphin adopt it only 2(?) days before said event. Even at Mango's Genesis bootcamp, all of the setups except the main stream setup were on UCF 0.8, not 0.84. Everyone has been practicing on a different game. Changing the game right before the biggest tournament in the world is extremely rude in my opinion. I know 0.84 was said to have been beta tested by the public at regional events for the past year, but let's be real -- 99% of players would not think to blame the software if they missed a few things. I also am the world's most-traveled Melee player. I went to ~30 tournaments all across the world in 2023, and all of them used UCF 0.8, not 0.84.
Have you tested all these things in UCF 0.8 using the same setup (same controller, same console, pc, etc)? having said that, I agree that it was whack to have slippi/UCF updated a few days before genesis
Hey Spark! I DM'd you on Twitter. But you can reach me on Discord as well if you prefer. I'd love to dig into it further, but not back and forth on social media :)
I appreciate the proof that 0.84 dashbacks are working as intended via the stated definition, but I slightly disagree with your methodology. Imo you should have included a tournament using a prior version of UCF in the testing as an additional (and granted, redundant) control. Additionally, the claim by people seems to be that "0.84 dashbacks are giving slow turnarounds more often than older versions." In my opinion, the best way to falsify this statement would be by comparing the rate of slow turnarounds rather than successful dashbacks. It's possible an older version may have been giving dashbacks when it should have been giving turnarounds. I'd be interested in seeing someone break down how many slow turnarounds happened in this same recent 0.84 major, listing what 3-frame series of analog inputs led to that, searching for those same permutations in an older major, and comparing the outputs. Love the work you do! Stay hydrated!
Alas, there's only so much I can cover before the video becomes an hour long. One thing I considered covering but didn't was the chain of events your inputs take until being consumed by the game. The point there would be that UCF has nothing to do with the creation of the raw inputs, as read by the game. If the allegation is that your RAW inputs are suddenly different, then that really has nothing to do with UCF. Still, it might be interesting to see a slow turn / fast turn ratio across different majors. Perhaps I'll look at it.
To be more precise, a barely-missed dashback doesn't give a slow turnaround, it gives a few frames of slow turnaround and then dash. It's harder to see but still very impactful.
This is true! Also even in “reubicar Meele, you have two frames to buffer a true 1F-turnaround dashback out of many lag animations such as throws. In vanilla/regular, dashback was inconsistent out of stand and aerial landing lag (with the latter being significant in my opinion).
Nice vid! Technically, controllers send unsigned bytes for stick values, which are converted to signed ingame. I.e. values from 0 - 255, 128 corresponding to signed 0 ingame (if controller is exactly center calibrated).
Does the physical "wiggle room" of a controller have any impact on the games deadzone? I thought it was purely a mechanical degradation in the stickbox. Isn't the distance from the center, as read by the potentiometers, still the only thing that affects the deadzone? If you used brand new potentiometers with a loose stickbox it would still have no pode and worst vanilla dash back right?
_as read by the potentiometers_ is the key point here. Potentiometers are reading 0 within the entire wiggle zone. It's unintended hardware deadzone. Very few controllers use optical control sticks, but a very notable one that does is the N64 stick. Indeed, a very loose 64 stick flopping around will send input to the game.
@@Cmanorange In a lot of ways it would actually make the game better. 1frame dashback is really broken for characters like marth and fox. It would also get rid of tech like dash back out of crouch and smash turnaround bair which are really annoying to execute and very strong.
what makes you think slow turnaround is intended and 1 frame dashback is the bug? I would argue starting a slow turn around animation (that's also when you tilt the stick slowly) then cancelling it after a few frames into a dash is the more strange and buggy outcome than just dashing backwards on the frame you input it like dashing forward
@@roundupssbm dan salvato found a way to align polling with the frames or something a long time ago but we ended up using a different polling fix for slippi, idk, but its definitely possible
That's polling drift fix, which is already being used on slippi and slippi nintendont. Doesn't eliminate the problem of polling because it's impossible to circumvent by nature. Polling drift fix =! Unlucky polling on 1f windows
@@roundupssbm the version used on slippi is the same one from faster melee years ago, it was chosen to reduce lag but dan salvatos would have fixed the 1f windows afaik
@@TylerClibbon Dan Salvato's fix does nothing about unlucky polling for 1f windows. It's more of a physical phenomenon than a software thing. It's not possible to fix unless you change how certain actions are actually handled in the game.
I heckin love these vids! They’re always in good faith, super informative, and well put together to where you can learn stuff that goes beyond melee, too!
Glad there’s no issue 🙏
Betteridge's law of headlines
I've noticed that I've been missing dash forwards (walk occurs instead) equally as often as dashbacks on the new UCF, and I have two possible theories -- assuming I'm not crazy. Please at least consider that what I'm saying might be true.
1. With a character like Sheik, because you want to "flick" the stick rather than "holding out" the input when you dashdance in order to perform her foxtrot dashdance without entering run, I've experienced issues that many other players wouldn't have happen to them, and maybe the new UCF has changed this from the previous version in some way, or that the 1.0 "clamping" code has messed with this in some way
2. The 1f buffer for executing a dash out of lag has possibly been removed or compromised in some way. I've been entering walk very often especially when trying to act out of lag, and it's possible that my previous muscle memory is producing different results.
I've experienced this dashing issue on Dolphin and CRT with 0.84, and with the input integrity adapter I've ensured that visually my netplay setup's latency is extremely close to that of a CRT setup (within 2ms). I've also used various controllers (PhobGCC, OEM), with different stickbox springs in new-condition stickboxes as well as ensured the health of their potentiometers (for the PhobGCC, replicated the waveforms to that of a healthy OEM), yet still have had issues dashing.
Some other various things I've felt have been off:
Shielddropping, especially when using the buffer for doing so, seems to cause a spotdodge instead, especially when done out of shieldstun. Several other top players (Zain, Ginger, Krudo) have corroborated this, but obviously it's just our opinion.
When trying to shield tilt, I've found that I've been rolling instead. Perhaps the old version of UCF made it easier to do so, and I've developed muscle memory according to that.
Even if all of this is placebo and I'm completely wrong about everything, I would say it is extremely unwise and downright rude to enforce and switch to a new software right before the biggest tournament of the year, and have Slippi Dolphin adopt it only 2(?) days before said event. Even at Mango's Genesis bootcamp, all of the setups except the main stream setup were on UCF 0.8, not 0.84. Everyone has been practicing on a different game. Changing the game right before the biggest tournament in the world is extremely rude in my opinion. I know 0.84 was said to have been beta tested by the public at regional events for the past year, but let's be real -- 99% of players would not think to blame the software if they missed a few things. I also am the world's most-traveled Melee player. I went to ~30 tournaments all across the world in 2023, and all of them used UCF 0.8, not 0.84.
Have you tested all these things in UCF 0.8 using the same setup (same controller, same console, pc, etc)?
having said that, I agree that it was whack to have slippi/UCF updated a few days before genesis
Hey Spark! I DM'd you on Twitter. But you can reach me on Discord as well if you prefer. I'd love to dig into it further, but not back and forth on social media :)
@sparkmelee @2600AltF4 soo...anything new about this?
Something definitely feels off about 0.84 and I don’t like it
I appreciate the proof that 0.84 dashbacks are working as intended via the stated definition, but I slightly disagree with your methodology. Imo you should have included a tournament using a prior version of UCF in the testing as an additional (and granted, redundant) control.
Additionally, the claim by people seems to be that "0.84 dashbacks are giving slow turnarounds more often than older versions." In my opinion, the best way to falsify this statement would be by comparing the rate of slow turnarounds rather than successful dashbacks. It's possible an older version may have been giving dashbacks when it should have been giving turnarounds.
I'd be interested in seeing someone break down how many slow turnarounds happened in this same recent 0.84 major, listing what 3-frame series of analog inputs led to that, searching for those same permutations in an older major, and comparing the outputs.
Love the work you do! Stay hydrated!
Alas, there's only so much I can cover before the video becomes an hour long. One thing I considered covering but didn't was the chain of events your inputs take until being consumed by the game. The point there would be that UCF has nothing to do with the creation of the raw inputs, as read by the game.
If the allegation is that your RAW inputs are suddenly different, then that really has nothing to do with UCF.
Still, it might be interesting to see a slow turn / fast turn ratio across different majors. Perhaps I'll look at it.
To be more precise, a barely-missed dashback doesn't give a slow turnaround, it gives a few frames of slow turnaround and then dash. It's harder to see but still very impactful.
This is true! Also even in “reubicar Meele, you have two frames to buffer a true 1F-turnaround dashback out of many lag animations such as throws. In vanilla/regular, dashback was inconsistent out of stand and aerial landing lag (with the latter being significant in my opinion).
*regular Melee
Nice vid!
Technically, controllers send unsigned bytes for stick values, which are converted to signed ingame. I.e. values from 0 - 255, 128 corresponding to signed 0 ingame (if controller is exactly center calibrated).
All your videos are great :)
babe wake up new alt f4 video dropped
sick arasaka shirtt
Does the physical "wiggle room" of a controller have any impact on the games deadzone? I thought it was purely a mechanical degradation in the stickbox. Isn't the distance from the center, as read by the potentiometers, still the only thing that affects the deadzone? If you used brand new potentiometers with a loose stickbox it would still have no pode and worst vanilla dash back right?
_as read by the potentiometers_ is the key point here. Potentiometers are reading 0 within the entire wiggle zone. It's unintended hardware deadzone.
Very few controllers use optical control sticks, but a very notable one that does is the N64 stick. Indeed, a very loose 64 stick flopping around will send input to the game.
Awesome thanks for the video!
Hey cool video! I'm curious; what cards are those in the background?
Mostly modern decks that are half assembled. And I think one of them is Legacy Hogaak?
That people are even paranoid of things like this, regardless of whether they are real or not, is a inherent downside of software modding.
Dont let hax fine out or he will make a new faulty Mechanic video
( I love hax no hate to him)
Slow turnaround is actually the intended behaviour. 1 frame dashback is the bug so really we arguably should've just removed dashback entirely.
troll posting this early eh?
yes, instead of making the game better we should have made the game worse. you have a career in government my friend
@@Cmanorange In a lot of ways it would actually make the game better. 1frame dashback is really broken for characters like marth and fox.
It would also get rid of tech like dash back out of crouch and smash turnaround bair which are really annoying to execute and very strong.
what makes you think slow turnaround is intended and 1 frame dashback is the bug? I would argue starting a slow turn around animation (that's also when you tilt the stick slowly) then cancelling it after a few frames into a dash is the more strange and buggy outcome than just dashing backwards on the frame you input it like dashing forward
Source? Evidence? etc? You are just guessing about what is a bug and what is intended.
Vanilla is good idk why it gets hate, fucked up
I thought default was just called vanilla because it’s common… didn’t realize ppl were hating on a solid ass flavor
Should have used Melee 1.03 but bunch of sheep flocked together as usual cause haxbad
1.03 god, all Hail Hax$
we should fix polling instead of changing frame data
Lmao do you even understand what polling is
But sure, I'll bite. How would we fix polling?
@@roundupssbm dan salvato found a way to align polling with the frames or something a long time ago but we ended up using a different polling fix for slippi, idk, but its definitely possible
That's polling drift fix, which is already being used on slippi and slippi nintendont. Doesn't eliminate the problem of polling because it's impossible to circumvent by nature. Polling drift fix =! Unlucky polling on 1f windows
@@roundupssbm the version used on slippi is the same one from faster melee years ago, it was chosen to reduce lag but dan salvatos would have fixed the 1f windows afaik
@@TylerClibbon Dan Salvato's fix does nothing about unlucky polling for 1f windows. It's more of a physical phenomenon than a software thing. It's not possible to fix unless you change how certain actions are actually handled in the game.