kcrca

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.

I just tested something, and found this was my mistake. I can’t mark this closed myself or I’d do so.

Fair question. I looked and saw many messages like the following:

[00:39:53] [Server thread/WARN]: Failed to parse equipment: Duplicate entry for key: 'b[type=minecraft:banner_patterns, removed=false]'; No key pattern in MapLike[{color:"cyan"}] missed input: {banner_patterns:[],"minecraft:banner_patterns":[{color:"cyan",pattern:"minecraft:stripe_bottom"}]} missed input: {offhand:{components:{banner_patterns:[],"minecraft:banner_patterns":[{color:"cyan",pattern:"minecraft:stripe_bottom"}],"minecraft:base_color":"white"},count:1,id:"minecraft:shield"}}

I say "many" because the function actually creates 40+ shields this way with the same issue. Is this telling me that "cyan" must be "minecraft:cyan"? Until the introduction of components, "Minecraft:" was assumed in front of names if no namespace was specified; now it is required for components themselves. Maybe this is one of the places where "Minecraft:" is now required? I don't think so, because (as shown) the manually entered command is exactly the same as the one in the function, why would the namespace be required in the function and not in the chat command inputs?

This has broken all my book creation commands as well. It's pretty hard to make a valid book (with a command) without newlines.

Actually, I take it back, I can't find a real workaround. I just noticed that the sign lines are converted to simple text if they are all basic compound nodes (with only a 'text' field). So I cannot set up my sign to use compound text for when I add a click_action to it. I am restricted to simple text, or compound tags with at least one non-simple compound tag.

This means that my two example legal values are only sorta true. The compound one is legal when setting, but it converts to the simple one automatically.

But the following isn't even syntactically legal:

/setblock 34 101 -4 pale_oak_wall_sign[]{front_text:{messages:["", {text: "hi"}, "there", ""]}}

I can do this:

/setblock 34 101 -4 pale_oak_wall_sign[]{front_text:{messages:[{text: ""}, {text: "hi"}, {text: "there"}, {text: ""}]}}

But then look at the output of /data get block 34 101 -4:

[22:55:12] [Render thread/INFO]: [System] [CHAT] 34, 101, -4 has the following block data: {back_text: {has_glowing_text: 0b, color: "black", messages: ["", "", "", ""]}, is_waxed: 0b, x: 34, y: 101, z: -4, id: "minecraft:sign", front_text: {has_glowing_text: 0b, color: "black", messages: ["", "hi", "there", ""]}}

Now it's all simple text.

(Let me say that I think the stuff you're doing to eliminate the special JSON syntax is very cool, this is just one of the edges that needs cleaning up, but generally, THANKS!)

I should note that while there is a workaround, it is quite ugly. In effect, it means that unless you know in advance whether there is any compound text, you really don't know how to set text on a sign successfully unless you want to set it all.