Hitbox Expansion using Rounding Errors

Показать описание

I can't tell if this is the funniest meme I've come across in this game or the most upsetting information I've had the displeasure of happening upon.

Basically, the long and short of it is that the size of your hitbox doesn't really get fact checked too often, and so by abusing weird rounding you can cause it to grow(or shrink) ever so slightly over time.

And I guess the long and longer of it:
Disclaimer I'm really in no position to explain this, I literally had to google what a float was for this video(I mean I knew they existed but what do you mean a "mantissa" that's just an old lady's name??).

Pretty much, your hitbox is defined as a minimum and a maximum coordinate on each axis. And when you move around, it calculates how far to move you in whatever axis, and then adds that distance to both your minimum and maximum on that axis. (Your actual position then gets set to the bottom center of this new hitbox).

It's just kind of assumed that since you're adding the same distance to both the min and max, the distance between them should stay the same. In fact, it only really resets your hitbox to default if you like. do something that updates your hitbox size(idk crouch/uncrouch/swim), or relog/similar. Mathematically it's a pretty fair assumption I suppose, but its also just not true when it comes to floats n stuff.

See floating point numbers only have so much precision, so its a given that adding numbers won't always give the perfect result. But as long as the precision is consistent there aren't any problems, since everything would be off by the same amount. But alas, the precision isn't consistent. Whenever the value passes over a power of two, the precision gets coarser and coarser(I think by half(?)).

So what I do in this video is go super far on the X axis, to the highest power of two accessible in a Minecraft world(2^24, or 16,777,216). By then standing on this coordinate, I can have my hitbox's minimum X coord on one side of the power of 2, and my maximum on the other side of it. Essentially this just means the coordinates of the two will have slightly mismatched precision levels. That way when I move around on the x axis, there's a chance one rounds it differently from the other. It's only the difference of like, one float value, but its still a difference. And it still leads to a net size gain in that axis(or size loss if the opposite happens).

From there I just did this for 1000 hours(technically only 33 but at 600tps), and came back to a hitbox ~0.12m larger!

Theoretically, if you could go way out past the world border, the effect would be even more emphasized as the precision decreased, but oh well. You can also technically do this closer to the world origin, but even out at 8192 the size change would be like 0.000000000001m, and take like a millennia to grow by 1m. It'd work for the other axes as well, including Y, but since you can't really go past y 256, you'll be stuck jumping for like half a million years to grow by 1m.

There could be ways to optimize this, again you're literally only changing your hitbox by the smallest possible value every tick, but it's miracle enough I managed to get a consistent setup for this.

I should also probably note that the server is much more strict about its hitbox sizes, almost constantly making sure they're the right size. So even though your hitbox is funky shaped here, the server probably still thinks it's 0.6x1.8x0.6. This can do some funny stuff in of itself, but I think this is what renders small hitboxes pretty useless. It just sounds the alarm or smthn and it resets. This also might mean this doesn't work for other entities, but I could just be making stuff up.

More silly than useful, but that's the finding(I say, as if there probably isn't some 4 person parkour community out there that's known this since 2013). I could honestly see this being useful for aligning yourself float precisely, but that's not really something you need to do too often, lol.

Curcuit Store

Рекомендации по теме

Комментарии

time to make a parkour puzzle map with a 5 block jump

woodchuck

I was just curious to find some stuff about floating point precision, and I found this. This is one of the most interesting bugs I have ever seen in minecraft. Strange that I have never heard of this before

wscamel

cheaters explaining why they're not using hitbox:

eighties

You actually are like Myren Eario 2 with the amount of cool but mostly useless technical tricks you’ve found! So cool

Nooticus

Haha, nice, I didn't know exactly how this works and that it has so many possibilities.
I used it to clip in the walls on 1.8.x versions with correct setup, of course with the help of powers of 2, because the shrinked hitbox allows for that.
It took me really long time to realise how to clip in the walls consistently, because I didn't know about floating point errors, most people thought that the wall clipping was a ping thing lol (which is not true).
Finding that crossing the powers of 2 changes the player collision was so hard back then.
It's so cool that changing the hitbox works for newer versions too.
This is the channel I've been looking for, it took so much time, finally!
I'm amazed by your discoveries, I will definitely have fun with some of them.

kemytz

Could this be possible with other entities like minecarts ? I'm really interested because it would allow for new specific cart clips inside some immovable blocks with several internal hitboxes in 1.13+ (particularly sideway hoppers)

Door_Maker

Also I already knew this but this is something interesting. If you are on MCPE. The size of your character lowers Ur hitbox or makes it bigger. This is why you're unable to attack when you look at the standard pitch . Lol never realised they added dwarfs and updated them to MCPE lool

Hoggiehog

I could see a hack client somehow making use of this to make hitboxes tiny

spencerjohnson

Coolest bug ever. This was mind-blowing

zfoo

well what if you shrink the hitbox to 0 blocks

moonyl

Yeah there are definitely a fair number of 1.8 parkourers who know this, although its not quite 'common knowledge' yet. Never seen it taken to the extreme like this though. Also, this is why you sometimes clip into walls if you're running parallel to the side of them. Although I think that may have a little bit of extra of complication on top. One application Ive seen recently is a vertical gap that you wont fit in (Y position is above one tick, below the next) without first shrinking your hitbox first

benrosenthal