mojira.dev

clipka

Assigned

No issues.

Reported

MC-279603 Unable to descend scaffolding while standing next to vine or ladder Duplicate MC-275916 Buckets disappear when used Duplicate MC-270919 Advancement "Voluntary Exile" outdated Confirmed MC-165620 Llamas don't breed when a trader is near Duplicate MC-165379 Bees pop in and out of nest constantly Duplicate MC-15203 viewing direction lags while on horseback Duplicate MC-15202 Player can be pushed around by mobs while on horseback Fixed MC-14783 Mouse freezes, then Windows plays standard sound Invalid MC-14778 Zombies spawning in mid-air Duplicate MC-5860 Endermen can place cacti in illegal places Fixed MC-4905 Minecraft crash Duplicate

Comments

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!

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.

Having tamed one of the horses now, I moved away and back again to find another horse gone; like the first missing one, it was a foal. I later discovered that foals occasionally take damage for no sane reason when climbing, so that might explain the missing two.

I just tested with 13w16c 13w18c: Started a fresh Creative standard world, flew into the sunrise, and lo and behold! Right where I hit the first plains biome, there was a pack of four horses waiting for me already. The rather smallish biome also featured another pack of two a good deal away. Crossed a strait into a nearby significantly larger plains biome to find no horses whatsoever, but returning to the first biome the horses were all still there. It took me a while to find another plains biome, but there I did encounter an abundance of horses right away (near a village): A pack of 13 ⚠️ horses & donkeys, two smaller packs, and a solitary one, over 20 all in all.

Returning to the first plains biome with its 4+2 horses, I found that one of them was missing by now, but I suspect it died rather than despawned (I did witness one of that pack take damage earlier).

I think we might be good now.

What's the deal then with making the saddles and armor more difficult to obtain? If it was intentional that horses themselves are nearly impossible to come by, there wouldn't be any point in making the equipment rare as well. As it is now, finding a saddle is still easier than finding a horse in the first place. You do occasionally stumble across the former when exploring caves, but it appears to be virtually impossible to stumble across a horse by pure chance.

As for MC-14269, the original mod seems to feature quite a deal of infighting between creatures, so I suspect their spawning habits are not restricted to chunk creation time. At any rate it allows to customize the spawn rates of creatures. So while the despawning habits of vanilla Minecraft wild horses might be as intended, I suspect (and sincerely hope) their current spawning habits (apparently chunk creation only) are unintentional.

I noticed that it is irrelevant for the bug whether you carry a compass with you while traveling to the nether, or whether you obtain it later.

Still present in 13w17a.

I'm surprised this bug has been left around for so long; it seems to rarely pose a real problem, but when it does it might hit you hard.