The Bug
Due to command results being limited to integer, a stopwatch timer cannot be read once its internal value reaches the integer limit. Since it is stored internally as a long, it will still count up, and depending on scale value a useful value can still be read.
This means, the following precision cannot be read using commands after the amount of elapsed time:
After 24d 20h 31m 23.648s miliseconds (it will always read like 24.20:31:23.647)
After 248d 13h 13m 56.48s hundreths of a second (it will always read like 248.13:13:56.47)
After approx. (using an average number of days per year) 6y 294d 1h 24m 12.8s tenths of seconds (always reads like 2485.01:24:12.7)
After approx. 68y 18d 15h 28m 32s seconds (will always read like 24855.15:28:31)
I don’t think this should be a big issue for most usecases, and there was also no way to do this better previously using a world border. I am not sure whether this should count as a bug or a feature request.
Steps to Reproduce
Either download the attached world ([mediaInline]), or download the [mediaInline] file and put it in your world’s data directory
If not using the world file, run
/scoreboard objectives add stopwatch dummy
and/scoreboard objectives setdisplay sidebar stopwatch
run
/execute store result score $time_in_ms stopwatch run stopwatch query neun:long_running_timer 1000
Observed Result
The extracted time always reads 2147483647. This is btw also true when using execute store
with a storage while storing a long
or float
, because the int conversion happens before.
Expected Result
There is some way to read the ms component without reading the entire value (e.g. /stopwatch <id> query ms
returns (int) (value % 1000)
).
Alternatively, it could just always do (int) (value % int.MAX)
, then you could still read the entire value and do some maths with the lower and higher bits, but this probably feels more buggy then the current behavior.
Attachments
Comments 0
No comments.