When pushed to water or lava edge, entities jump by themselves

14w29b :|

Confirmed for 1.8.1.

Confirmed for 15w51b.

Confirmed for 16w03a.

Seeing that this has not been fixed yet after 2 years, I would like to request this very relevant piece of information to be added to the description:
________________________________________

In order to reproduce:

1: Create a water stream that ends at the edge of a block (as seen on attached image).

2: Step into the water stream and hold down the shift key. Wait for your character to reach the edge of the block

3: Try moving away from the edge. This will work for all four direction keys (W, A, S, D). Any attempt of moving up the stream at this point will result in the character jumping off the edge.

_________________________________________

Also, after some testing, I would like to report that the title of this bug is inaccurate.

The character does not jump by itself when pushed to water edge. It does so when attempting to move away from it. Therefore, I would like to suggest this title as much more accurate:

When moving away from block edge with flowing water, the character jumps over it by itself

^
Confirmed for 16w03a?

It's best to post a new comment for confirming for new versions.

@Alexander, when you're saying "move away" it might be understood as if there is user controller interaction. However, my original bug report is stating that no action is being performed and no button is being pressed.

If you mean that the jump occurs as soon as the character is pushed out of the water, then ignore my comment 🙂

@Boris Aranovich

But there has to be controller interaction for the character to jump off the edge. It just won't happen by itself. For example, if you are facing the edge of the block while being pushed towads it by the stream, you have to push 'S' for the jump to occur. If the edge is to your right, you have to push 'A'. And so on.

This is why i suggested adding this in the description, because that is how you reproduce it in the latest snapshot.

@Alexander

That's not precise. If you look at the repro I made originally, there was absolutely no interaction and no buttons were pressed.
http://www.youtube.com/watch?v=R_T1occhy9g

Confirmed for 16w06a

Confirmed for 16w07b.

Confirmed for 1.9 pre-1

Confirmed for 16w15a. Just thrown me into lava, great.

Confirmed for 1.9.3 pre-3

Still an issue in 1.9.4

Confirmed in 1.12

P.S: How can I find said method? I was searching in 1.12 and I cant find such class.

@@unknown with MCP 9.40 PRE 1 for 1.12 the method is called net.minecraft.entity.EntityLivingBase.func_191986_a(float, float, float). Or did you mean something different?

Yes, I can't find that class in 1.12 while decompiling with JAD, but i'm gonna try using MCP.

MCP does not only decompile but also renames classes, methods and fields. This makes the names easier to understand than just a random letter combination. Additionally it makes it somewhat consistent between versions while the obfuscated names change.

If I recall correctly MCP uses fernflower which also changes names itself since the obfuscator Mojang is using does some pretty nasty stuff like giving classes and fields the same name. While this apparently works for compiled files this does not work in the source files since there is no difference there and therefore classes with a name a field has are treated as references to the field.

It does use fernflower as I saw in the log message in "decompile.bat".
Also, I found the package.

net.minecraft.EntityLivingBase.func_191986(float, float, float) :void

...
2209          if (!this.hasNoGravity())
2210          {
2211               this.motionY -= 0.02D;
2212          }
2213
2214  -->     if (this.isCollidedHorizontally && this.isOffsetPositionInLiquid(this.motionX, this.motionY +
      -->     0.6000000238418579D - this.posY + d4, this.motionZ))
2215  -->     {
2216  -->         this.motionY = 0.30000001192092896D;
2217  -->     }
...

Maybe removing it or changing this.motionY = 0.30000001192092896D; to this.motionY = 0D; will fix the issue?

Worth noting that this also happens when swimming using the new 1.13 water mechanics.

Is this bug also the cause of auto-jumping when walking up to a waterlogged chest from open air?

Explained better:
1. Place any kind of chest where water will only flow off it in one direction (like going over a cliff).
2. Use a water bucket to add water to the chest.
3. Walk up to a side of the chest where water is not flowing out.
4. The player automatically jumps even when auto-jump is off.

I was going to create a new issue but maybe this is already covered by this issue?

Edit: Here's a screenshot of the setup: https://i.imgur.com/IIis8xB.png .

It seems different enough for a new report to me. Can you please create one and then comment here so that it can be marked as related?

Ok I created issue MC-127224

Affects 1.13-pre7 (surprisingly, as I'd expected MC-127224's fix would have also fixed this).

Seems fixed in 18w30b, but was probably fixed earlier.

Can't reproduce either. Please comment if you still can.

(in the pic) Endstone??? thats sponge though?

I'm still able to reproduce while holding W; however, it doesn't seem to automatically happen anymore with the setup in the second picture (probably because of the slower character movement). However, a setup where the water is closer does still have it work:

Additionally, this setup triggers it when walking (similar to the one from MC-121610):

Curiously, walking forward into these and then releasing all buttons also triggers it... This is a separate issue (actually 2) although also closely related.

I'm also still able to reproduce MC-8959.

Given the code piece calls a generic 'liquid' function I guess this is expected but it also happens with lava.

This one, or MC-8959? I can't seem to get this to happen with lava (possibly because lava doesn't push?), but I can get MC-8959 to happen with lava (if I push forward manually)...

Is the current state of MC-142942 a duplicate?

The current state of MC-142942 is chaos. Someone needs to sort through all those "updates" and figure out what the report is actually about. But if you mean only the first linked video, no, that's different from this report.

Can confirm in 20w48a.

Can confirm in 20w51a.

Can confirm in 21w03a.

Can confirm in 21w05b.

Can confirm in 21w07a.

Can confirm in 1.17.

Can confirm in 1.17.1 Release Candidate 2.

Can confirm in 1.18.1.