Tyler Kehne
Enter Hazy Maze Cave without Pressing A
updated
For a concave corner like this, it's much more precise. Mario has to target an FP-precise overlap 10 units below the ledge, which will cause him to move more than 20 units away from the wall. Additionally, if this point is less than 10 units away from the adjacent wall, the adjacent wall must be the unreferenced wall. Here, that is the case and the quick ledge drop is possible. However, it apparently does not save time. Perhaps it will somewhere else.
I believe this is truly useless but it's kind of neat. You never know
It's not much in this video but you can see Mario pop up when the steep slope pushes him into the air.
I don't know if this has any applications but it conceivably could in ABC speedtasing. Outside shot at it being useful somewhere in the 0xA BitFS route.
EDIT: Initial description was wrong about subframe event order so I fixed it
The platform tilt behavior isn't axis symmetric and for some reason it is much more difficult to perform USCX. I was never able to get it before despite trying very hard, and there was actually a significant bounty placed on it at one point. Recently I posted a video (youtube.com/watch?v=14_srcwQ4Lw) that provides a blueprint to solve the final speed transfer (FST) dilemma, and as part of that I hovered less than 4 units over the platform as Mario began falling. For those couple frames I was able to keep tilting the platform while building up falling speed. I also used NUT spots to build even more falling speed while tilting the platform, but that's not possible with USCX because the edge we fall off is not jagged (it's always guaranteed to be axis aligned). Still, the two hover frames combined with a more optimized approach ended up making the difference and I pulled off the speed transfer with no extra frames to spare.
I still don't really understand the movement for USCX that well, despite countless hours studying it. I can say that the initial normal before Mario rounds the corner is not as important as Mario's speed when he rounds the corner. That's why I run all the way to the far edge before turning around, so I can maximize my acceleration before turning. Aside from that, there are all kinds of weird tradeoffs and it's very hard to know when to turn and what angles to take. It was a very frustrating problem and I'm happy to have finally solved it. Hopefully it comes in handy later!
The next step is to reduce the number of hacked bullies from 3 to 1. This will require a huge effort, and people have already been working on tools to gather data for it.
Special thanks to ds273 for his PU displacement height calculator, which was indispensable for this, bad_boot for developing Wafel, which is a new SM64 TASing suite that was also indispensable for this, pannenkoek2012 for TASing the beginning, AnthonyC4 for porting my python PU navigation tool to C++ (much faster), Krithalith and fifdspence for laying the groundwork for SM64 automation, M13, lemon and nim for console verification and sound crash debugging, Simon Lindholm for investigating the sound crash, and jongyon/DerockProject for brainstorming ideas with me (and just being generally helpful).
ds273: youtube.com/user/Th3DekuScrub
bad_boot: youtube.com/channel/UC280b7IZCFnzCR0RCwi6JYg
pannenkoek2012: youtube.com/user/pannenkoek2012
AnthonyC4
Krithalith: youtube.com/user/Kiefertje
fifdspence: youtube.com/channel/UCXubFNfZaMVLsTZzKcgnHOQ
M13: youtube.com/channel/UCeAApNJQhcUVrTAJvAqnbYA
lemon: youtube.com/channel/UCoZ8JbiXlq_Zh0DGvaGRTDQ
nim: youtube.com/channel/UCG_b-lywDked3HfbZQXU8Gw
Simon Lindholm: github.com/simonlindholm
jongyon/DerockProject: youtube.com/user/jongyon7192p
Basically, when the bully hits Mario, the game actually treats it almost exactly like a 2D elastic collision (think billiard balls). In an elastic collision between two cylinders, the force vector is parallel to the distance vector between them, since that's where the point of contact is. The component of each cylinder's momentum perpendicular to the force/distance vector are retained, while the parallel momenta are swapped between the two cylinders. This conserves total energy and momentum.
However, there is a small but significant difference in SM64's version of an elastic collision. When the bully's parallel momentum is transferred to Mario, it actually gets tripled. I assume this was done intentionally by the developers to make the knockback more dramatic. But for our purposes, it's a godsend, because it allows each collision to potentially triple the "energy" of the Mario-Bully system. Doing this repeatedly could allow for exponential speed building, similar to a BLJ. If Mario could quickly gain PU speed, he could potentially use PU platform displacement to upwarp arbitrarily high.
The biggest difficulty with this plan is that the bully automatically puts Mario in a knockback action after the speed transfer, and knockback caps speed at +/-32. To bypass this, the knockback must be cancelled almost immediately, before the action has a chance to execute. The only ways to do this are with water (unavailable) and this tech bad_boot discovered called squish cancel. Squish cancel cancels knockback into squish, and then squish immediately cancels into idle. The conditions for squish cancel are incredibly difficult to meet. Previously, I was only able to meet all the requirements with the assistance of the track platform's wall hitboxes, which prevented the bully from pushing Mario off the platform. While the track platform has some unique logistical advantages, we don't want to rely on it for squish cancel, since that limits our squish cancel opportunities based on the very long track platform cycle.
"Unassisted" squish cancel does not require the track platform, and so speed transfers can potentially be done much more frequently. This could shave several minutes off the final BitFS TAS time, which I projected to be in the 5-10 minute range (not counting stuff after the pole).
You can also see in this video that I successfully transfer speed back to the bully, giving it 27908 speed compared to its initial 10900 speed. The bully also remains in the neighborhood, which is important for subsequent speed transfer attempts.
There is still a lot of work to do to get this strat fully working, and there are some major logistical challenges to solve, but this a huge step forward, and I am extremely optimistic about everything coming together. Stay tuned, and feel free to share this video and explanation to build HYPE that fast N64 BitFS is on the horizon!
Oh, and you also need to be holding Z when you jump for it to work.
Most of this course is pretty straightforward, with the exception of two parts that are almost impossible. You almost can't get past the very beginning, and obviously I had to get creative to do so. The other main obstacle is the grey striped triangular platform on the second level. Going up steep slopes without the joystick is nearly impossible, so we got very lucky there was fire in the area, since the burning dash action prevents Mario from sliding. Normally it ends too early, but you can extend it indefinitely (given enough HP) with frame perfect jumps, which is how I was able to make it up the slope.
I TASed the course itself, but the Bowser 2 fight was TASed by pannenkoek2012, who I'm sure you've heard of if you're watching this video. Shoutouts to him, and also to M13 who was the first to complete the fight (youtube.com/watch?v=7PF-g2SwPGA&list=PLwgnNBufj5huSvZ1bZmEd2SHBV3wkNUP4&index=45&t=0s).
No Joystick Challenge playlist: youtube.com/playlist?list=PLwgnNBufj5huSvZ1bZmEd2SHBV3wkNUP4
EDIT: The coordinates here are x = -89.9566192626953125, y = 2313. Precision for x coordinate is 6.25 * 10^-14.
-I have Mario move into a wall hitbox on the fourth quaterframe of his last sliding frame.
-For ground movement, Mario has no vertical speed. So his horizontal movement happens first, and then the wall collision test happens. This means that the position being tested is at the new position horizontally, but at his previous height vertically. This position is above the wall, so Mario does not get pushed back by it.
-Next, Mario's floor collision test happens. After this he snaps down to the ground. This brings him inside the wall hitbox, but because the wall collision test happened already, he doesn't get pushed away. Since this is the last quarterframe, Mario will start the next frame inside the wall.
-On the next frame, the initial wall collision check (prior to qframe movement) pushes Mario away because he is now inside the wall. This pushes him off the slope and onto the flat ground. The initial floor collision check does not change Mario's height, so Mario is now above the flat ground by about 30 units.
-After this comes the DR check. Because Mario is above flat ground, he is able to DR, and the extra 30 units allows him to reach the star. In fact, it gives him 11 DR frames to reach it, so the h speed I get from the slope (about -80) is enough.
.st: drive.google.com/open?id=1ourMk14-6bJ_MSkocp_Rtn0k4q2NWqfM
Credit to bad_boot (youtube.com/channel/UC280b7IZCFnzCR0RCwi6JYg) for discovering HSG and Sidney (youtube.com/channel/UCla5Eru3DbPgxz6LwSBOyaw) for finding this spot. I managed to get enough speed to jumpdive up, which only requires 1 A press, as opposed to the two needed to get past the elevator and the pole. There are several speed thresholds that are difficult to get past, and you have to strain a certain way depending on the random treadmill direction to progress. In particular, the speed range from about 150-180 is very difficult. Mario tends to clip through unless you have good strain + speed + RNG combo. That's why I wait at a couple points for better RNG. The jumpdive is also quite weird; it seems to be way harder than it should, and seems to always bonk at certain speeds. Anyway, because it works on the random setting, it saves 1 a press for both The Pit and The Pendulums and for Timed Jumps on Moving Bars. Also, because it doesn't use a bob-omb, if we can get the cogs misalignment VSC to work, we can use a second bob-omb after the jumpdive, potentially saving 1-2 additional A presses.
.st: drive.google.com/open?id=1Z34aVfEmndp8Q7IM6x4oZBwNNkuDtJel
Obsoletes crystal VSC strat which takes a little bit longer. This is incredibly precise and I actually made the m64 first and then hacked the .st to be in the right position.
Major shoutouts to Iwer Sonsch (youtube.com/channel/UCnJKlalNQWIco1DS0Uw_XXw) and bad_boot (youtube.com/channel/UC280b7IZCFnzCR0RCwi6JYg) for their help with this.
.st: drive.google.com/open?id=1304lBHrD6D9v0pHchBGPWeBXN4xwqd2K
If this works, we won't need to go to PU at all, although the route still requires 40 minutes of speed building and a significant amount of time for shy guy manipulation. The speed conservation strategy is complicated. You want to HSP to about 45k speed and then at the end of a punch, you crouchslide. This lets you rotate Mario a little bit so he's facing in bounds, and he moves into the air above the shell over the slope by the red coin. The next frame he would bonk, but instead he hits a flame clone which puts him in a burning state so he can fall without bonking. When he hits the shell, the burning state is cancelled by the shell riding, which is itself immediately cancelled into a crouchslide. This crouchslide lets you take advantage of the 10k glitch, which is a technique I found that allows you to significantly vary Mario's speed. It can be used to gain massive amounts of speed, but in this case I use it to instantaneously reduce speed to the amount I want to conserve into the castle. The lower speed also allows Mario to move forward one quarterstep without bonking on OOB. This puts him back into the air. Fun fact: that one frame contains no less than 4 action transitions (Mario starts in burning fall, then enters shell riding, then crouchslide, then butt slide, and finishes in freefall), which is just ridiculous.
On the next frame he bonks, but because he bonks during quarterframe movement he doesn't lose speed until the next frame. But on the next frame, he bounces on the shy guy, which cancels the knockback into the twirling state. The twirling state allows you to turn Mario to the desired angle and pause exit upon landing. Pretty nifty.
All that remains at this point is for pannenkoek2012 to figure out a way to get the flame clone and shy guy in position, which he thinks he can do. The shell clone is in a legitimate position here.
Shoutouts to bad_boot for helping me work this out. He knows a lot about this game and he made this process a lot easier. Here's his channel: youtube.com/channel/UC280b7IZCFnzCR0RCwi6JYg
.st: drive.google.com/open?id=1mFqeig6rIrBE6vsuvMCdzA621ovYc7xA
This was way, way harder than it looks. The insanity at the beginning was because I hacked a shy guy over by the cannon to bounce on. Twirling is really nice because it lets you change your angle while conserving speed, and you can pause exit with the speed when you land. Pannenkoek2012 thinks he can get the shy guy in that position.
I used 6k speed because the 2080 I had in previous videos wasn't enough, but the 2080 might actually be possible since we have a little more leeway on the coin platform than I thought. Next up: SSL PU route.
.st: drive.google.com/open?id=1056qIcUbk5Kv_FOg1VixbD51UWbTxKIT
Another glitch I've been holding onto for awhile because it didn't seem useful, but we're plotting some things with it. Basically a bully that goes OOB doesn't lose speed, and you actually add speed to it via the weird billiard-ball-esque collision physics between Mario and the Bully. It's more like momentum or energy than speed, since the game calculates some sort of mass for both objects. The method is repeatable, and has no upper bound on the speed limit, but you get diminishing returns as the bully's speed goes up. For example if the bully has 150K speed and Mario has 200 speed the bully will get like .1 speed at best from the exchange. But with enough time it's probably possible to send a bully to PU this way.
The real potential here is that the speed can actually be transferred back to Mario...temporarily. Problem is it also puts him in a knockback state which has speed capped at 30 or something. But, we're looking into ways to cancel the knockback, and we have a good lead.
.m64: drive.google.com/open?id=1EhxSspfLSlYCc-b_RBu1EyWCgYTTkvNC
.st: drive.google.com/open?id=1JLr1CLyDjqEJhnOCK9RzBpgtgpA29JOs
You conserve a lot more speed up the pillar by punching. After the punch finishes, you can dive. The gets only half the speed of the jumpkick in Timestoppa's method (youtube.com/watch?v=3tDQ5aHmPh4), but starts about 150 units higher, so it covers the same distance.
.st: drive.google.com/open?id=1jjwvwMGSIGV1yafLCyg_4a41n5oLHHxA
EDIT: Doesn't actually save an A press because you can't hold A while punching.
Finally? I start with 150 stored sliding speed at angle -21770 (x = -130.4421047, z = -74.05982265). Swim into right edge of pillar and restore speed with Z+C^. Facing angle after C^ is also -21770. Lose about 12.73 speed from sliding frame, first c^ frame and first punch frame, but gain about 0.7 speed from each punch frame to finish with 151.222 speed, a net gain of 1.222. Because the angle of the final speed is the same as the initial angle, this method can be used repeatedly until it asymptotes. Not sure yet how much speed can be obtained but this will surely be enough to save an A press with Timestoppa's method (youtube.com/watch?v=3tDQ5aHmPh4). Long time coming. Except, not really, because you can't hold A. Still, there's potential here.
.st: drive.google.com/open?id=1MQHZH3gezP1Gc2dPHswth7TINfGDw8E9
This almost works. I started with 150 stored speed and finished with 146.071. You gain 0.15 speed on 6 air frames, 1.5 speed for 3 landing frames and .5 speed for each punch frame. About 11 speed altogether. Problem is you lose 15 speed from the restoration frame. It's possible to lose much less, but I had to have the incident speed be almost entirely uphill in order to get pushed into the air. If we could restore speed roughly parallel to slope, it would only be a loss of 9 speed.
Original plan was to restore speed parallel to slope and escape sliding with jumpkick. But I forgot you need a buffer frame from C^, and the speed loss from two c^ frames is crazy (like 6 units). So this was the next best option. You don't lose nearly as much speed from C^ going downhill (only 2.5/frame),
9f improvement; 17"77 w/ fixed cam switch
After seeing the (relatively) low speed the improvements to WDW and RR used, I decided to reevaluate my OJ route testing methods. As it turns out, the single OJ problem was solved by a Greek mathematician over 2000 years ago. Using this ancient method, I was able to quickly find multiple improvements in BitFS, the best of which is shown here. I'm not 100% sure that this is the fastest, because I don;t have an efficient way to test the method on slopes yet, but there's a good chance this is not improvable (at least the PU part).
This m64 branched off of a version of the 18"07 that mkdasher made, and I didn't change any input until the BLJ. This m64 has fixed cam mode already set, so it saves 6f in BitFS from not having to switch. However, the 6f camera switch has to happen at an earlier point in a full run. Not that I know anything about where that would be ;)
Console verification is crucial for PU routes, as many seemingly innocuous movements can cause a crash on console. In other words, fixing the camera in the real "universe" is necessary but not sufficient to prevent a crash. Thanks to mkdasher's TASbot (and shoutouts to Braden for figuring out how to make them), we confirmed that this strat works just fine on console. However, it does lag considerably at some parts, which I didn't attempt to fix here. The emulator m64 was done on the U version and console was J version (J has better lag in BitFS).
Although it's very small, this control over our position theoretically allows us to move in and out of the activation radius of some RNG object, effectively making an RNG "tap" that we can turn on and off. It turns out that we are very lucky with what we have available put this idea into practice. Bob-ombs have an activation radius of 4000 units, and call RNG every frame they're active to determine if they should blink or not. We can place a bob-omb in the cage near the "Roll Into the Cage" star with 0 A presses (using a strat similar to this: youtube.com/watch?v=YBwenkLF_H4), and it will attempt to return home, eventually converging on a point on the wall. This point just so happens to be 4000 units away from the Pedro Spot region on the uppermost red coin platform! In this video, I use a PS about 4000.44 units away form the Bob-omb. Starting at about 101 speed, every 10 frames, I move up to about 3999.71 units from the bob-omb, activating it for 1 frame, and then I move back. Some activation frames were lost because of my poor video editing software.
At this point, the only thing remaining to confirm the strat's viability is to test it with the platforms actually moving. The speed cap here is 1137, and it could probably be pushed up by 100 using a less bloated bob-omb (I used the largest bob-omb to make sure the activation zone didn't go into the wall). Also, I had to hack the draw distance of the bob-omb to be the same as it's activation distance so it would become visible when I activated it (normally it;s 2000 units on TTC).
Pedro Spots are of particular value for the ABC in TTC because of the vertical layout. Horizontal speed can be converted into vertical speed by jumping; this requires 1 A press, but that's much preferable to Stomp on the Thwomp's requisite 7 A presses. A Pedro Spot in an accessible area of TTC could save as many as 10 A presses.
Although TTC has a lot of unique geometrical structures, we haven't found any PSs when entering the course at 12. Entering the course at 6 allows platforms to take different angles however, and this video shows that PSs are present on the rotation red coin platforms at certain angles.
The biggest problem to applying this find is of course the fact that the platforms don;t stay in those angles, because they're moving. Our best bet is to enter at 6, where the platform rotation is constantly affected by RNG, and use RNG manipulation to keep the platform relatively static in the correct angle. Unfortunately, there's no direct way to manipulate RNG while accumulating speed in a PS, because Mario can't really move, and we need to move in order to create RNG particles like dust and stars. Despite this, we're working on a possible solution that manipulates RNG indirectly.
Moving OOB is actually quite difficult, because the game normally prevents it. The method I use here requires pushing the block in the wall all the way inwards, so the block itself is located partially OOB. I then clip inside the block and jump on it. If Mario stands at the edge of the block and jumps, he will move far enough away from the block to deactivate it's solidness property, and the only floor triangle below him will consequently disappear, causing him to be OOB. At that point the failsafe mechanism will warp him all the way over to where chuckya grabbed him.
Normally I would use chuckya to easily clip inside the block, but since he was already serving another purpose, I had to use BLJ speed to do it. You can store speed in water and restore it upon surfacing.
There is a very similar glitch called Remote Heave-Ho that's demonstrated here: youtube.com/watch?v=nj3jGoVV4fc. However, although the effect of the glitch is the same (warping Mario back to his visible body), the cause is completely different. Despite the similar setup, the glitches are completely unrelated outside of their effects.
1ted59's channel: youtube.com/channel/UCZM46z2hhd0yO9iAYpObE0g
Basically I use the ceiling triangle of the red door instead of a perpendicular wall to prevent Mario from moving. Once he has enough speed, Mario will clip through the wall if you turn around, so you can use OOB to keep Mario and increase his speed without limit.
Also, shoutout to pannenkoek2012 (or was it pannenkeok2012?) for converting this m64 to this hacked ROM after I did it on a different one. He also gave me 69 lives and stars...must be a big Bryan Adams fan!
Although I was not able to get either goomba close enough to realistically bounce off it from the sign, I think the strat has promise, and I will keep trying. The paths the goombas can take can be quite unpredictable based on the formula used to calculate the angle, so it's mostly trial and error.
P.S. This only works in the Japanese version. Also, I completely made up the Spawn Displacement term, fight me irl if you don't like it =P
EDIT: That other vid I refer to actually isn't gonna be useful after to all, though it's still a cool trick (basically a 207 DR w/ the bully).
EDIT: No it won't. Turns out there is another gap Mario can't cross lower down, but fortunately it doesn't matter because Plush was able to get max HP another way.
Also, see this link for an explanation of the 207 Dive Recover, which I make extensive use of here: youtube.com/watch?v=HZjol1P6M9A


