Apparently the one-line motd from the MT conf file gets inserted
as a second line at the end of the status line rather than being
sent as a separate message.
NodeCore, for a while now, has automatically and
transparently handled item dropping on teleportation
without the need for support from external mods,
and we should let it use its own internal logic.
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
Apparently it was broken due to using a "return" instead of
a "continue/next" (which Lua doesn't actually have) due to a
function body being inlined into a loop. Break it back out
into a function again to make the early return work right.
This reverts commit be7e70a09e992314a92c8349594e4070ff525528.
Don't block restart requests for other reasons just because an
"always" restart is already pended; track these in a separate
system so they don't interfere with other triggers.
Now these apparently load correctly, at least under docker, as
long as the mods are in secure.trusted_mods, disabling mod security
is no longer necessary.
- Always pend a restart on player join, so empty servers are
always freshly restarted for optimal RAM conservation. This
would kill uptime/availability stats for a public server, but is
ideal for private server that are often empty, e.g. when running
multiple private servers on "standby" for a smaller pool of
local players.
- Improve logging of restart triggers.
- Don't announce restarts extremely far into the future, so that
the "pend restart on join" feature doesn't cause undue chat
noise and scare players away who habitually quit to restart upon
seeing a "restart in..." message.
Waypoints can be added/removed via chat
commands. This makes it easier to adapt to
various "points of interest" that may evolve over
time with the world.
Finally mod_storage is actually efficient enough,
when using sqlite3, to ditch the old file-based
storage, which is a nightmare for backups. This
mod now effectively requires that sqlite3-based
mod storage be used for worlds of sufficient
scale, but that's probably a fair requirement for
using this rather obscure mod anyway.
By default, players joining the server who are
configured to act as cinematic cameras only
should not see the server status message ...
unless specifically configured to see it.
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.
