When doing /data get <target> <path>, result will be an Integer.
This can be problematic when trying to get Long, Float and Double values.
Linked issues
is duplicated by 6
MC-127536
Can't directly port a Long value to another Long value in NBT using /execute store
Resolved
MC-155407
Unable to store UUID (long) into NBT property
Resolved
MC-178643
Floor values in storage decimal types - Command - /data /execute
Resolved
MC-212345
Scaling during execute store command causes loss of precision when given precision number
Resolved
MC-239731
Casting data with /data get ... [scale]
Resolved
Attachments
Comments 5
Use scale to myltiplay the value for more accuracy.
It has to return an integer so it can be used in combination with execute store.
What if I want to execute store a LONG value inside NBT?
Then, why make it possible to store values as LONG, if you can't use it properly?
Scale won't work, since the limit will be ±2³¹, when long values can be up to ±2⁶³.
[media]
Very sad indeed. hope the variation can be added soon. like /data get <enitity> <path> <type> <scale>
Confirmed for 20w10a.
I would like to see a reason why this is 'works as intended'. Cause I don't think it makes sense for NBT data of type Long to be silently casted to int and back to long when trying to move the data to another nbt container.
This won't work for example, while for expectation, it should:
/execute store result storage test UUID long 1 run data get entity @p UUIDMost
The thing is, you can achieve the exact same thing (except it works as you expect it to) using
/data modify storage test UUID set from entity @p UUIDMost
This might be a useful work-around for people who require this behavior.
Probably intended, but it would be nice if we could clone / move nbt from one entity to another (UUID, Large doubles...) (eg, make a shulker_bullet target the nearest zombie...)