Inventory restore

Inventory restore keeps a copy of what a player was carrying, so a staff member reading a report three days later can look at what they actually had and give it back. Copies are rows in the database, not files, so the whole network reads the same history.

Module id restore, switch modules.restore, files under modules/restore/.

Commands

That is the whole command surface. Everything else — saving a copy now, deleting one, purging a player, reading the history — is a button in the menus, so there is one thing to remember and one place to look.

The argument is a network name: everybody connected to the proxy is suggested, not only the players this server has seen. A name this server has never met is asked of the proxy through the staff member who typed it, which is why console cannot reach one. The bare command answers with its own usage lines rather than the server's parser error.

Two more permissions gate buttons rather than commands:

When a copy is taken

The last two have no switch on purpose. A manual save is a staff member asking for it, and the copy taken before a restore is what makes a restore undoable.

A copy is only written when there is something to copy. min-seconds-between (60) is the gap between two ordinary backups of the same player, so somebody bouncing through a portal does not write a row a second — deaths and manual saves ignore it, because those are the ones staff come looking for. Two backups minutes apart holding the same items are still two backups: the one a staff member wants is the one at the moment they are asking about.

The quit copy is skipped while the server is stopping. Paper disconnects every player before it disables a plugin, so a quit backup there is one row per online player written in the same second, and the join copy says the same thing.

How long they are kept

Deaths and manual saves are not pushed out by the count. Those are what a report is about, so they stay until keep-days takes them rather than being shoved aside by ordinary joins. The purge runs when the module starts and once an hour after that.

The screens

Servers opens first: which server each backup was taken on, the current one first and glowing. Inventories lists that player's backups newest first, tabbed by event, each drawn with the icon of its cause and a line saying what the event was. Backup is one of them, laid out with its own armour and off-hand zones — the preview stacks are buttons, and their lore says so. Empty slots are drawn as air rather than filler panes, so what you see is what they had.

Restore is where you tick the parts, and Restore history is the record of who handed what to whom, readable from either end: what a staff member gave out, and what a player received.

What you can hand back

Eleven parts, ticked one by one before you confirm:

INVENTORY, ARMOR, OFF_HAND, ENDER_CHEST, EXPERIENCE, HEALTH, HUNGER, POTION_EFFECTS, GAME_MODE, FLIGHT, LOCATION.

default-parts is what is already ticked when the screen opens; the default is inventory, armour, off hand, experience, health and hunger. A name this server does not know is skipped rather than throwing, and a list that leaves nothing at all falls back to those six: a typo must not open a screen where every box is empty.

The four parts made of items — inventory, armour, off hand and ender chest — can be added to what the player is carrying instead of written over it. default-replace (true) decides which of the two the screen opens on. Replacing saves their current items first either way, so the wrong choice is one restore away from being undone.

LOCATION is the one part this module puts back itself rather than the library, because the coordinates live on the backup row. It is never applied across servers: a location taken somewhere else is not a place on this one.

notify-target (true) tells the player when a staff member hands their items back.

Players who are offline

A hand-back for somebody who is not connected is queued with its own copy of the items and of the parts you ticked, and lands the moment they join — their arrival backup is written first, so the two never blend into one row. If they are online on another server, that server is nudged over Redis so the delivery happens at once instead of waiting for a relog. A staff member who queued one by mistake can drop what is still owed.