Runes belong to the identity, not the player.
MCIdentityRune is a standalone add-on that gives every MCIdentity identity its own set of rune slots. It ships as its own jar, keeps its own database, and installs alongside the core plugin. Open it with /rune.
What changed: runes left the core plugin
The rune system used to live inside MCIdentity, sharing its tables and its GUI. MCIdentity 4.0.0 removed it, and this add-on picked it up — along with the storage, which it now owns outright.
Runes inside MCIdentity
- The list of rune types and every identity's rune slots lived in the core plugin's own database.
- Slot 6 of the main identity menu opened a rune GUI the core plugin drew.
- Handing out runes was an admin command of the core plugin.
- Every rune change meant a release of the whole identity plugin.
Runes in MCIdentityRune
- The add-on creates and owns its data in its own database, with no link to anything the core plugin stores.
- Its own /rune command and its own menu, on its own version line.
- It reads one thing from the core: which identity you are currently wearing.
- Either plugin can be upgraded without waiting for the other.
Upgrading the core to 4.0.0 deletes the old rune data from its database, and this add-on starts empty rather than importing it. Existing rune assignments are not recoverable — back the database up first if you want to keep them.
Every row is keyed by identity
A rune is equipped by an identity, never by a player. Two identities owned by the same person wear entirely separate runes, and swapping identity swaps the whole rune set with it.
This is the invariant the whole add-on is built around: every read and every write is tied to the identity the core plugin says you are wearing, never to the player. A player with no active identity has nothing to read and nothing to write to.
| Situation | Result |
|---|---|
| Wearing a profession identity | allowed — reads and writes that identity's slots |
| Wearing the base Player profession | denied — the base profession may not use runes |
| No active identity | denied — there is nothing to key the row by |
| Core plugin unreachable | denied — the add-on fails closed rather than guessing |
| Identity swapped mid-interaction | The write still lands on the identity that was resolved when the action started, never on the new one. |
A failed read returns an empty result, never another identity's runes. There is no fallback that could show one identity the equipment of another.
The rune menu
/rune with no arguments opens a six-row menu for the identity you are wearing. Equipped slots show the rune's display name; empty slots show a placeholder. The layout is fixed, because the slot numbers are stored in the database and existing rows reference them.
Rune slots 1–9 Slot 10 — ultimate rune Close
Ten slots per identity. The last one is the ultimate slot, set apart in the layout but stored exactly like the others. Clicking a slot equips or clears it; every other click in the menu is cancelled so nothing can be dragged out of it.
Commands & permissions
| Command | Description | Permission | Default |
|---|---|---|---|
| /rune | Open the rune menu for the identity you are wearing. | mcoriax.mcidentity.rune.command.use | everyone |
| /rune list | List every registered rune type. | mcoriax.mcidentity.rune.command.list | everyone |
| /rune register <code> <display name> | Register a rune type. Idempotent — registering an existing code keeps the original. | mcoriax.mcidentity.rune.command.register | operators |
| /rune set <slot> <code> | Equip a rune into an empty slot of your active identity. | mcoriax.mcidentity.rune.command.set | operators |
| /rune clear <slot> | Empty a slot. The only way an assignment is ever removed. | mcoriax.mcidentity.rune.command.clear | operators |
mcoriax.mcidentity.rune.admin grants every operator command at once, and mcoriax.mcidentity.rune.* grants everything.
Registering and equipping a rune
An operator first registers a rune type with a short code and a display name, for example the code ember with the name Ember Sigil. They can then place it into a numbered slot of the identity they are wearing, and clear that slot again later.
Rune codes ignore capital letters and surrounding spaces, so Ember and ember are the same rune. A slot number outside 1 to 10 is refused before anything is saved.
Setting a rune fills a slot, it does not swap
An assignment is permanent, so setting a rune refuses rather than writing over what is already there:
| Case | Result |
|---|---|
| The slot already holds a rune | Refused. Clear the slot first. |
| The identity already holds that rune in another slot | Refused. A rune is held in one slot or none. |
Moving a rune is therefore deliberate: clear the slot, then set the rune again. Clearing is the only way a slot is emptied, and it stays an operator's command: it exists to correct a bad row, not to swap runes around.
Storage
The add-on keeps its own storage and picks its backend the same way the core plugin does, in its own configuration file.
- SQLite — default, zero configuration
- MySQL / MariaDB
- PostgreSQL
- MongoDB
- MCIdentity Central Server (needs MCIdentity 4.7.0 or newer)
It stores two things: the list of rune types, each with its code, display name, and an optional item that shows what the rune looks like; and which rune sits in which slot of each identity.
What a rune looks like
When an operator registers a rune while holding an item, that item is saved as the rune's look. An empty hand registers the rune without one. The look describes what a rune is, not what anyone has equipped, so a rune can later be handed out, inspected, or browsed as a real item.
Nothing in the add-on's storage depends on the core plugin's storage. That is deliberate: it lets the two plugins be upgraded, and even kept in different databases, independently. Storage is set up automatically on every start, and every query is built safely from fixed templates.
Every database call runs off the game thread on the add-on's own worker pool, so a slow or unreachable database never stalls the server — see the core plugin's Data Storage page for the same model applied to identities.
Installing
| Requirement | Why |
|---|---|
| Java 25 or newer | Matches the core plugin. |
| SpigotMC, PaperMC, or Folia | One universal jar; the server type is detected at startup. |
| MCIdentity 4.2.0 or newer | Hard dependency. It owns the identity a rune is attached to, and 4.2.0 is the first release that shares its scheduling with the add-ons. On an older core the add-on logs an error and switches itself off. |
| MCIdentity 4.7.0 or newer | Only when the add-on stores its data on the central server, because it reuses the core plugin's connection to it. |
| A database | Optional in practice: SQLite is the default and needs no setup. |
- Put the MCIdentityRune jar into your server's plugins folder, alongside MCIdentity.
- Start the server once. The add-on writes its configuration file and then switches itself off, because it ships disabled so it never does anything you did not ask for.
- Turn the add-on on in that file, and choose a different storage backend if you do not want SQLite.
- Restart the server.
If MCIdentity is missing, the add-on logs an error and switches itself off. It never runs with runes attached to nothing.
For developers
The add-on publishes its own developer library, in the same three-part shape as the core plugin's. Plugins that build on it should list MCIdentityRune as a dependency so it loads first.
| Event | Fires when |
|---|---|
| Rune set | A rune is about to be equipped into, or cleared from, a slot. Cancellable — cancelling refuses the change before it reaches the database. |
The event tells you the player, the identity the change targets, the slot number, and the rune (none when the slot is being cleared). Store your own data against the identity, never the player — that is the key the add-on itself uses.
The core plugin's own integration surface is on the Developer API and Events & Listeners pages. For this add-on's release history, see the MCIdentityRune change logs.