This is killing the productivity of my blaze farm. Most blazes get damaged on the way, but more importantly, about half of them are killed before they get to me. Please fix this.
Ah, it turns out the dragon_fireball is being summoned, it's somehow invisible. kill @e[type=dragon_fireball] says it killed one even though I can't see it. (FWIW, adding Invisible:0 doesn't change anything, I tried that as a long shot.)
I have also had this problem with a Horse's SaddleItem, which I cannot seem to remove in any way. Also not working: Setting the count to 0, setting the id to 'air', both, setting it item to {}, setting it from a horse without a saddle...
Oh and also – why aren't those original two goats entirely overlapping? 900 % 360 is 180, as you say, so two goats summoned with the same rotation should look like one goat. Try it with any other mob.
There is something wrong with summon rotation and goats...
I just tried explicit rotation commands that also acted weirdly. First I tried to right their rotation
/execute as @e[tag=goat] run data merge entity @s
{Rotation:[90f,0f]}
This didn't affect them. Running the same command with a rotation of 270f caused them to align themselves along the Z axis, with a few degrees of shift. For me, that is a rotation of 0. "data get" tells me that the goat thinks it's rotated at 270. Other various rotations pretty much either fail to move the goat, or just move it a few degrees off of 0.
@tryashtar can you give an example? I find that the the non-JSON string is simply rejected by the command parser and so never executed. And, say, to remove horse armor I've tried things like setting the specific armor slot to "air" or to Count:0, which don't work.
I agree that this works for CustomName, and I'd guess for other string properties.
However, my bug was marked a dup of this one, and I was looking at non-string properties, such as SaddleItem. And it does not work (afaict) for a horse's SaddleItem. I tried
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value ""
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
{id:""}
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
{id:"",Count:0b}
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
{id:"",Count:0}
Other things that don't work: {}
{id:"\"\""}
So it's a workaround for some cases, but not all I'm afraid.
FWIW, making sure the location is along a wall where the painting will happily stay does not seem to affect this problem, but I didn't run that down entirely to ground.
Um, maybe so? I don't know. But what is the advantage of this change? Who is better off because of it? I can certainly cite folks who will be worse off, starting with me, but I am surely not the only person who uses stored commands from command blocks and functions. So that's on the negative side. What's on the positive side?
Or should they just randomly change attribute names each release? And if not, why not? When you answer that, you have answered why this should be fixed.
But also, if mojang is going to change property names to a common case approach, that makes it much, much more important and useful to do property lookup ignoring case. If they did that, then a case change would break much less.
Ah, so if someone changed the case of every property at every release using RanDoM CAPiTAlizATioN, that would be OK?
This is only a "request for format change" if you ignore the reason for the request, which is to unbreak something that got broken. Where I've worked, that would be bug (maybe a low priority one) unless the change was intentional. You may not guarantee the format, but you should guarantee that you won't make changes capriciously. This feels capricious, accidental even. Either there's a reason for the change, and it's not a bug, or there isn't, and it is a bug.
As far as gameplay, does its usability in commands count? Because commands that used to work on all kinds of (say) slabs will no longer include all kinds, just all kinds except bamboo. That's how I personally ran into this.
You have no way of reporting a common problem that spans multiple bugs? Large scale problems that have been reported only at smaller scales may not be noticed? Reported?
Since /data remove does not work, there are hundreds of individual bugs that could be logged by someone with the patience to do so. Or you could be made aware that there is a systemic problem lurking among the others.
I was doing this all in functions and replacing both halves. But that doesn't work either. The space has to be air (maybe water works too). You can't replace a door with another door. You can only remove the door via fill or such and then place a new door. (The wood function did that, but I'd forgotten (years have passed). So yes, wood and copper behave the same.)
Yes, I agree this is a duplicate of MC-192791, sort of. I'll leave a comment there.
A simple fix might be just to define the behavior of setblock/fill for multi-block "blocks" (doors, tall grass, ...). Define
setblock 0 0 0 oak_door[facing=east]
to implicitly mean to set (0 0 0) to the bottom half and (0 1 0) to the top half, copying any other state. (Maybe this is what Dhranios meant, it sort of sounds like it, but I wasn't doing this in 1.15 so I'm not sure.)
which I submitted earlier. It seems reversed, in that here the nbt path does not require the prefix, where there it does. I put this in just to potentially add useful info, but I'd personally guess they have different fixes.
It is intended that users have to remember a few random instances in which "minecraft:" is required, when 99% of the time it is not? "Not fixing in the next release, priority too low" would make sense. But "we're happy with this, it seems good!" has got to be wrong.
I've created a datapack with the mcfunction file in it, created a world with that pack, and uploaded it. In that world, run
/function p:foo
The data command is better as:
/data get entity @e[tag=banner_stand, limit=1] HandItems
Just so you don't have to play around with the UUID in the command.
You've misunderstood me, I think. I noticed the bug because I have my own authors for my versions, and those are the ones that matter to me, and which don't get translated. I was reporting using the default values so that you could see it wasn't an error of mine.
But fwiw, your current en_us.json (1.21.4-pre1), on line 5660 says:
painting.minecraft.wind.author": "Mojang",
So you do provide them. That's why I reported the bug using them.
If you're saying that the entire idea of an author for these four paintings was deprecated so no resource pack can ever assign an author to them, well, that's just weird, especially because I can assign a title to them.
I'm not sure if you'll see this because you resolved it, so if you don't seem to see it, I will file a new bug with a more precise description. It might be easier if you allowed a bug to be reopened once.
OMG, I figured it out – you didn't want authors for some of your painting images so you removed the ability for anyone to set authors for their own versions of those paintings.
"wither" is also non-author-able, and it's not an unused painting.
This is not a good choice. Mojang could have removed authors by removing them from en_us.json (and the other language files). Then they wouldn't be making a choice for everyone everywhere, just for Mojang. Instead, now it's just not possible for someone to create a version of Wither and get in-game credit.
Thanks for the added explanation, I really appreciate it! I just don't understand why Mojang didn't just remove authors from its files rather than, effectively, forbid everyone from ever having authors. Thanks if you have an answer for this.
I'm pretty sure I know why this is true: It seems to me that the list of messages (lines) on a sign must either be all simple text or all compound text. The following seem both to be legal 'messages' values:
When you create a sign, it starts out with plaint text: ["", "", "", ""]. But when you subsequently try to set a specific line to a compound object, such as to have a click_action, that is considered improper, and is rejected, pretty much silently.
So right now, the only way to have a sign with a compound text is to set all the lines to compound text, you can't just change one.
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.
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.
(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!)
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:[
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?
Ken
MC-131651
Low![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
2021-04-04_17.49.59.png
This is killing the productivity of my blaze farm. Most blazes get damaged on the way, but more importantly, about half of them are killed before they get to me. Please fix this.
I had not changed the banner base pattern to high res, so there was an inconsistency in size. Fixing that fixed this problem.
The reason I care, by the way, is that I'm working on textures, and it's hard to see how something looks if I can't see it in a world.
Ah, it turns out the dragon_fireball is being summoned, it's somehow invisible. kill @e[type=dragon_fireball] says it killed one even though I can't see it. (FWIW, adding Invisible:0 doesn't change anything, I tried that as a long shot.)
Just attached my default.json file, since the pasted version I hard to work with.
I have also had this problem with a Horse's SaddleItem, which I cannot seem to remove in any way. Also not working: Setting the count to 0, setting the id to 'air', both, setting it item to {}, setting it from a horse without a saddle...
Just to make it clear – this seems to be general. I can't remove saddles from horses, items from frames, ...
Admittedly so, but the result is the same with 90 (see attached). Sorry for the original typo.
(Huh, this addition didn't reopen the bug. I'll file a new one in a day or two if needed.)
Oh and also – why aren't those original two goats entirely overlapping? 900 % 360 is 180, as you say, so two goats summoned with the same rotation should look like one goat. Try it with any other mob.
There is something wrong with summon rotation and goats...
I just tried explicit rotation commands that also acted weirdly. First I tried to right their rotation
/execute as @e[tag=goat] run data merge entity @s
{Rotation:[90f,0f]}This didn't affect them. Running the same command with a rotation of 270f caused them to align themselves along the Z axis, with a few degrees of shift. For me, that is a rotation of 0. "data get" tells me that the goat thinks it's rotated at 270. Other various rotations pretty much either fail to move the goat, or just move it a few degrees off of 0.
@tryashtar can you give an example? I find that the the non-JSON string is simply rejected by the command parser and so never executed. And, say, to remove horse armor I've tried things like setting the specific armor slot to "air" or to Count:0, which don't work.
Ah, yes, thanks, good to have this in the text!
I agree that this works for CustomName, and I'd guess for other string properties.
However, my bug was marked a dup of this one, and I was looking at non-string properties, such as SaddleItem. And it does not work (afaict) for a horse's SaddleItem. I tried
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value ""
{id:""}/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
{id:"",Count:0b}/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value
{id:"",Count:0}Other things that don't work: {}
{id:"\"\""}So it's a workaround for some cases, but not all I'm afraid.
Still true in 1.17.1
Following up, I have found that my specific problem about saddles can be solved using the /item command, as in:
/item replace entity @e[tag=armor_horse] horse.saddle with air
For some reason, there is no "remove" subcommand of item
This is not a general answer, it only works for attributes that are supported in the item command, but it's a workaround for some cases.
Agreed, pilot error, sorry to bother you.
FWIW, making sure the location is along a wall where the painting will happily stay does not seem to affect this problem, but I didn't run that down entirely to ground.
Also, I cannot seem to rotate a painting using the tp command on it, which is a workaround I just tried.
I see the real problem is this:
The property "Facing" is now "facing".
This is also a bug: You have broken whatever scripts are out there that expect the property name to remain unchanged.
But it's a different bug, and I will file that. Please close this one.
That other bug is
MC-251815Um, maybe so? I don't know. But what is the advantage of this change? Who is better off because of it? I can certainly cite folks who will be worse off, starting with me, but I am surely not the only person who uses stored commands from command blocks and functions. So that's on the negative side. What's on the positive side?
Or should they just randomly change attribute names each release? And if not, why not? When you answer that, you have answered why this should be fixed.
Yes, MMK21, I agree.
But also, if mojang is going to change property names to a common case approach, that makes it much, much more important and useful to do property lookup ignoring case. If they did that, then a case change would break much less.
Ah, so if someone changed the case of every property at every release using RanDoM CAPiTAlizATioN, that would be OK?
This is only a "request for format change" if you ignore the reason for the request, which is to unbreak something that got broken. Where I've worked, that would be bug (maybe a low priority one) unless the change was intentional. You may not guarantee the format, but you should guarantee that you won't make changes capriciously. This feels capricious, accidental even. Either there's a reason for the change, and it's not a bug, or there isn't, and it is a bug.
This is a problem with bamboo for all tags, pretty much. The only tags bamboo appears in are bamboo_plantable_on and flower_pots.
As far as gameplay, does its usability in commands count? Because commands that used to work on all kinds of (say) slabs will no longer include all kinds, just all kinds except bamboo. That's how I personally ran into this.
Oh, also I'm seeing this in prerelease 2, so it's still there.
Well, still true in final 1.19.3. Sigh.
Yes, Dhranios's comment fixed it, thanks!
My point is that there should be no stems. Petals that fall to the ground from flowers on a tree don't have stems.
You have no way of reporting a common problem that spans multiple bugs? Large scale problems that have been reported only at smaller scales may not be noticed? Reported?
Since /data remove does not work, there are hundreds of individual bugs that could be logged by someone with the patience to do so. Or you could be made aware that there is a systemic problem lurking among the others.
But you won't accept that?
I was doing this all in functions and replacing both halves. But that doesn't work either. The space has to be air (maybe water works too). You can't replace a door with another door. You can only remove the door via fill or such and then place a new door. (The wood function did that, but I'd forgotten (years have passed). So yes, wood and copper behave the same.)
Yes, I agree this is a duplicate of
MC-192791, sort of. I'll leave a comment there.A simple fix might be just to define the behavior of setblock/fill for multi-block "blocks" (doors, tall grass, ...). Define
setblock 0 0 0 oak_door[facing=east]
to implicitly mean to set (0 0 0) to the bottom half and (0 1 0) to the top half, copying any other state. (Maybe this is what Dhranios meant, it sort of sounds like it, but I wasn't doing this in 1.15 so I'm not sure.)
I'm not sure if this is related to
MC-269271which I submitted earlier. It seems reversed, in that here the nbt path does not require the prefix, where there it does. I put this in just to potentially add useful info, but I'd personally guess they have different fixes.
Found another case: On an armor stand holding a shield,
does nothing, but
works
Thanks! Is there a writeup on this that I missed? I've read most of the snapshot release notes, but didn't catch this.
It is intended that users have to remember a few random instances in which "minecraft:" is required, when 99% of the time it is not? "Not fixing in the next release, priority too low" would make sense. But "we're happy with this, it seems good!" has got to be wrong.
I've created a datapack with the mcfunction file in it, created a world with that pack, and uploaded it. In that world, run
The data command is better as:
/data get entity @e[tag=banner_stand, limit=1] HandItems
Just so you don't have to play around with the UUID in the command.
New World.zip
This is also in 24w12a, and the bug still exists here.
You've misunderstood me, I think. I noticed the bug because I have my own authors for my versions, and those are the ones that matter to me, and which don't get translated. I was reporting using the default values so that you could see it wasn't an error of mine.
But fwiw, your current en_us.json (1.21.4-pre1), on line 5660 says:
So you do provide them. That's why I reported the bug using them.
If you're saying that the entire idea of an author for these four paintings was deprecated so no resource pack can ever assign an author to them, well, that's just weird, especially because I can assign a title to them.
I'm not sure if you'll see this because you resolved it, so if you don't seem to see it, I will file a new bug with a more precise description. It might be easier if you allowed a bug to be reopened once.
OMG, I figured it out – you didn't want authors for some of your painting images so you removed the ability for anyone to set authors for their own versions of those paintings.
"wither" is also non-author-able, and it's not an unused painting.
This is not a good choice. Mojang could have removed authors by removing them from en_us.json (and the other language files). Then they wouldn't be making a choice for everyone everywhere, just for Mojang. Instead, now it's just not possible for someone to create a version of Wither and get in-game credit.
Thanks for the added explanation, I really appreciate it! I just don't understand why Mojang didn't just remove authors from its files rather than, effectively, forbid everyone from ever having authors. Thanks if you have an answer for this.
More detail: I had a log on fire in a room, and several wood items a few blocks away. Those blocks caught on fire by the time I noticed them.
For me, this will work:
/data merge block 33 101 -4 {front_text: {messages:[{text:"hi"}]}}I'm pretty sure I know why this is true: It seems to me that the list of messages (lines) on a sign must either be all simple text or all compound text. The following seem both to be legal 'messages' values:
["", "hi", "there", ""]
[\{text: ""}, \{text: "hi"}, \{text: "there"}, \{text: ""}]
When you create a sign, it starts out with plaint text: ["", "", "", ""]. But when you subsequently try to set a specific line to a compound object, such as to have a click_action, that is considered improper, and is rejected, pretty much silently.
So right now, the only way to have a sign with a compound text is to set all the lines to compound text, you can't just change one.
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.
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:
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!)
This has broken all my book creation commands as well. It's pretty hard to make a valid book (with a command) without newlines.
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?