BitFS 0xA Pole Skip with 3 Hacked Bullies Description

It's been almost two years since my last video. I've been working on this ever since, but didn't have any noteworthy progress to share until now. This video provides a blueprint for a solution to the biggest problem with the BitFS 0xA Pole Skip plan, which we've named the Final Speed Transfer (FST). This video does not solve the FST, but it reduces the problem to a much simpler (although computationally difficult) form.

The pole skip relies on getting PU speed for Mario, and then moving to the tilting pyramid platform in a PU. This causes the platform's rotation matrix to be applied to Mario at a very large distance, which magnifies the vertical displacement he gets by a factor of thousands. This is used in VCutM in 1 Key. Normally this displacement is always negative, but ds273 demonstrated that it can be positive at certain extreme platform tilt ranges (https://www.youtube.com/watch?v=bS_5UJLibKc). I believe this is because at some step in the calculations for the rotation matrix, the game assumes the rotation about the z axis for the platform is 0.

The problem with the FST is that tilting the platform into this range while also having PU speed is almost impossible. When Mario has PU speed and is pushing against a position that is out of bounds, he will stay in place, but he won't snap down to the floor of the platform as it tilts. The platform's rotation matrix is supposed to apply to Mario, so in theory he should stay at the surface, but as discussed the rotation matrix is incorrect, and he will drift away from the surface of the floor due to the error. The game only considers Mario to be on the platform if he is within 4 units vertically of the floor, so he quickly exits this range due to the accumulating rotation error, and the platform stops tilting.

This makes it very hard to tilt the platform after performing the final squish cancel speed transfer. Additionally, performing a speed transfer has required Mario to slide off the platform and fall for at least 6 frames. Each frame Mario is not on the platform, it tilts back to the resting position. These 6 frames pretty much eliminate any chance of being able to meet the extreme platform tilt requirements. Additionally, there are limitations to how far you can tilt the platform in the right direction and still meet the conditions for a squish cancel speed transfer.

Despite these obstacles, in this video I use 3 bullies with hacked speeds, angles and positions on 3 specific frames to pull off the FST. Nothing else is hacked. I use a number of tricks and optimizations to perform a squish cancel speed transfer to a sufficient PU speed for Mario while still meeting the requirements for the platform tilt. Additionally, I make use of some powerful automation software developed by bad_boot, myself, AnthonyC4, fifdspence and Krithalith to calculate a way to perform the platform displacement upwarp and navigate a quick return route through PUs.

Here's what happens.

Step 1: Mario activates the track platform at the beginning and waits by the 1 up so the platform can get into position. Then, Mario performs movement that causes him to land on the farther pyramid platform at a floating-point-precise X and Z position. pannenkoek2012 was kind enough to TAS this section, as he has a method to target FP precise positions. This was actually TASed after the next part, so the position was known beforehand. I hexed in the appropriate number of waiting frames based on where the track platform needed to be on a later frame.

Step 2: Mario lands on the platform, and simply waits for it to tilt a bit. Then at a specific time, he performs a punch cancel to get a little bit of speed. This is when the first bully collision happens. I hacked the bully to have 75 million speed in a direction parallel to Mario's speed, but I hacked the position to be fully perpendicular to both speed vectors. Because the bully-Mario collision is basically elastic, both objects preserve their speed in this case. If the angle was anything but perpendicular, the bully would transfer a small portion of its momentum to Mario, which would easily give him 32 speed (knockback speed is capped at 32). 32 speed is a problem because MArio moves way too far and slides off the platform. We need him to barely move at all so Mario must have only a little bit of speed, hence the requirement that the bully's speed be perfectly perpendicular to the angle of collision.

