can confirm in 1.21.11
can verify in 1.21.11
FWIW, here’s another related log: https://pastee.dev/p/BVg9eVFp
In my case, it looks like a bee was down too low.
To be precise, before following the above commands, do:
Set world to “Peaceful”
Run the second command above (This may not be necessary)
Set the world to “Normal”
Run the second command above again
The bee will do nothing.
OK, now I know what was missing: If I set the world to “Peaceful”, run the second command, of course nothing happens. BUT then I set it “Normal” and still nothing happens. I had done that in the world before running into the problem, but didn’t know it was connected.
I am in creative mode. But this also fails for me for non-player entities. For example, if I summon a nearby parched (also in a pen), and run
/data modify entity@n[type=wolf] angry_at set from entity @n[type=parched]the wolf also fails to get angry. However, if I run get the parched’s UUID and put it into a merge command so I set both at once, as in:
/data merge entity 163ac043-3b47-44be-b643-88aaff94cd0e {angry_at: [I; 577786577, 605832062, -1989529972, 1018961742], anger_end_time: 0}this works. Which seems more evidence that the problem is that setting the values in different commands doesn’t work. (FWIW, this isn’t a solution because in a function I won’t know the UUID of the entity get angry at in advance, so the only direct way to do this is to use “/data modify … set from …”, which has to be in a separate command.)
Yes, this is the solution I’d suggest as well. I’m asking Mojang to do what you suggest to restore the status quo, because red sand has been allowed for a long time.
I don’t see this in 25w43a.
The golem: 12 100 45
Closest banner: -42 101 -22
30-40 blocks away there are many, but nothing closer than that.
I don’t understand what you’re saying/asking
Shouldn’t the mannequin’s head move in sync with the body while in the boat, and face the direction any entity would initially after leaving a boat, with the head and body in sync? (or is that what you’re saying and I’m just not getting it?)
By “ESC never worked”, I mean it never got the popped up UI dialog to release the focus, or maybe more precisely it just grabbed it right back.
I had this same issue, which was resolved as a duplicate of this. However, this seems to be stuck on the creator responding, so the bug isn’t being fixed. I uploaded a video in my bug: MC-301287. Is that enough? I can also verify the bug still exists in 25w35a, which should also cover reinstalling. I’m using MacOS. For me the ESC never worked. I had modified “use” to be a key. Minecraft works as intended if the default binding for “use” is used.
Sorry, I thought lantern was also renamed, not just chain. Please close this, since I can’t (can I?)
No, Use Item is on “Hold”.
However, I have bound it to a keyboard shortcut (“<option>” on my Mac). And when I reset that binding and use the mouse (actually a special click on my trackpad) the behavior goes away.
This is the setting I’ve had forever, at least as far back as 1.8. However, this certainly could be why others are not seeing it (which I presume they aren’t). And this did not happen as recently as 25w33a.
Here it is. Are you not seeing this?
The fix seems incomplete. The armor on a small stand is adult armor, not baby armor, which is what a small stand should have. I’m thinking this comment will re-open this bug, rather than having to file a new one.