Jump to content
Domination: Earth

Recommended Posts

As long as I remember, timers in DE had various gitches that made them:

  • lagging behind the actual time, like showing the building still being built despite already being built;
  • skipping from time to time, as if the lagging timer got updated

I assume this glitch must be there due to some weird mechanics used to count the time, but... well...

Couldn't you just store somewhere the target time for each counter, so that whenever the screen is updated, it shows the diff between current date and end date?

Wouldn't such approach fix the problem? Or is the issue completely different?

Edited by Олег Поленин
Link to post
Share on other sites
7 hours ago, Олег Поленин said:

As long as I remember, timers in DE had various gitches that made them:

  • lagging behind the actual time, like showing the building still being built despite already being built;
  • skipping from time to time, as if the lagging timer got updated

I assume this glitch must be there due to some weird mechanics used to count the time, but... well...

Couldn't you just store somewhere the target time for each counter, so that whenever the screen is updated, it shows the diff between current date and end date?

Wouldn't such approach fix the problem? Or is the issue completely different?

It's not exactly that simple; difference between two dates is exactly how the timer works already. :)
The problem is the "whenever the screen is updated" bit, i.e. the 1-second tick itself.
It seems that there are minor (micro) variations in ticks on different devices, then the ticks get frozen when the app or its screen go into "background mode" and the timer itself never really knows when it gets frozen or if it lags.
The "skipping" bit is the timer synchronizing the current & end dates with the server and refreshing the visible countdown on the UI, i.e. resolving differences caused by UI lags and freezes.
Unfortunately, unless the server-side synchronisation happens on every tick (which, as you can imagine, would be a massive load) there isn't much I can do as a quick fix.

There are some ways I could address this problem, but the effort involved in refactoring this functionality just outweighs the gain, so the issue is a low priority at the moment, sorry!

Link to post
Share on other sites

But what I mean is: store the target time locally, on the device and as perceived by the device.

I understand there might be a more or less significant drift between the device and the server, but the time should be pretty consistently flowing on both devices.

When you register a capture event at the device at 10:15, and the server time is 10:17, then store target time on both device and server, 10:30 and 10:32 respectively. Each time you update information from the server, you may get both server times (current and local) and adjust the local timer, but to be honest, you'll need this much less often, likely only when the game restarts.

The actions are still gated by the server, thus any local drift won't mean anything, and the UI will be more predictable.

Edited by Олег Поленин
Link to post
Share on other sites

It could be done, yes, but as I mentioned above, the problem is relatively minor (compared to the top 10 issues in my list) and there are only so many hours in a day (most of which are already reserved by my primary job). :)

So yes, at some point in the future I will look into improving the timer accuracy, but I can't promise it will be in the next release!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...