Still happens on 25w05a
Still happens on 25w05a
Additionally, I request this ticket to change its title to "Baby villagers do not drop armor/items when killed"
Can confirm in 1.21.4 and 25w04a, it still happens.
Still happens on 25w04a
A discovery I made is that when a leashed llama is mounted it stops attacking you, unless it is a tamed llama, because in that case it will continue to attack you even when mounted, even if you switch to Creative mode, or even if you are mounted on it on creative mode
Seems to be closely tied to MC-215097 (btw, thanks for giving more specific details and why it happens for Wandering Traders as well)
Can confirm it still happens on 25w03a
I tested both entities' behavior when leashed or unleashed and it does change, even if leashed to a fence
Still happens on 25w03a
I don't know if it happens for any entity they might be leashed to, but for Wandering Traders, it still happens
The reason of why I did report this on a separate ticket is that even with this testing it's not always happening like this, but some weird calculations happen (if you use /data get entity <villager>
, you can see that items being shared aren't in a consistent behavior if you give a villager more than 2 stacks), and also specifically wheat behavior is more inconsistent than other crops, sometimes it isn't shared, other times it is, and I'm not a technical person, but this looks like it's a bug originated from how villager stack-splitting sharing collides with the 24 excess sharing.
This still happens on 1.19.4, technically, but there are different things that are happening here that might better get a new bug report, since this is somewhat inconsistent.
Can confirm this still happens on 1.19.4
Per MCPE-33209 I think this is an appropiate feature for parity. This allows you to not fall from cliffs when you are doing risky things while using GUIs, and would be similar to Bedrock, where they do have this as a feature for touch and controller options. Since this is not the default option but an optional feature, it should remain.
Potentially WAI since it's a variant of Mangrove Roots, and changing it would make it inconsistent with its origin block
I always like when redstone changes in a way that can help more people to understand it. Currently this is pretty much a "Change this because it will break old structures" situation.
I have seen Ilmango's video, and definitely seeing the new behavior I'm pretty happy with it. I'm not the best at redstone and this is useful to get easier systems for non technical players. Redstone behaving more logically opens the possibility for getting more players using redstone, and building potential new contraptions.
This is (kind of) more intuitive for non-technical players though, which makes redstone available for more people. Also, older player-made structures are always subject to break on any game as long as updates go on, sometimes it's just that we need to update our structures.
This is pretty similar to texture reports, where those are either rejected or fixed (like the inventory door items, which got changed due to a report here). This would fall into the grey area of inconsistencies, so it's something that may get ot not get fixed.
Probably intended to make a better transition between 1.17 deepslate blobs/patches and 1.18 deepslate transition.
It also allows deepslate coal ore to generate so it's fine.
Shouldn't be intended, since it makes pandas hard to find, and even more with the new generation. Anyway if that's how it's supposed to happen then just increase pandas' spawning chances.
For me this is an issue like MC-230343+,+ so I don't think this is invalid. This is a new parity break made by a new feature being added, and on a gameplay-related way I'd say that it would help players to know when their worlds are being saved in a more noticeable way if it was similar to one counterpart or another.
I just wanted to comment that, but anyway I'll accept what do you think is right.
Still happens on 25w05a