When swimming, the player can stand up even though there is a block above
The bug
The player is able to stand up when swimming through a one-block high gap, the player can stand up even though there is a block above.
The name tag will visually appear lower than usually and in the first-person view it still looks like the player was still swimming, but when in third-person mode (or as seen by another player) you see that the player is actually standing. If you sneak, the first-person view will jump up inside the block above.
If the block above the player is solid (in the example: the red glass block), the player will suffocate when sneaking (if in survival mode) and won't be able to leave the block it is in without destroying any blocks.
To reproduce
- Build this:
- Go into the water and start swimming
- Swim into the one-block high gap
- Touch the ground or press Space without pressing Ctrl
- Sneak
Video
Linked Issues
is duplicated by5
MC-128316Player appears standing after swimming in a 1x1 waterDuplicateMC-128344Swimming through one block holes are glitchyDuplicateMC-128584dark lava and swim motionDuplicateMC-128680Player model can stand up when swimming in a 1x1 tunnelDuplicateMC-130256Suffocate when swimming straight upDuplicate![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Created Issue:
When swimming, the player can stand up even though there is a block above
The bug
The player is able to stand up when swimming through a one-block high gap, the player can stand up even though there is a block above.
The name tag will visually appear lower than usually and in the first-person view it still looks like the player was still swimming, but when in third-person mode (or as seen by another player) you see that the player is actually standing. If you sneak, the first-person view will jump up inside the block above.
If the block above the player is solid (in the example: the red glass block), the player will suffocate when sneaking (if in survival mode) and won't be able to leave the block it is in without destroying any blocks.
To reproduce
- Build this:
- Go into the water and start swimming
- Swim into the one-block high gap
- Touch the ground or press Space without pressing Ctrl
- Sneak
Video
Attachments1
The bug
The player is able to stand up when swimming through a one-block high gap, the player can stand up even though there is a block above.
The name tag will visually appear lower than usually and in the first-person view it still looks like the player was still swimming, but when in third-person mode (or as seen by another player) you see that the player is actually standing. If you sneak, the first-person view will jump up inside the block above.
If the block above the player is solid (in the example: the red glass block), the player will suffocate when sneaking (if in survival mode) and won't be able to leave the block it is in without destroying any blocks.
To reproduce
- Build this:
- Go into the water and start swimming
- Swim into the one-block high gap
- Touch the ground or press Space without pressing Ctrl
- Sneak
Video
The bug
The player is able to stand up when swimming through a one-block high gap, the player can stand up even though there is a block above.
The name tag will visually appear lower than usually and in the first-person view it still looks like the player was still swimming, but when in third-person mode (or as seen by another player) you see that the player is actually standing. If you sneak, the first-person view will jump up inside the block above.
If the block above the player is solid (in the example: the red glass block), the player will suffocate when sneaking (if in survival mode) and won't be able to leave the block it is in without destroying any blocks.
To reproduce
- Build this:
- Go into the water and start swimming
- Swim into the one-block high gap
- Touch the ground or press Space without pressing Ctrl
- Sneak
Video
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mojang] Agnes Larsson](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Agnes Larsson![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
relates to
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
relates to
relates to
relates to
At first I was gonna argue that this bug has nothing to do with 1.12.2 (new swimming is a 1.13 thing), but ever since the elytra's hitbox was changed about 2.5 years ago, the visually-standing-but-eyes-in-knees thing has been possible. Seems like blocks that have no repelling properties if you were to stand within them will switch you to 1x1 elytra mode the moment you swim under them like this. This bug used to happen with all solid blocks too, but 18w20a fixed it via MC-128472 (while overlooking the fact that it's still happening with non-pushing blocks like glass). I just wrote a wall of text over there that was partially about how it shouldn't be marked as fixed since it's still half-broken, but it was mainly elytra/animation talk.
But anyway... I guess that makes this a dupe of MC-128472 rather than a "relates to" like it currently is? Then again maybe not, since the other half of this report talks about the actual "air swimming" itself, which I also hope is here to stay, albeit with a proper animation so that it doesn't feel like some kind of bug...
P.S. It's incorrect to say that you can no longer pass under solid non-transparent blocks during the stand-up bug. Just need to sprint.
![[Helper] gaspoweredpick](../../../data/avatars/users/80904.png){kind=small}
Duplicate of MC-128472
I believe this was a result of fixing MC-128472 (which I found one more way to break - I already left a comment there about it). Basically, if you're swimming in a 1-tall gap or otherwise have a block above you preventing you from standing upright, you'll constantly get pushed up or down based on how far up or down you're currently looking until you're actually able to stand. I believe the reason for the momentum is that the game doesn't realize you're not sprinting forward anymore (which is normally the requirement to continue being in swim mode), so while it correctly doesn't push you along the X or Z axis after you stop moving, it still affects the Y axis.
This can make mining underwater difficult if your camera is looking above the horizon point, because the game thinks you're not grounded unless you hold sneak while not looking too far up. It's also mildly annoying being forced to bob up and down constantly if you're looking upwards at all.
Easiest way to demonstrate this bug to full effect is to make a 3x3 tower in some water while filling the middle with waterlogged cobblestone walls.
First enter a body of water, and create the main tower with this command:
/fill ~1 ~ ~1 ~-1 ~50 ~-1 sea_lantern
Creative-fly yourself directly underneath the middle of that tower and then fill the middle:
/fill ~ ~52 ~ ~ ~2 ~ cobblestone_wall[waterlogged=true]
Then /give yourself a debug_stick and set the "up" value of all the cobblestone walls to false with it (the reason for not adding up=false in the fill command is because it would only affect one wall at a time, so it's much quicker to use the stick).
Now just enter the tower, tap sprint for a moment to enter swim mode, and simply look up and down to experience the effects of this issue. The game sees that the cobblestone walls are still there, so it doesn't allow you to exit swim mode, and thus, you get to see the problematic artificial gravity in all its glory rather than just along the underside of some random blocks.
P.S. This momentum affects your gravity while swimming on land as well (but isn't strong enough by itself to lift you off of the ground). It's especially easy to tell this fact with the current 1.13-pre4 bug where you can't automatically stand back up without water (MC-132064).
P.P.S. This tower is also a great way to demonstrate a different bug, MC-129773. Make sure not to confuse the main bug I'm reporting here with that one (you should only be moving the mouse once you're in swim mode, don't touch movement keys afterwards). The other report is about automatically being shot upwards due to actively moving towards walls while standing within waterlogged blocks.
Confirmed in 18w19b
I don't think this should be marked as fixed. The change that was made in 18w20a seems to have to do with canceling your sprint as well as making you float upwards slightly as soon as you look above the horizon point of your view, but that aside, this fix only works when opaque solid blocks are above you, not transparent ones (I say "opaque" and "transparent", but what I really mean are any blocks that attempt to push you out of themselves versus blocks that don't). So a situation like what's shown in the screenshot/video still happens in full force, since the blocks above are glass, and glass doesn't push you.
All that said, the root of this problem seems to stem from entering the elytra's 1x1 hitbox mode when this bug happens. When they originally fixed the players' hitboxes during elytra flight to actually be as small as they looked, they didn't bother to fix literally everything else that should have come with that, like the eye level when sneaking, or the player model visually standing up after landing in a 1-block high gap despite there being no room to stand, or solid blocks (except the non-pushy ones) just above you still attempting to push you towards nearby air as if you still had a full hitbox (it's difficult to cleanly fly through a pushy 1x1 gap without a firework, and a 1-tall, 3-or-deeper gap is doable but VERY difficult, and such gaps are actually impossible to force through with only a single firework... To win against the pushback with fireworks apparently requires the extreme acceleration (not max speed; that's capped as far as I can tell) of literally 3 fireworks at once), etc. (or is there an "etc."? I think that's actually already most if not all of the major elytra issues that are still somehow around after 2.5 years...).
In other words, what basically should have probably happened was to first fix the core of the problem (the elytra bugs) rather than treating its strangely related symptoms (swimming bugs) with puzzling workarounds (why does the current fix have to cancel your sprint (doesn't prevent sprinting, just stops it if you're not holding forward when you look above the horizon, but maybe swim sprint was never intended to stay active? I'm rambling on about this part because 1.13 is the first time you've been able to sprint in all 4 directions, even if it's only "swim" sprinting and requires you to be touching the floor)? Why does looking above 45° apply slight upward motion so powerful that it absolutely cannot be prevented by sneaking without the help of a magma bubble column? And why doesn't "swimming" in air-filled gaps require any of these things?).
Anyway, some sort of crawl animation might be good for any situations where the player initially lands/swims into a 1-block high air gap. Beginning to think there should just be some kind of crawling ability at this point of the game, but I imagine it's probably simpler for now to just have a separate animation for "swimming" in air gaps (nearby dolphins still buff you if you're "swimming" in air by the way (as in proper swimming animation, not elytra's 1x1 mode), but that might be something to report in a new issue if it doesn't already exist).
P.S. Whatever coding magic was used to fix
MC-125240feels exactly like what the elytra bugs need! Also, I think this issue technically relates toMC-125085.It's indeed not fixed. I'm still able to reproduce in 18w21b.
So I was meaning to comment again during 1.13-pre3, because while I hate to say it, I found out by chance that it's still possible to trigger this bug. XD However,
MC-132064, a new bug in 1.13-pre4, mostly prevents this bug from occurring due to being almost completely unable to get out of the swimming animation while on land. All that aside, here's how you trigger it again in 1.13-pre4:Swim into a 1-tall gap (whether or not the gap itself has water in it doesn't matter), and then poke your head out from under the block (for easier testing, make sure the block you're poking out from is one that doesn't push you out of itself) without moving completely out from under the block. If directly above the middle of your hitbox is water of any kind (or, if this was before 1.13-pre4, this would also include air/any other non-solid block that would normally allow you to stand back up), you enter elytra's 1x1 hitbox mode just like before, a.k.a. "visually standing up inside blocks". Coincidentally, this is how you escape the aforementioned new bug (it's escaped by having any kind of water block 1 block above your feet level, even if your feet level itself isn't in water). I'll write about that over there too.
The fix for this needs to check if your whole hitbox would be able to stand up (just like how the sneaking hitbox works; you can verify the sneak hitbox thing for yourself with a carpet and a trapdoor on the top half of a block directly above it), rather than only checking the block directly above your x/y/z coordinate (at least I assume that's primarily how all this swimming stuff is detecting whether or not to start/stop swimming).
I really think elytra's 1x1 mode just needs to be (or transform into) the land version of swimming (if land swimming is even actually intended anyway). Its bugs need to be properly fixed first of course, but 1-tall gap travel's technically been possible ever since flying minimized your hitbox. Another reason I bring this topic up again is because I believe it functions similarly to the sneak hitbox in that it only fully stands up once there's room for the entire hitbox. Bugs may make it look/act weird, especially the push-back one when trying to get through a gap, but it still only stands up when there's room for the entire hitbox. Also, it doesn't seem like sneaking/elytra 1x1 mode checks for required blocks to stand back up, but rather, just checks if the top of the hitbox would collide with anything solid. From what I can tell with swimming, it requires completely non-solid blocks (well, in the case of 1.13-pre4, it's solely water for now) to stand up rather than basing it on whether the hitbox has room.
P.S. Seems that elytra push-back bug starts when there's a "push-you-out" block up to 1.5 blocks above your feet level; if you're even 0.00000000000001 lower than that (by the way that number is the smallest possible teleport increment), then it won't push you away.
Yes, this is indeed still not fixed.
Looks like 1.13-pre5 also re-broke it in the sense that its behaviour is exactly back to the way I described in my first wall of text (meaning blocks above you that aren't of the "push-you-out" variety cause you to enter elytra's 1x1 mode again).
Sounds like 1.13-pre6 may have fixed it again, but I haven't tested it yet. Can someone else try it?
Seems to be fixed for MC 1.13-pre6.
Nope, it's not fixed.
1.13-pre6 has it acting the way it was before 1.13-pre5, so it's back to happening in the way I described in my second wall of text this time. In short: elytra's 1x1 mode is entered if the middle of your hitbox would have room to stand up, but not the rest of it (seems to me like swim mode is checking for certain blocks directly above your x/y/z coordinate instead of checking whether the player's hitbox would collide with something solid like sneaking/elytra's 1x1 mode seems to do).
As an extra note, the reason I said "any non-solid block that would normally allow you to stand back up" in my second wall of text is because apparently some partially solid blocks don't allow you to stand back up even if there's actually room. For example, closed trapdoors one block above you on the top half of a block won't allow you to stand up even though there's room to do so (unless you jump out of the water to get to the next y coordinate, assuming there's also a "stand-up-able" block above the trapdoor (which causes you to enter elytra's 1x1 mode since the trapdoor is in the way at that point)). Yet when they're open, they're treated entirely like a block you can stand up in (triggers elytra's 1x1 mode if your hitbox would collide with it; no secondary blocks needed).
Piston heads are pretty much the same; swim under a couple of them and you won't be able to stand up between them despite there being room.
Speaking of this bug and trapdoors, I imagine trapdoors in particular are gonna be a guaranteed way to enter elytra's 1x1 mode as long as the game continues to only check for stand-up-able blocks 1 block directly above the x/y/z coordinate of the player, since there's room for players to crawl right underneath trapdoors (therefor it'll almost always only be checking the block above the trapdoor).
I know I sound like a broken record here, and I'll try to stop mentioning it after this, but if the elytra's 1x1 mode got fixed (pushback and the sneak eye level bugs), and was given a dedicated crawling animation while not flying (perhaps even just a copypaste of the swim one), then wouldn't most of these issues disappear? I mean, ever since around the introduction of swimming mode, it seems like the elytra's 1x1 mode was being utilized as some kind of swimming fallback, so the framework feels like it's already there. Would just need to match up the eye level and sprinting differences between the two as well, and bam all set!
Alternatively, if swimming becomes fine-tuned enough to not even need the backup of elytra's 1x1 mode, then that's just as well (albeit a shame since the elytra bugs would probably continue to get left alone, haha).
Seems to be fixed in 1.13-pre7, at least I cannot reproduce it anymore.
Edit: ... aaaand I just managed to reproduce it again.
I attached a video of it happening in 1.13-pre7. If the blocks above the water are solid, you'll get quite in serious trouble if you're in survival mode.
I'm not able to recreate the issue in 18w31a. I built what was shown in the picture. I used stone blocks instead of glass. I was sneaking and swimming up in the 1 Block gap with no Damage taken. This might actually be fixed?
The player doesn't take damage anymore, but it gets stuck at the end of the tunnel if there are solid blocks above. I might create a new ticket about this though, this is slightly different from the original bug I reported.
The issue I'm still experiencing apparently is already described by
MC-131116