kcrca

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?

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”

To reproduce:

• Summon armor stand nearby, with the tag “stand”

• /attribute @n[tag=stand] waypoint_transmit_range base set 10000

• At this point the stand should appear in the locator bar. If not, fix that somehow, I don’t know why it wouldn’t.

• Notice the locator bar “dot” for the stand. It should be one color

• /waypoint modify @n[tag=stand] style set default_0

• Notice the locator bar “dot” for the stand. It will look like the image, a checkerboard with black and some color, possibly a different one than the actual original.

• /waypoint modify @n[tag=stand] style reset

• Notice that the “dot” is still weird.

As a side note, you might notice in the image that the colors in the weird waypoint dot texture don’t correspond to the colors of the waypoints, which are named in the armor stands (for instance, the one in the middle should be a gold waypoint). I don’t know whether that matters or not.