Dragon Insta-Kill Test Curcuit Store 2023-05-28 | I've been putting this off for months because I have a burning hatred for math and doubly so for programming. But then I remembered that it would be funny sooooIf you want context, I'd suggest watching my infinite dragon knockback video(youtu.be/DBYgB2sESmM). Basically there's a point on the dragon's hitbox. And as you get closer to it laterally, you gain an exponential amount of server velocity. Separately, when you shoot a bow you transfer all of your server velocity to the arrow. And funnily enough, the damage an arrow does is proportional to its speed. So tie it all together and you can fire a 20,000mph arrow into the dragon, using the dragon, killing it instantly.Technically that's nothing new; the idea has been floating around for years, and iirc people have pulled it off in simpler contexts in the past couple. But I never understood projectile collision/dragon knockback, so I never got anywhere personally. At least until recently learning about them while drowning myself in unrelated distractions.So, today I show off the trick by pearling directly into the dragon's knockback tickle spot as its flying around, and use the velocity from a single tick's knockback to shoot and kill the dragon. This isn't optimized in any way, but would be a high 28.xx in a real end fight, which is still faster than my zero cycle tas from a year ago(petition to call this a divide by zero cycle). You could save a second+ by doing things better, I don't shoot immediately cuz lazy, and a real run could probably start sooner. You could prolly do some other silly stuff too.Now for some deets for the bored of yous:The dragon has 200hp, and arrows deal 2x their speed(in m/t) in damage. So in theory you only need 100m/t. But because air resistance and since the dragon quarters all damage that doesn't hit the head, you need more like 400-450m/t. And to get this in one tick from dragon knockback you need to be within ~.02m laterally of the tickle spot. You can stay there longer, but the dragon flies away too fast for it to matter.Once you get the knockback you can just shoot the arrow, but getting it to hit the dragon is a challenge in of itself. In order to get into the spot you basically need to be inside the dragon's body hitbox. But entity hitboxes are only tangible from the outside, so your arrow straight up can't hit the dragon's main hitbox. Luckily the dragon has multiple hitboxes tho, so we can aim for these. Except we can't really aim for anything because the dragon's knockback completely overpowers the the arrow's initial velocity by like 100x. Instead we have to just rely on the knockback being in the right direction, which is based on your angle towards the tickle spot. So we're aiming for a .02m circle around the spot, but also only for certain slices of it that knock us towards the wings/head/tail hitboxes.(Except you can't hit the actual head hitbox afaik since it sits inside the neck hitbox, so you just hit that.)That's also glossing over a pretty important part though, which is figuring out how to throw a pearl that tps you into those slices(this is the part that actually takes effort). The notable thing about this video is that none of the starting positions/dragon positions were selected special for this. Instead I wrote a program that takes a starting pos/dragon pos, and half solves/half bruteforces a series of angles that let you land a pearl into the right position. Which is epic sauce because it means I could (relatively) easily incorporate it into a real end fight.It's easier said than done though, because we're not just trying to hit a .02m moving target- that's pretty easy because projectile collision is (mostly) continuous. We literally need the pearl's /actual/ position to land inside that small range, and then have it collide with the dragon a tick later. But pearls move like 1.5m at a time, so even if we pass through the .02 target, there's less than a 2% chance its position actually fell in the right spot. And we can't just fix it just by choosing a different pitch/yaw because the target is so small- you literally need to get a different starting position/velocity. Obviously I can't change position, but there is an easy way to change velocity since you also transfer your server velocity to pearls. See, when you sprint jump you get .2m/t of velocity in the direction of your current yaw. But your server yaw is delayed 1 tick from your client yaw, which can desync this added velocity. So skipping the logistics, you can sprint jump/throw a pearl in one direction, but with the added velocity of a sprint jump in another. The velocity change is almost nothing, but gets magnified over the trajectory so you basically always get a solution, even when you're only searching every .01 or even .1 degrees for each yaw/yaw/pitch. (I think I even saw some that gave like 10k+(actually i fixed a bug and got a 250k+ one), but that would just freeze the game :sob)idk maybe some of that made sense
Dragon Zip w/ Strafe Example Curcuit Store 2024-09-21 | Super Very Extra small video showing how the dragon's Y acceleration can become briefly uncapped if its position is aligned float precisely* with its current target on the X & Z axes. This is pretty useless considering it stops when the dragon flies out of alignment after 1 tick, but at least now it's been done(?)*as long as you're not at like exactly 0,0 i thinkSpecifically, the dragon is always targeting 1 specific point when flying around. And for each tick, its vertical acceleration towards this target is supposed to be based on its vertical/horizontal distance to it. Usually the vertical distance gets divided by the horizontal distance, and then capped to a specific range to be used as acceleration. However, presumably to avoid a divide by 0, if the dragon is exactly perfectly horizontally aligned with this target, then both the division and the cap are skipped, resulting in the dragon accelerating as much as it can. Here there's a vertical distance of ~60m, so it gets an ~-0.6m/t boost in one tick, vs the normal max of +/-0.006m during most phases. In order to actually line this up for the video, I first aligned my own X,Z position float precisely with a position the dragon will eventually fly into. I did this using the same stuff from my fast float positioning video(youtu.be/oG1SZsszCXg) but done once for each axis. Then, by shooting a crystal as the dragon flies exactly over me, it enters a strafe phase and immediately targets my exact X,Z position, which is also its exact X,Z position, completing the setup.Again though, i doubt it's useful for any run because of the nasty setup/strafe/height difference requirement for very little benefit. Since it is a strafe you could maybe align yourself with a new float precise position every tick to extend it and then it miiight be worth, but lol... you could also prolly pull this off without a strafe by shooting the dragon perfectly a bunch to align it, but that would definitely only be for 1 tick max, with even worse results(less height difference). Not to mention how awful/clunky finding a solution/executing it would bebut oh well!!! i don't actually know if this has a name, but i swear i heard someone call it a zip once 35,436 years ago and it stuck with me. i can't find any reference to that now though so i probably just made it up!!! either way! enjoy your daytimes! and nighttimes! bye :)
Every Minecraft Star Sorted by Rotation Curcuit Store 2024-08-25 | (maybe flashing lights- i turned the sun down a bit but still)anyway im in my clickbait tick tock shorts era i apologize in advanceJust a showing of all 780 stars at midnight, along with their stats, and also sorted by rotation because i have this information and i don't know what to do with itloosely based on the star spreadsheet i made a couple years ago(so be warned): docs.google.com/spreadsheets/d/17yfxFAaSD7LiJ2ONZMYCDC7Mo4CBPwsjpeadM5EWGa0which was meant to go with another paragraph i wrote elsewhere, which went ~as follows:when the game starts, it tries to generate 1500 stars based on the seed "10842." each of these attempts get a random position between -100m and 100m on each axis, but any star closer than 10m or farther than 100m from the origin gets thrown out, ig to keep it spherical/stop them from bunching on the corners. this check kills 720 of the 1500, leaving the 780 you can actually see in-game. these positions are then flattened onto a 100m radius sphere and placed 100m from your camera at all times, they just render behind everything to be dramatic. they also get a random radius between 0.15m and 0.25m(aka a side length of 2x that), and a random rotation between 0 and 360 degrees.is there any reason for knowing any of this? nope! i dont even know why i did it(procrastinating finals). i do think it would've been neat if they were based on the world seed or smthn tho.. that'd make for some fun seed findingoh well thats all! i hope you are well and dandy!! :)music: hal1 - c418
Minecraft BLJ Curcuit Store 2024-07-27 | *maybe flashing lights from pause screen at 20hz!!*also not backwards *or a long jump *the title is just funnybasically: i learned how ticks work yesterday. worst mistake of my life!As it goes, every 50ms(barring lag) the server will try to tick. However, if you're paused when it tries to do this, it simply won't tick and just waits another 50ms to try again. sooo by pausing on the exact right intervals you can completely prevent the server from ever ticking. This can still let the client tick though since its own tick timings get "paused" while paused, while the server's don't. You can technically do the opposite too, but that's not useful here. I'm also //pretty// sure this is known(igt moment), but I've never seen an explanation/example, so idk. smthn smthn I'll make/link a video here showing them both Eventuallyregardless, that's what the pausing in the video is for. im spamming pause so the server never ticks, but staying unpaused enough for the client to tick semi-normally. This is conceptually pretty similar to just lagging the server a bunch, but with one significant difference: since the server is just waiting for an unpause(instead of being busy lagging), it can still process any packets you send it. This lets you send a bunch of movement packets telling it to sprint jump a bunch, which it gladly executes, getting an extra sprint jump boost each time. and since it's never actually ticking, it'll never lose any velocity to friction or bonking, letting you basically build up as much as you want. that's prolly pretty broken for 78975894 other reasons too, but this was the first and funniest i thought ofAs always, all this velocity is just server velocity, so it doesn't do much by default etc. But you can transfer this back to the client by taking damage, which I do with the fire, making the weee. This transfer is still capped at 3.9m/t in each axis(sad), so this is about the max you can get, but still pretty funny+i also dont think you can ever left click/attack during the pause spam since it seems like pausing stops you from attacking for 1 tick(?)idk. yeaahhhh. this game sure exists.bye!!
Predicting Dragon Desync Curcuit Store 2024-07-12 | BREAKING: my prefrontal cortex has developed enough to kindofly understand desync. what comes next may shock you"Oneshotting" the dragon at perch(youtu.be/717kfB39gjQ) has become reasonably viable to do rta. But something that's bothered me since my first video on it(youtu.be/OaIesw4T7YE) is the seeming inconsistency from server/client desync, which could make it weird to line yourself up visually and get enough velocity. While i couldn't find anything to /fix/ this, i did come across a way to sometimes maybe predict some of it. is it actually useful in practice? idk! but it's interesting nonetheless i Think(And if you don't know what any of this video means, the first link above is probably a good watch)the basic rundown is whenever the dragon moves, the server is supposed to keep track of that movement and send it to the client, so the visual dragon can move that same amount. however, its very first tick of movement never gets tracked, causing the dragon you see to be slightly offset from where it actually is, by however much it did/didn't move during that 1st tick. This is only true for the first 60 seconds though, since after that the dragon's exact position gets synced with the server, removing the offset.or, if you unload the dragon you can create even more offset, just for funBut interestingly! The amount the dragon moves on it's first tick(and hence the amount of desync) is always 0.06m, towards whatever angle it spawned in facing. And with planar fog and nice terrain you can actually see this angle, making it //technically// possible to actually account for this desync. There is still some other desync from the dragon angle which can slightly affect things, and i think some other mystery stuff i cant recreate myself, but it's cool nonetheless. And if you can't see the dragon spawn, you at least know the spot is actually /somewhere/ on a 0.06m circle around the center*, until it syncs itself after a minute.*technically it slightly turns towards its first node first, it's more "a ~0.06m circle around the center, minus like 10 degrees exactly opposite the 1st node"also: this actually affects all kinds of entities(super noticeable if you've ever /summond a mob with a lot of speed), but ofc they usually don't move much, and fix themselves a lot sooner. Plus moving entities also have a second kind of desync, which is that theyre just ~4 ticks behind the server at all times by default. that doesn't really apply to a perched dragon tho, and that catches up with itself just fine on its own. (still affects the dragon while it's flying around though, which you've probably seen before)idk!! bye!!!!!!!muisc: creative2 - c418
Minecraft Softlock Tutorial Working 2025 Free Curcuit Store 2024-05-08 | Forever ago I made a small TAS showing how clipping into a specific 0.0000001m area of a block could "softlock" you in place(youtu.be/feHC9xzeILc). Since then a few people have actually accidentally done it rta, but as I'm sure we've all been wondering: What if you wanted to do it on purpose? Well! Look no further :relieved: because you can do it in these few simple and definitely not random sounding steps:1. Get a yaw of exactly 0. In the video I do this by placing a boat with a yaw of between +0 and +1.3 on F3 and then getting in and out of it. You could also do it manually with a few different low sensitivities, but boats are nice and easy.2. Align your hitbox with a block and then break it/move away from it while staying aligned(easy since your yaw is 0).3. Set your sensitivity to "HYPERSPEED!!!" and then press the left arrow key 7 times(so the slider reads 190%). Don't drag it there though, since that can give you a slightly different sensitivity based on your window resolution/the screen pixel you click which can cause this to fail, even if the slider and number are the same.4. Turn until your yaw in F3 says 36.2 and then sneak forward for 1 tick.5. Turn until your yaw in F3 says 143.8 and then sneak forward for 1 tick again.6. There you go! your position should now be aligned perfectly so that if you drop/put a full block 1 block in front of you, you'll get stuck!If you want to do this on a different axis/direction, then just replace the "sneak forward" with a "sneak left/right/back." Just keep in mind the 36.2 movement should always move you towards the block pos you want to clip into. You could also try just rotating the angles themselves around, but there's a chance it won't work because of sin table stuff.Also try not to move your mouse too crazily while going between angles. It's probably lenient enough to not matter, but too much can mess up your exact yaw because floats :slight_smile:.music: hal3 - c418
The Dragons Mismatched Hitboxes Curcuit Store 2024-03-12 | This has bothered me for years but I've never seen anyone even as much as mention it so here we are I guess?? ft. more of my patented dodgy explanations of things i dont understand because you only live onceThe basic rundown is that the neck taking full damage does seem to be a bug(?!) And simply caused by the client incorrectly assigning entity IDs to allll the client dragon hitboxes, "linking" them all to the wrong parts on the server. So basically the client head thinks it's the whole dragon, the neck thinks it's the head, the body the neck and so on. So if you try punching the neck, the client just tells the server that you're trying to punch the head, and so does full damage. This also means punching the head does nothing, since it tells the server you're punching the actual dragon, which just ignores all damage(cuz you can't damage the big white hitbox). Only the dragon parts are affected though, so the main dragon still knows it's the main dragon. This also doesn't affect something like shooting the dragon with arrows, since that collision happens basically entirely on the server, so the messed up client IDs don't change anything.It's also what makes the dragon so hard to hit from certain angles, because not only do you have to be close enough to reach the hitbox you're trying to punch, but you also have to be close enough to interact(less than 6m feet to feet) with the hitbox it thinks it is. The most obvious example of this is just trying to punch the body hitbox, since you have to also be within 6m of the neck hitbox when punching it, which can be weird if you don't know what's happening. It's honestly rather funny how much of a difference fixing these IDs makes too. There's still some desync obviously, and dragon collision is also just completely broken across chunk borders, but it's still night and day.The exact exact blah blah reason for it is mostly just because the dragon hitboxes aren't really full entities. Whenever an entity like the dragon, or its parts/hitboxes, spawns on the server, they're automatically assigned a server entity ID so it can be easily referenced. Most entities will then get spawned on the client, and in doing so send this server ID over to the client so it can later use it to communicate back with the server. aka just say "hey my player hit entity #69" and the server will Just Figure It Out. The dragon parts never do this spawning themselves though, and so have to rely on the dragon itself to keep track of their server IDs and copy them to the client. This /should/ be really easy because the IDs are completely sequential, and the hitboxes always spawn in the same order immediately after the dragon. So if the dragon gets one ID, the head will get that ID offset by +1, the neck by +2, etc. But alas, when the dragon goes to do this it starts the offset at 0, and actually gives the head its ID +0, the neck its ID +1, and so on. Which just offsets/shifts the whole thing by -1 from what it should be. Would have been really funny if it was offset by +1 so one gets linked so some random entity that spawns after the dragon, but oh wellI'm not sure if this affects anything other than just punching, or if the server ever tries to reference a client entity(which would offset it by +1 in a way?), but I'm suuupper not familiar with this stuff and didn't feel like it. It also still exists up into 1.20 which is just absurd, particularly since i think it worked fine until like 1.14. Oh well. Who am I to question mojangFull data(this is also their spawn order):Main Dragon, of course, hits Main Dragon(No damage)Head hits Main Dragon(No damage)Neck hits HeadBody hits NeckTail0 hits BodyTail1 hits Tail0Tail2 hits Tail1WingR hits Tail2WingL hits WingRNothing hits WingL :(That's all! Sorry for the innactivity, im simply addicted to the zzzzzzzmusic: piano3 - c418
Infinite Block Collisions from Clipping a Block by 0.00001m Curcuit Store 2023-12-26 | A few months back I showed that clipping a full block just right could freeze/"softlock" you in place (youtu.be/feHC9xzeILc ). Obviously very funny, especially when it happens in the middle of an rta tournament, but it has some other fun side effects too which I wanted to explore today. If you want to know why/how the bug or these effects come to be, the original video's description probably has some information, but this one is mostly just about silly ways to apply it.As a rundown, whenever the client executes a tp packet, it sends a movement packet to the server to sort of "double check" it. But because of the bug, this movement packet can just immediately send the same tp packet right back, creating a crazy loop that runs completely independent of the main game physics. And because it's not locked to running just 20 times a second like actual ticks, it just runs constantly as fast as possible, even while the game is paused. This freezes you in place because of the tp, but because movement packets also execute some basic physics, you can get certain things to run WAY faster than they should. I say in the video it's ~150 times/second, but I assume it just depends on your computer, and it varied quite a bit for me. Especially of course when I'm playing in a lower tickrate.Now, unfortunately most of the stuff ran in this little loop isn't too useful, since anything that would need to be consistent would be in the actual game tick, not just whenever you move*. But there are some fun interactions you can mess with:Fire: Increases burn time by 1 for each interaction (Lets you increase it infinitely instantly.)Cauldron Puts out fire/drains it (Lets you drain a full one instantly if you have a source of fire.)Bubble Columns: Spawns particles for each interaction (Lets you spawn infinitely many instantly.) Adds server velocity for each interaction (Caps pretty low for whatever reason(~-0.9-1.8m/t), but lets you hit it instantly.)Honey Blocks Spawns particles for each interaction(if you have enough downwards velocity) (Lets you spawn infinitely many instantly, assuming you have something constantly setting your velocity low enough, like a bubble column.)Wither Rose Gives the wither effect if you're not on peaceful (Lets you activate the wither effect while paused, just by cycling the difficulty option?)There are some other blocks you can easily interact with in these packets, but they're mostly useless since they're either locked by another timer, or just update values for the next game tick:Buttons Can activate once if there's arrows (Once activated it won't do anything else.)Pressure Plates Can activate once (Once activated it won't do anything else.)Detector Rail Can activate once if there's minecarts (Once activated it won't do anything else.)Tripwire Can activate once (Once activated it won't do anything else.)Cactus Does damage (Have to wait 10 ticks for each damage tick.)Campfire Does damage (Have to wait 10 ticks for each damage tick.)Sweet Berry Bush Does Damage (Have to wait 10 ticks for each damage tick.) Updates speed multiplier (Doesn't take effect until next tick.)Cobweb Updates speed multiplier (Doesn't take effect until next tick.)End Portal Changes dimension once (Breaks the loop.)Nether Portal Updates output location if you've moved (We haven't moved. Sadly doesn't control the 4 second timer.)*For example, standing still while in fire will make your burn timer only net increase once every 20 ticks, instead of every tick if you're constantly moving/shaking your mouse. Or infinitely many times a tick if you do this bug lol.Anyway, that's about all. Maybe you could do something with end portals, but I couldn't see anything that jumped out at me. There are other non-block physics stuff that can run here too, but since we're stuck in place it'd be had to get them to run meaningfully. Most desirable of those being server jumping, which could in theory give a source of infinite server velocity from sprint jump boosts, but seems pretty impossible in practice. Would probably require somehow oscillating between two positions and also some onGround collision shenanigans, but /would/ let you instantly pearl anywhere and instakill everything. so y'know, small incentives...music: wait - c418
Trapdoor Obstacle Course Test/TAS Curcuit Store 2023-10-09 | 15 seconds of trapdoor movement to relax and study to. Is this particularly interesting? Eh, probably not. But it is cool to look at and at the end of the day what else matters?!!!! This was a test I did with my beep boop movement pathfinding friend(youtu.be/9OPPzJHz6AU) because why not. While the movement itself isn't anything special compared to something like the Diversity 3 Train Parkour(youtu.be/AVXUxxnxHNg&t=11) I think it's interesting to see it controlling all of it. I'm still semi-uneasy about it placing stuff in case it gets stuck, but it seems to do a good job of not doing that even here. It's also solidified an idea I've had for a while now but haven't been quite sure of. I first ran this for 8 hours where it just separated the world up into 0.5x0.5x0.5m areas. I then completely reran it except on top of those 0.5 cubes, it also broke it up by whether the player was on the ground or not. It quickly matched the first run in less than half the time, and went on to save another 1.1 seconds. It was actually still finding stuff when I stopped it, but it was like 1 tick every two or so hours so eh. This would probably be where I'd take it over if minecraft was a tas-able game and i cared about beating this random thing as fast as possible...This on-ground thing is obviously especially important here since there's not much difference between being "at floor level" and "at floor level and on the ground(trapdoor moment)", but it seemed to work pretty well just during average movement in the Diversity 3 TASes as well. Notably, even with 0.5m squares, being on the ground and ready to jump would be grouped the same way as 1 tick after jumping(.42m above ground) and up to 2 ticks before landing(.495m and .121m above ground), not even mentioning other funkities. It also just makes sense since being on the ground is so important for getting speed, so it should probably be common sense to make it try to get on the ground as fast as possible. idk. I suspect I'll probably keep this as a standard from now on, especially for more complex movement like this.okay have a nice day i hope you become aware of unfathomable things you can never forget. im going to crawl back into my hole nowmusic: strad - c418
Fast Wall Clips/Float Positioning Test Curcuit Store 2023-09-26 | Last video I showed off a funky wall clip(technically it works in all directions but walls are coolest) that you can do by slipping into a float precise gap in block collision(youtu.be/wNyKwe5c_-M). The only issue is that doing that is rather hard! And also very time consuming! Both in-game and to TAS. This was mostly because I was doing it all manually though, cuz as it turns out 64 bit floats are very tiny!! And humans(at least this one) is are very not good at that!!So I, aka chat-gpt, and whatever countless innocent people it stole from, rigged up a thing to find movements for me. Not only does this take negative time and effort from me(which is great, because TASing is a hobby(?) I want to spend as little time doing as possible), but also the setups are wayyy faster in-game. Cuz computers are almost as good at math as I am at hating it. This lets you align yourself in like half a second in most reasonable situations, vs the like 20 seconds in my original video. The closer your position is to 0 on the axis the harder it will be since the floats are closer together though, which is why the one at 6m is a bit longer. I included it though because literally if you're off by 0.000000000000001m it just fails and that's insane. literal minecraft femtometer(surely that's a meaningful comparison) you cannot even perceive that difference. Which tbf doesn't help my case because it is impossible to comprehend the difference between that number and the 0.0000000000001m of the 270m one.I also showed off a fun way to climb the walls faster once you clip in. I explain how this climbing works more in the original video above, but basically by moving on specific axes you can make the floors/ceilings tangible/intangible. So by moving just right you can make the ceiling disappear long enough to jump up, and then kill your movement to make the floor come back to land again. In the original video i sped this up by making the ceilings tangible just in time so I could bonk on them and shorten each jump, but turns out there's a faster way too. If you try clipping further into the block the server will tp you back and kill your momentum, which will conveniently cut the peak off your jump sooner, as well as make the floor tangible again. It's a lot easier to do rta too since it doesn't require any tick perfect inputs. Just jump and move parallel to the wall at the same time, and then hold into the wall once you get high enough. Plus if you're sneaking you can start moving a tick late.And speaking of rta, since these setups are so much tinier, they're also much more ideal for eventually pulling off rta. I still need to work out the weird sensitivity slider stuff to get the right angles, but only needing to hit 4 angles is so much better than like 50. The inputs can also probably be simplified, but these ones can already be "pause buffered" pretty easily on singleplayer. But doing it on a server is also funny so idk give me some ideas to test it on(that aren't malicious). probably works on anything you can join in 1.14-1.17 and ig 1.18+ if you're braveAs for the actual how's and who's, here's the code I used: pastebin.com/na3YWYb7Be warned I guess lol. Probably not the best way to do things, and it is kinda slow, but it works so idc!!! It just generates a bunch of individual tiny movements and tries to piece them together to get to your target. It's not perfect since it can't track /every/ input, and each movement has to be completely individual(usually by abusing the 0.003 velocity snapping stuff), but way better than I can do manually. It can also be a bit silly because the same movement can move you 1 float more/less depending on your exact position, but that's usually avoidable by just moving the movement orders around. i have no idea how float addition works tho so idk exactly what's going on there. Also probably doesn't work across powers of twoi don't know. enjoy the funny. perhaps i shall go turn myself into a human todaymusic: cat - c418
Wall Climbing w/ Float Perfect Wall Clip & Single Axis Collision Discrepancy Curcuit Store 2023-09-19 | Me when I'm mojang and I'm obsessed with the number 1e-7 and put it in every other line of collision code so that it will save me from scary float errors. Anyway here's a float precise wall clip that only works between certain powers of two and specifically right on the edge of one of those 1e-7 checks.I won't claim to know every exact bit of what's going on here, the collision code is way over my head, but I kind of have an understanding of what has to happen.First off the wall clip, which is just kind of silly:If you just walk into a block hitbox(like i do with the sand), your hitbox gets be pressed completely flush against it. You can see this with the negZ value in the top left when i press against the sand, which shows the neg Z coord of my hitbox becoming exactly 270. But interestingly, the sides of each wall(i say wall but this means ceilings/floors/whatever too) are shrunken inwards by 1e-7m on their edges, leaving open corners on every side of the hitbox. You can use this to get your hitbox slightly inside the block, but unfortunately the walls also have some thickness that extends 1e-7m /into/ the block. So even though you can clip 1e-7m into the wall through one side, the 1e-7m thickness of the perpendicular will stop you from moving any farther into it(it won't push you out though). The kicker is though that sometimes there's a single float value wide gap between the two where you can sneak past both of them, which is what lets me in the wall. You can see in the video that the server still tries and eject/revert my position if I try to go any deeper into it, but it does show that I'm fully inside the hitbox. And if the server wasn't annoying I'd be able to completely walk completely through it. This doesn't let me climb anything though, since like I said I'm sneaking past any of the walls/floors that i would climb on. But this is where the real funny part is, since all of that only applies when you're moving on more than 1 axis at once, which uses your/the block's actual hitbox positions to test collision. But if you're moving on just one axis, the game will actually just test your hitbox relative to the block hitbox. This introduces a discrepancy since subtracting a float like that creates small errors. And between certain powers of two this error can just barely makes your hitbox closer to 0 than before, making it possible to interact with walls that you couldn't with multi-axis movement(walking around counts as multi-axis movement on the client because gravity and sometimes weird trig errors are also pushing you in different directions. Not necessarily true on the server, which intrigues me, but doesn't really matter here).So, to scale the wall, all I had to do was move around on multiple axes to make the ceilings/floors intangible and climb up a level, and then kill all but my y movement to make the floors tangible again and safely land. rinse and repeat. If I tried to walk at all I would simply fall through the ground since the floor disappears, even if I sneak.Again this only works between certain powers of two, presumably because the precision doesn't always line up. I also don't think it works the on negative side(but does on negative axes), but don't quote me on that I'm no float expert. Although getting those inputs to align my hitbox on the exact float certainly made me feel powerful. idek how I managed that tbh but never again...okay im done idc enough to proof read that enjo your day :)music: mall - c418
Mid-Air Jumps w/ Elytra and False Ground Detection Curcuit Store 2023-09-16 | yep that sure is a videoLast video I showed that you can jump in water by getting a super small Y velocity while swimming(youtu.be/qwxMsvhxlns ). In the description I stated that this was also possible with elytras(in fact that was the first thing I thought of trying), but I thought it would be too hard to find inputs for so I just went with swimming. But then I actually used an elytra for once and turns out it's not any harder at all, and maybe even easier! In my defense I thought you could only activate an elytra if you were falling, which /would/ make it hard, but turns out that's just not true and not what they mean by "fall flying"...Anyway, the main concept of this is exactly the same as the water video(linked above), so if you want the super details I'd suggest that. Basically, by using elytra physics you're able to manipulate your Y velocity to be just barely under 0, which incorrectly registers as you "standing on ground," even though there is none. Specifically, you need a Y velocity between -0.0000001(-1e-7) and 0m/t. This triggers a rather odd check in 1.14+ where if your velocity is less than 1e-7 on axis, you just won't get moved on that axis. The game then sees this discrepancy between your velocity and actual distance movemed and figures you must have hit something, and since "being on the ground" is just defined as hitting something while trying to moving downwards, it all checks out.And being on ground is then great because it's really the only requirement to be able to jump. So if you can trigger this silly little fake ground then you can just jump anywhere! This is definitely conceptually a lot more broken and goofy than the water version since eltyras are so mobile, but frankly I can't see this ever being of much use. The swimming jumps are at least useful, this is just :p. But then again I could just valiantly argue that they're both terribly major and game breaking glitches and should NEVER be allowed in glitchless and then they'll never get used anyway(not that anyone other than me would anyway lets be real). Tbf I could see this one being a major glitch but the water one is definitely on the edge cuz I know for a fact the perfect 90 degree x surf would be allowed in glitchless and these are just the vertical version of that. Nobody can do it rta anyway so I say we allow it just for funAnyway elytra movement is a lot simpler than water movement since your only control over your y velocity is your pitch, so I just went through and found some pitches that got me the perfect velocity for these. For the first iteration of it I press jump 4 ticks after the initial jump to activate the elytra, and on that same tick I do a pitch of 36.57. Then the next tick I do a pitch of 36.22, which gets me the exact right velocity, marking me as on the ground. This lets me jump the next tick, but the velocity of this jump is a little different from normal since it uses elytra physics instead of the usual ground physics. So in order to do the second iteration I again press jump after 4 ticks, but this time use a pitch of 64.1 and then 64.005. That pair of yaws then works for each consecutive jump as well, since everything gets reset in between. There's a million combos that work tho, I just chose those for fun and minimal flicking because my eyes and stomach are testing meYou can also change yaws and sprint jump during any of these to gain a bunch of horizontal velocity, without affecting any of the inputs. You actually build up quite a lot of speed since you never get any ground friction and the sprint jumps ofc give a big boost. This could probably be boosted by sacrificing height too, but you'd need new inputs for that and i'm lazy.Oh well that's all for now. :3 Probably some of my favorite silly things recently. Maybe I should start getting 103 fevers for 7 days straight more often cuz clearly it is increasing my brain function instead of killing it like I would've been led to believe.music: stal - c418
Water Jumping w/ False Ground Detection Curcuit Store 2023-09-13 | This is a very messy video i don't know why i did anything i did but it's a very fun concept so I'm posting it anyway. Just in case this sickness kills me before I make a better one lol. enjo anyway ig :)So, being on the ground is determined by two criteria: First, you have to be moving downward. Second, that downward movement has to be interrupted in some way, so the distance you end up moving isn't equal to the distance you were trying to move. Usually the only way this interruption can happen is by bonking a block, which impedes any movement past it. For example when you're just standing idly on the ground, gravity from the previous tick tries to push you downward. But then this movement gets stopped by the ground, so you get marked as on the ground for the next tick. But! There is actually another way to do this: If you try to make a movement smaller than 0.0000001m(1e-7) on an axis, the game simply won't move you on that axis. This creates a discrepancy, and so if that intended movement was on the -Y, you actually get incorrectly counted as being on the ground. Tangentially this same concept is also what causes the perfect 90 degree x surf, just with your z velocity instead. You get a z velocity of like 1e-18 before getting snapped, creating a half-collision on the z axis and thus preventing your x velocity from ever resetting.Unfortunately though, at the start of every tick your velocity on any axis will get reset to 0 if it's smaller than 0.003m/t. This means you can't just carry in the right velocity from a jump or let gravity trigger it. Instead you have to use your actual movement acceleration from your inputs to get the 0.0000001m velocity. This is easy for the x surf since it's all horizontal, but normally this won't even touch vertical velocity, so no dice. The exception, of course, is with swimming. This let's you adjust your y velocity with jump, sneak, and most importantly by changing your pitch. Although sneaking doesn't always count since it comes before the .003 snap unlike jump and pitch for whatever reasonSo with this in mind, I just went ahead and found some inputs that would get my y velocity between -0.0000001 and 0.0m/t. Not always a super easy task in general, but I kept the examples pretty simple here. I end up swimming so that my y velocity starts at 0, and then I swim for one tick with a pitch of -3.76 with jump and sneak held, and for another tick at 27.68, this time with just space held. fwiw there's A LOT of angles that work, those were just the ones I chose. Pressing jump and sneak for the first tick doesn't inherently affect my velocity since the jump and sneak velocities cancel out. But annoyingly negative pitches just don't affect your y velocity if you're swimming at the surface unless you're pressing jump, so that just forces it to work without changing stuff. Pressing jump on the second tick does affect it, since the +.04m/t from it is what sets up the velocity correctly. Not necessary with different angles, but what I went with. And all and all this will get you a y velocity of like -4.7E-8! Which counts as being on the ground. You only see -0.0 on the menu though because since this counts as a colliding with the ground your velocity gets set to 0From there it's just a matter of jumping on the next tick to ~ do the water jump ~, but there's a bit more to that as well. You can either stay touching the water and jump as long as your eye level or whatever is above the water, or you can completely exit the water horizontally on that next tick when you jump. If you exit the water the jump will be like any old sprint jump, with friction that kills like half of your horizontal speed. But if you're still in the water when you jump, you only get the water friction, which only kills like 10% of your horizontal speed. This kills a bit of you jump height too, but the speed you retain is quite significant(adjusting pitch can giv height too btw). Essentially the equivalent of skipping the ground friction tick in a normal sprint jump altogether, which makes this one jump literally faster than where sprint jumping on flat ground caps out at. Not quite as fast as where 2 high ceiling sprint jumping caps out, but that still feels crazyAnyway that's all I've got rn sorry if that's a mess. You can 100% do this with elytras too which would be cool since they're so mobile(whoever made the .003 thing is a meanie...), but the angles are prolly much harder to get right. It also might be possible to chain these to just flat out swim faster? But I'm not sure. It's definitely faster for exiting water though, probably in all situations, presumably by quite a bit. The water friction straight to air friction is just sooooo good for speed. 100% some cool stuff to do with it but that'll have to wait until I feel better. Also I'd be curious if anyone's done this before, because it's obviously too precise to just happen, but it feels so obvious now that I've realized itMusic: Piano 1 - c418
(TAS) Diversity 3 Parkour Section | 8:36 Curcuit Store 2023-09-10 | Maybe flashing light at 7:40? idk watching this back made me seasick anyway so be warned there too ig. But maybe that's because I have a horrible fever and haven't slept.This is just a compilation of the Diversity 3 Parkour TAS's I've made over the past few months into a full run. Overall probably one of the longest and intensive TASes I've "worked on." Prolly not in terms of effort, sub 30 still takes that cake, but also I was like 14 then so who cares. Minecraft is definitely still not a game that is meant to be TASed tho! And I can very much feel it every time I work with it. Maybe that's A Good Thing(?) but it's also kind of frustrating.Regardless, inputs were written by my pathfinding roomba friend( youtu.be/9OPPzJHz6AU (are you tired of me using this video as reference? I sure am)) and myself. This is all playback, but each section was recorded individually and spliced together because it already takes 30 minutes to record one section without lag desyncing it, let alone the whole thing. Far from a perfect run, but it's up there I suppose. I imagine most of the time loss could be solved by manually refining a lot of what was done by the program, but that's just not feasible for me to do while maintaining that same level of optimization. Not that I /couldn't/, I don't think it's above me in that department, but I just don't have the tools or time to make it reasonable. There's a lottt of small collision order abuse and insane angles that are easy to see, but are just insanely difficult to do blindly(unless you're a bot who can just throw a million rerecords at it in under a second), and compound to save more time than I could get by cleaning the obvious stuff up. One day...Overall hours of work: 69Overall hours of computation: 121Map: planetminecraft.com/project/diversity-3Music: Dragon Fish & Menu 2 by C418Also the letter parkour is in this, which I haven't otherwise published, because it doesn't deserve to be. Every time you play it you get a random board of letters, and it's your job to go find the ones that spell out DIVERSITY 3. And not in the fun deterministic random way, just the completely random way. I ended up just running some isolated version of the function like 2 billion times until I got something good and then just fed it into the machine. Could be better/done better/more properly maybe, but I could care less I'm a certified rng hater get me out. I also ended up doing a fair bit of that part myself because idk.Plus the ending cutscene was a nightmare. You're supposed to wait a while for a jump pad to appear, which lets you jump up into the wool(which is actually just an armorstand holding wool). This is made to automatically give you the wool, which causes the cutscene to end. However, it's actually possible to just flat out grab the wool off the armorstand normally just by clicking on it, even without the jump pad. You still have to wait for the jump pad to appear for it to see the wool and end the cutscene, but you avoid waiting for an extra cycle to grab the next one. Fairly easy in theory, but it's actually pretty annoying.See, in order to grab an item from an armorstand, two things need to happen. First you need to close enough to it on the client to even click it. This is just the standard 3m from eye position to the visible hitbox like you'd expect(except this hitbox is invisible so use your imagination). However, you also have to be within a raw 6m of the armorstand on the server as a sort of safeguard. This normally doesn't matter since server/client positions should be almost the same, but when entities spawn with super high velocities(like the wool armorstand), they desync A LOT. They're like 10m apart most of the time here, making it impossible to grab the wool normally. But! Near the end of its trajectory the server armorstand actually hits the ground and gets friction'd, letting the client armorstand just barely catch up a bit. You can then get close enough to satisfy both those conditions by jumping up off the edge a little bit. You could even do it and just jump to your death without losing time(besides lag), but spending 4 hours TASing 8 more of these jumps to get a hotbar of wool was just wayyy more fun...Otherwise yeaaa that's that. Definitely understand a lot more about how to use everything/how the boop bop beep works/behaves now, and hopefully that should make future endeavors easier.
Softlock by Clipping a Full Block by 0.00001m Curcuit Store 2023-09-03 | technically it’s within 0.00000005m but who cares numbers are useless at that scaleThis has been haunting my mind since I worked on la machine budget scattershot ripoff(I swear I'll give an update on that soon the server is just scary). But recently I finally figured out why it happens so now we can all enjoy it together c:Basically, there's a 0.0000001m range where you can get yourself just completely stuck inside a full block's hitbox. There's probably some way to escape it with lag or something, but "softlock" sounds cooler and gamery, and I couldn't find any way to get out without smthn external(dying, mobs breaking blocks, spectater mode) so idk. Seems to have been added in 1.16, and still exists in 1.20.Anyway, this small range(where your hitbox lies 0.0000100m-0.0000101m within a full block's hitbox) lies right on the border of what the server deems "trying to clip into a block." And as a result of some small precision inaccuracies, it'll think you're trying to move into the block, even though you're standing still. This creates an infinite loop where the client and server get stuck constantly telling each other to reset your position/rotation to the same thing. So if you're not looking in the right direction to mine it yourself, you're just kinda stuck.The "precision inaccuracies" in question is just a shortcut in the collision check specifically for full blocks, which is why this is exclusive to them. Usually collision checks give you 0.0000001m of leniency where you can clip into it without it caring. But occasionally for performance they'll just check the raw hitbox of full blocks, which accidentally(?) forgoes that leniency. I'm pretty sure 1.16 is when this shortcut was introduced in some places(but not all), which is why this bug happened.Specificallyy(this is basically just my notes now),,,, when you send a position to the server, it first checks to see what blocks you're already colliding with(assuming your hitbox is shrunk by 0.00001m, which doesn't matter, but is why it's 0.00001-0.0000101m not 0-0.0000001m). It doesn't use any shortcuts to do this, so it'll miss any blocks you're just barely clipping. It then checks to see what blocks you'd be colliding with at your new position. If it finds any new blocks here that it didn't before, it'll assume you're trying to move to inside of a block, and tp you back to your previous position to try and fix it. The issue is that(in 1.16+) this check /does/ use the shortcuts, so it'll catch any blocks you're just barely clipping, even tho the other check wouldn't. This leaves a 0.0000001m range on every full block where even if you're standing still it'll think you're moving into a block, and send a packet to the client to tp you back. And once that tp is complete it immediately sends a new packet to the server to redo the check, but since you haven't moved, it just creates this loop.Now, since the loop all happens within packets it doesnt require any ticks to pass, so in turn it just constantly runs as fast as it can. Even if the game is completely paused and there's no ticks happening. You can use this to interact with certain blocks infinitely many times instantly(youtu.be/-LBSvVARAEU ), but sadly it doesn't let you eo anything super fun like infinitely jump(but if you could get something like this oscillating between two positions maybe?)Also to actually do it in game, I just found some inputs that move me by 0.0000100-0.0000101m, and then lined myself up against the wall. Wayyyyy easier than I was expecting it to be tbh. Inputs were just sneak forward at yaw 119.735 for a tick, then at yaw 306.290 for another, then let go of everything and wait for momentum to stop. Cuz who doesn't love when your yaw needs to be accurate by +/-.005. Mordern game tasing is so dumb why does everything have to be a 64 bit float... Also the jump isn't necessary but I thought it was more funner.
End Warp w/ Server Movement Correction Curcuit Store 2023-09-01 | I have no doubt this is nothing new, but I've never seen it before so might as well document itUsually when you change dimensions your coordinates get updated in some way(divided/multiplied by 8, set to 100,49,0). However, there's a few glitches that let you change dimensions while leaving your coordinates completely unchanged. aka end/nether warps. Most of them that I know tho require a lot of lag, relogging/closing the game, and are for 1.12ish. But, recently I was looking at movement again, and realized that this probably existed. Sure enough it does, and even tho this is 1.16, it works in 1.12ish too, just with less precision. It prolly exists in newer versions too, just with more precisionThe idea is that you make the player enter the end and also move illegitimately in the same movement packet. This puts you in the end, but then reverts you to your overworld coords in an attempt to correct your bad movement. Specifically...Occasionally, the client sends your current position to the server. This happens either 20 ticks after you last sent a position, or if you move more than .03m from the last position you sent. Usually the server just takes this position and updates your server position to it. buuut, it doesn't just accept any position you send, because that would be ridiculous! What if someone abused it to instantly move hundreds of blocks at once?! Instead, it analyzes the movement/collision necessary to get to that position to determine if it's "legitimate." If it is, it updates the server position as normal. But, if it deems the position a bit sussy, it'll refuse to update anything and instead makes the client update /its/ position to the old server position in an attempt to "correct/revert" the invalid movement.This fancy movement analysis is pretty meh tho, so it's easy to make it falsely flag weird/small movements. Additionally, it actually pseudo-ticks the server player to do this, which lets us interact with blocks(like end portals!) So, by sending a bad movement that also causes the player to intersect an end portal, you can get the end warp. No lag required!So then, what makes a movement bad? Well, there's a few things, but these are the main 2:Moving Wrongly! One of the first things the server does is take its current position, and try to move to the position you sent all in one big movement step. This follows all the same collision order/movement logic as normal movement, and is what lets us interact with stuff like end portals. If the resulting position is more than 0.25m horizontally from the original position you sent, then you "moved wrongly!" You won't get marked as moving wrongly if you're changing dimension tho, so this isn't useful here.And even if you do get marked, it doesn't necessarily mean you'll get corrected. You also have to make sure that your current/old server position isn't intersecting anything so the correction doesn't move you back into a block. Maybe worth noting that you get 1e-7m of leeway on non-full blocks, but none for full blocks. So if you pass this and get marked as moved wrongly!, you will get corrected. Again, not useful here.Collision Test: The other main way to get corrected is by failing a collision test. This looks at what you'd intersect at the position you sent, and if it intersects with any new blocks you wouldn't already be colliding with at the current server position, it fails. This automatically triggers the movement correction, and is what I use here. Also maybe worth noting you get 1e-5m leeway for full blocks at the sent position, and like 1.01e-5m for everything else. This discrepancy actually leaves a tiny range where you can get stuck in an infinite correction loop, but sadly you can't use it to instantly build up infinite server velocity...Now for what I do in the video. I do outline it a bit, but here it is with the above context. There's infinite ways to do it tho, this is just an example:First I make super small movements to move into the trapdoor while keeping the server position outside it. The trapdoor could be anything, it's just easier to close it than to clip into somethingI then send a new position(from within the trapdoor) to the server by waiting 20 ticks/moving more. The server tries to move from its position outside the trapdoor to the new position, but it just bonks on the door since it's still standing up and the trapdoor is closed. Luckily tho the server player can actually climb 1m steps(opposed to .6m), so it just steps up onto the trapdoor, causing it to enter the end portal. Then it looks at the position I sent and realizes that it would start intersecting the trapdoor even if it could move there. This immediately fails the collision test and triggers the correction, reverting my position while keeping me in the end.mayb that made sense idk am tire but is fun i think : )
13% Fast Perch Insta-Kill Setup 1.12 SSG Curcuit Store 2023-08-26 | This would sub 1 on a 22 second end enter btw. Also thx for the patience it's been One Of Those Weeks. An average end fight should be like 38-38.5, but that's assuming 0.05 seconds per ticks. This video was like 761 ticks but still sub 38But!!! This will ONLY work with yaw 229 dragons and a fast perch. If you're reloading a world or setting the dragon's phase you'll have a very hard time hitting it(like less than 1% if no 0). If you don't know what any of that means I explain it a bit in this description(youtu.be/SQWFLieGRP8 ), but also I'll give a small overview hereSetup!0. Make sure you get a yaw 229 dragon. I'd recommend just using render distance 12 and then pausing a bit when you enter the end. You'll get it as long as the last chunk the dragon generates populates 2 different chunks, which can happen at higher render distances, but I'm not sure I trust it, and 12 is prolly just safest.1. Get a fast perch. You'll want to sneak on the edge of the obsi platform(anywhere with your x over 102.5) for 3.9 seconds after the dragon/bossbar spawns. This will give you a 10-10.7 second perch ~27% of the time. You'll also probably want to mine at least 2 endstone during this2. After that, go up and break the block at (102, 55, -16). You'll use this hole later to position yourself to shoot the dragon. You could /maybe/ save this until after the perch, but this is easier imo. Fwiw I line this block up with the hill you climb out of, and the nub on the edge of the island. The f3 screen is just for reference, I can't actually read it that fast3. Build an endstone pillar at (98, -16) up to y 58. The top block(y58) HAS to be endstone, which is why I suggest mining some earlier, but technically the bottom block(y57) could be anything. This pillar will both slow down the dragon AND stop your server velocity from snagging on the Z. Without it, you'll only hit the setup like 1% of the time. This could also go after the next step if you want/have time4. Go wait at (97.3, 57, -14.7). You need to get into this position before the dragon leaves its perch, and stay there until it does, so that it charges the right position. It's not free to get there in time, but it's not too bad. Keep in mind Y is important tho! The easiest way to get there imo is to just break the block at (97,56,-15), get in the neg neg corner, and then jump back up and replace the block. Any block works to replace it, just don't place endstone anywhere else.5. Move to (102.7, 56, -15.7) to shoot. This position lines up with the most likely spot for the tickle spot to be, and is in the pos neg corner of the hole you made in step 2. You could maybe dig the hole now like I mentioned, but again I find it easier not to. Technically y isn't super important here, but 56 is prolly best6. Shoot and kill the dragon. The timing in the video is perfect, and gives the full 13.2% chance of killing it, but a little late can still work.8. Beeline to the end fountain. Don't jump out too fast or you might get hit by the dragon again(we're so far from 0,0 that the dragon doesn't ascend very fast). But don't take too long either, or the fountain might open before you get there lolOverall this setup gives 13.2% chance of getting the velocity and keeping enough of it to kill the dragon(assuming a perfect shot). It should also average 12.05-12.2 seconds from perch leave to the death dance. Luckily my suspicion that these faster perches would give more consistent paths was right, and that's why the success rate is so high. But also tbf if the yaw thing existed in 1.14+ there'd be 100% success setups soooo. I can def vouch that it works tho cuz this setup now makes up 5 of my like 20 killsI suppose that's it tho. All that's left now is to go get sub 1! Which is an insane milestone, but I've made it so easy that it won't even be that crazy lol. Literally you! innocuous viewer! Could go get sub 1 right now if you're semi-decent at the game. The world (record) is your oyster! (Just get a lil lucky)ngl tho, very satisfying end to this chapter.Huge thanks to:Matthew Bolan, for introducing me to the main idea like 5 years agoCrafterdark, for laying the foundation of the trickT Wagz, for inspiring me to look at rta setupsKeima, for inspiring me to look at 1.12and Mojang, for somehow creating the perfect conditions for this to exist by: -Keeping dragon knockback uncapped for like 9 years -Letting server velocity transfer to arrows -Keeping arrow speed/damage uncapped -Keeping dragon knockback server-side -Poorly syncing server/client velocity -Using the same rng to generate chunks and set dragon yaw -Making the dragon default to a fast/simple perch when you're out of range -Making that range just barely avoidable while sneaking -Letting the perch standardize dragon positions just barely enough -Letting you set the dragon's exact target when it charges -Making the dragon slow down when it passes through blocks
Fast Perch Timings/Comparison 1.12 SSG Curcuit Store 2023-08-23 | This video is a LARGE mess of made up word salad I'm sorry. Just wanted to get some of the fast perch info/times and sneak timing stats in one place for future referenceRecently I showed off a way to get faster perches on seeds where the dragon flies towards the +X first, like the 1.12 ssg seed(youtu.be/7DaOGpOTi7s). Put simply, by sneaking on the edge of the obsidian platform you can get completely out of the dragon's range. And if the dragon attempts to perch during this time it'll actually default to a weird east perch, instead of flying across the island like usual. These are these "fast perches," and they're both up to 6+ seconds faster, and a lot more consistent in their times/paths. Additionally, they angle the dragon much more favorably for fast chargesAnd while this is great, it means that there's a lot less time to get into position for an insta-kill setup. Not only do you have ~6 seconds less to get there, but you have to burn time sneaking on the obsidian platform as well. The longer you wait the more dragons will be able to "fast perch," but waiting too long means less time to get into better/faster positions, and also just more slower dragonsLuckily, the dragon makes breaking these up pretty easy. There's actually a clear range of time where the fastest dragons will attempt to perch. These dragons will take the quickest route and have the highest chance to perch(1/3). There's then a second range a bit afterwards where the slowest dragons will attempt to perch. They have a lower chance to perch(1/13) and will take a much longer route. The spawn yaw of the dragon(229 or 37 here) will then control the exact distribution of these fast "1/3" and slow "1/13" dragons, and the time ranges where they try to perch. In the video I simply go through these different variables and show how they affect things. In the end, I think that sneaking for only the 1/3s, particularly with yaw 229, is best.~background/raw info~Yaw 229/37:The dragon is supposed to spawn with a random yaw. But since it force loads a bunch of chunks right before spawning, the rng used for that yaw gets reset to predictable values. You can manipulate what these values are by pausing and pre-loading certain chunks using certain render distances before the dragon spawns in. On this seed this can give you a yaw of either 37.8311 or 229.78471 degrees, depending on what render distance is use. From Crafterdark:Render distance 2-7 & 25-32 - yaw 37Render distance 8-24 - yaw 229This happens because end city gen resets world random each chunk, and the last generated chunk then advances it based on what chunks it populates(which changes based on the chunks you/it already loaded). This difference in yaws is important tho cuz it affects the dragons path, and in turn its chance to perch1/3 vs 1/13 Perches:When the dragon reaches the end of it's first path(marked by a target a random height off the ground), it'll roll a random chance to perch. If it reaches this target within 5 seconds of spawning, the perch chance is a 1/3. But if it takes more than 5 seconds, the perch chance will be 1/13. The dragon can almost always reach the target's horizontal position in this time, but if the target is too low or the dragon too high, it can overshoot it and have to backtrack, making it take longer than 5 seconds. This makes it less likely to perch, but it also causes it take a slow outer node route to perch. This is all because when the dragon first spawns in, it takes a while to "register" all of the crystals. So for the first 5 seconds of the fight it believes that all of the crystals are destroyed. This affects the perch chance(which is 1/(3+number of crystals up)), and the nodes it's allowed to route thru(if all crystals are down it can't route thru outer nodes)To put that into context, yaw 37 starts the dragon already facing the target, so it can start flying towards it immediately. But this also gives it less time to descend, meaning it has a higher chance of overshooting the target and taking 5+ seconds. Yaw 229 on the other hand has to do a full 180 before it starts flying, giving it much more time to descend, making it less likely to overshootaaand timings in da video(all times from after dragon spawn):best setup imo:(Yaw 229) Sneaking for 3.9 sec:-Necessary sneak range: 3.25-3.9 sec-Catches 1/3 insta-perches(no 1/13s)-26.6% for 10.0-10.9 second perch w/ 10.25 averagemeh setup:(Yaw 37) Sneaking for 2.85 sec:-Necessary sneak range: 2.5-2.85 sec-Catches 1/3 insta-perches(no 1/13s)-5.8% for 9.9-11.05 second perch w/ 10.25 averageimpractical:(Yaw 229)Sneaking for 7.25 sec:-Necessary sneak range: 3.25-7.25 sec-Catches all insta-perches(1/3 AND 1/13)-27.2% for 10.0-17.4 second perch w/ 10.45 average(Yaw 37)Sneaking for 11.1 sec:-Really only need to sneak between 2.5-11.1 sec-Catches all insta-perches(1/3 AND 1/13)-11.5% for 9.9-18.95 second perch w/ 14.25 average
Faster Insta-Perch Idea SSG 1.12 Curcuit Store 2023-08-19 | This is very silly but it's frankly more embarrassing that I completely glossed over it for the past 3 weeks. In my defense I thought it was 150m, but turns out that's the range for entering the charge phase, not perching... This /will/ require a new insta-kill setup, which I'll get to as soon as I feel able, but it could be a good 8+ second time save if everything works out(maybe it could be more consistent too?). The timing will also probably be pretty tight/hard to gauge, but speedrunners are smart, and it'll open up sub 1 at the very least lol.In order to guarantee you're out of the range, you just need to be sneaking more than 102m from 0.5,0.5 when the dragon tries to insta-perch. This basically comes out to just keeping your X over 102.5 while sneaking on the obsidian platform. Even at the corners it's over x 102.47 so like yeah. Just stay over x 102.5 lol. Once the dragon decides to perch you can just continue on up as normal. This could be anywhere from 3.25 to 7.25 seconds after the dragon spawns, but it averages about 3.75, and 85% of insta-perches will be before that(and 90% will be before 5 seconds). Remember that that's after dragon spawn tho, not end enter. Which should just be 1 second apart until we start entering end sub 15 lol.aaannnd deets for the bored of yous. aka future me when I need to remember smthn:When the dragon enters the landing approach phase, it tries to look for a player within 128m from 0,0. In 1.16 this is completely broken and always finds the player, but remarkably, in 1.12 it actually does something! Except instead of "within 128m" it's actually "within a 128m radius 16384m tall cylinder centered around 0.5,(top 0,0 block),0.5." And while the height of this cylinder is always the same, the radius decreases based on your "visibility." Which is affected by stuff like being invisible or wearing a mob's heads, or more importantly: sneaking. Specifically, sneaking cuts this distance down to 80%, or 102m.If it does find a player in this cylinder, then it pretty much just tells the dragon to route out to the farthest mid node from that player. In reality it's just the closest node to the furthest point on a 40m circle around 0,0 from the player's horizontal coords(with the y then set to 105, which is why its so hard to get diagonal perches). But that's basically just the furthest mid node, and idk how to say that elegantly.But!! If you're not in range, like I show in this video, it will instead just look for the closest node to (40.0,(top 0,0 block), 0.0) to go to. This /would/ cause the dragon to just do a reverse e/w perch since the e/w node is directly above 40,0(like this youtu.be/t_Z41RjCBM8?t=159). But since that node is all the way on top of the east pillar, it actually finds the center 20, 0 node to be closer instead. This leads to something even faster than a reversed e/w perch, since the dragon doesn't have to climb the tower before landing. All cuz instead of looking for the closest node at y105 when it finds you, it's from whatever y the top 0,0 block is.Anyway all in all these fancy insta-perches range from 10.0 seconds to 17.4 seconds for yaw 229, versus the 16.3 to 21.3 seconds for normal insta-perches(as always measured from dragon spawn to entering sitting scanning). The average is also only 10.9 seconds, but of course the 1/8s and non-insta-perches all end up much slower for this instead of faster. So it's probably just under 30% for a super fast perch using this.I'm also not sure if the insta-kill setups will be more or less consistent for this. I'm tempted to say they'd be better just cuz there's less flying/random targets to mess up the paths, and not to mention the dragon yaw already being consistent. But that's just speculation. My only (big) worry is that "backwards" dragons are going to end up the norm here(but still probably less likely than "correct" dragons with the current perches though). It'll be great for speed since the dragon is already facing the right way and preserves all it's speed from before the perch, but it does worry me in terms of consistency. I have a feeling the turning(and the time it takes) helps get all the dragons on a similar path, and that without that it'll be rough. I don't know for sure though, and maybe I'm just worrying for nothing. Best case scenario the less flying around evens it out ig.Having 5 seconds of downtime while sneaking and waiting for the perch might be fine too, since you could probably mine end stone there while you wait. Which can let you make your own terrain for the dragon to fly though instead of a pillar(kinda like the bonk block in the current 5% setup(youtu.be/sJOT9dejeno), but to slow down the dragon instead/as well).idkkkkk! lots of stuff to look into, but I randomly thought of this when I woke up today and wanted to get it out before I do too much more.enjoy your day :)
SSG 1.12 Perch Times Comparison Curcuit Store 2023-08-16 | Figured this would be interesting to look at. These aren't necessarily the absolute fastest/slowest since I only did a sample size of about 200k dragons for each category, but it's probably a decent estimate. The fastest/slowest ones were usually tied with a lot of other ones anyway, so it's not like they were already crazy outliers or anything. ALSO!!!! this timing starts on dragon spawn(usually 20 ticks after entering end), and ends once the dragon enters the sitting scanning phase. So if you want full end fight times you can add that 1 second spawn time, 5 seconds for the perch, the takeoff to shoot to fountain time, and then the 10 second death dance time. Also by "insta-perch" I mean it perches as soon as possible, since apparently they're not always so "insta"Something to point out is the yaw 229 vs yaw 37 distinction. Basically, depending on what chunks you load before the dragon spawns, you can guarantee that the dragon spawns with either a yaw of 229 or 37 on this seed. As a result, some render distances will give you a yaw 229 dragon, and others will give 37, assuming you wait for all the chunks to load before the dragon spawns. While small, this can affect the dragon's path a bit. From Crafterdark:Render distance 2-7 - yaw 37.8311Render distance 8-24 - yaw 229.78471Render distance 25-32 - yaw 37.8311As far as I understand it, this just happens because right before the dragon spawns, it first makes sure all the chunks around the island are generated. This sets world random to predictable a value because of end city gen, and then advances it based on the last chunks populated. This then causes the dragon(who also uses world random) to choose a predictable yaw when it spawnsBut!!! Even though yaw 37 /can/ give faster perches, I wouldn't suggest using it because (a) its bad. and (b) it cuts your chance of hitting the current insta-kill setup(youtu.be/sJOT9dejeno) down to like 4%.The numbers:Slowest Insta-Perch(229): 21.3 seconds(426 ticks)Fastest Insta-Perch(229): 16.3 seconds(326 ticks)Slowest Insta-Perch(37): 23.35 seconds(467 ticks)Fastest Insta-Perch(37): 15.6 seconds(312 ticks)Fastest 1/8 Insta-Perch(229): 14.15 seconds(283 ticks)Fastest non-Insta-Perch(229): 14.9 seconds(298 ticks)(technically just fastest perch that didn't perch on the first path but did on the second. I didn't check anything else)Fastest Insta-Perch if the End Island was Simply Backwards: 10.75 seconds(215 ticks)The yaw 37 dragons were a lot more extreme than the yaw 229 dragons. I assume this was just because they start facing the right direction, so they can hit the first node a lot faster. But on the other hand it makes it easier for them to miss their target on the first swoop, adding a lot of extra time if the target height is less than ideal. That's mostly just speculation, but it does seem like the positioning is just more prone to missing targets.The 1/8 dragons being faster was a bit of a surprise to me, but it makes sense. Normally the dragon has to circle all the way around the island to get to the node where it perches. But if it 1/8s, it just immediately flies straight across the island. Unfortunately though this means that the dragon doesn't roll the chance to perch until quite a while into the fight. So instead of having a 1/3 chance to perch, it only has a 1/13. This is also the case with some normal insta-perches if they take a while or miss the target on the first swoop. Which is just greeeeaaat cuz who wouldn't want the fastest perches to have less than a 1% chance of happening!! The same 1/13 is true for the fast non-insta-perches, since they have to travel further. I'm less certain why those can end up faster than insta-perches though. On average they're a lot slower since their path is so much longer, but I guess the targets can line up perfectly to not be out of the way and position the dragon just rightThe backwards end island thing definitely isn't very possible, it was more to show how fast perches can be in this version(they could be even faster on different seeds!). Sadly the front tower on this seed is just higher up than the back one, forcing the dragon to fly towards us at the start of the fight. And then when it tries to perch it has to fly all the way back to the opposite end of the island, since it always perches directly across from you. If the back tower was taller(like this example), it would already be heading in the right direction when it tries to perch instead. This isn't ever a problem in newer versions since you have time to get into a position where the dragon is already directly opposite you(so it just immediately perches instead of flying somewhere else). But 1.12 dragon is just so fast that you can't get anywhere fast enough, dooming you to a e/w perch all the way across the island. The tower/node heights that determine where "directly across from you" is definitely don't help either
Spinning Perch Recreation/Example Curcuit Store 2023-08-15 | hiiiii. I saw an absolutely amazing clip today(youtu.be/nvwBoSPT7QY?t=388 ), of something I've somehow never seen before. Apparently, if you shoot the dragon super perfectly as it perches, you can get it to just spiral around the fountain all the way down. Which is absolutely hilarious, and since I'm worryingly obsessed with the ender dragon, I wanted to try recreating it. Is it useful? Probably not. Ngl I just wanted to see what it looks like if it spins for more than 2 seconds(and in slow motion).In theory it's not even anything crazy. In fact the reason it happens is actually pretty similar to how I went about minimizing the death animation(youtu.be/TWr8edoqJz0) in one of my previous end fight TASes. You just have to get the angular momentum/actual velocity of the dragon just right so that it gets stuck continuously turning towards its target as it descends, without speeding past it. The only difference is that instead of speeding up your end fight this just messes up your one cycle! I will say it is a LOT harder to do than the death animation tho cuz perch physics are pretty crazy funky silly. Which is also why you probably wouldn't ever see this naturally, but it's not too hard to do with TAS. Mainly it's just difficult because a perching dragon turns super fast, which means the dragon has to be suuuper closer to its target in order to get into the swing of things(get it!??!). You also have to make sure it has as little velocity as possible or else it'll just speed past its target and start swooping again. The death animation doesn't have this issue as much tho since the spirals are so much bigger. Ideally you start with a little extra angular momentum in the right direction too to get things moving, but the dragon turns so fast here that it doesn't really matter. Otherwise that's all it takes!Also sadly I couldn't find a setup to get it to start spinning from the very top top of its perch, but this was enough to satisfy me. You could prolly do it better with more arrow shots or other dragon shenanigans, but that was more brain power than I was willing to invest in this lolidkkk that's all. i hope your day is spinning as beautifully as this dragon
Flying to the Outer End on a Very Fast Llama Using Dragon Knockback Curcuit Store 2023-08-13 | Welcome back to episode 2 of getting to the outer end islands using very unreasonable and morally dubious setups. On today's episode I am employing the service of my noble steed(and a dragon) to launch myself there. I've been meaning to do this for a while but I kept on forgetting to try it. And unlike my last video you actually could do this in game!The idea is pretty simple. The dragon can give huge amounts of velocity, so I use that to give the llama a huge boost, and then get on the llama to come along for the ride. I can't just give the player the velocity since it would get capped at 3.9m/t. But since entities are handled differently they can get all the boost they want, whenever they want. If you want more information on what that server/client difference looks like/does for players, I talked about it a bit in this video(youtu.be/SQrrpitg-Ts). And if you want more info on how the dragon knockback works, I made a video about that a while back too(youtu.be/DBYgB2sESmM).That's all! I don't think this has much of a practical use but it is probably faster than killing dragon and entering the gate if you're really gamer tbf. You could do this with basically any rideable mob(pig/strider/horse/etc), but I thought llama was funniest. Sadly boats/minecarts wouldn't work, but dragon doesn't knockback them anyway.
Dragon Insta-Kill w/ Velocity Desync Removed Curcuit Store 2023-08-13 | Don't mind the janky makeshift tickrate changer I had to play at 1% speed just to get the terrain to render fast enough lol...I've seen a few people/shorts explain how the insta-kill works, but I feel like most of them under-estimate how fast you need to be going to actually kill the dragon. Obviously if you're explaining it you have to bring up the fact that the dragon can launch you crazy distances(dozens of blocks into the air!!), but even the biggest launch you can physically get from the dragon is only 2% of the actual speed needed to kill it. So! Since I was curious too, here's what the approximate average minimum velocity needed would look like if it was actually fully transferred to the client. Technically there's still some desync in this video since the setup relies on it, but this was close enough for me. Calling it "desync" is kind weird anyway tbf.Normally, this "desync" happens for a few reasons. First off, the dragon velocity is only applied on the server(pre1.3 dragon knockback goes craaazy tho). So for you to physically get launched at all it needs to actually be transferred over to client. But, this only happens during certain actions. The biggest one just being whenever you take damage. This is usually the only thing that makes the dragon actually launch you. It’s also why perched dragons are so hanky, since they don’t automatically damage you when this knockback happens. But also, (sadly? luckily?), all velocity copied/transferred to the client is capped at only 3.9m/t in each axis. So even if you did take damage and try and transfer this huge knockback, it just gets capped to be super low. For this video, I've just removed that 3.9 cap and then made it transfer velocity whenever you get closest to the dragon.For the record, the absolute lowest velocity that can kill the dragon is 267m/t, which would send you almost 3k blocks in 2 seconds if it all transferred to the client. But funnily enough you almost always just bonk on the outer end islands before going that far. The /average/ necessary velocity is like 320m/t though, which would send you like 3.5k in 2 seconds and still leave you with like 7m/t of velocity.anywho that is all ig. i hope your day today is/will be glood :)video on the ssg 1.12 insta-kill setup shown in the video: youtu.be/sJOT9dejeno
Faster 5% Dragon Insta-Kill Setup 1.12 SSG Curcuit Store 2023-08-12 | (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(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 doesn't think there's 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. I'm 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 there's end island chunks that need to be generated(smthn smthn end city gen resets world random)(?). Regardless, it's 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 transferSETUP INFO!Pickaxe is kinda required, and you can do the setup up as soon as you want, it's just hard to see. You just can't 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 isn't 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 that's all for now. Hopefully better/faster setups coming soon, but maybe this can tide you over. I'd wait until I had something better but this is More Dramatic and Also I Felt Bad. I'm also considering looking at 1.9 setups(?) I'm hesitant cuz hunger sucks, but on the other hand there's potential for some silly stuff. It's the only version with the bug that directly ties the dragon's yaw to it's head/neck hitbox heights(they literally use the dragon's 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, I'd actually have to look into it to find out, but that's like the only version difference anywayalso! these %s includes the "backwards dragons," which always fail, and happen 4% of the time
SSG 1.12 Insta-Kill Setup Proof of Concept Curcuit Store 2023-08-03 | I gave in to the urges and decided to test out a full non-peaceful 1.12 insta-kill thingie. I was honestly going to take the time to grind out an actual run, but I won't be home for a while so here's the closest I got in a few hours. Someone else can take a day and become history lol. Even this probably would have been about 1:42 if it hit, but it was also one of my first attempts, and my best end enters ended up being around 52(doing exactly the same thing just faster). Which, fwiw, is only about 5 seconds slower than my best peaceful enters.The insta-kill setup is exactly the same as the peaceful one(youtu.be/EbUeARgcC0U), except I stay in the corner when shooting instead of pillaring up. This way when the dragon hits me and transfers a little bit of knockback I can still stay aligned. Usually I shoot about the peak of the knockback, but occasionally that’s a bit off so idk 5 or so ticks after you’re hit is usually correct?(better to be late than 1 tick early tho because you’ll retain 91% velocity tick to tick)I can't be bothered to figure out any tools to actually look at the numbers for server velocity/position, but I'm fairly confident the dragon upwards knockback is enough to offset your server position above the little cubby so you can't bonk on it. I've killed it 3 times in practice so it's definitely possible, I just haven't taken the time to ""rigorously"" prove anything.In practice i actually managed to kill the dragon with only 160m/t of velocity, presumably from hitting the head. I’m not exactly sure how or why though, and would probably need more investigation. my only guess is that that dragon started to take off(since it enters holding phase right before you kill it) and i just managed to be at the perfect height with the perfect angle to hit the head. if so that’s kind of lame(and impressive cuz it should only barely stick out from the neck here) but idk maybe there’s some hitbox quirk of 1.12 i missed. and if so that would be huge for this. only needing 70ish velocity would make it like 1/5 chance of killingThe whole route is pretty clunky too, but I just did whatever worked just to get something out before I left. Someone else can actually try stuff or smthn. Mobs are annoying but idk skill issue. also I failed killing the chicken pretty bad here but holllyyy crit, wait to land, sprint hit, crit is great. So yeah I guess best of luck y'all get a sub 100 second run for me :)seed: 4973628407607760032edit: guess it works 💀(rip my one shot at ssg wr)Next step is probably to look for faster setups. There’s a lot of 1-1.5% setups that I found, whereas this is like high 1.xx%. It’s a bit slower as a direct trade off though just because the dragon has to travel farther. I'll also have to filter out a bunch so that the dragon knocks you into the right corner for it to be non-peaceful-able(this isn’t the case for the secondary setup I initially mentioned). I could potentially yell at people to get pickaxe too, which would open up more potential (better) setups, by either creating your own terrain to manipulate the paths or to use the ground. I’ll also probably factor in dragon death animation/turning and try and optimize that too, which I think could save several seconds. Depending on the timing it's maybe also possible to force less than perfect 1/13 to get a perch from a different direction too which could be interesting and faster since the dragon wouldn't have to decelerate and turn for like 4 seconds. Idk point being there's still lots of time saves and consistency to find. This is very much a prototype and the night is young, people are just jumping the gun. I’ve literally only looked at this version for like 1.5 days. And rn i’m on irl vacation after sinking 5-8+ hours a day into the rest of this trick for the past like 2 months lolI think there's potential with arrows too, but I doubt many top runs will have 1+ arrows, and more importantly it removes all hot-spots which ruins a lot of stuff. There's also a chance I can find setups for different dragon positions/angles, which could potentially be recognizable and react-able to, and give a higher chance to hit it. idk.
1:37 SSG Peaceful 1.12 (w/ insta-kill setup) Curcuit Store 2023-08-01 | my last ssgp pb was exactly 1,900 days ago(how was 2018 5 years ago wdym im not 14 anymore) funnily enough my ss pb is also 1:37 igtAnyway, a few weeks ago I was asked to look into the 1.12 ssgp insta-kill, but all I could really say at the time was "ouch yeah that sucks." So, after I made my perch positions video(youtu.be/fk_LBLn6Mzw), I took a few days to port all my stuff to 1.12 to repeat the """analysis.""" But this time with an actual purpose.If you're unfamiliar with the dragon insta-kill, idk watch any video on this channel from the past 2 months. This one prolly has more links: (youtu.be/otXRufIkvyM)Remarkably, the 1.12 dragon fight is pretty much identical to 1.16. Most of the changes are just small float rounding things, like what makes some negative nodes/towers to be off by 1 in 1.16. Also mojang broke sight/distance test stuff between the two versions, but who cares besides no strafes 64m from 0,0 lol. The most noticable difference though is that the 1.12 dragon accelerates vertically like 10x faster than in 1.16. As a result, 1.12 dragons can east/west perch before most 1.16 dragons can even finish their first holding path. This is delightful because it opens up using the dragon's takeoff player charging phase thing to do the insta-kill. Which is exactly what this category does, and is great because the dragon just comes straight to you for free.The only issue is letting the dragon fly around the island for like 30 seconds practically ruins any chance of predicting its path or getting any nice patterns. I was hoping that the perch positions in this version would be condensed enough to sort of normalize all these paths so that you could predict the charge path better, but it was pretty meh. fwiw, the perch positions just form a big blob here because the dragon is too fast to do silly lil swoops. Even by the time the dragons reach a super far away target there's still a huge 1x.1m strip where a dragon's tickle spot could be during any given tick. Which isn't horrible, but means even if you know exactly where to stand you have less than a 1% chance of getting close enough to the dragon. Arrows don't even really help since they just disrupt this and the dragon flies away once it gets too close for too long anyway.Luckily though, I still had one more trick: the obsidian pillars. If you didn't know, the dragon will slow down by 20% whenever it intersects with a block it can't break(e.g. obsidian!!). In theory this could compress our strip of possible tickle spots, making it denser and easier to hit one, but that wasn't what I was interested in. Instead, consider that a dragon only slows down if it's /intersecting/ the pillar. And since we have a whole big strip of possible dragons, chances are not all of them will intersect in the same tick. If instead, say, half of the dragons intersect on one tick, and the rest on the next, it'll essentially fold the strip in on itself. This'll create voids in the strip where no spots can be, but also double the number of spots in other sections, doubling the chance of hitting them. A similar thing happens as the dragon leaves the pillar, and all in all if the dragon target is right some positions have like a 4% chance to hit.And luckily, we can control the dragon's target and our position pretty easily. By standing in one spot when the dragon takes off you can set the target to that position, and then you can just move to another position to shoot at a good spot. With this information I sifted through a bunch of potential setups that align you just by running into a corner. In the end I came up with a setup that gives a ~3.8% chance of getting close enough to the tickle spot, and just did runs with it for a day until I got this. I stand at ( 75.3, 59, -23.7)(Y is important!), wait for the dragon to leave the perch, then go to (77.7, ~, -24.3)(Y not explicitly important). I found another pair of positions(59.7, 59, -26.3 for charge, 62.3, ~, -27.3 for shooting) that are faster, but only have like a 2.5% chance of getting close enough.Buuuut those percentages are a bit misleading. Even if you do get close enough and get the huge knockback, there's still a chance of that server velocity bonking on terrain and resetting. In pre 1.14 your movement is processed in each axis at a time in the order YXZ. So unless you build up like 10m, you're doomed to just bonk and lose like 50% of the time. I try to get as high as possible before shooting to avoid some terrain, and the upwards dragon knockback can offset you upwards a bit, but no matter what if you have more than like 30m/t in -X you'll just bonk on terrain/a pillar and lose all of it. And then you also run the risk of snagging on something else over there and losing all your Z velocity as well. soooooooo yeahidk. that description was rushed but i am SOOO tired why doesn't anyone tell you that playing video games is so exhausting. idk gllll comprehendingalso seed: 4973628407607760032
Dragon Perch Positions Curcuit Store 2023-07-26 | Episode 3 of random text over unrelated footage of dragons perchingJust a small video on the dragon's "perch positions." Probably not super interesting on its own, but I felt it was worth documenting in case I come back to it.For context, the dragon doesn't move at all while perched. It simply flies down to the top block at 0,0 until it's within 1m of the top center of it and stops. And won’t move from this "perch position" until it leaves again. It can still turn around to look at you, which moves the smaller green hitboxes around, but its main position stays exactly the same. Which, fwiw, is located at the bottom center of the big white hitbox, and is what I show on the graphs.Now, this would leave a whole 2m diameter sphere of places where a dragon's "perch position" /could/ be. But since the dragon takes a pretty predictable path when landing, I figured a while back that there'd be some sort of pattern to them. Not to mention that they stop right at the target, which they all try to pass over anyway.Regardless though that's pretty hard to prove/investigate without either a full dragon fight simulatinator3000 or a lot of patience, of which I had none. But after spending a week or so losing brain cells trying to recreate the whole dragon fight(did you know the dragon can use old targets from phases its not even in? Cuz i sure didn't!), I figured I'd test this out.The results were fairly neat I suppose. Most of it isn't super surprising, but still fun and novel. The movement is almost identical to normal dragon movement, it mainly just gains angle momentum faster, so I suppose the two nice lines are to be expected. Plus they're mostly mirrored across all perch directions, since the end is (almost) one big circle. The positions are scarce towards the center of the sphere tho since the dragon is only moving like 0.25m/t, which is why they're hollow. It also gets the arch shape since once the dragon goes down below the target, it accelerates back up towards the target, essentially cutting them off below the target. This also causes them to bunch up near the bottom since every dragon that overshoots/gets an extra swoop ends up in that same area.Something that did surprise me though were the weird bunches throughout the arches. I put this video off for a while just because I couldn't figure out why they exist, but idk maybe it'll be obvious to someone else with better experience. My best guess is just that somehow the different swoops form it, but I don't know why that would be the case or how to test that. Or what else to test so idk.It also makes sense that certain seeds would have have some areas more common/scarce than others, since different seeds/terrain can have different height differences between perch node/target and the actual fountain/0,0 target. This can make it more common for the dragon to land during certain parts of a swoop, which determines which direction it'll be facing/approaching from. This height difference will also vaguely correspond to different areas on those arches too, cuz idk intuition? and dragon descends slower as it approaches its target ig?. Insta-perches are fun too since they're all approaching in basically the same way, at the same heights, even for multiple perch target heights.Either way fun stuff i suppose. I mentioned yaw and tickle spots here a little bit because it's what got me interested in this initially. I made a video on a perched arrow insta-kill a while back(youtu.be/OaIesw4T7YE), but it seemed that getting close to the tickle spot was more difficult than I anticipated. So I thought maybe if there was a strong enough pattern to this it might be possible to predict where it was. Whether or not you can is kinda eh, but at least I got some fun facts out of it.more speiciofioacially, the tickle spot is always 0.5m from the dragon position in the direction of the dragon's yaw(aka the center of the body hitbox). And since the dragon is usually flying towards its target, its yaw is usually facing towards the target as well. This leads to the tickle spots being much more condensed than the actual positions. Obviously if the dragon changes its yaw after perching that gets messed up, but I don't think current setups let it anyway. Yaw is also pretty fun because it lets you group the positions up by which way the dragon is facing, potentially letting you narrow down where the dragon position is even further. But again, probably not better than anything elseidk tht is all oki i hope ur world is spinning nicely todayalso i didn’t proof-read/watch any of this so if something is wrong it’s actually my brain’a fault for not reading my mind
Universal RTA Dragon Insta-Kill Setup Potential (Using Damage Knockback) Curcuit Store 2023-07-08 | Just a fun shower thought I had yesterday. I swear I'm not obsessed...Recently I've been going through a lot of different numbers to find the best places to stand rta to get as close to the dragon/tickle spot as possible, which is necessary to insta-kill it. If you're unfamiliar with the insta-kill, it's a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial TAS Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)RTA tests (youtu.be/czgSR9Z6U3M and youtu.be/MhQ3tQ5Av7I)Crazy doc in the video( docs.google.com/document/d/11qCI-BhZftr7tA1qvEp3VScY3ki2aVsC52eJy2Psp4Q ).But! Throughout all that, something that I hadn't considered was simply forcing the dragon get close to me instead. And it turns out that's pretty easy.The idea is rather simple. By default the dragon tries its best to fly straight towards its target. But it takes so long for it to adjust its velocity/angle that it just ends up looping back and forth a lot, missing the target by like 1m each time. So to get as close as possible, you need to adapt to each of the possible ways it can miss. However, by standing directly on the target and shooting the dragon as it's approaching you, you can adjust its velocity manually, forcing it to correct its path. This takes about 3 shots, and after that it'll pass over its target(and you) almost perfectly. I measured the paths(not points) a few times and they all came within like .005m. Which is pretty good, considering naturally they can vary up to like .1m iirc.This works because of a few things. Mainly, damage knockback actually halves all of an entity's velocity, and then adds like .4m/t in its opposite direction from you. This means that if you stand directly on the dragon's target(28.0x, -29.0z for front 7/8), every shot you do will not only reduce the dragon's velocity(which means it has less adjusting to do), but also add velocity in exactly the direction you want it to go(just opposite, but that doesn't matter). Note that this doesn't have anything to do with the arrow you shoot or its position/velocity, just where you're standing. So there's no rng there.I'm not sure if this is particularly helpful yet, but I do think it's neat. It works exactly the same for every seed, dragon height, node, node height, target height, or dragon angle. So it's a reaaally simple setup at least. It also forces the paths to converge much nicer than they ever would naturally, which is cool. The only big issue is that it messes with the exact positions of the dragon, which makes them harder to predict. Normally many different dragon angles/paths bunch together, creating hot-spots along the common paths where a random dragon is more likely to be. You can look at the heatmaps in the crazy doc above to see them better. Now these probably still exist here, although admittedly I've only tested this empirically, but its much harder to predict them since you'll probably shoot the dragon slightly differently each time. It also requires more time to setup, but actually getting into position is so much easier/simpler.Regardless, maybe if looked into more it could help create more consistent setups, even if it doesn't stay "completely universal" as a trade for better odds. It lets you knockback the dragon without worrying about messing up its path, which could help slow it down and make hits more likely. Or maybe you could position things so the dragon decelerates on its own because of target placement. Who knows!This whole video is kind of ?? embarrassing but oh well I'm not going to dwell on it. Nothing is real anyway
2.95 Second Dragon Kill TAS Curcuit Store 2023-07-04 | This is not optimized for a full end fight! I just wanted to see how fast I could get an enter end to dragon deaded split because I'm a huge dream fan and also thought a "3 second dragon kill" would be funny. Dragon literally only got to experience life for 39 ticks :(It's also a bit more of a look into boosting pearls with beds in an end fight. I made a video about this a while back(youtu.be/3VkJqZ-Ogf0 mind the cringe), but it was just too daunting with only the tools I had. That video was also more focused on a zero cycle, since I hadn't quite math'd out the insta-kill yet.And obligatory spiel: If you're unfamiliar with the insta-kill, it's a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)RTA tests if you're interested? (youtu.be/czgSR9Z6U3M and youtu.be/MhQ3tQ5Av7I)Originally I cited positioning and damage as the main obstacles here. I still haven't found a satisfactory way to avoid the damage, but I was at least able to get it to not kill me. There's still a bit to be desired from the bed position too, but it was good enough. Positioning the player was way more annoying since I needed to juggle building the setup and getting into position... And there's a whole range server/client angles that all overlap(placing blocks, client/server jumps, bed/pearl directions) which severely limits mobility. It's not /that/ precise, but I needed a pearl to land inside the pillar within a small y range so that I could instantly snap up on top with a damage velocity transfer thing, which is kinda hard when the pearl is going 3m/t. I complained about dragon positioning too, but it's not really an issue when I can just pearl anywhereTo blast the pearl I actually blow up 2 beds at once to basically double-boost the pearl, in kind of the same idea as a double place(youtu.be/ofY8THnZa0w). I just place the bed, then right click 3 times in a tick with another bed. First click blows up the bed, turning it to air, second click places another bed where the previous was(since air is replaceable), and third click blows up that bed. In theory this is infinitely repeatable with an infinite stack of beds(creative), but since you can only stack 1, 2 is as good as you can do. Offhand also doesn't work since the beds eat your use actions before it can ever test offhand or smthn iircI also tried to get some extra server velocity with a funny dance while waiting for the pearl, but it wasn't as effective as I hoped. The ground ticks just kill too much of your velocity. On the client I'm sprint jumping back and forth on the Z axis, but I'm actually turning in such a way that every jump is boosting me straight -X on the server. This is why the pearl had to clip me into the pillar, otherwise I'd bonk on the outside and kill the velocity. Definitely needs work, but that'll have to be a job for someone more powerful than II decided to leave the velocity/positions in the corner too, so ig if you're one of the 4 people who read these lemme know if that's a good idea. idk might be useful to see what's happening since server stuff is so silly(for you and future me).a:insta-kill angle code: pastebin.com/ZJsVHpFtbed pearl angle code: pastebin.com/a4BmhiGESeed: 10042737 (just wanted a tall tower, but y72 fountain was funny)Dragon Angle: 90.78664 (just random good one)inputs:yawr 134.9; pitchr 48.9; +back; +sprint; +right; +hotbar1; -hotbar1; +use; -useyawr 90; pitchr 25; -back; +use; -useyawr 94.8; pitchr -26.5; +forward; +jumpyawr 90; -jump; -right; +left; +hotbar2; -hotbar2; +use; -usepitchr 15; +hotbar3; -hotbar3; +use; -use-left; +hotbar4; -hotbar4; +use; -use; +use; -use; +use; -usepitchr 30; +hotbar1; -hotbar1; +use; -usewait 1pitch 15; +use; -usewait 1pitch 0; +use; -usewait 2pitch -30; +use; -use-forward+forward; +jump-jumpyawd 180yawr 180; +jumpyawr 90; -forward; +left; -jumpyawd 0yawr 0; +forward; -left; +jumpyawr 90; -forward; +right; -jumpyawd 180yawr 180; +forward; -right; +jumpyawr 90; -forward; +left; -jumpyawd 0yawr 0; +forward; -left; +jumpyawr 90; -forward; +right; -jumpyawr 90; -right; -sprintyawr 90; +forward; +sprint; +jumpyawr 34.9; -forward; -sprint; -jumpyawr 89.588829; pitchr -50.8; +forward; +sprint; +jump-forward; -sprint; -jump; +hotbar2; -hotbar2; +use; -use+hotbar5; -hotbar5; +usewait 17yawr 135; pitchr 90; -use; +forward; +left; +sprintwait 36yawr 90pitchr 52; -leftpitchr 17; +hotbar6; -hotbar6; +use; -use+use; -use
Optimizing the Dragon Death Animation Curcuit Store 2023-06-15 | Nothing particularly new or exciting, I just wanted an excuse to show more fun graphs because I'm addicted. I know nothing I say here makes any sense just look at the pretty graphs :3Basically just a video about how I went about optimizing the death animation for my last end fight TAS(youtu.be/QKWM3jTSGxg). I alluded to how you'd do this in the original insta-kill TAS(youtu.be/czgSR9Z6U3M), but just didn't have the stuff/motivation to make it possible at the time. Plus in the past I've just ignored the little fly down phase/animation altogether, and I can't imagine I'm the only one, so ig it's probably not a bad idea to make something on it. Frankly I was quite surprised by how much of a difference it made, especially considering the extra waiting time. I mean going in I kind of assumed that the best results would be those tighter spirals, but I didn't expect it to work so well/at all. Building a bridge is probably still optimal, but eehhhhh this is more fun for now.The basis of this video is an end fight TAS I made of a strat involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)RTA tests if you're interested? (youtu.be/czgSR9Z6U3M and youtu.be/MhQ3tQ5Av7I)The two TASes referenced: (youtu.be/czgSR9Z6U3M and youtu.be/QKWM3jTSGxg)To summarize/elaborate on this video though, the big time sink in the death animation is just waiting for the dragon to descend low enough to start its little light show. Specifically, it targets the bottom center of the highest block at 0,0(not counting certain blocks- usually those without collision) when it dies, and spirals towards those coords until it gets within 10m of it. But interestingly, the rate at which the dragon descends(or ascends) isn't static. Instead, its based on the dragon's vertical and horizontal distance to this target. The further away it is vertically, the faster it'll vertically accelerate towards it. But also, the further it away it is horizontally, the /slower/ it'll accelerate. The equation looks a little like vertical distance / horizontal distance / 100. This is actually the case for all dragon movement, but most of the time this acceleration is capped at +/-0.006 so it doesn't make much of a difference. But! During the dying animation phase thingie the cap is raised to +/-0.03, which makes quite the difference. And means if you're not staying super close to 0.5,0.5 laterally, you're probably not accelerating very optimally.And as it turns out, the best way to stay near 0.5,0.5 is to just do super tiny circles around it. This rarely happens in practice though because the dragon is always just barreling straight towards the target. So it just flies past the target and by the time it can turn around its already super far out, and doomed to repeat the process as it speeds back. So in order to get these tiny circles you need to get the dragon to be already turning by the time it passes the target, so it can carry that momentum through and complete the turn before it goes out too far. This then just feeds back in on itself as it continues to preserve that momentum. It's not completely clear to me what the exact requirements are to get this going, it's more of a spectrum of circles anyway, but I suspect that the following give the best chances:killing the dragon closer to 0,0killing the dragon when it's already turning/traveling perpendicularly from 0.5,0.5(?)knocking it off its path with knockbackkilling the dragon when it has less speed(goes along with the last 2)or, some combination of all of the above, which is what it looks like ended up being the solution here.Anyway yeaazzzz that's that. I'd share the code to get where I got but I wrote over it a bunch making the graphs so oops. Basically just iterated through a bunch of differt insta-kill arrow shots at different angles at different amounts of time into the fight for a bunch of different starting yaws/first node heights, and then timed how long the fight lasted until it reached the center. I don't think the node heights made like any difference at all though. and tbh all the angles were fairly lenient too, within like 5-10 degrees. If you want the exact numbers I put them in the actual TAS's video(youtu.be/QKWM3jTSGxg).mmm this description is a mess but I don't feel like organizing it better. Consider it an abstract artistic reading comprehension test
23.5 Second End Fight TAS (Dragon Insta-Kill) Curcuit Store 2023-06-13 | This is a 5.0 second improvement over my previous end fight TAS of the same strat(youtu.be/rVKx_EugxAg). If you're unfamiliar with the insta-kill, it's a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)RTA tests if you're interested? (youtu.be/czgSR9Z6U3M and youtu.be/MhQ3tQ5Av7I)Now, I had mentioned in the original insta-kill TAS video(youtu.be/rVKx_EugxAg) that almost all of the TAS was spent waiting for the death animations. The biggest culprit being the long sequence of the dragon flying down to 0,0 in order to start its fun little light show. So, this TAS is my best attempt to combat that(without building a huge bridge out to 0,0, anyway).If you're observant, you might notice that the dragon dies a whole 1.5 seconds slower here than in the first TAS. This is because instead of just trying to kill the dragon as soon as possible, I spend a little extra time in order to better "manipulate" the path the dragon will take after it dies.As I mentioned, the big time sink is just waiting for the dragon to descend all the way down to the block at 0,0. But interestingly, the dragon doesn't just descend downwards at a fixed rate. Instead, it actually accelerates downwards /faster/ the closer it is to its target laterally(0.5,0.5). But under most circumstances the dragon will only briefly get close to that target as it occasionally swoops past it, meaning it's rarely descending at max speed(see the original TAS for what this looks like, idk how to describe it).But! In this TAS I kill the dragon in such a way so that it gets stuck doing super small spirals around its target instead of those huge loops across the island. This keeps the dragon close enough to more or less always descend as fast as possible, which apparently is enough to save 5 seconds, even though I kill the dragon 1.5 seconds later.I don't have concrete proof as to why these spirals/loops appear, but I assume its just a result of how fast the dragon can turn. Presumably, normally the dragon just speeds past its target, so by the time it can turn around its already wayyy far out, and doomed to repeat the process as it speeds back. But here I kill the dragon such that I push it off of its course, so by the time it passes its target it's already turning with quite a bit of "angular momentum" or whatever. This gives it enough of a boost so that it can complete the full loop while still near the target, allowing it to continue turning around and around it, conserving all that momentum. Or something like that idk lolAnyway the other elephant in the room is the weird pearl I do to get down after killing the dragon. Except I don't actually do it to get down, it's actually just to get the right amount of knockback on the dragon when I shoot and kill it. In order to get those nice speedy spirals, I need the arrow that kills the dragon to knockback the dragon in a fairly specific direction. But to make a long story short, the movement of the dragon makes most angles impossible without moving at infeasible speeds(I say, while accelerating an arrow to 5000m/s).But! All hope is not lost because for whatever reason the knockback an arrow does isn't dependent on the arrow at all. Instead, it's decided based on the difference between the shooter and shootee's position when the arrow hits(aka the player and dragon here). So by timing a pearl to land right as I shoot the arrow, I can change where I am relative to the dragon, thus changing the direction of the knockback to anything I want. You can kinda see this in action as I'm running back to the fountain.But yeah, that's all! I hope to make a little video on the optimizations in a bit, but I wanted to upload this first.stuffz:dragon angle: 344.67056dragon first node height: 10.12712seed: 19None of those are at all specific, just what workedaand the inputs since they're also short:yawr 90; pitchr -14.650108; +hotbar1; -hotbar1; +forward; +sprint; +jump;+use; -use; -sprint; -forward; -jump;wait 18;+jump;-jump;wait 5;yawd 90; pitchd -72.03987;yawr 90; pitchr -72.03987;+forward; +sprint; +jump;+use; -use; -sprint; -forward; -jump;wait 16yawd 41; pitchd -42;yawr 41; pitchr -42;+use; -use;wait 3yawd 90; pitchd 15;yawr 90; pitchr 15; +jump; +forward;-jump; -forward;wait 19yawd 30.900082;yawr 30.900082; yawd 76.146439; pitchd -55.800522;yawr 76.146439; pitchr -55.800522; +jump; +forward; +sprint;-jump; -forward; -sprint; +use; -use; pitchd 45; yawd 135;yawr 135; pitchr 45; +hotbar2; -hotbar2; +use;wait 28-use;
37.7 Second End Fight (RTA Dragon Insta-Kill) Curcuit Store 2023-06-10 | (igt is 37.6 cuz turns out 1000m/t velocity is laggy)Last video I showed myself attempting a dragon insta-kill RTA(youtu.be/czgSR9Z6U3M). Basically a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)However, my last video wasn't particularly fast. So I looked back at my graphs and chose some new points to hit, about two swings above those first ones. Every other swing the dragon does is kinda similar tho, so it's pretty much the same thing from before, just with less time to go further up. I also wrote a crude thing to actually find the points to stand at, so ig there's that. I'll give the points in a sec, but if you want to try this I'd suggest using a real dragon fight/a better map. idk if the map I'm using is the standard or even up to date, but there's a few miiiinor discrepancies that maybe don't matter for zero cycle, but that I tried to correct here cuz I'm paranoid1: the map dragon spawns immediately. This prolly shouldn't happen though, unless you're running glitched, or somehow enter end in like 15 seconds. So I made it offset by 20 ticks, which is what happens normally (and makes it easier lol). 2: they made map dragon spawn at 0.5 128 0.5 instead of 0.0 128 0.0 for whatever reason. Not a huge difference since the dragon will try to correct itself, but it made my numbers silly so I changed it. Technically it also only spawns dragons at integer degree yaws, which can make super specific coords better/worse, but I was too lazy to change that. (+ my 1 test said it shouldn't really matter and I went with it, esp w/ human error)Anyway! the numbers. The dragon swoops by at ~y110, so I build up to just below there. And if the dragon was coming in from the x, I would go to 27.9375 -27.125, or 26.125 -28.875 for the Z. These aren't the /most/ optimal (26.132 -28.879 is good for z dragon, idr for x), but they lined up with the block pixels and it doesn't really make a difference(I'm just selfish). Not like I had time to position myself anyway, which I can really only do while building up. Combining air sneak acceleration with ground friction is super nice for small movements ig, so I just (try to) do a tiny input right before landing while pillaring.If you can hit those exact positions and shoot your arrow perfectly, my dubious math says you should hit the dragon about 2.5% of the time. idk how that translates into real attempts, but it def took me than 40 tries(another like 6 hours- but I also miss like 50% of my bridges/pearls). I feel like the more velocity you have the harder it is to hit the dragon, but idk if that's true. My only explanation would be that I don't shoot the arrow at the right height, and so the stretching out of the vertical velocity over hundreds of blocks is tricking me. Since the dragon gives you a fair amount of upwards velocity(like 1.5m/t), if you're too low then at lower speeds then the arrows might be be able to make up some height by the time they reach the tail/wing hitboxes. But then at high speeds that 1.5m gets stretched out across 400+m, so it only raises like .01m by the time it passes them. If this is true then building up higher/the little jump I do/unsneaking might be important, but also maybe I made it all up.otherwise yeaaaaa. tbh the 2.5% number scares me cuz it like. borders on feasible. Obviously the big obstacle is just the speed of the dragon, which is just too fast to reliably line up with your own position. Frankly in isolation isn't even hard to solve, I just can't figure out how to make it work. It's literally just relative too so you could just run along with the dragon you to increase your chance. Or even just punch the dragon! which would basically just zero out/reverse its velocity(normal punch would be like .9 / 2 - .4, sprint punch would be like (.9 / 2 - .4) / 2 - .5). Or you could even catch the dragon on one of its turns, since it'll slow to like 1/3 speed there. The only issue is that you only have abt 10 ticks to reach the tickle spot after entering the knockback hitbox, else your damage tick runs out and you get launched. and if you slow down the dragon you increase the time it takes to get there- making the timing either super tight or impossible. Which is why I propose we accept crafterdark owns src into the rules and allow peaceful mode. Or just find a better way to stop yourself from getting launched. Or just get a power 5 bow. idk. gneurshk. maybe worth noting that dragon won't give knockback if /it's/ in a damage tick, but that still doesn't give enough time afaik.
Attempting an RTA Dragon Insta-Kill Curcuit Store 2023-06-05 | More of just a test than anything. A proof of concept if you will. I couldn't get it any faster than a meh zero cycle, but then again I only got it once, and only went for a super safe version. Getting it at all is good enough for me and I'm kinda over it anyway. I got pretty decent at it by the end though, I was getting enough velocity like every 20 minutes or so in the last hour.Context: This is a crude RTA version of a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)I spent the last few days reading through all the dragon movement and stuff in hopes of improving my last TAS of this trick(youtu.be/rVKx_EugxAg). But while doing so I got curious what a graph of a whole bunch of dragon paths would look like. So I simulated about 100k dragon paths up to their first target. And then I just graphed the "tickle spot" for each tick of them (idk what to call it and "tickle spot" is objectively funny. "Belly button" would be too tbf).And it's very cool, I tried to show some of them in the beginning, but what I noticed was that quite often all of the paths converge nicely into a pretty small thin line. Now previously I had considered any version of this trick "impossible" RTA because the dragon path would just be too random or disjointed from each other to predict with enough precision(you need to be within 0.02m to even get a chance). But during these convergences this prediction isn't quite true, and it almost looked feasible. Sadly the dragon still moves like 1m per tick, so you can't know /where/ on this convergence line the dragon is(since initial angle/speed from target renders its exact position/speed unknown). But you still know it's on the line, so as long as you line yourself up on it there's at least a chance you both collide perfectly. And that's about all I considered before spending 6 hours of my life doing this this morning. I throw a pearl right before the dragon hits me so that I don't get a velocity transfer of the dragon knockback, so I don't get launched, but other than that it's just shoot and arrow right as you pass over the spot. There's still a looaaad of rng in getting the arrow to hit one of the dragon's hitboxes, but I think you can hit any of the wings/neck/tails if you play your cards right(unlike the TAS where you can only hit the neck). I still lost like 7 400+ velocity arrows to that before this though so it's still a pain. At least that I noticed, and who know how many I just released a tick early/lateI can't really give you the setups I used since it was just kinda intuition, but initially I was just going up to either 29.89 x ~-28.9 z when the dragon was coming at me towards -Z(hence Z not being exact), or to ~27.8 x -30.885 z when it was coming at me towards -X(hence X not being exact). I just kinda went with how it felt by the end though.I doubt this is viable for any sort of runs as is, but you could definitely get kinda good at it. I was surprised by how often I was getting close, and I've never even done a zero cycle before, so idk how actual speedrunners would do. And there's definitely faster setups too, you can see that I'm just kinda waiting around for 10 seconds sometimes, which would be like what a 35 second end fight rta? This map feels inaccurate on dragon spawn times though so idk how that would play in. Or maybe I'm just being silly. idk there were other things I wanted to say but I forgot them and I have to go be productive now oops.Oh yeah! I realized you can throw a pearl to catch yourself with this pretty easily. Since you do get hit by the dragon almost at the end of the trick here, and you're only inside it for a little bit, your Y velocity should be mostly synced on the client and server, so you shouldn't fall faster than a pearl. (since it won't be over 3.9 and get capped)
Dragon Insta-Kill TAS | 28.5 Curcuit Store 2023-05-31 | New World Record for most unsatisfying TAS ever. Also saves 0.55 seconds over my previous fastest end fight TAS(youtu.be/l8wD4BQWu2I), which I think I finished exactly a year ago. There's loads of room for improvement, I just wanted to try getting a full run of this strat, and it worked pretty nicely. Also an excuse to use this title once because it's funny and im too quirky to name it "end fight TAS" just yet.This utilizes a trick involving accelerating an arrow to extreme speeds using an odd quirk of dragon knockback. And since arrows deal damage proportional to their speed, this can be used to kill the dragon instantly. If you want more information on how it works/how I make it work, I'd suggest these videos:Original Dragon Knockback Exploration: (youtu.be/DBYgB2sESmM)Initial Insta-Kill Test: (youtu.be/ON8c6IhE7-E)Lamer Insta-Kill Test with Misc Info: (youtu.be/OaIesw4T7YE)info that may aid me and me only because i'm selfish:dragon angle: 90.78664 (not really important just first good angle i got- and tbh even a really bad one doesn't lose time)seed: 19 (also not really important- I'd wager better terrain could save like 3 seconds easily but idk how to seedfind)This is also probably the fastest dragon kill split? Dragon is dead 4.5 seconds after entering the end, which is honestly laughable. And also means 85% of this TAS is just waiting for the dragon animation. I tried for a few hours to cut down the flying to 0,0 animation, but I couldn't get anything and I couldn't think of anything else besides trying random knockbacks, which would be impossible to do by hand. So instead I propose we pivot all computing power in the world towards finding a dragon zip at 0.5,0.5 because that is surely feasible. Unfortunately I imagine it's still optimal to just build a huge bridge :broken_hea. But I'm putting that off because I still want to investigate using the dragon knockback to build it super fast for the elusive sub 20 end fight, and that sounds nightmarish.Also as an update I realized that the head(neck) is basically the only hitbox we can shoot at from this, which makes it more just a single slice of a .02m circle we're aiming for. The other hitboxes are just too high to reach without either an insane amount of upwards velocity(since it gets magnified over like 500 blocks), or doing a funky jump(slow). I'm also using a pretty short tower for this since I don't have to build up to the dragon for this, just pearl into it. And doing two medium yum pearls are better than an huge one and a small one because idk math.I also did some fun pearl things such as:You can land and throw pearls faster by jumping right before they hit the ground so that you're already falling pretty fast when you teleport.You can get up onto the pillar by pearling into the space 0.4-.0.58 on the top block and then jumping as soon as you pearl. This triggers a step up onto the top of the block and kills your momentum, so you can jump again after a tick.Also! if you want to somehow get my jank working and want to give things a shot yourself(omg get it), here's the code I used(just poorly written chatgpt java good luck):Instakillinator: pastebin.com/ZJsVHpFtBonus Pitch Thing: pastebin.com/cWYcFtCjand here's the inputs since it's so short lol:yawr 90; pitchr -14.650108; +hotbar1; -hotbar1; +forward; +sprint; +jump;+use; -use; -sprint; -forward; -jump;wait 18;+jump;-jump;wait 6;pitchd -72.03987;pitchr -72.03987; +forward; +sprint; +jump;+use; -use; -sprint; -forward; -jump;wait 23pitchd 15;pitchr 15; +jump; +forward; yawd 154.3;yawr 154.3; -jump; -forward; yawd 178.55; pitchd -73.2;yawr 178.55; pitchr -73.2; +jump; +forward; +sprint;-jump; -forward; -sprint; +use; -use; yawd 90; pitchd 45;yawr 90; pitchr 45; +hotbar2; -hotbar2; +use;wait 23-use;wait 28;+hotbar1; -hotbar1; +use; -use;mmmmmmmmmmmmmmmm yep
Dragon Insta-Kill w/ Perch Example Curcuit Store 2023-05-30 | I didn't expect people to be so fascinated with the actual insta-kill(youtu.be/ON8c6IhE7-E), the sprint jump desync for the pearl was way cooler imo. So here's a way worse version as an excuse to rant for another 5k charactersThe idea is the same as before, just using a perch instead. So no pearling, and it's a lot more lenient position-wise. Normally when the dragon gives knockback, it also damages the entity. This is annoying because damage triggers a transfer of your server velocity to the client, and causes you to go flying. (You don't get the full velocity tho, since the transfer is capped it at 3.9m/t in each axis :broken_hea) But! When it’s perched it doesn’t damage you, which means you can just sit near the spot for as long as you want without being launched. (I don't get launched in the original video because the pearl damages me before I get the knockback.) So you just have a bunch of time to position yourself and build up speed before shooting.You can kinda use the dragon's hitbox to line yourself up, but the dragon's position can be slightly desynced so idk how useful it is. And even though you still need 400-450m/t for the arrow, you don't need to be within .02m this time since here you can stand still for more than 1 tick. Notably the upwards velocity ensures you're almost always in the air on the server, so you conserve like 90% of your horizontal speed tick to tick, letting you accumulate a whole bunch before it asymptotes. Specifically, if you're in both knockback hitboxes, it caps at 80.8889/d, where d is your lateral distance to the point. So in theory you only have to be within .1-.2m of the spot. But alas, as with anything there arises qualms. And if you watch my server velocity in the upper left, you'll notice that it doesn't just rise up and plateau. Instead it resets and fluctuates quite a bit. And I assume this is the result of two forces working against you:Movement Packets. Every so often the client sends its position to the server using a "movement packet(?)." This position then becomes your server position, which I'll touch on in a bit. But, it only does this when either:you move more than 0.03m from the last position you sent, orit's been 20+ ticks since the last time you sent a position.Now, it also sends a movement packet when you change your rotation. These ones don't update your server position, and neither directly affect velocity, but they do have one thing in common: they both update whether you're "on the ground" on the server for a tick. So earlier I said you're almost always in the air, which means you conserve ~90% of your horizontal speed. But if you're on the ground you only conserve ~55%. And since we're just sitting on the fountain(on the ground), whenever one of these occur you'll lose a bunch of speed. This doesn't affect vertical velocity tho, so if you watch my vertical velocity it does the expected plateauing(which peaks at 0.3136/.02).Collision. Despite not doing much visually, server velocity still moves you around on the server. You can see this from my server position in the top left. However, it's important to note that your server position is sort of "locked" in whatever position the client last sent, so the velocity doesn't accumulate tick to tick. Instead every tick it sorta gets reset to the transferred position, and then offset by whatever your server velocity is. Collision still applies during this offset though, and if it hits a wall, you will lose your velocity in that axis. This was fine in the first test since I was above all the terrain, but down on the island chances are you'll snag on terrain/pillars, even if they're reaaally far away. As a basic rundown, collision gets checked in each axis individually in the order of Y, X, Z if X is higher than Z, or Y, Z, X if not. So here if you try using X as your major axis you'll always bonk on the west/east pillars, killing your x velocity once it gets over like 30m/t. The same could happen if you were near terrain, but since Y comes first it won't necessarily kill your velocity if your Y can offset you above the terrain first. So like if you were to block yourself in on all sides you could still retain speed if your Y velocity is higher than the walls. And technically even if you blocked the top an x surf could build up a bunch on the x axisOnce you do get the right velocity, the big challenge is hitting the dragon. Like the original test you're inside the dragon's body hitbox, which renders it intangible. So you still have to aim for a different hitbox. This is wayyy easier tho since the target is larger and you have time. The real issue is that the dragon is perched, and when the dragon is perched it ignores all arrow damage, including those flying at mach 20. So I have to wait until right as the dragon leaves its perch, and then shoot the arrow. And since the dragon is no longer perched it'll take the damage, and as a bonus fling you into outer space
(TAS) Diversity 3 Beanstalk Parkour | 1:18.30 Curcuit Store 2023-05-25 | month ago me: "if I were to actually make a whole TAS of this map I'd either have to run a finer search or do it myself idk(which I will not be doing)."lolNot the whole map obv but yeah. This is a remake of my first TAS of this area(youtu.be/Aq_4iSiQ62E). Again huge thanks to my friend for most of the movement(youtu.be/9OPPzJHz6AU). The original TAS included the top of the stalk achievement because I was curious whether la machine could climb the whole stalk at once, and turns out it could! But since then I did the other parkour areas, and decided I wanted to do this one without the achievement(since the other achievement is just rng).However I've also gotten a bit better at using la machine to do things, and also probably just better at TASing these in general. So even though the first part is exactly the same, I was able to save about 2.5 seconds getting up past the clouds into the second room. Which is remarkably considering it's mostly a jump autoscroller. Plus it took way less time.And speaking of time I did TAS the water by hand. Which is a lot of fun when you have to replay the first 50 seconds just to see if the one tick of inputs you wrote did what you wanted :dance. Even then there's definitely time to be saved there, again I really need to get the thing working with swimming. I envision it teaching many dark magics.There is some goofy lilypad tech like before, just wayyyyy more efficiently used. It's honestly baffling that it managed to hit some of them. If you want an detailed explanation I think I have one in the original TAS, but otherwise basically whenever you jump from a block to lilypad you save one tick over jumping lilypad to block/lilypad.Hours of work: 4Hours of computation: 11Map: planetminecraft.com/project/diversity-3Music: stall - c418
Explosion Centers Curcuit Store 2023-05-23 | After messing with explosions a bit I realized that there's almost no consistency between different explosion sources and where they spawn their explosions. I also couldn't find a good resource explaining exactly /how/ they differ, so I tried to compile a few and show them off. If I spelled something wrong or missed something I take no responsibility sorry. I also have no idea how to communicate why this point is important or what to call it because I have no social skills- so idk this is all you're getting, figure it out yourself lol. Smthn smthn break more blocks, get more velocity, the world is your oyster.Everything was measured in 1.16.1, and either verified in-game or by my past experiences (very trustworthy I know).Information from the video:Beds: Center of the pillow block.Creepers: Exact position.Fireballs: Exact position.Respawn Anchor: Center of the block.TNT: 0.06125m above exact position.TNT Minecart: Exact position.Wither Spawn: 2.975m above exact position(eye-level).Wither Skull: Exact position.End Crystals: Exact position.Pillar Explosions while Respawning Dragon: 1.0m below the end crystal, or the center bottom of where the bedrock block spawns. This does not mean the explosion is absorbed tho you have been warnedTo be clear, by exact position I mean the entity's actual position. Which I'm pretty sure is just always the bottom center of their hitbox.Music: Wait - c418
(TAS) Diversity 3 Pirate Parkour | 33.6 Curcuit Store 2023-05-20 | This area is kind of a mess but also pretty trivial ig. I forgoed 100%ing it here(spoiler: you have to punch a guy off the boat. Which technically can just happen on its own but :sob:) because it's just rng so rip but oh well. Again huge thanks to my minecraft roomba (youtu.be/9OPPzJHz6AU) for most of the movement. I TAS'd the part from entering the area to jumping into the water, but the rest is mostly its doing. You actually get sent to a weird loading room to spawn the villagers before entering the main map, where you just fall down onto a pressure plate. But there's also a button in the room for whatever reason(you can avoid the pressure plate but not like you can't just step back on it?), which you can press that has the same function. So instead of waiting to fall I just press that.The only cool thing in this TAS is the ladder fence jump at 0:33. It's just the walk off a ladder and jump to get extra velocity thing, but doing it back to back on the fence looks funny. I guess there's some fun x surfs on the ladders too but idk. Amen for the ladders though for making the server damage syncing almost painless.Maybe it's worth mentioning, but when you get teleported somewhere it zeros out your velocity and stuff. However, it doesn't clear out whether you're on the ground(which is like pseudo delayed by a tick anyway). So in the previous TASes I would make sure to enter the teleporter on the ground so that it caries over. Otherwise you end up in the air the tick after you get teleported, and because of your velocity being zeroed out you stay in the air for an extra 2 ticks after that(your y velocity has to be negative to be on the ground, and its decided after movement). That's all to say it's very cringe and it means you end up with air acceleration from 0 velocity for like 3 ticks, which is quite slow, unless you carry in being on the ground which lets you sprint jump immediately. Anyway basically that goofy loading room makes this impossible(since it puts you in the air for a tick), so I'm doomed to just walk slowly off the edge. I can bring sprint air movement into the main room by sprinting in that little room, since that's also not cleared and is delayed by a tick, but the positioning doesn't let it save any time. I suffer the same fate while getting teleported from the water to the deck too, since you're just in water. You can't really get sprint air speed without initiating swimming afaik, but it doesn't explicitly save any time anyway.Also I fixed a bunch of dumb mistakes in my mess of a program so maybe it'll be better now who knows. Nothing tragic just a couple things slowing it down and wonky float things. Also fun fact I had to record this(which takes like 10 minutes at 1tps) twice because the first time I accidentally recorded my 5 tabs of dinky dinky dinky cat in the background. At least maybe that would have made it at least a bit entertaining thoughHours of work: 3Hours of computation: 5Map: planetminecraft.com/project/diversity-3Music: Nuance 1 - c418
Scaffolding Portal (but 10 ticks) Curcuit Store 2023-05-17 | Welcome back to episode 2 of random youtube videos nerd-sniping me. Except none of them are particularly nerdy so it's more just a homicide.In today's episode I saw a really silly video of someone building a nether portal in 13 ticks using scaffolding(youtu.be/B6FnM7Xpn0M). Because yes I do regularly search "minecraft tas" and sort by new, it's great funAnyway this intrigued me because my fastest nether portal is still 14 ticks using a fire damage boost/double place thingie(youtu.be/hoAiB-5JEi4). That fancy scaffolding portal also uses fancy double placing(youtu.be/ofY8THnZa0w), but saves a tick by using the glorious properties of scaffolding- specifically the fact that you can place a whole row/stack of them in 1 tick. This lets you place multiple corners at once, and makes it super easy to reach the top of the frame. I can't imagine getting scaffolding is ever practical in a real run, but it's still really funny and I love it for that.But! Something sneaky that I don't think the original video realized is that scaffolding itself is an insta-mine block! Which means you can double place with them in practically the same way you can fire. If you're curious about how/why, I go more in-depth about it in the original double place video(youtu.be/ofY8THnZa0w). I more or less just incorporated that into the portal, and this is what I came up with. Plus 10 ticks is very silly because it actually takes /11/ ticks to just build a portal against a wall. Even though you literally only have to place 11 blocks for that.Sidenote I do use some goofy server stuff in order to double place in the middle of the stack. Technically you could do it in 11 ticks without that, but it's basically the same concept as a lagged pearl(youtu.be/xGcWIuqiARY). You just break a scaffolding and double place to above it, and if the server gods are in your favor the block above will break in time for the full double place.Sidenote part 2: I'm pretty sure this could be 9 ticks if you start the timer already sneaking. The vertical scaffolding by sneaking mechanic ????? is delayed by one tick, and I couldn't figure out how to route around it even after a couple hours of thinking so idk. I could've incorporated it here anyway with 1 tick of idling but the movement for it would be soooo gross and meh. I swear you can save at least another tick on this though, just might need to break out my pathfinding friend for it... (no promises, but a video like my original portal one(youtu.be/HEH7rW1-ly8) would be neat)Until then though the inputs aren't too scary so I won't bother explaining them all. Here they all are though if you want em:(you'd have to jump through 493 hoops to execute them yourself so more just as reference)yawr 270; pitchr 60; +swaphand; -swaphand; +hotbar3; -hotbar3; +use; +use; -use; +sneak; +jump; pitchd 20;yawr 270; pitchr 20; +use; +use; +use; +use; -use; -jump; -sneak; pitchd -60;yawr 270; pitchr -60; +hotbar2; -hotbar2; +use; -use; pitchd -30;yawr 270; pitchr -30; +attack; -attack; +use; -use; pitchd 20;yawr 270; pitchr 20; +attack; -attack; +use; +use; -use; pitchd 75.5;yawr 270; pitchr 75.5; +attack; -attack; +use; +use; -use; +sneak; yawd 90; pitchd 70;yawr 90; pitchr 70; +hotbar3; -hotbar3; +use; +use; +use; +use; -use; -sneak; yawd 270; pitchd -75;yawr 270; pitchr -75; +hotbar2; -hotbar2; +use; -use; yawd 90; pitchd 30;yawr 90; pitchr 30; +attack; -attack; +use; +use; -use; pitchd -60;yawr 90; pitchr -60; +hotbar2; -hotbar2; +attack; -attack; +use; +use; -use; yawd 180; pitchd 5;
(TAS) Diversity 3 City Parkour | 27.15 Curcuit Store 2023-05-16 | AI TASers after a long day of typing prompts. Making this frazzled my brain for some reason so I don't have too much to comment on. Again credit to my pathfinding friend for doing most of the movement(youtu.be/9OPPzJHz6AU). It didn't do much that I didn't expect, but god bless for not making me have to type the inputs. Thankfully this area is short im medium medium yum, and now there's only 2 areas left wowza(except I'd prolly redo the beanstalk to not be 100% cuz 100% is just rng for the other area :/).I didn't have it explore too much, I just immediately shoehorned it into jumping off the building towards the golden thing until something happened. I even gave it a special 45 strafe button to make sure it could squeeze as much distance as possible. I also forbid it from going too far to the left on the second building because I didn't want the levitation track thingies over there to distract it. tbh I expected it to jump from the top of the stone slabs, but it ended up deciding to go underneath. Which, I did consider, I just didn't expect it to be possible, which I suppose is where this thing shines. It doesn't really care what /seems/ possible, it just throws spaghetti at the wall until the horse come home to roost. I mean even knowing that it is possible I still have trouble pulling it off, but maybe that's a skill issue more than a big tech advantage. Oh well.Again same deal with the resyncing on damage, except the jumps were so long that it didn't differ too much from the approximation. I also TAS'd the swimming on my own cuz I'm terrified of implementing that. And I know you can tell I lose some ticks there but idk free time save for my future rivals. I just made my friend find the fastest way to the water with a rough account for about how long it would take to swim up to the top from there, which probably should have been more robust.I really should get it working with water tho because there's a lot of weird movement things you can do with water, and I'm too stupid to understand how to use them to my advantage. The only thing holding me back I guess is dumb server hitbox/pose stuff lagging a tick behind.Hours of work: 6Hours of computation 10(half were kinda wasted though)Map: planetminecraft.com/project/diversity-3Music: Mall - c418
(TAS) Diversity 3 Liberty Parkour | 1:08.05 Curcuit Store 2023-05-12 | Small improvement over my first TAS of this area (youtu.be/eRtH0Hvjb74). There I had to play through a bunch of the first room to get into a good spot for the fake freefall(youtu.be/-EPkAJY9uv8) in order to skip the rest of the room. But since then I figured out how to do it without a wall(youtu.be/XjD4OojWfiQ), which opened up a few other spots that could work. Notably, the very first ledge above the first slime piston thing.While it is possible to get enough upwards velocity using that first slime piston and a wall fake freefall, the positioning is so limiting that it's pretty much useless. If you can even make it to the slime you just bonk on the platform above you, and even if you didn't you can't make it all the way to the top optimally because the horizontal distance is way too much.But, now that I can do the fallin' right at the edge, there's way more freedom in the positioning. Mainly, I can reach the corner of the slime I used in this video, instead of being restricted to the opposite one with the wall freefalls. The platform above is still really annoying, but you can just narrowly avoid it by going outwards a bit more. From there you can just barely make it to the end of the room. I'm only human but I think I made it by like 0.005m here.Sobbing at 3 days ago me saying that TASing the fake fallin in the first TAS was difficult though, cuz this one was like 10x harder. Not using a wall makes the movements waayy more precise, and trying to do it fast doesn't help. Not to mention the horror that is the piston slime thing. It starts transitioning right about when I need to jump off and hit it on the server, and if if you hit it during this it just kills your velocity instead of reversing it. I think I had to start the fake freefallin as soon as possible or else everything goes to shambles, which tbf going as fast as possible should be the goal anyway but it's annoying. You basically have to land in the air with enough velocity to reverse it back onto the ledge the tick later without moving 0.03m. I didn't even realize you could land in the air until I did this part! It makes sense though since your Y collision comes first, so as long as you start above the ledge and your x/z velocity puts you over it you just kinda chill. Trying to get that within like .03m and within the right velocity is a headache though. Anyway the rest of the TAS is pretty much the same. I reused the same inputs for the first bit and the part to the next slime piston, but since its cycles were all different I ended up recomputing the rest of the end climbing. It does it in the same amount of time, just with some different routes. Which makes sense, but it's neat to see. There might be a better way to get the hit off the second slime piston but I used all my energy on the first part of this TAS and I'm not sure how to go about optimizing that anyway. Fun TAS only x-surf tho. Speaking of which I was going to make a video on that but then got distracted by writing a 10 page doc(which is only like 25% of what I wanted to say) on the horror that is minecraft cos/sin(which causes the x surf) and then got distracted by la machine oops.Hours of work: 8Hours of computation: 7(+ whatever from the original)Map: planetminecraft.com/project/diversity-3Music: mellohi - c418
Wall-less Fake Freefall Curcuit Store 2023-05-10 | This is probably the most versatile adaptation possible of the artificial/fake freefall trick I showed recently(youtu.be/-EPkAJY9uv8), which allows you to gain a bunch of negative y velocity on the server without actually falling at all on the client. If you're looking for the exact movements I put them at the bottom, but otherwise here's a brief run-down of the trick:Every so often the client sends its current position to the server, which it takes note of, and then constantly sets your server position to until it gets a new one. So if we send it a position up in the air, then the server position will be "locked" there, constantly falling/gaining velocity, until it gets updated with a new position. Simple enough, but the catch is the client only sends a new position when either:you've moved more than 0.03m from the last position you sent,or, it's been 20 or more ticks since the last time you sent a position.So, if you combine these mechanics with the fact that you can walk off an edge for a tick and then walk right back a tick later(due to collision order/step logic), you might be able to guess what's happening.First you walk off the edge for a tick, making sure you either move more than 0.03m, or time it to be right when that 20 tick timer is up. This guarantees you send your new position to the server that tick. And then you just need to walk back onto the ledge, making sure not to move more than 0.03m from the position you just sent, so it doesn't update again. Then you can just wait for the velocity to accumulate, making sure to repeat the process every so often so the 20 tick timer doesn't update your server position back onto the ledge(which kills the velocity). Then you can do whatever you want with your new velocity. Here I just transfer it to the client using damage, because idk.Of course that's easier said than done. The hardest part by far though is making those super small 0.03m movements. It doesn't matter for the first tick when we walk off the ledge, since we want our position to update then, but after that you can't go more than 0.03m from there(which indirectly means you can't walk more than 0.03m off of the ledge for that first tick). In the initial videos (youtu.be/UUieYw5wPQs and youtu.be/-EPkAJY9uv8) I dealt with this using a wall, since I could just angle myself towards the wall to kill any momentum perpendicular to it, leaving only the small bit on the other axis. I wasn't a fan of that restriction though, because I can never be satisfied and god is cruel. Instead, I wanted a version I could do on any ledge, given there's enough room underneath it.This is rather difficult because all of your normal movement options add like .1m/t to your velocity, which is wayyy more than our limit of 0.03m. The only exception(disregarding eating/shields/etc cuz that's also a lame restriction) is sneaking, which only adds like 0.0295m/t, assuming no sprinting/45 strafe. But ironically that speed effect is delayed by one tick, while the ledge grabbing isn't. And since we need to walk off a ledge the tick before, it's essentially useless(for now). That information pretty much stumped me, and maybe the answer is pretty obvious to everyone else, but oh well spoiler alert I figured it out anyway(rip the detailed explanation cuz youtube is 2 coward 2 let me write more than 5k characters):Tick 0: Align yourself on an edge. Crouching is probably easiest, but keep in mind the coarseness stuff might stop you like 0.05m from the edge instead of near it. If so idk try a better angle that's a whole other can of worms.Tick 1: Sprint off the edge. You want to be facing almost parallel to the edge(I use 1 degree off here). This puts you off the edge by about 0.001m.Tick 2: Walk backwards onto the ledge. This should be at about the same angle you ran off the edge with, but angled a bit back towards the ledge. This overpowers your remaining sprint velocity just enough to move you about 0.0285m back onto the ledge, leaving you with ~0.015m velocity going into the next tick.Tick 3: Sneak and walk towards the edge. You want to be almost perpendicular to it, but angled a bit towards the direction you sprinted in to cancel that extra 0.015 of extra velocity you still had. I think I used 9 degrees off perpendicular here. This gives you a bunch of velocity towards the edge, but the sneaking prevents it from moving you so it's fine.Tick 4-idk: You can stop moving, but stay sneaking until your velocity off of the edge dissipates. Or get fancy idc. Either way you win! You have to repeat the process at least every 20 ticks(starting from tick 1) to stop your position from accidentally updating onto the ledge, but you can also just do it as much as you like if you want. Which is neat because it does scooch you about 0.1m along the ledge each time. Either way you'll probably have to tweak angles to get a perfect loop cuz I'm too lazy to find the perfect angles for you sry.
(TAS) Diversity 3 Liberty Parkour | 1:11.3 Curcuit Store 2023-05-09 | Me when I'm in a lag competition and my opponent is Diversity 3 sry.There's not much interesting about most of this. Again credit to la machine(youtu.be/9OPPzJHz6AU) for most of the movement. I was initially really worried about the piston cycles, but you can just barely make it to the first one, and the other one just kind of worked. It's probably worth noting that, like damage, slime pistons also transfer your server velocity to your client. So along with the fall damage I had to resync all of those by hand too. Ideally you can sprint jump the tick the slime hits you to transfer a full sprint jump's horizontal velocity, but I didn't get that luxury here(it would've only mattered for the first one anyway).The elephant in the room though is probably the jump at 0:16. This is just an application of a trick I've showed recently(youtu.be/-EPkAJY9uv8), that I used in order to skip most of the room. Put simply, by making super small movements on certain ticks, you can keep your server position suspended in the air in order to accumulate a bunch of fall velocity on the server, all while standing idle on a ledge. An infinite fake freefall if you will :dancer. There's a more detailed explanation in the video linked though if you're curious. Here I accumulate about two seconds worth of fall velocity, and then jump off the edge. I use that velocity's offset on my position in order to hit the slime block on the server while I'm still in the air, which turns the huge negative y velocity into like +2.4m/t of positive y velocity. I then move past the slime block and just land on the ground in order to take fall damage, which transfers the huge (now positive) velocity to the client, launching me way in the air. Which is lovely because then I didn't have to TAS the rest of the room.It did mean I had to TAS that part by hand though, which was a strange experience. I reveled in the novelty of it though I suppose. I would not suggest trying to TAS something with .001m movements by just writing inputs in notepad and playing back the whole thing with no tick advance at 20tps to see if it worked, though. In the initial fake faux fraudulent freefall videos I had to to wait 20 ticks before starting the freefall so that the position would update over the air, but here I just made sure my first movement over the edge was more than 0.03m so it would automatically update, and then just canceled out the rest of the velocity by driving it backwards into the wall so my next movement was only like .01m back onto the edge(so it wouldn't update again). Plus after TASing the whole thing I realized you could just wait for more velocity so that you boost up and land on the platform sooner(?). I was able to do it, but since you're moving faster the positioning was less favorable for the ladder, so I couldn't get it to save any time. I still resynced the rest of the TAS though so that's the version you see here :sob.Also also towards the end of the TAS(1:05) la machine does a really silly jump in order to smack its head on the weird stairs, but the server, in its infinite kindness, kept yelling at me for "moving wrongly!" and tping me back. I was able to find movement that worked eventually, but I thought that was goofy. (It thought I should only be at (996.67, 121.42, -1105.30) despite me telling it I was at (996.67, 121.4, -1105.01) and it didn't like that since its more than 0.25m off.)Hours of work: 12Hours of computation: 12(which is remarkable since it's been less than 12+12 hours since I started it)Map: planetminecraft.com/project/diversity-3Music: mellohi - c418I know that's a horrible description but smthn smthn Pascal's letter I just write these and never look back because there's nothing scarier than a mirror.
Infinite Artificial Freefall ANYWHERE(mostly) Curcuit Store 2023-05-08 | I suppose I made the last video too fast because I took another nap and invented something 100x better. This gets rid of the 20 tick cap AND the trapdoor/block breaking requirement. You can quite literally do this anywhere you have a ledge and a wall nearby. There might be a way to get rid of the wall requirement but I haven't given it enough thought.At the heart of the trick, the only requirement is you keep your server position in the air. In my original artificial freefall video(youtu.be/UUieYw5wPQs (if anyone has a name for this pls)) I assumed the only way to do this was to remove the floor under you. But, I realized there's a far easier way. As it turns out you can just walk off the edge for a tick, and then walk right back onto it a tick later. So as long as you time it so that tick you're in the air is the tick your server position updates, it'll stay hovering in air the whole time. Plus this is completely repeatable since it doesn't require anything other than moving a bit.Funnily enough the biggest annoyance ends up being the server velocity offset. You can't have a floor anywhere under you or else your server position gets offset by your server velocity and ends up colliding with the ground, killing all your y velocity. So if you want terminal velocity you basically can't have a floor 4 blocks under where you're doing this.Random explanation for why you can walk off the edge for a tick that I wrote and then decided wasn't necessary but am keeping anyway in case you're interested:When your movement is calculated for a tick, it does so one axis at a time, in either the order Y, X, Z or Y, Z, X (the horizontal axis with highest magnitude is always second). Either way though the Y axis always comes first. So if you try walking off an edge, you'll always collide with the floor, even if you get placed completely off the edge. This stops you from falling at all(since you hit the floor), but also means you're still considered on the ground, despite being in the air(since you hit the floor). This is fun because on the very next tick you're free to just walk back onto the ledge again. You do get moved downwards first, so theoretically you should just fall straight down, but since you're "on the ground" step mechanics step in(lol) and essentially let you do a subtick blip onto the block again. Since you didn't lose any height(gravity is -.078 or smthn) your server position doesn't even update, but that doesn't matter here since we want it to update when we walk off the edge. I actually think that might be abusable to remove the wall restriction but it's super hard to make your movements small enough to not update anything, especially since you can't sneak off edges :sob.
Artificial Freefall Curcuit Store 2023-05-07 | This video is kinda obsolete, if you want to see a funnier version there's this video: youtu.be/-EPkAJY9uv8And here's the wall-less version, which has a more in-depth explanation in the description: youtu.be/XjD4OojWfiQSemi-sequel to my last server velocity video? (youtu.be/X4eRb31tRQQ) There's a lot of stuff on this topic I want to talk about but the thoughts don't exist in english yet so you'll have to wait. In the meantime! Look at this silly thing I thought of randomly in my sleep. Yeah I woke up at 3pm so what rare non-3am upload.The idea is fairly simple: Trick your server position into not updating, move out of the way, and then remove the floor under that position. Since there's no floor it'll just enter freefall and start accumulating fall velocity, while you stand clueless nearby. It won't /actually/ "fall down" since your server position is kind of "locked" in the position it was last it updated, but it still continues to accumulate negative y velocity from being in the air. You do technically see the server position in the top left slowly lowering, but that's a result of the server velocity's offset on it, not it actually "falling"- if that makes any sense.Actually tricking the position into not updating is rather simple, and it doesn't utilize any sort of lag like I did in the video linked above. In fact! Everything here is completely intentional! Normally your client position just gets copied over to your server position, but this only happens if: you move more than 0.03m from the last position it got updated to, or it's been more than 20 ticks since it last got updated. So first I do a little jump to reset this 20 tick timer(so the TAS would play back in sync), then wait for it to update once more. As soon as it does this though, I move .001m over and open the trapdoor/remove the floor. Since I haven't moved .03m the server position stays positioned over the trapdoor where I started, and since the floor is gone, it enters freefall. Of course I'm still on the floor though since I moved .001m over to another block. I then just sit there while accumulating server velocity. I can't sit here forever since the 20 tick timer will eventually run out and update the server position to over the floor again, but just before that I jump off into the air. This does update the position, but since there's still no floor it continues to fall.Then just for fun I run into a slime block to convert that huge negative velocity into upwards velocity, and then transfer that over to the client using damage from a fire. Idk if that all made sense I'm still asleep but the other video I linked might have more information.You can maybe do something similar using hitbox expansion(youtu.be/ScElwg857ck), since server hitboxes stay pretty in check, but it's probably like float perfect to do reasonably idk. Plus you can't press sneak which is fun
Ladder Towering Examples/Test Curcuit Store 2023-05-07 | The sleek slim portable version of my last video about ~ladder stairs~ (youtu.be/9NJLHMH4pGA). Catch me pulling up to the TAS bedwars game with this one.The idea is exactly the same what I showed in that video, using climbing to cut your jump short, allowing you to hit the ground sooner than normal. Except this time I've added the complexity of building it on the fly, and also having a much more restrictive area to do it in. The inputs in this video were generated just by telling la machine(youtu.be/oDxinlwUJTM) to only press forwards/backwards, jump, and place block. I also show doing it with twisted vines just for fun. You could try it with normal vines but I think it would be 1 tick slower than the other two due to its lack of collision and the block's requirement to cling to edges. You could maybe get it on par if you built to towers at once, but that's a bit dank for something that doesn't really matter(one tower to jump off of, another to place the vines on. Otherwise you can't place a block while jumping off the tower since placing happens before movement, so you can't place the vine soon enough to grab you on tick 2).If you want an exactly play by play you can read the description of the original video. Just substitute in the following ideas:Instead of entering the ladder hitbox on tick two, you just place the ladder on tick two, automatically putting you inside it.Instead of just willy nilly landing on tick 6/7, you have to land exactly, and only, on the ladder hitbox. You either need to be able to place a block on the block tower, or already have place one there(this is easier since you can just press against that new block).And then, once you start repeating it, you need to make sure to move away on tick 1 so that on tick 2 you have room to place the ladder. Otherwise it'll fail since you're inside its collision hitbox.It's basically just constant tick perfect inputs to do accurately/avoid climbing when you don't want to. If anyone could pull this perfectly rta I would gift them a cookie.For the twisting vines the idea is the same, just a bit sillier. You can't use the ladder hitbox to jump off of this time, since twisting vines have no collision hitbox. So instead you jump off the block tower instead. This would cause problems for ladders/vines, since it prevents you from placing a block there the same tick you jump, which prevents you from placing vines/ladders off of it the next tick(like I mentioned with vines above), but twisting vines don't need a horizontal supporting block, so there's no requirement to place the tower block until you're at your peak and everything is dandy. You can technically stand on the tower block, but with your position inside the twisting block, to make everything pretty trivial(you'll see if you try it). But I didn't do that here because I like torturing la machine and it looks cool(and I love dealing with position desync ghost blocks). This one I could see someone doing rta.
Ladder Stairs Example Curcuit Store 2023-05-06 | While working on the Diversity 3 Train Parkour TAS (youtu.be/HRv4OTPCd1o) I noticed(my pathfinding ai overlord noticed) an interesting strat. Most of the TAS consists of jumping upwards as fast as possible, and at 0:31 it uses an optional ladder in order to cut height off its jump arc, allowing it to land and jump a few ticks earlier than normal. The idea is that by grabbing onto/climbing the ladder, you can automatically set your y velocity to like .2(functionally like .12). So by doing it at the right time, you can cut all the fluff off the top of your jump arc, so instead of peaking at like +1.25m, you only peak at about +1.0m, letting you land faster. This technically comes at the expense of moving slightly slower, but I think ticks make that completely negligible(?). I show ladders and stairs as references in the video, but it's probably more useful to say that it's 1 tick per jump faster than having a 3 high ceiling on your stairs, which is pretty silly. Sorry for making the video look like that I just felt like it.To execute(I use ladders, but any climbable should work):Tick one: Jump. You shouldn't be in any ladder hitbox, or else you'll trigger a climb. You should end the tick at a height of +0.42m with a 0.33 y velocity.Tick two: Enter a ladder hitbox while either still holding jump or while colliding with a wall. Basically just trigger a climb- you should end the tick at a height of +0.75m, and climb velocity(like .11 y velocity).Tick three: Continue the climb by either continuing to hold jump or colliding with a wall, while staying inside the ladder hitbox. You should end the tick at a height of +0.87m, still climbing.Tick four: End the climb this tick. So stop holding jump/colliding with a wall, or alternatively leave the ladder hitbox that tick. You'll experience one more tick of climb velocity, ending the tick at +0.988m, but you don't want to trigger more for the next tick.Tick five: Do whatever you want, even if you're still in the ladder hitbox at the beginning of the tick. Your velocity should move you out of the ladder hitbox before it can do more than cap your movement anyway. You should end the tick at a height +1.03m, with a y velocity of -0.04.Tick six: Again do whatever, just waiting for that negative velocity to pull you down to the ground, which should place you at +1.0m by the end of the tick.Tick seven: Voila, you win. You're on the ground so do whatever you like.Ladder information to aid you in your pain:"Ladder Hitbox" is just "is your exact position inside the block of a ladder(or any climbable.)" It doesn't have anything to do with your or the ladder's actual hitbox.Climb velocity is applied after you move for the tick. Conversely, ladder velocity capping is done prior to your movement that tick. That doesn't explicitly have a use here though.
(TAS) Diversity 3 Garden Parkour | 58.3 Curcuit Store 2023-05-05 | Insanely silly Minecraft TAS for game Minecraft. Was kind of a mess to make but turned out fairly decent.Again, this was made with the help of my little friend(youtu.be/9OPPzJHz6AU), I just had to do a bit more than stitch inputs together this time.First off, the map is massive. I tried running the thing throughout the entire course so it(and I) could get a feel for things what you're even supposed to do here, but it was only simulating like 2 million ticks per second just because of the size of everything, even disregarding the number of areas it would take. So I ended up cutting it off and just going for individual sections off the bat. So up until jumping to the yellow flower(?) was about the same workflow as the other areas I've done. But after that I had to accept my fate: fall damage.I mentioned in the other videos that fall damage is super annoying to simulate, which is because any time you take damage your server velocity gets transferred over to the client. So if you want to accurately simulate anything that happens after you take fall damage, you need to have an accurate simulation for your server velocity as well, which means you need a accurate simulation of your server position and its logic too because those are oppositely related for whatever reason. And even then pray that the order of operations has you in their thoughts. Anyway my point is I Do Not have an accurate server simulation, or really any server simulation for that matter. And I couldn't just tell la machine to avoid it like I did in the other areas since it's such a crucial part of this one, so I had to take a slightly different approach.Instead of having damage update the player's velocity to a server velocity, I simply had it set the x and z velocities to 0, and leave the y velocity as is. This is far from "accurate," but I figured it would be a close enough approximation that I could have something to work with. See, most of the time your x and z velocities /are/ 0. As far as this situation is concerned, the only time they aren't zero is when you sprint jump, which gives you 0.2m/t in the direction you're looking. But, even if you hit the ground as soon as possible, this has already dissipated to about 0.05m/t by the time you take damage. And since you're colliding with the ground, your y velocity doesn't matter(most of the time).With this approximation, I set it free on the course just like I would normally. And then when it found solutions using this approximation, I would either manually adjust those inputs to sync it up correctly, and/or feed it back into the program with the actual velocities measured in game. Nothing glorious, but it worked surprisingly well considering how crude of an approximation it was. A perfect system could maybe save time because of it, but all things considered it turned out pretty good. Plus I still had to deal with it desyncing every other time it took damage because of course.It didn't do anything super crazy here, just general good movement, but I will say working with this thing has definitely made me better. It's kind of validating to look at a section, theorize what it might look like, and then see the program independently come up with that same route. And even when it does one up me that's always interesting too.Hours of work: 8Hours of computation: 15Map: planetminecraft.com/project/diversity-3
(TAS) Diversity 3 Train Parkour | 41.55 Curcuit Store 2023-05-04 | I accidentally peeked at this area to stop myself from thinking and accidentally realized there were really neat movement opportunities here. So I decided to bite the bullet and teach my pathfinding friend(youtu.be/9OPPzJHz6AU) how to climb ladders and open trapdoors(remarkably only took like 20 lines of code thanks chatgpt babe), and set it loose. I was expecting to have to coerce it pretty hard into finding the strats I had in mind, but to my embarrassment it ended up finding it all pretty quickly. Plus the area was naturally pretty segmented so I just had it optimize each train car at a time, and then I stitched all the inputs together.Maybe my favorite movement-focused TAS I've worked on(?), which is a bit bittersweet since I only wrote like 4 ticks of inputs just to improve visibility, and a bit silly since most of it is a jump time autoscroller. Some of the cool things it did(some of which I hoped it would do, others of which really surprised me):-Jumping on first tick of entering of the area(using the extra tick of being on ground in the tp room)-Actually using the trapdoors(low bar but I expected it to get stuck way more)-Opening/closing trapdoors above it to cut off its jump arc and land sooner-Optimal ladder climbing (afaik)(I learned how climbing physics work and I've been forever cursed)-Cutting its jump with a ladder climb at 0:31(it's laughably genius but deceptively hard to pull off - I'm still not 100% sure how to do it consistently)-Closing the door trapdoors in the horizontal train cars to spam sprint jumps(and then opening them again for more favorable height?? or maybe coincidence idk)-Just spamming trapdoors while it's waiting(most important part)Hours of work: 6Hours of computation: 12Map: planetminecraft.com/project/diversity-3
(TAS) Diversity 3 Hobbit Parkour | 47.25 Curcuit Store 2023-05-02 | I didn't know how to beat this so I just threw 12 hours of beep boop at it to come up with a route(youtu.be/9OPPzJHz6AU). It found a 54 second time after about an hour, and by the end had a low 49.xx. I was pretty pleased with that considering I just gave it free access to the whole area, which has like 200k collision boxes and way too much cubic area. Once it had the general route I decided to refine it by doing super restrictive runs on 4 different sections, and then stitched those together into this. I only gave it about 2 hours per section for those though, and you probably lose some goal clarity by splitting it up how I did, so yeah it saved time but maybe there's probably some ticks you could chew off too. Oh well it was good exercise I suppose. Just don't pay attention to the fact that I lose a tick on entering the map area in order to make it sync up.It had some cool movement in the beginning stages, but I don't think it ended up working out for it. Maybe it would be faster and it just couldn't get it right, I don't know. You can see it use the stairs/slabs on the side of the bridges to get double sprint jumps, kinda like I showed in the 50m video(youtu.be/1hklEJeA9Z4), but it did it a lotttt in the beginning. It also used the iron bar/cobblestone wall height difference to do the same, which I thought was neat, but I can't tell if it does that here at all.I'm tempted to try some of the other parkour sections of this map, but it'll be tricky because fall damage isn't turned off, and so far I've just been telling it to avoid all damage. Or, in the case of one section of the beanstalk parkour, to only go for fall damage if would completely kill you. The issue is that taking damage triggers a transfer of your server velocity over to the client, which best case scenario, doubles your velocity for a tick, or worse case scenario, transfers a wildly different velocity to you. Smthn smthn this video(youtu.be/X4eRb31tRQQ).But notably, it's super common for the worst case scenario to be the case in parkour settings. Mainly due to the server velocity offset in cahoots w/ packet jumps just not make any sense. So I'd either have to wing it with a crude approximation, and hope it doesn't make a physical difference(pray that collision takes care of it), or spend forever making a janky server simulation and hope the actual game plays nicely. Which, to be fair, would be useful, but admittedly I'm not sure how the double ticking/order of operations goes, and I'm paranoid about the two being out of order or smthn.Hours of work: 4Hours of computation: 20Map: planetminecraft.com/project/diversity-3
