Systems

Migration

Moving from the protections module of ExyliaSurvivalCore, on one server or a network, and importing ProtectionStones regions.

From ExyliaSurvivalCore

Protections used to be a module of ExyliaSurvivalCore. They are now this plugin, with the same features, the same keys and the same data under new table names. The survival core keeps running beside it: its statistics and player settings still apply to protections, read through ExyliaLib.

What the import does

The import runs on its own on every start until .imported-survivalcore is in plugins/ExyliaProtections/. It reads plugins/ExyliaSurvivalCore/; without that folder there is nothing to import and nothing is written. Every path under From is inside it.

What	From	To
Database settings	`database.yml`	`database.yml`, copied as it is, only when ExyliaProtections has none yet. Same engine, same credentials and the same Redis `server-id`, so every protection keeps belonging to this server.
An H2 database	The H2 file `database.yml` names, `database/h2.mv.db` by default	The same path under `plugins/ExyliaProtections/`, through a temporary file moved into place. When it cannot be copied, or ExyliaProtections already has an H2 file there, the copied `database.yml` points at the survival core's file instead.
Settings	`modules/protections/config.yml`	`config.yml`, only when there is none yet. The keys are the same.
Messages	`lang/<language>/modules/protections/messages.yml`, every language	`lang/<language>/messages.yml`, where none exists yet. The keys are the same.
Rows	Every `sc_protection*` table	Its `protections*` twin. See below.

The files are copied first, before anything opens the database, and never over a file ExyliaProtections already has. Each one copied is named in the console. The rows are copied before any protection is loaded:

Old table	New table
`sc_protections`	`protections`
`sc_protection_logs`	`protections_logs`
`sc_protection_accounts`	`protections_accounts`
`sc_protection_listings`	`protections_listings`
`sc_protection_seen`	`protections_seen`
`sc_protection_rent_offers`	`protections_rent_offers`
`sc_protection_warps`	`protections_warps`
`sc_protection_warp_ratings`	`protections_warp_ratings`
`sc_protection_warp_visits`	`protections_warp_visits`
`sc_protection_warp_totals`	`protections_warp_totals`

A table is copied only while its twin is empty, so on a network sharing one database each table is copied once, by whichever server gets there first. The old tables are left exactly as they were, so a rollback finds them untouched. When every table is in, the console says how many rows were imported and .imported-survivalcore is written; from then on nothing is read from the old tables again. Deleting the file runs the import again on the next start, which still only fills empty tables.

The rows wait, without writing the file, while ExyliaSurvivalCore still runs its own protections module, which could change them after the copy. The files are copied all the same, and the console says:

ExyliaSurvivalCore still runs its own protections module, so its protections are not imported yet. Update it and restart to bring them over.

Update it to a release without the module, and restart. A failed copy of the rows is reported and tried again on the next start; protections load either way.

When the import was skipped

The files are only ever copied where ExyliaProtections has none, and nothing runs once .imported-survivalcore exists. A server whose console said the protection files of ExyliaSurvivalCore could not be imported already has its own defaults and possibly the marker, so restarting alone brings nothing over. Make room for the import and let it run again:

Stop the server

Nothing below is removed while the server has it open.

Remove what should come from the survival core

In plugins/ExyliaProtections/, delete database.yml, and on H2 the database file too, database/h2.mv.db unless database.h2.file names another; then config.yml and each lang/<language>/messages.yml you want the survival core's version of.

Delete the marker and start

Delete plugins/ExyliaProtections/.imported-survivalcore if it exists, and start the server. The console names each file it copied and says how many rows were imported.

If ExyliaProtections already ran on its own new H2 database, protections players made there stay in that file and are not carried into the one copied.

What is not imported

The menus. They were redesigned — a hub, a list and an overview with seven sections — so the old modules/protections/menus/ is ignored and the new screens are written fresh. Restyle them again under lang/<language>/menus/; see Menus.
Statistics and player settings. They stay in ExyliaSurvivalCore, which keeps counting and applying them while it is installed.

WorldGuard regions

The import copies your config.yml, so a server on the WORLDGUARD backend stays on it. The regions it mirrors keep their sc_ps_ prefix, so the regions the survival core wrote are recognised as this plugin's own: they are rewritten in place, not left behind, and never count as a foreign region that blocks new land.

Without your config.yml the mirrored regions are removed

