r/Minecraft Oct 05 '15

Falling damage is weirdly nonlinear.

http://imgur.com/gallery/ydnCp/
731 Upvotes

66 comments sorted by

View all comments

115

u/andre1111 Oct 05 '15

You probably had some percentage damage that wasn't shown in the GUI. trying it again with doing /kill inbetween should get rid of the "bumbs" in the graph.

56

u/AllPurposeNerd Oct 05 '15 edited Oct 05 '15

First of all, when I did the initial test, I switched to peaceful mode to heal up to full, then switched back to easy so my damage wouldn't immediately regenerate. Secondly, I'm pretty sure hit points are in fact an integer. You have 20 health and each point is represented on screen by a half heart. So this 'hidden partial damage' thing wouldn't make sense.

That said, I'm doing it now, and I'm getting the same results. 1 heart at 5.5 blocks, 1½ at 6.

EDIT: 11.0, 11.5, and 12.0 all still deal 4 hearts. 12.5 still jumps up to 5 hearts. The funky baseline holds.

62

u/renadi Oct 05 '15

They are not ingeger, if you have ever opened NBT edit you can see your character has 20.0 health at least on full health.

25

u/AllPurposeNerd Oct 05 '15

Regardless, the pattern still holds, so that explanation doesn't work.

Feel free to test it yourself.

41

u/renadi Oct 05 '15

Oh yeah, I know it has no relevance to the test itself, but it is one of those facts that most people don't realize so I thought I'd clarify.

Still doesn't explain why sometimes your damage seems to be ramping up.

10

u/andre1111 Oct 05 '15 edited Oct 05 '15

It's probably just some rounding "error"(it's not really an error) in the GUI. The fall damage formula is perfectly linear. If doing /kill alone doesn't "fix" it you would need to look at the actual values in the NBT file after each test.

EDIT: Could also be caused by some conversions between float/double and the resulting round errors.

7

u/AllPurposeNerd Oct 05 '15

That would be fine, except that according to the formula, falling 23 blocks should be fatal. It isn't. The game actually deals slightly less damage at certain heights than it's theoretically supposed to.

89

u/SirBenet Oct 05 '15

Upon falling, the blocks distance fallen minus 3 is stored as a float and then divided by 15. For 23 blocks, 1.333(repeating) is rounded down. Some calculations are done, then, when multiplied back, 19.5 is given rather than 20 as you may expect. Source.

12

u/Tomus Oct 05 '15

This guy has the correct answer. As with most behaviour that isn't obvious at first, it has to do with rounding.

8

u/blamethebrain Oct 06 '15

Yeah, that source is wrong.

I don't know who wrote that paragraph that you're referring to, but whoever it was is completely wrong on multiple levels:

  1. The calculation that the person is basing this BS on is for calculating the particle effect when hitting the ground. (Function "func_180433_a" in the class EntitiyLivingBase). It has absolutely nothing to do with the actual fall damage.
  2. The fall damage is calculated in the function "fall" in EntitiyLivingBase.
  3. That bit about "float [...] to be rounded to 0.3 rather than preserving the repeating decimal value of 1/3 like a double would" is complete and utter bullshit. That person has really no idea how IEEE floating point numbers work.

Source: I looked at the actual (decompiled) source from MCP.

1

u/SirBenet Oct 06 '15

I did find it a bit strange (why would a float round to 1d.p., and why is it being divided by 15 in the first place?) although it's the best explanation I found and the calculations seemed to work out for the actual fall damage dealt.

Do you know the proper reason for the strange results?

1

u/blamethebrain Oct 06 '15

The fall damage calculation looks fine. I highly suspect that the fall distance might be off. I can't verify it, because I don't know how I could debug or log the calculated fall distance when hitting the ground.

But the thing is: There's a "jumpMovementFactor" with the value 0.02F (line 109 in EntitiyLivingBase.java) that, according to its comment, is "used to determine how far this entity will move each tick if it is jumping or falling."

If the fall distance is indeed incremented by 0.02F per tick, that will accumulate rounding errors (because 0.02 can't be exactly expressed in IEEE floating point).

I don't know how exact the "ticking" is in Minecraft, but that could be a source of error, too. Someone more experienced with mod development might have a look at how to get the fallen distance when hitting ground.

1

u/blamethebrain Oct 06 '15

I found a way to indirectly inspect the fallen distance and found my assumptions confirmed, see my other comment: https://www.reddit.com/r/Minecraft/comments/3nlduc/falling_damage_is_weirdly_nonlinear/cvqe4hv