Remin

I guess this should be marked as WAI rather than Invalid then? Did a search for what you said and found a comment by Searge in MC-66943.

Gotta admit I'm just as confused as the guy replying to Searge there, feels rather weird that bugs cropping up from commands dedicated to editing entity data are considered WAI. Have there been any recent statements from the devs still saying so? Because that thread is nearly 4.5 years old now, and I can't find anything more recent. I don't think it's appropriate for such an old comment to still be thrown around (especially since 1.13 was a big update to relevant commands), unless their stance even now is confirmed to be the same.

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).

Yeah I'm not entirely sure either, but at the very least it's completely missing its hitbox when all of its states are set to false, which doesn't seem right. Then again, the hitbox for vines seem to have changed in 1.13 in the sense that it only has a thin hitbox on each side set to true (thin vine hitboxes exist in 1.12 as well, but only when a single face is set to true). So the missing hitbox thing in 1.13 might actually be WAI since it technically has no faces.

Also I don't think it's quite the same situation for redstone wires, since their default "all-false" state (technically they have "directions" rather than true/false states) is to just be a single blotch on the ground.

In the end, I think this might actually be more of a problem of the southern vine face being rendered despite everything being set to false. Maybe vines should be the same as all-false cobblestone walls in regards to total invisibility? That could for example give it use as a niche invisible fall damage prevention block for map creators, or a fake slowfall (not sure if a bug (it's inconsequential if so; beneficial in fact), but unlike in 1.12, vines aren't updated by blocks placed below them in 1.13, so it's/it'd be possible to make a fake slowfall/invisible ladder).

1.13-pre6 note: Bug behaviour is back to how it was before; tower example works again.

The thing is, hostile mobs aren't the only things that naturally despawn these days, and when it comes to 1.13 oceans in particular, it causes absolutely massive lag. I can't speak for how laggy it is as a server host (my tick rate by myself is completely unaffected in 1.12 when it's just squids constantly spawning/despawning), but oceans never lagged me to such hardcore levels until the new water mobs. Now my ticks get slowed down by about 80% in 1.13 oceans when things are constantly spawning and despawning due to this bug.

Also figures I'd find this report immediately after I create one about this exact problem XD (MC-132406)

...Whoops. Literally 30 seconds after I posted this, I spotted MC-91621, which is pretty much exactly the same report. I'd like to emphasize how awful the tick lag is with the new water mobs though; it's seriously terrible.

Special note for 1.13-pre5: Since it looks like the devs are having a terribly hard time deciding how the heck they want swim mode to work, my tower example doesn't work anymore. However, now all you need to do is simply enter swim mode in any body of water (since currently you can't get out of that mode while in regular water) and you'll experience it to full effect just like the tower would have shown. The problem should be especially prevalent now that fully showing off its effects no longer requires a special setup (the point of which was mainly to highlight how annoying it is to control and how strong the up/down force is) and is instead currently happening by default.

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).

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.

Technically not quite fixed in 1.13-pre3 since the particles are appearing just below the surface of water now (and instantly disappearing as expected since that type of particle doesn't survive in water). Seems like the rain is treating the bottom of sky-exposed water blocks as the surface instead of the top of them (this includes flowing water, though particles'll often successfully appear in the shallowest flows).

Oh, nice! Didn't realize this got fixed last week until just now. It's missing from the list of fixes on the Minecraft pre-release page.

What the... Welp, I guess I got ninja'd when I posted MC-131075, because this report didn't exist when I was originally writing mine, haha (the time stamps disagree, but I'm generally fairly thorough when trying to find already-existing reports, so I really don't know what happened here... maybe I fell asleep and finished writing it later or something). Feel free to check out my report if anyone wants to see more info on this bug.

This is happening because that bottom water source is actually being deleted by the above water source. MC-128860 is the cause of this (I feel like MC-130530 is a dupe of that one, but it's been marked as "related to" instead, so I'll leave it up to the mods to decide which one this bug report is a dupe of), see my latest comment there (as of writing) for a bit more explanation.

P.S. If you need that 2x1 setup for a map/decoration or something, it'll work correctly if you first place the grass and then put the water on top.

Still happening in 1.13-pre1, which mostly follows the same conditions I wrote about in my previous comment here.

Basically, if a water source is directly above another water source (one that isn't infinite), the below source gets destroyed by the top one due to directly flowing into it. The only difference between the way the bug worked previously is that two water sources have to be directly on top of each other now instead of just having any ol' waterfall pour down into one.

Still happening in 1.13-pre1.

I'd also like to add that this bug doesn't affect only the blocks mentioned here; it affects ALL waterloggable blocks that have water in them. Aiming at the water source that the block is in makes the game think you're aiming at the block's hitbox, even if you're not. Came across this bug just a bit ago when I noticed the game was forcing me to target a sign when I was trying to test a different bug.

Still happening in 1.13-pre1

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.

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-125240 feels exactly like what the elytra bugs need! Also, I think this issue technically relates to MC-125085.

Isn't this a duplicate of MC-125240 (which has since been fixed) rather than a "relates to"?

Still happening in 18w20a.

Also, a water source block is only destroyed if it wouldn't be replaced by standard infinite conditions. Oceans still count as an infinite source here, despite the current bug of making holes in oceans with buckets and whatnot, so you're not gonna drill a hole in the ocean with a waterfall or anything. Of course, it could just be that the water source is still actually being destroyed but then instantly getting replaced by a new water source. Either way, water sources shouldn't be getting destroyed when water flows into it from above. Key word is "into" - a water source won't be destroyed by water directly on top of it until that water actually flows down into the source, so waterfalls are literally destroying water source blocks.