With WorldGuard installed, every start makes WorldGuard hold exactly the regions the chosen backend wants. A server that starts on the default INTERNAL backend — which is what happens when the import was skipped and your config.yml was not copied — removes every sc_ps_ region. No protection is lost: the protections are in the database. Copy your config.yml, or run /protections admin migrate WORLDGUARD, and every region is written again. See Backends.

A network

Update every server together. A server still running the old module keeps writing to the sc_protection* tables, and the import copies a table only once, while its twin is empty: a protection made on an old server after the first updated server started is never copied. Stop the network, update ExyliaSurvivalCore and install ExyliaProtections everywhere, then start it.

Each server keeps its own name — the proxy bridge's, or server-id in the redis block of database.yml — so each protection goes on being enforced by the server it was made on.

What else carries over

Permissions. The survival core's nodes are declared by ExyliaProtections and grant the new ones, so what staff were given keeps working:

Old node	Grants
`exyliasurvivalcore.protections`	`exyliaprotections.use`
`exyliasurvivalcore.protections.select`	`exyliaprotections.select`
`exyliasurvivalcore.protections.admin`	`exyliaprotections.admin`
`exyliasurvivalcore.protections.bypass`	`exyliaprotections.bypass`
`exyliasurvivalcore.protections.limit.<n>`	Counted with `exyliaprotections.limit.<n>`: the highest number of either wins

See Permissions.

Commands. /protections, /ps and /claims keep their names and subcommands.
Role permissions, flags, tiers and roles are stored in each protection and in config.yml under the same keys.
Placeholders. Inside Exylia plugins' own files the names are the same, %protections_count%. Through PlaceholderAPI the plugin in front changes: %exyliasurvivalcore_protections_count% becomes %exyliaprotections_protections_count%. See Placeholders.
The API. Plugins read protections through ExyliaLib's ProtectionsService. See API.

From ProtectionStones

/protections admin import protectionstones --dry-run
/protections admin import protectionstones

The import needs WorldGuard enabled; ProtectionStones itself may already be removed, because WorldGuard keeps the regions and their flags. Run it with --dry-run first: that reports what would happen and changes nothing. It is a command only, with exyliaprotections.admin, from the console or in game.

It walks every loaded world of the server it runs on and takes each region named ps<x>x<y>y<z>z. The core is the block that name points at, and the region's box becomes the land.

Region	Becomes
`ps-block-material`	The tier: `import.tier-map` first — the block as written, like `PLAYER_HEAD:Notch`, then without the suffix — then the tier placed with the same block, then `import.default-tier`
First owner	The owner
Other owners	Members with `import.owner-role`
Members	Members with `import.member-role`
`ps-name`	The name, as plain text up to 32 characters; without one, the default name
`ps-home`	The home; without one, on top of the core
`pvp`, `mob-spawning`, `fire-spread`, `crop-growth`, `leaf-decay`	The flag of the same name
`tnt`, `creeper-explosion`, `other-explosion`	`explosions`
`water-flow`, `lava-flow`	`liquid-flow`
`entry`	`visitor-entry`

A flag the region never set keeps the tier's default. When several WorldGuard flags feed one flag, any of them denying turns it off. A role the protection does not have falls back to its first role other than visitor, and with no such role the players are left out.

Key	Default	What it does
`import.tier-map`	`{}`	ProtectionStones block to tier id
`import.default-tier`	`small`	The tier for blocks nothing matches; blank skips those regions
`import.owner-role`	`trusted`	The role owners other than the first get
`import.member-role`	`member`	The role members get
`import.remove-source-regions`	`false`	Whether each imported region is removed from WorldGuard

A region is left out, and listed with the reason, when it is not a cuboid (merged ProtectionStones regions are polygons), has no owner, has no tier, or overlaps a protection of this server or one the same run already took. The answer counts imported, already imported, overlapping and skipped, and lists the first ten problems.

An imported protection's id comes from its server, world and region, so running the import again skips what it already brought over. Limits are not checked, and each protection belongs to the server that ran the import.

Kept regions still act in WorldGuard

With import.remove-source-regions off, the default, the ProtectionStones regions stay in WorldGuard and keep enforcing their old owners and members beside the new protection: a member added later in ExyliaProtections can still be refused by WorldGuard there. They also count as foreign regions, so upgrading an imported protection, merging it, or moving it over its old region is refused with the WorldGuard overlap message until the region is removed or listed in settings.allowed-world-guard-regions. Turn the key on to remove each region as it is imported; a dry run warns when it is on.

ProtectionStones also registers /ps. Remove it once the import is done, so /ps reaches ExyliaProtections.

Something missing on this page? Tell us on Discord