kcrca
Assigned
Reported
MC-305708
Sugar cane can no longer be placed on red sand
Confirmed
MC-305706
cannot make wolf angry using commands
Cannot Reproduce
MC-303891
Untamed zombie horses and skeleton horses cannot have saddles placed on their saddle slot using /item
Fixed
MC-303071
copper golem poppy not always visible
Cannot Reproduce
MC-302137
Mannequin poses swimming and fall_flying are identical
Confirmed
MC-302136
When changing to standing from sleeping, mannequins fall one block
Community Consensus
MC-302135
Mannequin in sleeping pose is perpendicular to the rotation
Confirmed
MC-301844
/tp on mannequins doesn't handle rotation right
Duplicate
MC-301814
CustomNameVisible does not work for mannequins (for the name, not the NPC annotation)
Fixed
MC-301544
lantern particle not renamed to iron_lantern
Invalid
MC-300701
text input fields in dialogs cannot hold an initial value that is as long as the current value (v2)
Duplicate
MC-298586
text input fields in dialogs cannot hold an initial value that is as long as the current value
Invalid
MC-298193
Warning button in notice dialog stays activated
Duplicate
MC-297305
/data command won't attach leash
Invalid
MC-297195
using /data command to attach boat to happy ghast gets wrong leash display
Cannot Reproduce
MC-297163
/waypoint modify style not working with default styles
Invalid
MC-296707
Ghastling grows into happy ghast even if randomTickSpeed is 0
Fixed
MC-296620
Waypoints not shown unless in multiplayer
Invalid
MC-279879
data values in functions not being applied when summoning
Awaiting Response
MC-279545
Narrator mispronounces "narrator" in English (at least US_en)
Invalid
Comments
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?)
I just copied my details into the older, closed bug. If I had done that originally, would that have re-opened that bug?
When I create a dialog with a text input field, the ‘initial’ field seems to be limited to 32 characters. This means that if I prompt a user for (say) a multiline text value that can have a 100 character sentence, when I ask them to update it I cannot put the current value into as the initial value of the field.
To reproduce, create a dialog with the following content, in (say) the file “dialog/test”:
{
"type": "notice",
"title": {
"text": "Notice"
},
"inputs": [
{
"type": "text",
"label": "Multiline Text",
"key": "multiline_text",
"multiline": {
"max_lines": 5
},
"initial": "sit amet, consectetur porttitor!!"
}
]
}
Now log into the world. You will not be allowed to due to an error (“Errors in the currently selected data pack…”).
Now edit the dialog to remove one character from the “initial” field (such as one of the “!” chars). Then log in. You will be allowed to do so. (Also, the dialog can be displayed, if you care to).
(I will note that this was previously reported as MC-298586, but I did not receive a notice about you needing more detail about how to reproduce the fact that your code has a 32 char limit on a field. Since I cannot reopen that bug, this new bug was created.)
I just tested it on pre-release 3 and it’s working now, so this is fixed.
… by which I mean you can reproduce it with:
/dialog show @a minecraft:custom_options
and doing the actions above: Click the button, dismiss the warning with “back”, look at the button.
FWIW, it happens in all dialogs afaict.
Ah, now I see. I don’t see what it means to have multiple sprites in the list, though. Still, that explains the behavior. Thanks!
Ugh, sorry, my bad. Thanks for pointing that out.
Huh, interesting, I must have misremembered that, should have double checked. Sorry for that.
In any case, the problem with setting a style is a bug, since those are styles you ship, nothing I created, and they aren’t working right. That’s what the bug report title claims as the actual problem in the first place.
“look like the image that I attached to this bug”
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
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:
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.)