Curcuit Store | (TAS) Diversity 3 Garden Parkour | 58.3 @CurcuitStore | Uploaded 1 year ago | Updated 20 minutes ago
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: 8
Hours of computation: 15
Map: planetminecraft.com/project/diversity-3
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: 8
Hours of computation: 15
Map: planetminecraft.com/project/diversity-3
