SnDevelopmentCommands
Root command /sntransfer, alias snt (editable in config.yml under command.aliases, re-read
on reload). It is a staff tool: the root needs snusertransfer.admin, and every subcommand works
from the console.
| Command | Permission | Description |
|---|---|---|
/sntransfer | snusertransfer.admin | Shows the help |
/sntransfer preview <oldNick> <newNick> [--uuid <uuid>] | snusertransfer.admin.preview | Dry run: lists, per plugin, every store, row and file the transfer would touch. Writes nothing |
/sntransfer apply <oldNick> <newNick> [--uuid <uuid>] | snusertransfer.admin.apply | Backs up, then moves every plugin's data from the old account to the new one |
/sntransfer undo <backupId> | snusertransfer.admin.undo | Restores a finished transfer from its backup. The undo is backed up too and prints its own id |
/sntransfer backups | snusertransfer.admin.backups | Lists the stored backups |
/sntransfer pending | snusertransfer.admin.pending | Lists the transfers queued for the next restart |
/sntransfer cancel <queueId> | snusertransfer.admin.cancel | Removes a queued transfer before the restart applies it |
/sntransfer reload | snusertransfer.admin.reload | Reloads config and lang |
/sntransfer help | snusertransfer.admin | Paginated help, filtered by permission |
/sntransfer debug | snusertransfer.admin.debug | Toggles the runtime debug output |
Only one transfer or undo runs at a time. A second one is refused until the first finishes.
Pinning the target UUID
The UUID written into every store is the new account's. The server resolves a name to a UUID from its own user cache, so for an account it has never seen there is nothing to look up. On an online-mode server the transfer is then refused instead of writing a UUID derived from the name, which would belong to nobody.
Either let the new account join once, or pin its UUID:
/sntransfer apply OldGuy NewGuy --uuid 069a79f4-44e9-4726-a5be-fca90e38aaf5
/sntransfer apply OldGuy NewGuy 069a79f444e94726a5befca90e38aaf5The flag is optional and the dashless form is accepted.
- Offline-mode servers resolve normally: the name-derived UUID is the right one there.
- Behind a BungeeCord or Velocity proxy the server reports offline mode while players have
real Mojang UUIDs. The transfer is not refused, but a warning shows the derived UUID before
anything is written. Pin the real UUID with
--uuidon such a server.
When a preview needed a pinned UUID, its closing line prints the exact apply command with the
--uuid part included.
apply overwrites: rows of the new account that collide with the old account's data are replaced,
and the chat names how many. Run preview first. Every apply can be reversed with
/sntransfer undo <id> while its backup is kept (backups.retention-days, 30 by default).