On the first server tick, world.tick_usage is approximately 13 trillion

ID:2705172
 
Aug 2 2021, 11:24 am
BYOND Version:514.1546, 514.1560
Operating System:Linux
Web Browser:Firefox 88.0
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary: The value of world.tick_usage before the first tick has elapsed is far too high. I don't know whether world.cpu or world.map_cpu are also affected, but the values I get out of those two seem more reasonable than the tick_usage figure.

Numbered Steps to Reproduce Problem: Run code below

Code Snippet (if applicable) to Reproduce Problem:
/world/New()
    world.log << "first tick: [num2text(world.tick_usage, 20)]"
    
    sleep(0.1)
    world.log << "second tick: [num2text(world.tick_usage, 20)]"
    
    for(var/i in 1 to 1000000)
        . = "a loop to use some time"
    world.log << "second tick, later: [num2text(world.tick_usage, 20)]"


Expected Results:
first tick: (a small value)
second tick: (a different small value)
second tick, later: (a larger value corresponding to the time the loop took)


Actual Results:
first tick: 13272397905920
second tick: 0.0020000000949949026108
second tick, later: 62.88899993896484375


(note that, if interpreted in milliseconds as the other figures are, a value of 13272397905920 suggests the tick has been executing for about 420 years, 7 months - very close to 1st Jan 1601, which is Windows' epoch - perhaps a missing initialisation at startup?)

Does the problem occur:
Every time? Or how often? Every time
In other games? Yes
In other user accounts? Unknown
On other computers? Unknown

When does the problem NOT occur? After the first tick has finished.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Last working in 514.1545, broken in 514.1546 and all later versions that I tested, including 514.1560.

Workarounds: Wait until the second tick before using world.tick_usage?
Aug 2 2021, 12:58 pm (Edited on Aug 2 2021, 1:09 pm)
The first time you run that code in an instance of Dream Daemon, you get the result you described. If you stop the server then start it again in the same instance of Dream Daemon, you instead appear to get the amount of elapsed time since you stopped the previous server.

EDIT: Hm. I swear it was the time since stopping the previous server a moment ago, but now it's the time since starting the previous server. I probably just messed up my testing.

EDIT: Also, yes, I can confirm that the first value it gives is exactly what you suspected, to the nearest 32-bit floating point value.