Timing system?

[jamespetts]

I am currently trying to decipher the game code's timing system, and should appreciate any help from those who know how it works. Is "ticks" in karte_t a measure of the amount of time elapsed since the map was created, whether the game has been reloaded or not? If so, what is the unit of measurement? If not, is there such a measure?

[prissi]

ticks are milliseconds since the map has synchronized the last time. Typically it will be reload, but every 134 game year (with bit_per_month=18) it has the resynchronize to prevent overflows. (With 20, this is 134/4=33). The ticks are always relative to a starting of a month.

There are also two kind of month: "Real month" and month with only three days, just according to the setting of the user. (This is one reason, while the setting in the schedule window are month based.)

The shortest relyable unit of time across everything are the months.

[jamespetts]

Thank you for the reply - very helpful :-)

The shortest reliable unit is the month? Hmm. Is there no way of counting the number of synchronisations or something similar...?

[prissi]

Ticks are never negative and always relative to the starting of a month; so you can use them, if you take care against underruns.

[jamespetts]

Aha, useful, thank you! But I'm not sure what you mean by "underruns" here - can you elaborate? :-)

Edit: And can I ask for clarification on one thing (so that I don't have to spend hours testing it with a debugger to find out how it works): does the the number of ticks get reset to 0 at every new month? Or is there a separate measure than "ticks" that is so reset? What I am after doing is using month plus ticks to get a more precise form of timing, but need to know how to handle the ticks in order to do that.

Incidentally, how does all of this fit in with speed? Say at the default 18 ticks per tag - how many ticks will it take for a vehicle travelling at 100kph to traverse 100 tiles in a straight line?

[prissi]

ticks and speed have no relation; or rather I never tried to figured that out. But since the length of an hour is different depending on display options and the length of a tile is either 25m or 1km the discussion about real speeds is futile.

[jamespetts]

Ahh, thank you for the reply. Does the number of ticks get reset to 0 at every new month, incidentally...?

[prissi]

No, the ticks value gets onlz reset when loading or when close to overflow in the current month.

[jamespetts]

Thank you :-) If that is so, then, how does the saved game manage to remember not only the month, but the day, the hour and the minute? (I have tested: these values are accurately preserved on reloading).

Edit: Looking carefully at the code, the "ticks" value is actually not reset at all. (There is some resetting code hidden behind conditional compilation, but that is turned off). Can I ask, Prissi: are you planning to add new resetting code or enable the currently disabled resetting code in the foreseeable future? Because, if you are not, the raw ticks value can be used quite happily for all kinds of timing. From my tests, approximately 50 years in gameplay produces approximately 132 million ticks. The ticks variable is an unsigned 32-bit integer, which can hold values of some way over 4 billion, so there is no danger of ticks overflowing if the game is played for a reasonably ordinary length of time (if people really want to spend years playing from 1400 to 2050, then it might be necessary to set the ticks to a 64 bit value, but that seems like a somewhat marginal case).

[prissi]

resetting is done in line 2539ff in simworld.cc

[jamespetts]

Ahh, I see: you mean this code:

Code Select Expand


if(ticks>next_month_ticks) {
ticks %= karte_t::ticks_per_tag;
ticks += karte_t::ticks_per_tag;
next_month_ticks = ticks+karte_t::ticks_per_tag;
last_step_ticks %= karte_t::ticks_per_tag;
}


That (sensibly) only resets the ticks if there appears to be an overflow immanent; but, with an unsigned 32-bit integer (max. value: 4,294,967,295), that is unlikely to happen (if 50 game years produced approx. 132 million ticks, then a player would have to be playing for over one and a half game millennia at the default time setting for the ticks to overflow)!

[VS]

There was one such player... I remember something related to timing had to be fixed about one year ago (?) because somebody played until year 25000 or something like that. Don't underestimate the way users can come up with bugs

[prissi]

It was actually the year 3624 if memory serves me right. This was possible, because in the old versions, the tick count was saved too.

[jamespetts]

Hmm, my tests show that the tick count is also saved in the latest versions.

[prissi]

Ahh, did comment this out. Most likely because the waiting stuff for convois was added.