As a game dev, this is the level of bug-reporting quality we only dare hope for in our wildest fever dreams.

Floating point numbers causes boats to break. Makes sense, since boats need to float correctly.

Him: Warning math people they don't need to know anything about Minecraft to enjoy the video Me: A Minecraft person, worried that I need to know anything about math to enjoy the video

Another fun fact: If a boat falls from 44970 blocks high, it will not break despite it being in the sequence calculated. This is because after falling for that long, the tiny difference between 0.0399999991059303 and 0.04 compounds enough to offset the boat by more than the 0.001 block margin to have the ON_LAND status. This also means that boats are safe to fall from any height of 43543 or higher until you get all the way up to 1794944 blocks, at which point the boat is offset by the 0.04 blocks needed to wrap back around into the range where it can take damage, after falling for nearly 8 minutes.

The status of neither being in the air nor on the ground is what we in more basic speech call "Swimming".

<a href="#" class="seekto" data-time="774">12:54</a> "famously, multiples of 5 are at least 5 apart"

examples of both on_ground and inair being false: -climbing/descending ladders -swimming -falling through cobweb -climbing/descending vines -riding a boat/other entity <a href="#" class="seekto" data-time="534">8:54</a>

imagine being the mojang dev that receives the bug report containing a full stand-up maths video

<a href="#" class="seekto" data-time="582">9:42</a> The reason we need to check that fall damage was actually caused by falling is that Ender Pearls deal fall damage to the user when used.

Last time I saw a gaming breakdown this specific it involved parallel universes.

A Camman18 Matt Parker crossover is NOT something I expected but I thoroughly enjoyed

but then matt had a very good idea. he used f5. you see, using f5 gave him a whole new perspective and he was able to see a floating point error he couldn't have seen before.

"whatever floats your boat"

I love how we’re all just accepting that the situations where falling from a great height whilst sitting in a boat kills you are the bugs and the ones where you survive with no repercussions are the game working as intended.

"Multiples of 5, in my opinion, are at least 5 apart." -Peggy Hill

I wonder how related this is to Minecraft's weirdest death message: "death.fell.accident.water"? That death message only happens when falling a specific number of blocks down onto a waterlogged slab (half block with water on top). Normally water cancels fall damage, but in this one case it doesn't and it gives a very unusual death message about dying by falling into water.

Climbing on a ladder doesnt count as in the air, while also not being on the ground

Programming tip of the day: floating-point values that get repeatedly added should, whenever possible, be chosen to be exactly-representable numbers. Instead of 0.04, the acceleration should have been chosen to be 0.0390625 ( = 1/32 + 1/128 ); then the problem would not have arisen. (In memory of the late Garry Tee, who taught me this many years ago. Rest in Peace.)

Finally, a video that combines three of my favorite things. Mathematics, floating point number tomfoolery and Minecraft.

