EverAlert
Smash Master
Revisiting the Hylian Desync
A Technical Analysis
A Technical Analysis
Recently, I’ve been giving Ice Climbers a lot of focus. With RoboCop around the corner, I’ve been doing a lot of hardcore training in the past weeks, and while a lot of it was pounding away at the most common faults in my gameplay (read: a LOT of chaingrabbing practice), thanks to Lux constantly pestering me I’ve also been doing a fair amount of testing. More recently, he’s been pestering me to play around with the Hylian Desync based on the theory that it’s actually just a specific other desync (we’ll get to that in a bit).
I’m not fully certain how well the Hylian Desync has survived the test of time, so all of this might be a misplaced effort, but the purpose of this thread is to analyse the Hylian Desync and a couple of others mechanically related to it, understand exactly what makes these desyncs tick, and then abuse this knowledge to raise consistency.
The last point I feel is important (and is a main motivator for this thread), because my consistency with the Hylian Desync skyrocketed after I understood exactly what was happening on a per-frame basis: I literally went from 1-in-20 success to a 90% success rate without putting in any practice whatsoever, just understanding how the desync worked and changing “what I was shooting for” accordingly. If anyone else was like me and couldn’t get it down consistently, or just didn’t bother learning it, I believe this analysis will be of tremendous help.
For each desync I will give a visual representation (pretty animations!), the frame data to perform the desync, then discuss what’s going on behind the scenes. The frame data will come in the form of input maps (see the end of this post if you have trouble understanding them). The rest should be self-explanatory. Any side notes will be in small text.
Enough of that, let’s start with the Turnaround Desync.
The Turnaround Desync
There is a single significant mechanic in play here, and that is namely the mechanic where Nana flips to copy the direction Popo is facing. But to understand why this is significant, we need to understand how a dash turnaround works.
Essentially, when you tap the other way to dash in the opposite direction, you experience 1 frame of lag where Popo is, well, turning around. After this, he simply dashes identically to a forward dash. This is why all the windows for rolling, FSmashing, etc. in the backward direction have a 1-frame larger window compared to doing them forward. However, if you do none of these things, Popo will simply dash. It’s important to note that if you tap back and release the stick after exactly 1 frame, Popo will turn around but not dash.
Because of Nana’s direction-copying mechanic, she will flip to copy Popo’s facing before ever experiencing this 1 frame of turnaround, and she is thus immediately thrust into a dash. Because she is stuck in this dash, but Popo isn’t, Popo is free to do what he pleases as long as it doesn’t involve the Attack button, and that is the basis of this desync and the desyncs to come.
As a side note, Nana will flip to copy Popo’s direction 3 frames after she sees he’s facing the other way (her input delay behind Popo is 5 frames, and she is therefore flipped on frame 4 of the Turnaround Desync, 1 frame before she would have experienced her turnaround).
The Reverse Initial Dash Desync
The Reverse Initial Dash Desync introduces one more important mechanic to the mix: Buffering. This is the desync Lux thought the Hylian Desync actually was - and he was half right!
Now, the fundamental reason the Climbers desync in this case is the same as the Turnaround Desync – Nana fails to experience her turnaround, causing her to be 1 frame ahead of Popo after accounting for her delay. This time, Popo opts to dash with her instead of acting on the advantage immediately. But where does buffering come into this?
Both Climbers each have a 10-frame buffer, the same as any other character. Because Nana is now 1 frame ahead of Popo, if she buffers an action (again, excluding Attack-button commands) on exactly the first frame of her buffer window, when the buffer takes affect she will perform the action. Popo won’t, however, because he never actually buffered anything in the first place, causing him to be free to do whatever.
In case you need further explanation, let’s make this concept more visual. Imagine a set of blocks, each representing one frame, that each Climber must go through in their action queue:
Popo - [02][01][00][01][02][03][04][05][06][07][08][09][10][11][12][13]
Nana - [01][00][01][02][03][04][05][06][07][08][09][10][11][12][13][14]
Purple represents “active” blocks, or buffering blocks
Green represents the block the buffered action takes affect
Grey represents dead/insignificant blocks
As you can see, Nana gets to access her first active block one block before Popo does, and as a result she gets to have her move come out one block ahead if she wishes. Because you tell both Climbers what to do with their blocks simultaneously, telling Nana to use her first active block means you’re also telling Popo to do something with a block that he simply cannot.
The Hylian Desync
With the Hylian Desync, we introduce no new mechanics. On the surface it even looks the same as the Reverse Initial Dash Desync! However, behind the scenes something different is going on, and here we abuse one of the previous mechanics in a different way, the mechanic of course being Buffering.
Consider this: What happens when you spot dodge, and buffer an action near the end? Obviously, that action will be performed. But what if you input a different action exactly 1 frame after the last frame of the spot dodge? The new action will override the buffered action and will be performed instead. In addition to the concepts introduced previously, this is the basis of the Hylian Desync.
If, instead of buffering an action on the single frame Nana can and Popo cannot, you buffer the action (with the same criteria as before) even 1 frame later, then both Climbers will perform that action at the end of their dashes. However, let’s say you input a different action 1 frame after Popo’s buffer window.
This causes Nana to perform the buffered action (she’s one frame ahead, so the frame after Popo’s buffer window is 2 frame after Nana’s window, or in other words 1 frame after Nana’s buffered action takes affect), but Popo of course will not because he has another action overriding his buffer.
This is commonly a dash, because it has the widest utility in real matches. However, Popo can cancel the buffer with any action he wishes, including those involving the Attack button (unlike before). Obviously, as long as it has a different duration to the move Nana is doing, it will cause a significant desync.
In Summary
So, how can we use this knowledge to make performing the Hylian Desync easier?
Before, the common method was to turnaround into dash, and then only at the very end of the dash input an action and then the second dash. This created the illusion of technical difficulty.
Now we know we have a full 10 frames in which we can input Nana’s action, followed by a second input on a precise frame. This reduces the number of precise inputs from 2 to 1, obviously with a huge gain in ease of execution.
And I believe that covers the essentials. Feel free to ask me about any details you need elaborated on, I'm here all week.
Appendix
A Note on Input Maps
Input maps are presented in the following syntax:
Frame : Timer : Action
The Frame is the number of frame relative to the overall duration of the action the input map is describing. The first input is always on Frame 0 because you have to input that the frame before anything happens. Similarly, all inputs will be recorded the frame before they are executed on screen, because the input is read by the game at the end of the frame before the action takes place.
The Timer is what the milliseconds part of the clock should look like if you start the inputs on the frame a full minute is shown on the clock (e.g., 5:00 00).
The Action is, of course, what’s happening during the input sequence. This can be anything the game is doing in response to inputs, or it can be the inputs themselves. For the sake of brevity, input maps in this thread will only include the actual inputs.
