Uploaded May 2023 | Updated September 2026, 1 week ago
Long awaited sequel to everyone's favorite video on the number one Minecraft ripoff of a Super Mario 64 bruteforcer(background/information at youtu.be/9OPPzJHz6AU).
This is a compilation of tests I did on various bedwarspractice.club maps in order to test the thingie's ability to place blocks. These are merely recreations of the maps/their logic, obviously I'm not going to be running these on the actual server. Complete credit to them for creating them though. Ip to the server is just bedwarspractice.club.
If you're super nit picky you might point out that the blocks don't actually disappear in this video. To that I say nobody asked, but also trust that the program thinks that they do, I just didn't want to figure out how to add that in game. So it doesn't really affect anything. In fact I did make the one top block at 1:14 disappear at the right time just because it assumed it disappears(ironically without ever even sprint jumping under it).
The program works under exactly the same logic as in the original video, just with the added ability to press the "place block" button, which also randomly changes the player's pitch. Overall it worked pretty well. I don't think it would beat out someone who knows what they're doing(without beefing the memory/time investment by like 1000x), but also I am Not Someone Who Knows What They're Doing, so maybe there's virtue in it. I've always wanted a mentor :heart_eyes:. I also made the camera smooth compared to last time. This doesn't affect anything, the program still only sets the yaw/pitch on a per tick basis, I just smoothed it out in between ticks. Everyone say thank you
During the last test I extended its area space to have a 4th parameter(distance to the nearest block directly under the player) to try and encourage it to actually slow down and bridge. It certainly helped, but it still wasn't able to bridge as well as a real player would, since it tries to get the block underneath it as soon as possible. Maybe in a super sterile environment like in my 50m sprint video(youtu.be/1hklEJeA9Z4) it could bridge like a human, who knows(I guess I should have tested that considering my epic clickbait title(I honestly have no idea how to title these videos what do I even call this program??)). Though, there I was able to replace the "nearest block under its feet" with "block furthest out on the x axis that it placed," which gives it a lot more information. I tried similar here as well, and again with just the number of blocks it's placed, but it was basically the same as the feet version but slower. In a perfect world maybe you just give it information about every block it's placed, similar to what I did in the nether portal video(youtu.be/HEH7rW1-ly8), but you'd just end up with an unfathomable number of areas and infinite compute times unless crazy restrictions.
The stuff it made obviously isn't perfect, and you could maybe squeeze out some ticks by hand, but for not even having to touch the game, it's good enough for me. At least I assume, partially since it only spits out inputs for runs that are a whole tick faster, so I don't know if it was like .01m off or smthn. It does lose sprint for a tick a lot, but honestly probably only 25% of those lose any distance, much less time. I have a gut feeling that losing sprint the tick before hitting the ground literally just doesn't matter, aside from what it implies(bad angles/bonking). If not it just really likes doing that specific timing a lot.
Here's the times from the video, within a tick anyway since I forgot to record the actual ones:
Speed Clutch: 10.10
Wall Block Clutch: 11.15
Broken Wall Run: 14.50
Side Clutch: 11.25
First Bridge Start: 23.25
Second Bridge Start: 14.75
My Bridge Start: 13.15
Music: shuniji - C418
i'm gonna keep clickbaiting these titles because i have zero idea how else to describe this system lmao. like i know its just a* ai with bruteforced inputs and infinite gluttony but i can't in good faith say ai in the title cuz the goofy heads are gonna see it and think omg machine learning chat gpt 😮😮😮... darn language and its ability to change over time. do people even call mob pathing ai anymore? cuz this is basically just pig ai but it eats 95% of your cpu for 12 hours 😭
Long awaited sequel to everyone's favorite video on the number one Minecraft ripoff of a Super Mario 64 bruteforcer(background/information at youtu.be/9OPPzJHz6AU).
This is a compilation of tests I did on various bedwarspractice.club maps in order to test the thingie's ability to place blocks. These are merely recreations of the maps/their logic, obviously I'm not going to be running these on the actual server. Complete credit to them for creating them though. Ip to the server is just bedwarspractice.club.
If you're super nit picky you might point out that the blocks don't actually disappear in this video. To that I say nobody asked, but also trust that the program thinks that they do, I just didn't want to figure out how to add that in game. So it doesn't really affect anything. In fact I did make the one top block at 1:14 disappear at the right time just because it assumed it disappears(ironically without ever even sprint jumping under it).
The program works under exactly the same logic as in the original video, just with the added ability to press the "place block" button, which also randomly changes the player's pitch. Overall it worked pretty well. I don't think it would beat out someone who knows what they're doing(without beefing the memory/time investment by like 1000x), but also I am Not Someone Who Knows What They're Doing, so maybe there's virtue in it. I've always wanted a mentor :heart_eyes:. I also made the camera smooth compared to last time. This doesn't affect anything, the program still only sets the yaw/pitch on a per tick basis, I just smoothed it out in between ticks. Everyone say thank you
During the last test I extended its area space to have a 4th parameter(distance to the nearest block directly under the player) to try and encourage it to actually slow down and bridge. It certainly helped, but it still wasn't able to bridge as well as a real player would, since it tries to get the block underneath it as soon as possible. Maybe in a super sterile environment like in my 50m sprint video(youtu.be/1hklEJeA9Z4) it could bridge like a human, who knows(I guess I should have tested that considering my epic clickbait title(I honestly have no idea how to title these videos what do I even call this program??)). Though, there I was able to replace the "nearest block under its feet" with "block furthest out on the x axis that it placed," which gives it a lot more information. I tried similar here as well, and again with just the number of blocks it's placed, but it was basically the same as the feet version but slower. In a perfect world maybe you just give it information about every block it's placed, similar to what I did in the nether portal video(youtu.be/HEH7rW1-ly8), but you'd just end up with an unfathomable number of areas and infinite compute times unless crazy restrictions.
The stuff it made obviously isn't perfect, and you could maybe squeeze out some ticks by hand, but for not even having to touch the game, it's good enough for me. At least I assume, partially since it only spits out inputs for runs that are a whole tick faster, so I don't know if it was like .01m off or smthn. It does lose sprint for a tick a lot, but honestly probably only 25% of those lose any distance, much less time. I have a gut feeling that losing sprint the tick before hitting the ground literally just doesn't matter, aside from what it implies(bad angles/bonking). If not it just really likes doing that specific timing a lot.
Here's the times from the video, within a tick anyway since I forgot to record the actual ones:
Speed Clutch: 10.10
Wall Block Clutch: 11.15
Broken Wall Run: 14.50
Side Clutch: 11.25
First Bridge Start: 23.25
Second Bridge Start: 14.75
My Bridge Start: 13.15
Music: shuniji - C418
i'm gonna keep clickbaiting these titles because i have zero idea how else to describe this system lmao. like i know its just a* ai with bruteforced inputs and infinite gluttony but i can't in good faith say ai in the title cuz the goofy heads are gonna see it and think omg machine learning chat gpt 😮😮😮... darn language and its ability to change over time. do people even call mob pathing ai anymore? cuz this is basically just pig ai but it eats 95% of your cpu for 12 hours 😭










