bugi74

... As I thought as a possible reason in the "Perhaps..." paragraph.

Although, that still leaves a bit of discrepancy between the shown hitbox size (and how it makes a sound without arrow visibly touching water), and when it hits solids (can get pretty close to them without the arrow stopping).  But, I guess that would best be a separate ticket after/if the tick-rate -related part gets fixed.  This one ended up listing 3 "weird things" in one ticket 😛

Oooh, only now watched that video.. the arrow isn't centered in the hitbox.. weird, but explains the doesn't hit solid, but makes sound -thing.

It is almost never "safe to assume", but...

It seems that the attack and pathing behaviors of zombies (and maybe spiders, too) have changed since I last tested this (i.e. very long time ago), too.. I could not reproduce with the old test method, not even to the point of zombies getting as close to glass panes as before (they don't "hug the pane" now, but stay about at the center of the full free block outside). And could not get them to even to try to attack as soon as there was glass in between. So whatever has changed (in addition to those other two issues), a proper fix or not, has apparently made them unable/unwilling to attack through at least glass panes (in normal situations).

Spiders could get closer the glass pane (as they climb it), but no attacks through the pane.

I tried with only 3 zombies simultaneously, so they didn't push each other much towards the pane, as they all tried to get to the center of the same block, not straight towards the player 😛   Perhaps with a bigger horde, some could get pushed against the pane, close enough, but that would then probably be more about the problem of containing too many mobs in too little space.

... Or need new/better reproduction steps to catch the remaining situations, if any left.

@Hubbi GamingTV, slightly incorrect: as described in earlier comments, at least in earlier versions (I have not checked the bug lately), in certain situations one could go as close to the pane as possible without getting hit by zombies.  If it was simply due to hitbox getting through the pane, zombies would have been able hit through the pane in all situations (where the player was close enough).

@Hubbit GamingTV  Correct!  As already figured out in 2012 and described in 2nd, 3rd, and 4th comments of this ticket.

I can still reproduce.

A video would be challenging currently... would a world save with nice instructions do?

Can also spawn on top of packed ice.

Could the description/title be added word ice to help with searches (and reducing duplicates). EDIT: Hmm, actually, there already was a ticket with "igloo" and "ice" and it was not found... Crappy Jira search...

Also, can confirm 21w42a.

Can confirm for 21w38a.

The straight walls at chunk borders were last generated in version 21w17a. The next 21w18a produced current nicer caves.

I have been trying to find more examples of this particular bug (not near water), and I have only found so few "cuts" that they may very well be just random chance of cave shape matching chunk border, and nothing as obvious as they used to be.

Of course, the final confirmation is to look at the code, if it still has similar optimization; if it still subtracts squared distances or not...

In any case, this is no longer affecting the playing experience the way it used to. (At this point, I would not cry about resolving this as "fixed".)

Probably not intentional, per se, but more like expected result of certain game rules.  The "bug" here is more about the mismatch between how things look and how they behave. Take a look at the example image and read my two old comments; soul sand at least looked full height, while lava looks slightly less than full height, yet their physical effects work as if their heights were reversed 😛

I can also confirm on 1.17 (and same feature in the same place in 1.16)

Single-player normal creative.
Seed: 1479112774635546442
761 70 226

 Another right near that one at
743 64 210

Note: they start to get more ice over time, so the effect isn't probably visible for that long.

The 1479112774635546442 examples had at least one case in orientation and distance from water that makes it unlikely to be caused of the water related bugs.

However, it seems that in 1.17 those seed examples are no longer valid or the bug has been fixed. One example cave/something in the above seed has completely vanished...

At least something related to cave carving has been fixed. Trying to check what exactly.

I was able to reproduce in 1.17. Indeed, seems to happen randomly, I needed like 15 tries, some in different ways, before it happened. Last 3 tests I did, as far as I can tell, without moving, simply checked the cat (not sitting), skipping to next night and back to sleep, and on the 3rd (last) one it was outside.

I was able to reproduce in 20w49a. They can still step up from 1 deep water, but not from 2 deep water.

However, if there are more than 1 villager in the "same spot" near land, as they keep pushing each other, they may start jumping, and one of them may get pushed on the land while jumping. A lone villager didn't get out.

My test case was to surround the village bell area (5x5 area) with 3 wide pool of water, with the innermost radius of the pool being 1 deep, rest 2 deep. Thus, when they want to get to the meeting, they will happily find their path all the way to bell area (on land), chat a while, but once the meeting is over and they should get back to work, all they do is to spread to outer edges, and can't get out (unless randomly "helped" by another villager).

(Attached screenshot of the test setup ("test-setup.png").. well, trying to.)

Nixinova, if you have (or don't mind to get) an access to Discord, the official help channel for this "Mojira" is there: https://discord.gg/rpCyfKV

Might also manage to work it out via https://www.reddit.com/r/Mojira

I.e. try and get some mods to get some Mojira admin (probably Mojang staff) to check things out. Perhaps there is some glitch going on or some deeply buried setting or whatnot.

In short: difficult to see if the fly-time-hitbox touches water, but judging from the tests, the hitbox stuff would not even explain the results.

Longer:

Hard to tell; there is too much particles in the way (and difficult to stop at just the right moment). Looks like once the arrow stops, the hitbox is half block height/width/length (cube), so presumably it would touch either the wood block below or the water (or glass) above, but there is big enough range of vertical aims where it does not stick to anything, so obviously the on-the-fly "hit" box is much smaller than that.

While testing more with the hitbox view enabled, I noticed that going further away, maybe 5-6 blocks, there is another distance where the arrow can easily pass through without making splash sound. (I had an idea that maybe the arrow gets somehow "active" only after one block away or something, which would have allowed the near shots to pass through without splash, but considering both the fact that arrow can hit the wood right in front of the player and the silent passes from longer distances, that does not seem to be a valid explanation.)

In any case, after shooting around 100 arrows at different distances and slightly different aims, it is clear (to me) that at suitable distances, it is possible to get the arrow through the gap consistently without splash sound (just have a decent aim), yet at some other distances it seems to be nearly impossible (no matter how many slightly differently good aims through the gap is tried). If the arrow's on-the-fly hitbox would explain the sounds, the sounds should be happening at all shooting distances roughly equally (or slightly more from further away, see below), which is not the case.

For example, at certain distance (around 5ish blocks), aiming (about) horizontally straight through (about) middle gives either consistent splashing, or by moving half a block away (without changing the aim at all), consistently no splashing.  Still at that slightly further distance, aim a tiny bit up and still no splash, move back the half a block forward, and it makes a splash again. I kept testing this while moving back and forth, the result is quite repeatable. Considering how the angles work, the shots from longer distance will have larger vertical spread by the time they are under the water, so they should be "touching" the water more often than when shooting closer. With this particular test case, the opposite was observed.

"If it is just raining, they should work normally"

Based on what information? Wiki mentions "Villagers run inside at night or during rain". Wiki, while not authoritative source, tends to at least document observed (i.e. old and/or current) behavior, so if that has changed to not be intended, please mention the source/reference.

Did this bug come back in the Java edition?

If it came back (or the dripping of liquids through blocks/slabs -"feature" was added) in Bedrock edition instead (and apparently needs to be after version 1.14/Buzzy Bees, according to https://feedback.minecraft.net/hc/en-us/articles/360015877192-Parity-Requests-and-You-A-Guide), it should be reported in the bedrock edition tracker. (https://bugs.mojang.com/browse/MCPE-32639).

I think iPhone would run the bedrock edition (aka pocket edition) of Minecraft; this particular corner of this Jira is for the Java-edition of minecraft...