-
Bug
-
Resolution: Unresolved
-
None
-
1.16.4, 20w49a, 20w51a, 21w03a, 1.16.5, 21w05b, 21w08b, 21w10a, 21w11a, 21w13a, 21w15a, 21w16a, 21w19a, 1.17 Pre-release 1, 1.17, 1.17.1, 21w37a, 1.18.1, 22w03a, 22w05a, 1.18.2 Pre-release 1, 1.18.2, 22w11a, 22w12a, 1.19 Release Candidate 2, 1.19, 1.19.1, 1.19.2, 1.19.3 Release Candidate 1, 1.19.3 Release Candidate 2, 1.19.3, 23w03a, 23w05a, 1.19.4, 23w12a, 23w17a, 23w18a, 1.20, 1.20.1, 23w31a, 1.20.2, 23w42a, 23w45a, 23w46a, 1.20.4, 24w03a, 24w04a, 24w14a, 24w33a, 1.21.1
-
Confirmed
-
Commands
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
/data modify storage mc-208005: a set from storage mc-208005: b
→ Modified storage mc-208005:
/data modify storage mc-208005: a set from storage mc-208005: b
Expected behavior
The result is the same as above.
Actual behavior
Nothing changed. The specified properties already have these values
The result will be the same until the world is closed.
Code analysis
net.minecraft.nbt.FloatTag.java
@Override public boolean equals(Object $$0) { if (this == $$0) { return true; } else { return $$0 instanceof FloatTag && this.data == ((FloatTag)$$0).data; } }
Because the two NaNs are different instances at the time of the first modification, this == $$0 returns false, and this.data == ((FloatTag)$00).data also returns false, which means they are not equal. This will cause the modification to succeed, and they will be the same instance.
In the second and subsequent modifications, since they are the same instance, this == $$0 returns true, which means they are equal. Thus, the modification will not succeed.