An interesting thing is that the boat breaks into sticks and planks. And here's the thing, once upon a time boats were really fragile, they would break from crashing too hard, and they of course also break when you hit them, and in both of those instances they used to break into blocks and planks. Then in an update a long time ago they made it so that they don't break as easily (can't break by crashing) and if you break them by hitting them they drop themselves (or in other words a boat item). But with that bug they still drop the old drops.

As a programmer, floating point imprecision has been cause for may hours of desperate debugging.

I like that, as soon as he told the numbers where that happened, my first instinct was to pause the video and put the sequence on OEIS. Next scene is he putting the sequence on OEIS and finding nothing.

<a href="#" class="seekto" data-time="68">1:08</a> - looking at this offhand, there is some patterning here: 12 and 13 have a difference of 1 49 and 51 have a difference of 2 111 and 114 have a difference of 3 202 and a perhaps missing 206 would have a difference of 4 310 and 315 have a difference of 5 I'm not sure what is placing these pairs, but I hypothesize that 206 is also a height from which you would die, and that the next two heights would have a difference of 6 between them. If 206 doesn't work, perhaps that is for a significant reason? edit- oof it was 198! so my hypothesis was actually not too far off then, nice!

Never in my life did I think Camman18 would end up in a stand up maths video. We truly live in one of the times.

Oh this is SO funny to see a video about this. Fun fact--since most players have no clue about this and use driving boats off ledges as a safe way to get down cliffs, you can often trick people into exploding if you measure out a drop that's exactly the right height. It gets a bit into the weeds, but the historical reason for the "don't calculate fall damage if you're falling" stuff is that boats used to break if you rammed them into land. That got removed, but the fix was kinda a hack and accidentally left this method in.

<a href="#" class="seekto" data-time="548">9:08</a> when you're under water, you can be neither in the air nor in the ground.

Ladder is probably an example on "Not on ground" but "Not in air"

Since you covered Minecraft, maybe have a look at the famous overbounce bug in the Quake3 engine (idTech3). Here also when you drop from a certain height, you get an "overbounce". In short, all your falling velocity gets "bounced" in your direction of travel tangentially. Though even more special, when your horizontal speed is exactly zero when the overbounce happens, you would bounce back up to the start height. This can be used in some maps to gain additional speed or each certain places more easily. Overbounce is kinda funny because there are several "variants". First of all the height above the ground is the most important factor. However you could always simply drop / walk off a ledge or jump off that ledge. Two different heights as a result. Furthermore your player could be in a "sticky" state as it's usually called. That state means your character is not perfectly on the ground but essentially hovers a tiny bit off the ground. You can get to this state either by stepping on a certain stair height and back off. So your falling velocity is just right that you get into the sticky state. Another common way is to use a single shot of the plasma gun to the ground you're standing on. The impact has a slight knockback and lifts you a tiny bit in the air (with the right angle against a wall you can actually climb walls). When you are sticky, the drop and jump heights for the overbounce to happen are different. Another way to get to a certain overbounce height is to do a rocketjump into the ceiling of the map. In some maps the distance from the ceiling to the ground is just right. Some mods (like DeFRaG) had built-in indicators which can tell you if you are "sticky" and if the surface you're looking at would result in a drop or jump overbounce. It's quite handy for finding great trickjump spots in maps. Q3 was and still is one of the best FPS shooters of all time. The physics and netcode are just perfect. Since the Q3 source code is released under the GPL (John Carmack, the hero) we can exactly see what the code does. The overbounce "bug" is also the result of a feature (specifically that you would slightly bounce of walls when you run into them at an angle) and a safety threshold (specifically you're considered on ground when you are less than 0.25 units off the ground. You player is 48 units in height). Here's a video that goes through the code to explain what happens: ( WmO2cdTU7EM ) and here's a defrag video from the 2017 world cub (round 6 is my personal favourite, but the final round is also sick ^^): ( cCO9QuV-cgM ). In Round 6 DeX reached about 1800 ups (units per second) with vanilla Q3 physics. Apart from VQ3 there's a modified version called CPM (Challenge Pro Mode which has some changes, especially more air control and fast weapon switching). "inder" reached almost 3000 ups in that map. The normal runspeed is 320 ups :) I played a lot of defrag but never was even close to be considered a defragger :D Pro players are just crazy people.

<a href="#" class="seekto" data-time="170">2:50</a> You can use levels of snow for 1/8 of a block precision with some additional levels at 1/16 - carpet, 3/16 - trapdoor, 9/16 - bed, 15/16 - grass path (I could've forgotten something).

The rabbit hole for Minecraft gravity goes so much further! Turns out most different entities experience different accelerations due to gravity, and different drag forces too! Boats are the simplest, since they don't experience drag. As an example, players and most mobs experience 0.08 b t^-2 of acceleration, or 0.01 b t^-2 if they have slow falling, and experience a vertical drag coefficient of *nearly* 0.02, and a horizontal drag coefficient of *nearly* 0.09 (just as in the video, these "nearly"s are due to floating point errors). Drag is calculated after applying acceleration. Another example would be projectiles, all which experience ~0.01 drag in all directions, but in this case drag is calculated *before* acceleration! Every projectile experience different gravity though: the ones that stack to 16 like pearls, eggs and snowballs experience ~0.03, while potions, arrows and tridents experience ~0.05, llama spit experiences ~0.06 and xp bottles experience ~0.07.

That's why we usually try to avoid floating numbers in programming! Excellent video, enjoyed every second of it.

underwater would put you not ON_GROUND while neither IN_AIR but more importantly these seperate values play different roles in applying gravity & using player's oxygen underwater

you can actually fall down non-integer heights, falling from different snow layers or from cakes, beds, enchanting tables, .... has anyone looked that those?

Didn’t realize there was an online encyclopedia of integer sequences, but thats pretty neat

The tolerance for 'in air' Was likely implemented due to something like a path block being very close to, but not quite a full block. If the game considered you airborne for that moment, it would feel clunky and not let you jump. Especially if you had one foot on the grass and another on the path (depending on where the ground check is measured from) It could also be to ensure your character remains grounded during little rounding errors like that Super cool break down!!

Did not expect another Minecraft video, but I'm very glad to see you looking into this!

This also makes ROUNDING a number an actual nightmare, because XX.5 might actually be XX.49999999 or XX.500000001 and you just can't tell

Stand-up Maths is slowly becoming a Minecraft stan

Did not expect Camman to end up in a science video but here we are.

in air and on ground are separate to allow for easily coding things like ladders, platforms, bouncy slime blocks, swimming, floating in lava, lots of stuff.

Stand-up Code Review

<a href="#" class="seekto" data-time="530">8:50</a> one example is having your upper body in the water (technically "swimming"), or in a cobweb.

I heard the opening line as "If you are named Natalie..." before the context based autocorrect kicked in.

I got so excited when he showed the IEEE converter! That website used to be my bible!

As a programmer working with geometric operations, I hate floating point numbers. They're the worst.

<a href="#" class="seekto" data-time="880">14:40</a> The short stops at 315 because that's the longest drop you can achieve within the buildable height of a Minecraft world, which goes from y=-64 to 320 for a total height of 384 blocks.

<a href="#" class="seekto" data-time="528">8:48</a> the game does do a check for when your head is underwater, which divides your mining speed by 5 unless you have aqua affinity on your helmet, and the same occurs when "in the air" (including creative flight in survival mode, but that requires mods or server plugins), not sure if those affect anything in this case, but they do combine (atleast in 1.10.2 that i have open to afk)

<a href="#" class="seekto" data-time="533">8:53</a> I beleive if you are in water/lava/cobwebs you aint in the air but aint on the floor either

<a href="#" class="seekto" data-time="528">08:48</a> I think the reason for having the additional onGround variable is because you can swim in Minecraft too (i.e. not in air, and not on ground)

Went to investigate. Turns out 198 will break the boat with a player in it (although it waits to do so until you leave the boat), but doesn't cause player damage, which is probably why it isn't in the short.

Boats are indeed famously sensitive to floating errors

Seeing camman in a Standup Maths video feels like seeing your drug dealer selling to your teacher

I was surprised to hear absolutely no mention of terminal velocity in this video about acceleration due to falling, so I did a bit of my own investigation and it turns out that although Minecraft does have a terminal velocity, under these specific conditions the boat/player would not be falling long enough to achieve it. 🤓

as of this comment, the sequence is still not in the OEIS but I don't expect that to hold forever

It is often done on platforming games, where the platforms actually extend a little further out than it looks, to account for input lag and so on. Developers found out, that if you don't add this compensation, it makes the game extremely hard (some of the early games known for being difficult were difficult exactly because of this ) My guess is, that this is to make jumping block to block easier. I had watched a video about this a while ago, but I can't remember what it was called.

I think you forgot to add 198 in the shot at <a href="#" class="seekto" data-time="857">14:17</a>! Great video regardless :3

With regard to the bit at <a href="#" class="seekto" data-time="628">10:28</a>, this is actually the normal, correct way to compare floating point numbers. The fudge factor even has a name, epsilon. You _never_ do a strict equals comparison on floats, because it'll be false unless you're comparing something to itself or to zero. Instead you check if it's within some range, like above or below a target value. You add or subtract epsilon from the value as appropriate to account for the rounding errors.

Both for this and the first Minecraft video, Matt specifies 'for those not familiar with Minecraft' that they shouldn't worry about not knowing. Now I'm curious how big an overlap there is between the "knows about minecraft" and "watches Matt Parker videos" demographics.

I was curious why certain pairs (12,13 & 49,51) were so close to eachother, the algebra behind it really helps

Floating point inaccuracy was one of the reasons why Universe Sandbox could not use CUDA acceleration for its orbital simulations.

<a href="#" class="seekto" data-time="536">8:56</a> While not on the ground but also not in the air, you could be swimming in water, swimming in lava, falling through packed snow, or falling through the Void (basically the out of bounds area). These are just what I could think of off the top of my head.

matt parker camman18 crossover is not what i expected today

not on the ground, and not in the air - swimming in the water.

Never expect this kind of overlap in my UKposts interest

who is that guy

<a href="#" class="seekto" data-time="660">11:00</a> The reason why the check has a tolerance on it is precisely because of those pesky binary floating point problems you tend to run into. Since you can never be *quite* sure you end up at exactly a whole number when doing calculations, an easy workaround is to just check to be within a 0.001 margin of it. Yes, we programmers are lazy and can't be bothered to do this properly 😎

2 or so weeks ago, I finished my 3 month long school project on polygonal numbers in certain modulo. This is very close to what you were doing here :3

Been a Parker viewer since the domino computer (redstone irl) and a minecraft player for longer, so these random crossovers always make my day :D hoping for more in the future!

I was NOT expecting such a good explanation from a non-minecraft channel

the fact that the boat breaks into planks and sticks is incredibly interesting and likely due to vestigial code. Back in the day if you ran into a shoreline, your boat would break into sticks and planks but now, there are no circumstances in normal gameplay where that should happen, if you break one by hand, it drops the boat item itself so there must be something else going on that makes the boat shatter at those particular heights

In hindsight, considering another video from a few years earlier and Minecraft's versatility as a sandbox, a Minecraft video on the Stand-up Maths channel wouldn't be out of the question.

Regarding "can you not be on the ground and not in the air at the same time", it all depends on what the code is doing really. On the face of it they are opposites. However if they are measuring slightly different things then both true or both false could be valid. It reminds me of a place I used to work (details changed to protect the not-so-innocent), where we monitored stuff in our warehouse. An item had several flags including online and offline, and every newb to the code had the same question: why are there two flags? It turned out that when an item is known about but not in the warehouse, it's offline, and online can never be true. When an item is online it's in the warehouse and we know what it's doing, and offline can never be true. For the most part online and offline are opposites. HOWEVER, there is some temporary storage in the warehouse, and when we put something there we're not monitoring it, so online is false, but offline is also false. Both flags true was definitely invalid though.

onGround is mostly used for deciding if you should take fall damage or not. This is often used for quite a few fly cheats to prevent fall damage, especially older ones. However, it also prevents ladders, vines, and scaffolding from killing you when you fall onto them.

The math and reasoning is sound all around , but i think there's a missunderstanding of the 'why', at around <a href="#" class="seekto" data-time="540">09:00</a> , with the whole 'on ground on air' explination, i think that it's not about 'taking fall damage while not being on the air' The actual 'bug' is, when you are on a boat, since you are ON TOP of the boat, 'this.status' is never on_land, so the game basically ignores the 'on.ground' and asumes you are still falling. But in those numbers, the distance from the ground to your character (trough the boat), is so small, it correctly identifies that you did fall and should take damage. I think this reasoning makes more sense than 'taking fall damage when you are not falling'.

<a href="#" class="seekto" data-time="403">6:43</a> the h-schmidt float converter has been so useful to me in my reverse engineering work. i unironically enjoyed seeing it in this video. no clue who H. Schmidt even is but their converter is such a great tool

Matt Parker doing Minecraft videos is peak content

<a href="#" class="seekto" data-time="524">8:44</a> Caption error here, “this is just boolean” became “this is just bullying” 😄

Finally tackling the big issues.

So, a while back, on my channel (in my 2nd Hardcore World) I died and lost my world due to this "bug"; which led to me doing a ton of reasearch and testing on my own (I was able to find the same numbers mentioned here). This is a bug that has been quietly discovered, but the developers did not plan on patching it. Additionally, for those that care, in the event that the player is in a boat, they will take damage at the same levels... unless the boat is stationary in the x&z directions; a stationary boat will not break, so I tend to just stay completly still when boating off ledges higher than 40 blocks. Good video. Have been waiting on this!

"How can you not be on the ground, but not be in the air?" *Anti-climactic drum roll* ... When you're swimming.

Minecraft!? Heck yeah!

you're not on the ground if you're IN the groud, suffocating also void also water and lava also cobweb

As soon as I saw the bug involved a list of numbers my very first thought was floating point numbers. It’s always floating point numbers. 😂

So the real bug is that status and onGround are not using same margin of error

Minecraft has some really interesting quirks with the way it calculates fast moving entities. To prevent it going through a block when it's moving extremely quickly, it checks every block position between the entity's previous and current positions, but does this separately for the x, y, and z directions. So it can go through a block diagonally because it effectively moves to its new position along the x direction, then y, then z. Some crazy tnt cannons take advantage of this.

Minecraft and stand up maths was a collab I never knew I needed. There are so many amazing maths problems in Minecraft, I think everyone would enjoy them

I was taught when I learned to code in the 1970s that all floating point checks need to use a precision check, and never a strict equality check for exactly this reason. The problem here is that they implemented the status check correctly, but the on ground Boolean incorrectly. I always thought that the equality operation on floating point variables should cause a compile-time error.

YOOOOO!!!! My favorite math guy uploads a video on MATH AND MINECRAFT?!! While I'M playing Minecraft?!? And while I'm doing Minecraft math myself for Stronghold triangulation?! THIS IS A DREAM!

Camman18 in a stand up maths video is something I never expected

Very informative and interesting video, I love seeing Non-Minecrafters' takes and opinions on Minecraft, especially those of mathematicians and people of other professions. Also, *<a href="#" class="seekto" data-time="528">8:48</a>* There are quite a bit of cases in Minecraft where you're simultaniously not in the air but also not on the ground at the same time. ''Going for a swim'' as you mentioned is one of them, but there's also being in lava, sliding down the side of a honey block, falling into powdered snow, stuck falling on cobwebs... You name it.

Speaking as a retired system tester, this sounds like the sort of bug that the average developer wouldn't find ("works for me" / "cannot reproduce" / "can't see anything wrong with the logic") and in any case the Development Manager would refuse to acknowledge it as a defect!

By the way if you ever find yourself in this situation in Minecraft (trapped exactly one of these numbers in the air with nothing but a boat) you can get in the boat and then, while you’re falling, quickly get out and then back in again. This will reset your momentum from the point you exited the boat, and prevent the bug.

<a href="#" class="seekto" data-time="540">9:00</a> as a games programmer and a minecrafter, there is one situation in game where you can be not on the ground and not in the air at the same time, and that's when swimming. In that case, onGround would evaluate to false, but status would be something like SWIMMING, and the game modifies the player physics based on status. onGround just determines if you can jump, start sprinting, and probably a few other things.

This sounds actually like not taking damage was the "bug", at least at some point. The status check sounds like a guard against "don't take fall damage while still falling", and the coupled state updates to position and the checkFallDamage event create an ordering dependency and, arguably, a bug. Classic spaghetti code problem.

As a dev that had problems with floating-point precission errors on multiple occasions, i still find it incredibly funny. Imagine if in the real world, if you fell 1 meter you'd be fine but if you fell 1 meter and 1cm you'd break your spine

You can actually test this hypothesis by testing to see what happens if you land on certain blocks. Some blocks in Minecraft are not exactly one block tall when it comes to entity collision (e.g. with boats and players), and this height can be measured and checked with regards to collision. (Alternatively, you can manually change the tick rate to check what happens when it changes).

What I found really surprising there is that for boats, Minecraft doesn't apply air resistance logic! So in theory if you were to spawn a boat at an insane height and go into it, you could reach arbitrarily high speed. This is not at all how the rest of the game works. The player itself has a terminal velocity, because the game takes into account "air resistance" Also Minecraft has different value for gravitational acceleration for different entity types.

<a href="#" class="seekto" data-time="1">0:01</a> hi, Timed users!

<a href="#" class="seekto" data-time="187">3:07</a> Unrelated, but the way you pronounced it as "metres per second per second" made me finally realise why it has a power of 2 there

I bet there's even more holes if you went from partial heights, such as using snow layers to add 1/8th of a block at a time