There are a number of mods in the pack that store metadata about
players "inside out", in mod_storage instead of player:get_meta,
because player meta is not accessible when the player is not online
and that's necessary for some mods. Player meta is also tied to
the "player character" and not to the auth account, so inside out
storage is necessary when we want data to survive resetting the
player character while keeping the account.
Unfortunately, this prevents MT from automatically cleaning up
the metadata when a player is destroyed, which can happen for
various reasons outside the control of the mod. This can cause
keys to accumulate in the mod storage database, which may hurt
performance over time.
To keep things tidy, periodically scan the mod storage keys for
each such mod (add a scan cycle, or integrate with an existing
one) and automatically clean up old mod storage keys.
szutil_xplevel was already doing this on startup and command;
convert it to do periodic scans like the other mods.
- Rearchitect so that we generate a list of lines as a separate
process from displaying them, so that we can add new things
beyond just the bucket graphs.
- Display cached lagometer to players as soon as they join instead
of having to wait for the 2 second "cold start" before seeing
anything.
- Add a status line to the bottom of the lagometer with live
display of things that would be in /status.
- Add the status line things to the JSON dump too.
These are all based on automated detection (intercept the minetest
settings metatable methods) and lack any useful documentation, and
may be incomplete (e.g. missing keys that are only discovered at
runtime based on specific actions).
Eventually these will be filled out and used to document settings,
and make it easier to manage settings in the MT Settings UI.
Just generate a single warning message on purging, don't do one
for player and auth separately, to cut down on the amount of
warning log noise that server warning monitoring scripts handle.
Instead of maintaining the short description of each sub-mod
manually in a giant README file, distribute the short descriptions
into each relevant mod, and then build the README listings
automatically at deploy time.
This should:
- Make it harder to forget to add/remove mods in the list
- Prevent them from being out of alphabetical order
- Ensure each mod has a description for in-menu use
We actually want to prune accounts based on the
last time they were used or seen online at all, not
just the last time they successfully joined the
world. Keeping track of our own timestamp should
catch scenarios like players sucessfully authing
but failing to complete joining the world, or players
who log in and then play for a long time after
login. This also makes it safer to use with much
shorter timeout periods and longer-running
servers.
Further tighten the race condition gap between
players authing and finishing joining. The
meaning of last_login is apparently officially the
last join time, but if the last successful auth time
was later, use that as the known account age.
It's possible for a player to log in right as the
check scan is happening, causing the decision to
delete the account happening, then the player
successfully authing, then the account being
actually deleted from the queue, and then the
player completing emerge and running joinplayer
callbacks. One of the joinplayer callbacks tries to
update the last_login, which fails if the account
was deleted while the player was emerging.
Rather than redo the checks, just perform all the
deletion stuff inline.
pruneplayers can race with other mods (e.g.
motdagree) to delete a player. If the player was
already deleted when the check runs, don't crash,
just skip the player this pass.
