clipka

As an added note: While it takes a copper golem 7 hours to oxidize to the next stage, it takes maybe a minute for a fully oxidized copper golem to turn into a statue. I would expect either

(a) a fully oxidized copper golem to turn into a statue immediately, or

(b) a fully oxidized copper golem to take the same time to turn into a statue as it takes for a less oxidized copper golemn to oxidize to the next stage.

Sorry, mistyped: Still present in 1.21.9 of course.

Still present at least in 2.21.9.

I wholeheartedly agree. Other mobs only occasionally try to pathfind in opposite directions, and if they do, we rarely care much. With Copper Golems, on the other hand, it is a common scenario, given that we may want to employ more than one to carry stuff from A to B, where they inevitably will have to pass each other in opposite directions.
What makes the situation even more frustrating is that it happens even if there is ample space for the golems to pass each other, just because they stubbornly insist on exactly following their chosen path, and not caring a jot whether something’s in their way.

Here’s a suggestion for a solution, which I think should be almost trivial to implement:
Just have Copper Golems always try to walk at an offset of 0.25 blocks to the right (from their perspective) of the block center while en route. Since they are only 0.49 blocks wide, this way Copper Golems walking in opposite directions would automatically pass each other without even so much as a fender bender.

(As an easter egg and a nod to players living e.g. in the UK or Down Under, there might even be an undocumented game rule to have Copper Golems walk to the left of the path instead.)

If that isn’t an option for some reason, I guess even just ever so slightly randomizing their path would help them to eventually pass each other, rather than just playing an endless game of push and shove.

I would argue that the scaffolding should take precedence, for two reasons:

(1) Formal reason:

The ladder/vine case can be seen not as a special feature of the ladder/vine, but rather a generalization of the "crouch" key preventing you from "falling" in a broader sense. While it's not necessarily the way it must be viewed, it certainly is a way it can be viewed.

As for the scaffolding case, there is no way whatsoever to see it as a generalization of the standard case - to the contrary, it can be argued that it does exactly the opposite as in the standard case: causing you to "fall" rather than preventing it.

Thus, the scaffolding case is arguably a "more special" feature than the vine/ladder case, and since the special trumps the general, the scaffolding feature should take precedence.

(2) Practical reason:

There are legitimate use cases where, while standing both on scaffolding and next to a ladder or vine, you do want to go down - and the current behavior prevents you from doing that. In some situations (e.g. in a 1x1 shaft), there is no viable workaround except changing the build.

There are also legitimate use cases where, while standing both on scaffolding and next to a ladder or vine, you want to not go down - but there is no need for you to make use of the current behavior: All you need to do is nothing, as this will cause the scaffolding to automatically stop your descent.

Turns out my initial search for the issue was not as thorough as I thought; please close as being duplicate of MC-275757

This may even push players upward, namely if the adjacent block is a fence or wall.

Please fix ASAP!

Possibly related to MC-110056.

I think I'm seeing this, too. Running 19w46b here.

I was breeding trader llamas, and I'm sure I left some llama babies behind, but when I returned from some other errand there were no newly grown-ups (which I could easily have recognized because I make it a habit of equipping all adults with carpets according to their stats), nor any llama babies.

Reverting to version 19w44a got my bees "unstuck" - but once I switched back to 19w45b, the bees were stuck again the next time they entered the hive, except for a baby bee "born" in 19w44a (which unfortunately and for unidentified reasons flew away - laden with pollen - without returning to the hive a second time, so I can't say whether it would have suffered the same fate).

I can confirm this for at least one of my hives.

In my experiments, bee overpopulation despite lots of hives seemed to be a factor in triggering this issue (but once they had entered this state, culling the other bees to resolve the overpopulation didn't do any good); luring a lot of bees with a flower also may have contributed, but I couldn't identify a clear pattern.

Silk touching an affected hive and placing it somewhere else seemed to have some effect on the situation, in that individual bees would subsequently pop out their heads for more than just a tick before returning, and one even got "unstuck", but this seems to be neither a reliable nor a permanent cure.

While it may be working as intended, I find this very annoying, and also counter-intuitive when considering how dispensers work with shears: They don't throw those out when facing an empty hive.

Might be related to MC-165173 (though I don't see my bees ever getting as far as shown in the image of that issue; sorry I didn't find that issue earlier, I didn't realize the list of issues presented in the search had multiple pages.

This might be intentional; however, as this is uncommon for Minecraft in particular and ego games in general (not to mention that it is inconsistent with horizontal mouse response) it can lead to motion sickness (rangin from an unspecific feeling of discomfort to dizziness and possibly nausea and headaches) even for experienced gamers, and shound therefore be avoided.

maybe it's actually an occurence of MC-1528?

still present in 13w18c

Same here, 13w18c: I was traveling by boat trying to bring a newly tamed cat back to my home, when suddenly I died because "player hit the ground too hard". Fortunately I was already close enough to home so that I was able to salvage all my equipment. (The cat seems to have died in the accident though.)

still present in 13w18c

Note that since some versions ago, livestock is intentionally unable to push the player around. I'd have expected this to also work when riding.

Tested with 13w16c 13w18c, horses can now be ridden in water as deep as 2 blocks. I would conclude that the current behaviour for deeper water (player is dismounted and horse swims) is therefore intended, at least in general. There's still an inconvenience though in that a swimming horse doesn't seem to actively head for land or more shallow water to give the player a fair chance to mount again.