Importing punishments

Back up your BlazeBans database. An import writes a lot of records. If the result is wrong, restoring is far quicker than unpicking it.

Stop the old plugin. AdvancedBan's local database and LiteBans' local file are both locked while their plugin is running. For a local file source, stop that plugin or the whole server first.

Read the counts afterwards. Every import reports how many records it imported, how many were duplicates, and how many were skipped. Those numbers are how you tell a clean import from a partial one.

Minecraft's own banned-players.json.

/blazebans import vanilla
/blazebans import vanilla confirm

The first command shows what will happen and gives you a confirm button. The second does it.

Every entry becomes a permanent BlazeBans ban. Vanilla stores no duration, so there is nothing to preserve.

If the file cannot be found, the error names the path it looked at.

Configure the connection in import.yml first.

AdvancedBan on MySQL

advancedban:
  type: "mysql"
  mysql:
    host: "127.0.0.1"
    port: 3306
    database: "advancedban"
    username: "advancedban"
    password: "change-me"

Use the same credentials AdvancedBan itself uses. Read access is enough.

AdvancedBan on its local database

advancedban:
  type: "hsqldb"
  hsqldb:
    file: "../AdvancedBan/data/storage"

The path is relative to plugins/BlazeBans/, and the default matches AdvancedBan's own default location.

Stop AdvancedBan, or the whole server, before importing from a local file. It holds a lock while running.

AdvancedBan has no table-prefix setting, so there is nothing to configure there.

Running it

/blazebans import advancedban
/blazebans import advancedban confirm

Bans, mutes, warnings, and kicks are all copied. The import runs in the background without freezing the server, and reports imported, duplicate, and skipped counts when it finishes.

litebans:
  type: "h2"
  table-prefix: ""
  h2:
    file: "../LiteBans/litebans.mv.db"

type accepts h2, mysql, mariadb, or postgresql. Use whichever LiteBans is configured for.

For a server database:

litebans:
  type: "mysql"
  mysql:
    host: "127.0.0.1"
    port: 3306
    database: "litebans"
    username: "litebans"
    password: "change-me"

The table prefix

Leave table-prefix blank. BlazeBans queries the database and detects the real table names itself, so there is nothing to keep in sync by hand.

Set it only if LiteBans shares a database with other plugins and auto-detection reports an ambiguous match, which happens when more than one table ends in _bans. The value is LiteBans' own sql.table_prefix.

The H2 file

LiteBans stores its local database in an old format that ordinary tools cannot open. BlazeBans works around this for you: it takes a temporary copy it can read, imports from that, and discards the copy afterwards. There is nothing to configure, and your LiteBans file is never modified.

LiteBans keeps the file locked while running, so stop the LiteBans plugin or the whole server before importing.

Running it

/blazebans import litebans
/blazebans import litebans confirm

Same behaviour as the AdvancedBan import: it runs in the background, with imported, duplicate, and skipped counts at the end.

Imported. Records written to BlazeBans.

Duplicates. Records already present, matched against what BlazeBans has. Running an import twice is safe: the second run reports duplicates rather than doubling the history. That also makes it safe to fix a connection problem and re-run.

Skipped. Records that could not be converted. Usually missing or malformed data in the source, such as a record with no target.

A large skipped count is worth investigating before you consider the migration done.

Check some records.

/history SomeKnownPlayer
/banlist

Pick a few players you know were punished under the old plugin and confirm their history looks right.

Check scope. Imported punishments take the scope you have configured. On a network, confirm that matches what you want before staff start relying on it. See Servers and scope.

Remove the old plugin. Once you are satisfied, take AdvancedBan or LiteBans out of plugins/. Running two punishment plugins at once produces conflicting enforcement and confused staff.

Clear the credentials. import.yml holds a password for a database you no longer need to reach. Reset it once the migration is finished.

BlazeBans imports from vanilla, AdvancedBan, and LiteBans. There is no generic importer.

For another plugin, the options are:

Write records through the API. The BlazeBans API can create punishments with any type, duration, staff name, proof URL, and scope. A one-off migration plugin reading the old database and calling createPunishment is usually an afternoon's work.

Drive the commands. A script that runs /ban <player> <duration> <reason> --punisher <staff> from console covers a simple history. It is slower and loses proof and exact timestamps, but it needs no code.

Start fresh. For a server whose old history was thin or unreliable, importing nothing is a legitimate choice. Punishment history is only useful if you trust it.

"Could not find vanilla banned players file." The path in the error is where BlazeBans looked. Confirm banned-players.json is in the server root.

A connection error. Check host, port, database name, and credentials in import.yml, and confirm the database accepts connections from this machine.

A file lock error. The source plugin is still running. Stop it and try again.

"Ambiguous match" on LiteBans. More than one table matches the expected pattern. Set table-prefix to LiteBans' own sql.table_prefix.

Everything skipped. BlazeBans connected but found nothing it could convert. Confirm you pointed it at the right database, and that the source actually contains punishments.