Step 3: It would be nice to just have Mario knockback with 0 speed so we can target the next position easily, but the tilted platform causes Mario to accelerate downhill. Knockback lasts for 25 frames and we need it to run out completely in order to perform the next part. In order for Mario to not move too far despite 25f of downhill acceleration, we want him to have around 10 speed or so, so he finishes with about the same speed in the negative direction. The combination of his low and changing speed and the rotation from the platform causes Mario to move in a small, roughly parabolic arc. I arranged for this arc to finish right at the edge of the lava, at an equilibrium point where the platform is tilted as far as it can go in that direction without Mario falling into the lava. THis is very important, because the platform tilt is represented by a normal vector (normal means perpendicular to it's surface), and due to the platform tilting logic, the X and Z components of the normal vector are conserved as we move across the platform towards the squish cancel spot. This means that our maximum platform tilt is limited by how far we can tilt the platform to start with. Ideally, the platform would be tilted at a 45° angle, as this provides the highest XZ normal sum, but I have to tilt it farther in the X direction for reasons I will explain below.

Step 4: Exactly 25 frames after the first bully collision, the bully collides with Mario again, this time at a non perpendicular angle so Mario gets 32 speed. The frame difference is important because it allows Mario to perform the 1 frame knockback glitch. This is a little-known glitch where if Mario enters a soft knockback action immediately after exiting it, he will exit it again in 1 frame. This conserves speed and puts Mario in idle, which is great for what we do next. Note that the glitch only works if you go from soft forward knockback to the same action, or soft backward knockback to the same action. Soft forward to soft backward or vice versa does not work, nor does this work with any other kind of knockback action.

Step 5: I also position the bully very close to Mario's position so the second collision displaces Mario close to the maximum distance (110 units or so). The combination of this clip distance along with the 32 speed conserved from the 1FKB glitch allows Mario to get across the platform much faster. Furthermore, 1FKB puts Mario in idle, which allows him to immediately dive in any direction since he has more than 29 speed. This means I can immediately perform a pause buffered dive recover as I can dive straight uphill. This is part of the reason for tilting the platform further in the X direction to start. If it was tilting at a 45° angle, uphill would be towards the center, which is not the direction we want to go. The DR is barely possible even diving straight uphill. so the tilt in the X direction is necessary. Not that when the game is paused, the platform appears to revert back to its resting position, but this is just a rendering glitch in the game.

Step 6: The dive+DR gives us +15 speed, but it also puts us in the air. It is possible to land immediately, but this leads to a bad quarterframe landing, and we need to traverse the platform as quickly as possible. Instead, I take advantage of the fact that Mario can be within 4 units of the platform floor and still be considered as on the platform (I mentioned this earlier). This applies even if Mario is in the air, so I am able to DR for several frames while continuing to tilt the platform. This avoids a bad qf landing, defacto speed loss, and ground deceleration, and I think all told it saves about a frame getting across the platform.

Step 7: Mario lands and runs for a couple frames to the edge of the platform. At this point, we have way too much speed. If Mario slides off the platform he will just fly off into the lava. We need him to decelerate rapidly. Fortunately, because we tilted the platform so far in the X direction and we were able to get the speed boost from the DR, we can do a second PBDR, this time to decelerate. IF you don't have any joystick input on the first frame after landing from a DR, Mario's speed will immediately drop to 0. Doing this saves at least 2 in-game frames over any other deceleration option (not actual frames because of the pause), and we need every frame we can get.

Step 8: I believe this is a new tech. Mario does a low joystick magnitude walk for 1 frame, which is uphill, so it gives him less than 1 speed. This puts him into a precise subpixel region on the edge of the platform known as a NUT spot (backronym: Nonstatic Unit Truncation). If Mario finishes a frame in such a spot in an action that can cancel to freefall, the error in the rotational displacement from the platform will move Mario off the edge of the platform, and he will enter freefall. Now, slow walking does not cancel to freefall, but if you don't input anything it will cancel to deceleration. Deceleration doesn't cancel to freefall either, but it does cause Mario to lose 1 speed. If after this, Mario has 0 speed, deceleration will cancel to idle, and that DOES cancel to freefall. However, the point of all this is to enter freefall without sliding off the platform so we can keep tilting it. If we have to avoid joystick input in order to enter the deceleration action, we won't be able to strain back onto the platform. So instead, I press C^ on the slow walking frame. This forces Mario into deceleration even if there is joystick input, so the chain of action cancels can proceed, and the input will be applied to freefall and cause Mario to move back onto the platform on the same frame that he enters freefall. I arrange for Mario to again be within 4 units of the platform so it continues to tilt in the right direction.

Step 9: On the next frame, Mario's Y speed (falling speed) is still low enough for him to hover over the platform in that 4 unit range by straining downhill. After that, he has too much falling speed, so I once again look to take advantage of the NUT spots. Because freefall landing cancels into freefall, I can chain 5 NUT spots together in a row with precise straining down the edge of the platform. Gravity is being applied this entire time, so I can build up -20 falling speed without ever leaving the platform. Mario needs to fall roughly 78 units to go below the floor and get squished by the platform, and gravity is four units per frame. This means in 3 frames, Mario will fall 20 + 24 + 28 = 72 units. By straining uphill in those 3 frames, I can make up the other 6 units, which means I successfully reduced the falling time from 7 (6 + a slideoff frame) to 3. This is crucial for meeting the platform tilt requirements.

Step 10: The third bully collision happens, which is a squish cancel speed transfer. This is done without the assistance of the track platform, which means the bully pushes Mario a considerable distance downhill. In order for this to work, The platform needs to be high enough for Mario to slideoff into the air from the squish push (more than 100 units above the lava). This is the other reason I started with the platform tilted so far in the X direction. It gives Mario barely enough time to get in position. If he takes even one more in-game frame to get there, the slideoff spot will be too low. On the other hand, tilting the platform significantly further in the X direction reduces the XZ normal sum, which causes us to fail to meet the platform tilt requirements at the end. It's all very tight.

Step 11: We now have PU speed and a great XZ normal sum, but our bias in the X direction means that the platform normal is still tilted too much in that direction. We need to convert the X tilt to Z tilt. However, as I explained before it is very difficult to tilt the platform after Mario has PU speed. After the speed transfer occurs, the platform tilts back underneath Mario. However, due to an idiosyncrasy in the code that displaces Mario rotationally, the displacement is not applied the first frame after Mario steps on the platform. This causes the platform to tilt downward without taking Mario with it, and Mario is now more than 4 units above the floor and can no longer tilt it. This is where the track platform comes in. I arrange for the slideoff spot to be near the edge of the track platform's wall hitbox, and I also arranged for the track platform wall to move into Mario on this exact frame. This nudges Mario about 7 units uphill, which puts him back within 4 units of the platform floor, so he can continue tilting it.

Step 12: Mario has now been on the platform for 2f so he will displace with it. Additionally, the error in the vertical displacement causes Mario to displace too far down each frame. I arranged for the track platform wall push to put Mario close to 4 units above the platform floor to maximize the number of tilt frames before Mario displaces more than 4 units BELOW the platform floor. This happens after 5 frames. At this point, the platform is still not tilted enough in th Z direction to pull off an upwarp. You might be wondering why we can't just perform a longer NUT spot chain to tilt the platform more in the Z direction and completely eliminate the need for the track platform push and subsequent tilt frames. Unfortunately, the NUT spots disappear as the platform tilts more in the Z direction, due to the displacement error favoring the center of the platform as the Z tilt increases. This is another reason why we must start with a higher X tilt.

Step 13: Mario has displaced below the platform and can no longer tilt it. However, in the first frame after it tilts back to the center, it puts Mario back within 4 units of the floor. This time, he's underneath it, so even though he does not rotate with it on the first frame, he is still within 4 units of it on the next frame, this time on the upper side. At this point step 12 basically repeats and Mario gets 5 more frames of tilt. This FINALLY meet the platform tilt requirements. For a small range of angles, Mario will get positive vertical displacement if he moves to a PU.

Step 14: But it's not that simple. Angles are not continuous, and the angles that Mario can turn to only will hit the platform in a PU at very specific distances. Furthermore, Mario also displaces a large distance horizontally. If this puts Mario out of bounds (only 1/16 positions are inbounds), the displacement won't happen at all. This all means that there are only a couple dozen of speed/angle combinations that will actually be valid for an upwarp, and most of these put him too far up, in a VPU. With all these filters, there are maybe 2 good speed/angle pairings for a given platform normal vector. Finding these would be totally unrealistic without automation software, and one of the tools I made does just that. I arranged for the third bully collision to give Mario the correct speed for this.

Step 15. Mario has performed the upwarp, but to complete the pole skip he must return to the main universe from his current position in a PU. I do this by manipulating Mario's speed using 1 frame crouchslides. Crouchslides cut a small percent of Mario's speed that depends on joystick input. They also cap his speed at 100, but if Mario moves into the air on the first frame this cap won't be applied. This gives us considerable control of Mario's speed in theory, but in practice most inputs don't move anywhere useful and cause Mario to bonk or fall into the lava in a different PU. So, I collaborated with AnthonyC4 to create a PU return route automation tool that iterates over all angles and inputs, with several filters for improving performance. The tool works quite well and you can see that I navigate back to the main universe very quickly. This route is actually the worst case scenario, because the upwarp puts me at a height just below the third level, which causes Mario to have to fall through PUs for quite a while in order to reach a platform on the second level. If we upwarp to a height where there is a floor, we can make it back in about a second. Also, it should be possible to target the Bowser 2 warp directly.

NOTE: This TAS is "console verified" to the extent that can be done with hacks (using an EverDrive and a ROM with the bully hacks). During the console verification process, which was done by M13, we discovered that the high speed bully collisions can produce an audio crash in some cases. There seem to be multiple workarounds, one of which is switching the game's sound output mode in the file select menu from Stereo to Mono. This TAS will crash in Stereo mode, but verifies successfully in Mono mode. Other than that, this TAS also avoids the other PU crashes that can happen, by using fixed camera during PU movement and avoiding certain actions and movements that can crash.

Also, the hacked bullies aren't actually visible on the frames where they collide with Mario, but they hover at that spot afterwards so you can still see where they were.

Thanks for reading! I hope you understand why this took two years :)