VeilStar

Oh yup. I didn't manage to find it before reporting. my bad.

Why "Won't Fix"? As minor of an issue as it is, surely there's no harm in leaving it open and fixing it one day (like a lot of other issues)?

This is not entirely fixed but I'm not sure if a new issue should be opened or not.

This still occurs in the following situations:

• If the project entity is created inside of another entity it ignores collisions with that entity. For example when throwing a snowball or ender pearl while your hitbox is slightly clipping inside another entity the projectile won't collide with this other entity. The entity's hitbox size is irrelevant here. This works even using a giant.

• Projectiles created by the player can still ignore collisions with the player that created them even after the projectile leaves the player's hitbox and collides with it again shortly after. This is most noticeable with arrows and splash potions, especially when throwing them straight up. The easiest way to reproduce this is by sneaking over the edge of a block while in at least 3 deep water and throwing a splash potion straight up. The splash potion will travel up, go outside of the player's hitbox, fall back down, completely ignore collisions with the player's hitbox, and continue sinking down in the water until it lands on a block below.

Just ran into this exact issue when attempting to optimize a datapack. Correct me if I'm wrong, but this means that any items created by a tile entity can't be handled by functions during the first tick of their existence regardless of what you do, right? Meaning that any work-around that could be done using functions would essentially involve waiting for the next game tick?

And 1.15 as well.

And 1.15 Pre-Release 7, but you might as well wait until 1.15 is released to update the ticket at this point... :/

Still affects 1.15

Still an issue in 1.15 Pre-Release 6

Still an issue in 1.15 Pre-Release 6

This is still an issue in 1.15 Pre-Release 1.

Looks like this got fixed along the way with all the recent rendering changes.

Nope. Seems fixed. Please close.

This seems to have been fixed at some point during the most recent bunch of snapshots for 1.15. Lily pads now generate even more frequently than they used to back in 1.12.2.

@ Jonathan

For context: This ticket was specifically regarding the player getting stuck inside a block upon teleporting through a gateway. What would happen was that you would get teleported clipping slightly inside the block you were supposed to be teleported on top of, and you were unable move out of the block through normal movement (walking, sprinting, jumping). You had to teleport (via ender pearls or other means), use water to swim up, or mine the block to unstuck yourself.

If this block you were clipping in was at the very edge of an island you would get pushed off the edge and fall the void with little you can do to save yourself. This itself isn't really an issue or specific to this issue, but just a game mechanic where you get pushed towards air if you're inside blocks that have air on at least one side.

Here's a video that shows the issue: https://www.youtube.com/watch?v=dlX73SOpOXU&feature=youtu.be&t=105

I'm not sure if the player clipping inside the block (and being stuck inside it) was caused by the 'crawling' feature (in which your hitbox becomes much smaller if your head is inside a block but your feet are not) that was introduced or not, but either way this sure appears to have been fixed as I personally haven't experienced it since. You now get teleported on top of the block.

Anyway, whether you're still experiencing the exact same issue or a slightly different one, create a new ticket if there isn't another one that already describes the exact issue.

Resolved in a future version according to a duplicate issue @ MC-152172

https://bugs.mojang.com/browse/MC-151399

This issue affects more than what is currently mentioned in here.

Any time the player (attemps to) break a block, but the block isn't broken server-side, the player gets teleported back to where they were when they broke that block.

This issue appears when running around while clicking the ground with a sword in creative mode I assume because the client is actually still sending 'block interaction packets' as they are technically still 'mining' the block. However, neither the client nor server break the block because the player is holding a sword.

This same issue can also be observed in survival mode when the server is lagging as the lag introduces 'block lag'. Block lag is when the player mines a block but the block re-appears due to not (yet) being broken server-side because of the lag. Before this issue was introduced the block re-appeared and that was that. Since this issue was introduced the player also gets teleported back as soon as the block re-appears. (Here's a video showing this on a vanilla singleplayer world where I caused excessive server lag for the purpose of demonstration.)

Also, while I know this isn't relevant for you guys, this issue also affects modded servers where the player isn't allowed to break certain blocks or blocks in certain areas. The block gets broken client-side, but then re-appears for the client in the next (server) tick, and since 1.14.4 (Pre-Release 4?) the player gets teleported back to the location they were at when they broke the block client-side. (Here's a video of that on a spigot 1.14.4 server with a plugin that offers such functionality.)

This is almost certainly caused by the fix for MC-156013, and MC-156852 might be in the same boat. What is the point of pre-releases anymore if changes introduced in them cause more issues than they solve and make it into the final releases for a version? Anyhow, my point is that fix implemented for MC-156013 is plain bad and I can't trust you guys to not fix this issue by doing something equally bad, like adding a check that doesn't teleport the player back if they're holding a sword.

With that said, a better fix for MC-156013 using the current method is probably to teleport the player back only if the player's hitbox intersects the re-appearing block. This would get rid of this issue as well.

Seems to be resolved. I can no longer reproduce this in the latest snapshot (1.14.4 Pre-Release 2). Please close I guess.

So....

The main thing that is described in this bug report has been resolved 6 days ago in a duplicate bug report at MC-153665 apparently, and the assignee for this bug report has been changed to no one a day after that happened, yet this bug report is still marked as in progress.

I still don't know the limitation that makes villagers only able to pick up a maximum of of 4 stacks for potatoes and carrots that was introduced at some point during 1.14.3 Pre-Release 1 is intended behavior. Is it? Is it not? Do I repurpose this bug report to be about that? Should a new bug report be created instead? Should this one be closed?

Duplicate of MC-152088 / MC-152168 ?

Not sure what your point is KennyTV. I didn't say the title is inaccurate or anything. I simply asked for "FOV" to be added somewhere in the bug report so that it's easier to find.

Reason being is that this bug also affects the FOV (which is a symptom of sprinting, yes), and the FOV not changing correctly was first and only thing I noticed about this bug for a little while, leading me to create a duplicate bug report as I didn't find this one. I realized later that there was more to it than that. Had "FOV" been anywhere in the bug report I would have found it immediately and not wasted people's time. I don't see the harm in it being added.

Anyway, FOV has since been added to the labels, which is all I was really looking for.