Handling /tick

[pdinklag]

Minecraft 23w43a introduces a new /tick command that allows setting the tick rate on the sever.

This is highly problematic in terms of displaying durations (e.g., time since last sleep, death, etc.) in the web frontend. The game measures these in ticks. If the number of ticks per second is no longer constant, it is impossible to reliably convert ticks to seconds, because the tick rate may have been changed arbitrarily.

This raises the question of how to handle dynamic tick rates. The most pragmatic (and perhaps only) way would be to present duration values as what they are: ticks, not seconds.

[tylerguy]

Wouldn't it be entirely possible to take difference between the new and old values during stat updates and use that and the current tick rate to calculate the seconds elapsed and simply add that to the previous value. Would mean storing a normalised value and the actual value which adds a layer of complexity, but is the best solution I can think of without losing access to a value in seconds.

Would certainly be an issue when calculating after a long interval has passed if for instance multiple tickrate changes have been made, but shouldn't be too much of an issue if either the update interval is low enough or not many tickrate changes are made.

I don't see a survival server making changes to the tickrate in such a manner, unless it's for testing or for optimising server load.

[pdinklag]

Optimising server load is precisely where I believe that people could use this, but only time will tell. Surely, admins won't be changing the tick rate all too frequently in a productive environment (that is, a server where people actually play and which is not just a server to test stuff).

Still, adding the mentioned layer of complexity is what I'd like to avoid. So far, MinecraftStats never needed to look back in history (other than explicitly for events), which allowed things to be done in a pretty elegant way. Whether the few time-based stats should change the entirety of how MinecraftStats processes data is questionable to me.

A tradeoff may be to store the server's tick rate in the summary (I would suppose that it can be extracted from level.dat) and clients compute seconds from that. They would become invalid whenever the tick rate changes, but this would be the admin's responsibility.

After all, I think it is out of this project's scope to think of a clever handling. Mojang will have the very same issue, as they also have to deal with presenting time values in the achievements/stats UI ingame. The best solution would be for Mojang to not store ticks in the stats, but actual seconds. Surely this will be a bug report eventually (if there isn't one already), and maybe they will provide a solution of their own that MinecraftStats can simply adopt.