Multiplayer Persistent Timers


#1

So this is an issue I just found out about while testing for player-based saved variables for my Obligation/Timer Tracker 1.0 mod. Apparently persistent timers for offline players continue. This means that if a player is offline for even a few minutes, they could lose the effects of potions they had just applied before logging off, their trading stalls may have already cooled down, and more importantly (disclaimer, haven’t actually looked into this yet, but I’m pretty sure it operates on the same system), their trades and goblin demands will also approach their deadlines.

In fact, it may even affect their general campaign progress, at least anything that’s time-based, unless those are daily checks rather than persistent timers, and they count only the game-time that has passed while that player was logged in.

I don’t know how difficult it is to “pause” timers for offline players. I can imagine a basic way of doing it, and I don’t think it would necessarily have big performance implications, but it would seemingly require some major refactoring. Basically, player_id would have to be included in the creation of timers (which it currently isn’t), and then you’d have an array of player_ids that tracks their most recent log out time. Nothing additional needs to happen when a player logs out besides recording this time. If the event triggers while the player is logged out, instead of running the function it just resets the timer. Then when a player logs in and all their timers are loaded, the server can compare the current game time to the recorded log out time and then increase all their persistent timers’ expiration times by the difference.

That part is simple. The part that’s not simple is going through and changing every timer creation call to include a player_id (though it could default to a neutral/host id if none is specified; actually, that may make this refactoring possible, since there are relatively few timers that would have to actually be changed; everything else would default to identifying with the host, which doesn’t need to track logout time and adjust its timers).


#2

Timers are a lower level of abstraction than player lifecycle management. A feature that wants to support pausing and resuming per-player is responsible for managing its timers by itself. The encounter system does that, for example.