![Faster 5% Dragon Insta-Kill Setup 1.12 SSG
(if you want setup info skip towards the end :] Most of this is just context for my own selfish indulgence)
Recently I released a video showing off a potential setup for a 1.12 ssg insta-kill(https://youtu.be/VMHl0SOFw_0). And while it was good enough for people to hit it, it left a lot to be desired in terms of consistency and speed. Originally I estimated that ~3.8% of dragons would give you enough velocity based on 5000 random end fights that perched and charged within 30 seconds. I then eyeballed that about 50% of those would bonk on terrain and lose the necessary velocity before you could use it. This left a rough 2% estimate of hitting it, but it was also slightly inaccurate
(fwiw, almost exactly 30% of end fights met the 30 second charge restriction, and almost all were insta-perches. Which makes sense, since the 1.12 dragon is so fast that it can get to the 7/8 node faster than it can register the end crystals(which takes 5 seconds). As a result it only rolls a 1/3 to insta-perch since it doesnt think theres any crystals up, similar to how the first holding path only ever routes to the middle nodes. And factoring in 1/8 & other 1/13s, you get ~30%.)
Anyway, while confirming my physics n stuffs, I noticed that the dragon almost always spawns with a yaw of 229.78471. Im not entirely sure /why/ this is the case or if you can manipulate it, but it seems to come from the fact that it uses world random. Which conveniently gets reset right before dragon spawn if theres end island chunks that need to be generated(smthn smthn end city gen resets world random)(?). Regardless, its pretty epic cuz it makes the dragon paths a bit more predictable than I assumed. And it actually brings my original setup up to a 5% to get the velocity, ignoring bonks.
And! Speaking of bonks, I took the time to simulate the full client/server physics interaction during the insta-kill. This let me get actual numbers on how often/where the player bonks, and all in all it gave an estimated ~3% chance of that original setup hitting(or maybe a bit higher I forget the exact decimal)
But anyway, now for this setup. It again works by using the end terrain/obsidian pillars to strategically slow down different dragons and create hotspots where a tickle spot is more likely to be. So by standing in one spot when the dragon takes off you can set its target to get the right path, and then you can get the best chance of hitting the insta-kill by standing elsewhere in a good hotspot. And using blocks is just the easiest way to align yourself and prevent getting launched by the initial velocity transfer
SETUP INFO!
Pickaxe is kinda required, and you can do the setup up as soon as you want, its just hard to see. You just cant get much closer without sneaking or dealing with fireballs. All that matters tho is that you stand at (54.3, 59, 38.7)(Y important!) when the dragon takes off, and then move to (56.7, ~, 39.7) to shoot. Y isnt important there, but digging down in that corner is prolly best. This gives you a 7.00% chance of getting close to the tickle spot, and to help avoid bonking/snagging your Z server velocity you also want to place an endstone somewhere (47-55, 60, 39). Technically the lower X the better, but X 50 works fine. This gives you an overall 5.56% chance of getting enough velocity and not bonking, out of 100k end fights that perch and charge within 23 seconds of dragon spawn(vs 3.7% without the end stone). Of course this assumes you shoot tick perfectly(as shown in the vid, Keep in mind this timing is a few ticks later than the first setup cuz the dragon slowed), but again you only lose 9% of your velocity each subsequent tick. So better late than early, but it does get increasingly rarer to hit the later you are. This setup also averages 12.3 seconds from perch leave to death dance(12.2-12.55), vs 13.9(13.75-14.35) for the old setup. (oops the original times I had there were jank sorryyyy)
Anyway thats all for now. Hopefully better/faster setups coming soon, but maybe this can tide you over. Id wait until I had something better but this is More Dramatic and Also I Felt Bad. Im also considering looking at 1.9 setups(?) Im hesitant cuz hunger sucks, but on the other hand theres potential for some silly stuff. Its the only version with the bug that directly ties the dragons yaw to its head/neck hitbox heights(they literally use the dragons yaw in degrees to offset the hitbox y in meters). And since the dragon slows down partly based on those hitboxes, it might not slow down in scenarios where a 1.12 dragon would, or vice verse depending on wherever the head ends up. And since the dragon slowing down is what makes different setups good or bad, that could result in some fun stuff. Of course, Id actually have to look into it to find out, but thats like the only version difference anyway
also! these %s includes the backwards dragons, which always fail, and happen 4% of the time Faster 5% Dragon Insta-Kill Setup 1.12 SSG](https://i.ytimg.com/vi/sJOT9dejeno/mqdefault.jpg)