DrHenchman
- drhenchman
- drhenchman
- Australia/Sydney
- Yes
- No
MC-117419![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
Advancement conditions with nbt datato not work correctly for inventory_changedAdvancement conditions with nbt data do not work correctly for inventory_changed
I have created a file at <world_save>/data/advancements/zed/challenges/root.json with the following contents:
{ "display": { "icon": { "item": "minecraft:redstone_block" }, "title": "Zedcraft", "background": "minecraft:textures/gui/advancements/backgrounds/nether.png", "description": "Custom goals and challenges for Zedcraft" }, "criteria": { "create_zedcraft_advancement_book": { "trigger": "minecraft:inventory_changed", "conditions": { "items": [ { "item": "minecraft:book", "nbt": "{display:{Name:\"Zedcraft challenges\"}}" } ] } } } }I am unable to get the advancement to trigger using either a Book named Zedcraft challenges in an anvil or by using the following give command:
/give DrHenchman minecraft:book 1 0 {display:{Name:"Zedcraft challenges"}}However if I remove the NBT condition it works correctly for any book, and I know that Minecraft is recognising the NBT string as if I make the syntax invalid in the JSON file, I get an exception in the logs. This could be true for other NBT related conditions/triggers as well, but I have only tested it on inventory_changed
I have created a file at <world_save>/data/advancements/zed/challenges/root.json with the following contents:
{ "display": { "icon": { "item": "minecraft:redstone_block" }, "title": "Zedcraft", "background": "minecraft:textures/gui/advancements/backgrounds/nether.png", "description": "Custom goals and challenges for Zedcraft" }, "criteria": { "create_zedcraft_advancement_book": { "trigger": "minecraft:inventory_changed", "conditions": { "items": [ { "item": "minecraft:book", "nbt": "{display:{Name:\"Zedcraft challenges\"}}" } ] } } } }I am unable to get the advancement to trigger using either a Book named Zedcraft challenges in an anvil or by using the following give command:
/give DrHenchman minecraft:book 1 0 {display:{Name:"Zedcraft challenges"}}However if I remove the NBT condition it works correctly for any book, and I know that Minecraft is recognising the NBT string as if I make the syntax invalid in the JSON file, I get an exception in the logs. I tried it with written_ book as well with a 'title' condition as well as with various different title/name strings. This could be true for other NBT related conditions/triggers as well, but I have only tested it on inventory_changed.
The following advancement use to work in 1.12.x
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "location": { "dimension": "the_end" } } } } } }From the wiki:
The villager the item was purchased from. The 'type' tag is redundant since it will always be "villager".
However in the 1.13 snapshots, the type tag is now required. The above advancement only works if you add the redundant type field:
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "type": "minecraft:villager""location": { "dimension": "the_end" } } } } } }This bug seems like it was introduced due to the changes which were made in 1.13 snapshots to the way entities are registered and constructed
The following advancement use to work in 1.12.x
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "location": { "dimension": "the_end" } } } } } }From the wiki:
The villager the item was purchased from. The 'type' tag is redundant since it will always be "villager".
However in the 1.13 snapshots, the type tag is now required. The above advancement only works if you add the redundant type field:
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "type": "minecraft:villager", "location": { "dimension": "the_end" } } } } } }This bug seems like it was introduced due to the changes which were made in 1.13 snapshots to the way entities are registered and constructed
The following advancement use to work in 1.12.x
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "location": { "dimension": "the_end" } } } } } }From the wiki:
The villager the item was purchased from. The 'type' tag is redundant since it will always be "villager".
However in the 1.13 snapshots, the type tag is now required. The above advancement only works if you add the redundant type field:
{ "display": { "icon": { "item": "minecraft:emerald" }, "title": "Trading in the end", "description": "Trading in the end" }, "parent": "example:challenges/root", "criteria": { "trade_in_the_end": { "trigger": "minecraft:villager_trade", "conditions": { "villager": { "type": "minecraft:villager", "location": { "dimension": "the_end" } } } } } }This bug seems like it was introduced due to the changes which were made in 1.13 snapshots to the way entities are registered and constructed. It doesn't seem intentional and I haven't seen it documented in the release notes
Written books resolves the JSON text when being opened by the player. If an op opens the book, selector components resolve correctly. However when a regular player opens the book, it causes an exception which causes the literal JSON to be displayed in the book instead.
Steps to reproduce:
Execute the following command
/give @a minecraft:written_book{title:"Example",author:"someone",pages:["{\"selector\":\"@s\"}"]}If a op opened the book, it would display their name as the contents. However if a regular player opens it they will see {
{"selector":"@s"}{"}} instead.
Written books resolves the JSON text when being opened by the player. If an op opens the book, selector components resolve correctly. However when a regular player opens the book, it causes an exception which causes the literal JSON to be displayed in the book instead.
Steps to reproduce:
Execute the following command
/give @a minecraft:written_book{title:"Example",author:"someone",pages:["{\"selector\":\"@s\"}"]}If a op opened the book, it would display their name as the contents. However if a regular player opens it they will see {"selector":"@s"}" instead.
Written books resolves the JSON text when being opened by the player. If an op opens the book, selector components resolve correctly. However when a regular player opens the book, it causes an exception which causes the literal JSON to be displayed in the book instead.
Steps to reproduce:
Execute the following command
/give @a minecraft:written_book{title:"Example",author:"someone",pages:["{\"selector\":\"@s\"}"]}If a op opened the book, it would display their name as the contents. However if a regular player opens it they will see {"selector":"@s"}
"instead.
The issue was supposedly fixed in
MC-169975but it doesn't appear to be fixed.This is because the isGlowing() method is overridden in net.minecraft.client.player.LocalPlayer but it is not overridden in net.minecraft.client.player.RemotePlayer.
This should be a very simple fix.
DrHenchman, I am already aware of that workaround, but it does not work for item names. However, I have added that in the description for other JSON text.
This bug causes problems for map makers. I have recently been working on a map which had a lobby above the world. In previous snapshots you'd spawn when you logged onto the server in the lobby and now you spawn underneath it.
I have investigated this further.
It seems that there is now a #minecraft:valid_spawn tag and it only has grass_block and podzol in it and this tag determines what is a valid spawn place. If you change the fill command in the description to be grass_block instead of dirt, it works like 1.12.2. Is this an intentional change that only glass and podzol are valid spawn blocks? It seems like other blocks like stone, dirt and sand use to work and occur naturally on the surface of a world.EDIT: I think I misunderstand how the valid_spawn tag is used. If I use a datapack to override it it doesn't change where you can spawn. Also, podzol doesn't work as a replacement to dirt with the fill command in the description to reproduce the 1.12.2 behaviour.
Still a problem in 1.13-pre1
Looks like this is a duplicate of
MC-125744which was fixed in 1.13-pre2Put another way:
chunkX -= this.maxDistanceBetweenScatteredFeatures - 1;is the equivalent of:
which when simplified is:
Confirmed still an issue in 1.13-pre2
This should be possible to fix in Minecraft 1.14 now with the new additions to the loot table. For example, you could add this condition to the magma cube loot table and it would then be able to be applied Magma Cube's of all sizes rather than conditionally to medium and large in the code
"conditions": [ { "condition": "inverted", "term": { "condition": "entity_properties", "entity": "this", "predicate": { "type": "minecraft:magma_cube", "nbt": "{Size:0}" } } } ]I believe I have experienced this same problem. I have attached two debug profiles taken a few minutes apart. There was 3 people on the server at the time, and one person was in there based with around 30 pillagers (maybe 6 different patrols) spread around the loaded chunks near them.
As a datapack developer, this is a huge issue for me. For example, when a player joined a server for the first time, I wanted to provide a personalised book which was addressed to them (using @s). Instead, they were presented with a page of text. Similar I maintain a UHC datapack which (which is reasonably well used by the community), I tried to make use named armor stands to provide toggleable controls in a book. Awesome features were added in 1.14 to allow for selecting NBT from entities and using them in JSON text but I can't make use of them because of this bug.
Ah thanks. I misread the original ticket and was concerned that it had not been fixed correctly. Sorry for the busy work
The workaround I am using is to put an empty text component at the beginning:
[{"text":""},{"text":"actual text","color":"blue"},{"text":"More text"}]