In-game time question

[HueijRevisited]

I never paid too much attention to the in-game clock but I am considering doing some passenger runs because I never did that before.

So what does this mean? 2084021:05:03:13? I know the last three parts are :hours:minutes:seconds, but what does the first number stand for?

[JensAyton]

I believe it stands for “date reference in a format that doesn’t reveal a specific connection to the Gregorian calendar.” :-) I believe the number increments by one every 24 hours, so it’s just the number of days since 2084021 days (or about 5700 years) ago.

[Eric Walch]

So what does this mean? 2084021:05:03:13? I know the last three parts are :hours:minutes:seconds, but what does the first number stand for?

As Ahurman says: it is a day-count. In my OXP I use it to determine the wait-time til the next event.

Time it very consistent calculated by Oolite. Jumps take time and increasingly more on longer jumps. But also installing equipment takes time. More expensive equipment takes more to install.

Be aware the variables: clock_days_number, clock_hours_number, clock_mins_number and clock_secs_number are only updated after a witchspace jump and then stay the same within the system. So you can not do much with the seconds to time things.

If you realy want timing with seconds you need: clock_number. This gives the time in seconds with about 6 or more decimal digits. I used it on some places to make sure the delay is several seconds. (for the case the scripts are executed faster in a future oolite version)

[HueijRevisited]

Ah, thanks guys. I suspected as much so now I'm sure. Too bad I didn't write down the starting date so I'd know how long I'm traversing those trade lanes by now

[JensAyton]

Start a new game and see.

[Helvellyn]

More expensive equipment takes more to install.

Unless you try to launch, in which case the clock stops racing ahead and you can simply fly out. I've not spotted if that's a bug, or it jumps straight towards where it was running to.

[HueijRevisited]

Start a new game and see.

Hehe... I realised that the moment I hit the submit button

[Commander McLane]

Be aware the variables: clock_days_number, clock_hours_number, clock_mins_number and clock_secs_number are only updated after a witchspace jump and then stay the same within the system. So you can not do much with the seconds to time things.

Thanks! I wasn't aware of it and it's a very helpful piece of information!

May I return the favour and make you aware that there is another problem with clock_mins_number and clock_secs_number?

Both clock_mins_number and clock_secs_number have the value of -2147483648 right from the beginning, which doesn't change at all. Given that this is a very high negative (-2^31) my guess is that all the clock-related counters (except clock_number, which happens to be a real and therefore not the same as clock_secs_number, whatever the wiki says) are stored as integers in a variable that has a certain range only. When this range is reached (my guess is +2147483647 = 2^31-1) the variable rolls over and isn't incremented anymore. The same thing will happen to clock_days_number and clock_hours_number eventually, but only after a veeeeeery looooooooooooooooooong time (2.14 billion days, that would be roughly 5.9 million years. A good age for any commander (even given the fact that there are some senior citizens on the boards )! Divided by 24 to get the maximum number of hours it's still about 250000 years.)

Given that all the counters start with 0 at a point long before Jameson and then are incremented at their own pace, obviously the rollover happened already before the game starts. And this makes the variables clock_mins_number and clock_secs_number completely useless. They should better not be used at all.

[Eric Walch]

Both clock_mins_number and clock_secs_number have the value of -2147483648 right from the beginning, which doesn't change at all.

You are right, I never looked at the real value. I wanted to use timing and only tested for [current value] minus [old value] and saw that the result was zero for the seconds and minutes. I did not want to wait for hours and days passing by so I just assumes they also didn't change. But seeing your analyse, I assume the clock_hours_number will be incremented by one every realtime hour if I had waited long enough.

[Commander McLane]

Indeed. And the same goes for clock_days_number, of course. And this one I have already used for timing purposes.

But anyway it's best to use clock_number, which is incremented by 1 every second (with even some decimals behind the point). That means for every minute you have to add 60, for every hour 3600 and for every day 86400.

[JensAyton]

Fixed (without changing semantics), using higher-precision numbers in the conversion. (There should probably be a set of JavaScript clock functions, too…)

Also featured in this screen shot: ability to scroll through console history with page up/down. :-)

[Commander McLane]

Congratulations for both!