MC-120371Data types and formatting are not corrected within items' tag NBT
The item data type (byte, int, short, float, double, string, long, int array, byte array, long array) are not corrected within item data's tag tag.
Using
/give @s minecraft:diamond_sword{Unbreakable:1}
should correct the Unbreakable tag to a byte (1b), but it instead just saves it as an integer (it will still function correctly though).
This affects every tag within item's tag tag.
This should be solvable without breaking custom item tags.
Steps to reproduce:
- Use
/give @s minecraft:diamond_sword{Unbreakable:1} - Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1b}}]}] - Notice failing command
- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1}}]}] - Notice successful command
- Remove the diamond sword
- Use
/give @s minecraft:diamond_sword{Unbreakable:1b} - Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1b}}]}] - Notice successful command
- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1}}]}] - Notice failing command
- Even though it's the exact same tag, the commands fail/succeed depending on the give command, unlike testing for tags outside of the tag tag
Linked Issues
is duplicated by2
- Won't Fix
user-f2760- 12
- 8
- Confirmed
- (Unassigned)
1.12 - 1.17.1
1.12 1.12.1-pre1 1.12.1 1.12.2 17w47b 18w01a 18w02a 18w19b 1.13 1.13.1-pre1 1.13.1 1.13.2 18w43a 18w43b 18w45a 18w46a 18w48a 18w48b 18w49a 19w04b 19w07a 19w12b 19w13b 19w14a 19w14b 1.14.3 19w44a 1.15-pre4 1.15-pre5 1.15-pre6 1.15-pre7 1.15 1.15.1 1.15.2 20w11a 20w12a 20w14a 1.16 1.16.2 20w51a 21w03a 21w05a 1.17 1.17.1
Created Issue:
Data types are not corrected withing item's tag tag
The item data type (byte, int, short, float, double, string, long, int array, byte array, long array) are not corrected within item data's tag tag.
Using
/give @s minecraft:diamond_sword 1 0 {Unbreakable:1}should correct the Unbreakable tag to a byte (1b), but it instead just saves it as an integer (it will still function correctly though).
This affects every tag within item's tag tag.
This should be solvable without breaking custom item tags.Steps to reproduce:
- Use
/give @s minecraft:diamond_sword 1 0 {Unbreakable:1}- Use
/testfor @s {Inventory:[{tag:{Unbreakable:1b}}]}- Notice failing command
- Use
/testfor @s {Inventory:[{tag:{Unbreakable:1}}]}- Notice successful command
- Remove the diamond sword
- Use
/give @s minecraft:diamond_sword 1 0 {Unbreakable:1b}- Use
/testfor @s {Inventory:[{tag:{Unbreakable:1b}}]}- Notice successful command
- Use
/testfor @s {Inventory:[{tag:{Unbreakable:1}}]}- Notice failing command
- Even though it's the exact same tag, the commands fail/succeed depending on the give command, unlike testing for tags outside of the tag tag
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Data types are not corrected withingitem's tag tag
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
The item data type (byte, int, short, float, double, string, long, int array, byte array, long array) are not corrected within item data's tag tag.
Using
/give @s minecraft:diamond_sword1 0{Unbreakable:1}should correct the Unbreakable tag to a byte (1b), but it instead just saves it as an integer (it will still function correctly though).
This affects every tag within item's tag tag.
This should be solvable without breaking custom item tags.Steps to reproduce:
- Use
/give @s minecraft:diamond_sword1 0{Unbreakable:1}- Use
/testfor @s{Inventory:[{tag:{Unbreakable:1b}}]}- Notice failing command
- Use
/testfor @s{Inventory:[{tag:{Unbreakable:1}}]}- Notice successful command
- Remove the diamond sword
- Use
/give @s minecraft:diamond_sword1 0{Unbreakable:1b}- Use
/testfor @s{Inventory:[{tag:{Unbreakable:1b}}]}- Notice successful command
- Use
/testfor @s{Inventory:[{tag:{Unbreakable:1}}]}- Notice failing command
- Even though it's the exact same tag, the commands fail/succeed depending on the give command, unlike testing for tags outside of the tag tag
The item data type (byte, int, short, float, double, string, long, int array, byte array, long array) are not corrected within item data's tag tag.
Using
/give @s minecraft:diamond_sword{Unbreakable:1}should correct the Unbreakable tag to a byte (1b), but it instead just saves it as an integer (it will still function correctly though).
This affects every tag within item's tag tag.
This should be solvable without breaking custom item tags.Steps to reproduce:
- Use
/give @s minecraft:diamond_sword{Unbreakable:1}- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1b}}]}]- Notice failing command
- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1}}]}]- Notice successful command
- Remove the diamond sword
- Use
/give @s minecraft:diamond_sword{Unbreakable:1b}- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1b}}]}]- Notice successful command
- Use
/say @s[nbt={Inventory:[{tag:{Unbreakable:1}}]}]- Notice failing command
- Even though it's the exact same tag, the commands fail/succeed depending on the give command, unlike testing for tags outside of the tag tag
relates to
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
relates to
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
is duplicated by
Data types are not corrected within item's tagtagData types and formatting are not corrected within items' tag NBT
Duplicate of MC-120371.
There's no upgrade path for any of those instances. Signs, entities and block entities just modify their save data to the "preferred" format (also changing key order), items never did this for any NBT inside "tag", let alone the name and lore. (MC-120371)
Your concern is valid, but that's a misconception that should've been corrected.
Thisisn't just for the boolean things, but all formattng which became more strict (invalid color name, malformatted click/hover event, etc.)
Confirmed for 1.13.1-pre1
Confrimed for 19w44a.
Can confirm that this issue is still present in 20w51a.
Can confirm in 21w03a.