For Server Owners
Everything Jade Slip exposes is editable in game from Cultivation's admin menu (cultivation.admin) → Config tab → the Jade Slip section, or by hand in Jade Slip's own config file. This page is the exact reference for both.
Config keys
| Key | Default | What it does |
|---|---|---|
Technique-Preset-Cap | 6 | How many technique keybind layouts this add-on raises Cultivation's cap to. Clamped to the engine's own ceiling of 8. |
Profile-Cap | 5 | How many cultivation profiles this add-on raises Cultivation's cap to. Cultivation itself never honors more than its own ceiling of 6, regardless of what's set here. |
Palettes-Require-Permission | false | Gates choosing a palette behind jadeslip.palette.<id>. |
Banners-Require-Permission | false | Gates choosing a sect banner behind jadeslip.banner.<id>. |
Meditation-Auras-Require-Permission | false | Gates choosing a meditation aura behind jadeslip.meditationAura.<id>. |
Titles-Enabled | true | Whether this add-on's nine cosmetic titles register at all. |
Brighter-Auras | true | Whether Jade Slip's palettes use the denser realm-aura set instead of Cultivation's own. |
A Last-Verified-Millis field also lives in the file. It is not a setting — it's the timestamp the license grace period counts from, written by the mod itself. Hand-editing it does nothing useful: a timestamp set in the future is clamped back to the current time the moment it's read, so it can't be used to buy an unlimited grace period.
What takes effect when
This is worth being exact about, because not every field behaves the same way once you save it.
Live, no restart needed: Palettes-Require-Permission, Banners-Require-Permission, and Meditation-Auras-Require-Permission. Each is checked fresh every time a picker is drawn or a choice is applied, so flipping one takes effect the next time a player opens the relevant menu.
Takes effect on the next restart: Technique-Preset-Cap, Profile-Cap, Titles-Enabled, and Brighter-Auras. All four are read once, when Jade Slip registers its content during server startup, rather than re-checked afterward — so changing one in the admin menu saves the new value correctly, but it only takes hold the next time the server (and therefore Jade Slip's own setup()) restarts.
All three permission toggles gate choosing, never keeping. A player already wearing a palette or meditation aura, or a sect already flying a banner, keeps it regardless of the toggle — that matches how Cultivation treats its own cosmetics; an equipped title outlives its own requirements changing too. Turn a toggle on before handing the looks out if you want the permission to bind from the start.
Permission nodes
Jade Slip declares no player-facing commands of its own — everything it adds is chosen through Cultivation's existing menus and commands, gated by the permission checks above rather than a command permission. The node for any one look is always jadeslip.<registry>.<id>, where <id> is the part of its registry key after the colon:
| Pattern | Example |
|---|---|
jadeslip.palette.<id> | jadeslip.palette.frost, jadeslip.palette.starfall |
jadeslip.banner.<id> | jadeslip.banner.frost, jadeslip.banner.stormcaller |
jadeslip.meditationAura.<id> | jadeslip.meditationAura.stillwater |
None of these nodes do anything until their matching -Require-Permission toggle is switched on; with the toggle off, the corresponding registry has no permission check at all. See Permissions for how Cultivation's own nodes are structured.
What Cultivation version this needs
The floor is enforced by manifest.json's own Dependencies entry, a real semver range the server checks before a line of Jade Slip's code runs — a Cultivation outside the range means Jade Slip is not loaded at all, with nothing fetched and nothing half-started. Check the jar you're running against your Cultivation version if you're unsure; the two are versioned and released independently.
License and compatibility self-checks
Jade Slip is distributed through a subscription, and it verifies itself against xianxia.dev so a copy that keeps circulating outside that subscription doesn't stay useful forever. This runs on a delay after boot, reading the verdict of Cultivation's own build check rather than making a request of its own.
What it checks, in order:
- Is this build too far behind? If the published version is more than three minor releases ahead of what's running, Jade Slip withdraws immediately regardless of whether it can otherwise verify — a build nobody has updated in months is exactly the case this exists to catch.
- Did the build check come back official? A confirmed, unmodified build resets the grace clock. If Jade Slip had withdrawn earlier in the session, this is also what restores it — the console says so.
- Did it come back unofficial? A build whose code doesn't match what was published withdraws immediately, with that reason stated plainly in the console.
- Otherwise (unknown — the check couldn't reach xianxia.dev or hasn't answered yet): the grace period. A build that has never verified starts a 30-day clock from the first time this happens, rather than treating a fresh install behind a firewall as instantly overdue. The console warns once 7 days remain, and withdraws once the 30 days run out with no successful check.
The compatibility check is separate and runs alongside it: Jade Slip reads the same published compatibility list Cultivation itself consults, which can name a Cultivation release that turns out to break this build after both have already shipped — something a manifest, baked into the jar at release time, can't do on its own. If that list marks this exact Jade Slip/Cultivation pairing incompatible, Jade Slip withdraws and says exactly which versions and which required range triggered it.
What withdrawing actually does: it hands back the palettes, sect banners, cosmetic titles, and the two raised caps — the same four things a plugin unload takes back. The meditation auras and the Codex lore stay in place; withdrawal is specifically about the parts of Jade Slip most clearly tied to an active purchase, not everything the jar contains. Nothing is deleted and no progression is touched: a saved palette or banner choice is kept and simply resolves to Cultivation's own default while withdrawn, and everything returns automatically — no restart of the withdrawal logic itself needed — the moment the build verifies or the versions are corrected. Withdrawal happens exactly once per session; a build that's already withdrawn doesn't repeat the action or its console message.
It fails open in every direction except silence. An unreachable xianxia.dev, a malformed compatibility list, or a version nobody has published an entry for all leave Jade Slip running untouched — an offline server is never stripped of what it paid for on the strength of one failed request. The exception is the 30-day grace period itself: a server with genuinely no outbound connection will eventually be withdrawn on schedule, with a week of console warning beforehand, because otherwise blocking the domain outright would be indistinguishable from a real check failing.
None of this is tamper-proof, and it isn't trying to be — anyone willing to edit the jar can remove the checks entirely, the same as they could delete Cultivation's own build check. What it stops is an unmodified copy that keeps working forever after being handed around outside the subscription it came with.