Jolin012 | Botw chus with skulltula push setup 1 stick and nut (oot calendar 2021 day 25) @MrJolin012 | Uploaded 2 years ago | Updated 1 minute ago
Joint discovery by blini and me.

This new trick was revealed in oot calendar 2021, day 25.
Calendar video: insert link here

WARNINGS:
The skulltula can sometimes push you on the wrong frame, either 1 frame early or 1 frame late despite all steps in the setup being performed correctly. While I have a theory on how this works, it will require more research and investigation to be sure, so i dont want to put it in the video. It seems likely that we can learn to manipulate this seeming randomness and make it 100% consistent, either by adjusting the setup to be more slight variation, or simply being more meticulous about certain steps when we know for certain what's going on.

Here are my current hypothesis on what is going on:

The corpse of the skulltula does not spawn a given number of frames after we kill it, which we would have liked. Instead it spawns a given number of frames after the skulltula drops and hits the ground. This means that if the height and initial y velocity of the skulltula when killed differs, the number of frames until it hits the ground differs, and in turn the push timing differs, which we cannot accept.

The y velocity of the skull when killed can differ and is affected by 3 things. Before listing them, some background info.

The height of the skulltula is affected by its cyclical bobbing up and down, the vertical bobbing cycle has 16 frames, 8 frames going up (positive y vel) 8 frames going down (negative y vel). this is not to be confused with the 60 frame flipping cycle, 30 frames facing link, 30 frames facing away. The bobbing cycles start when link enters the scene, while the flipping cycles are initiated by link entering into the close vicinity of the skull where it drops. This means the 2 separate cycles (bobbing and flipping) are independent and how they align depends on which bob you enter the skulls range at. If we learn more about this and which bob is ideal we could even look at the skull to know when to get in its vicinity making it drop.

Further, if we see that a bob is bad when we go to hit the skull, we can wait 1 flipping cycle. because 60 frames does not correspont to an even set of 16 frame bobbing cycles, this offsets the bobbing by 4 frames, which could in such a case be beneficial.

Lastly, if you pause buffer the slash input, the bobbing cycle of the skulltula, or at least the y velocity of it, in some sense keeps running. At least I have seen that depending on the number of frames you pause for, the y velocity on the following frame will be different, and can even attain values not part of the ordinary y velocity bobbing cycle. why this happens I dont know, but it cycles every 16 frames. So if you are in the pause menu for an additional 16 frames you get the same result. There is however some relief to be found, because in my single test of this, there were two sets of 5 consequtive frames in the pause menu giving identical result. Perhaps this will always be the case, perhaps not. But if it is, and if one of these consecutive frame windows is near the start there is some hope that immediate unpause hits a range of 5 consecutive frames with predictable results.

If you wanna go unbuffered for now, to skip this nonsense while its not fully figured out, but also dont wanna risk having to reset, you can throw a nut before slashing the skull, freezing it at a correct angle, without risking killing it.

So these are the 3 things that affect y velocity of skull, which in turn affects how fast it drops to the ground:

1: when you trigger the skull to drop, relative to its bobbing
2: if you let the skull flip additional cycles before striking
3: if you pause buffer anything before making the skull swing

Now, thats not the end of it. the time it takes for the skull depends on the y coordinate of the skull before it dies too, not just the y velocity.

This is affected by the same 3 things with a little extra nuance:

It naturally bobs cyclically every 16 frames, directly determined by y velocity fluctuating between positive and negative, so whether its at a peak or valley when it is time to strike it depends on point 1 and 2 above, i.e. when its triggered to drop and how many flips you wait.

The bobbing y coordinate is however not only affected by this. the mean value around which is oscillates up and down is not always the same. The mean value it can vary by 6.00 units, depending on when in its pre-drop bobbing cycle the skull is caused to drop. This is likely because it drops until it reaches threshold y value around which it resules oscillating (instead of dropping a specific distance), thereby dropping an additional distance if it dropped out of a high bob.

So while this is complex, if we can just have a robust setup where we know this is not enough to jeopardize it, an/or we can manipulate it by timing when the skull drops, and avoid pausing or understand when/how it is safe to pause, this will be fine. Help from decomp and more research will help.