Commands

Every /codex subcommand, the permission each one needs, and the meaning of the common errors are listed below

EmakiCodex uses /codex as its main command and /ecodex as an alias. Both codex and open open the category-entry codex GUI; the examples below all use /codex

Remember two rules first: the normal entry checks emakicodex.use, and emakicodex.admin bypasses the use, reload, and debug checks. All administrative targets currently have to be online players

Command list

Command	Permission	Description
/codex / /codex help	emakicodex.use	Shows help
/codex codex / /codex open	emakicodex.use or emakicodex.admin	Opens the category-entry codex GUI
/codex reload	emakicodex.reload or emakicodex.admin	Reloads config, language files, vanilla advancement pages, category entries, and GUI templates; rebuilds registrations and tries to resync online players
/codex grant <player> <advId>	emakicodex.admin	Grants one vanilla Codex advancement to an online player
/codex revoke <player> <advId>	emakicodex.admin	Revokes one vanilla Codex advancement from an online player
/codex admin unlock <player> <category/entry>	emakicodex.admin	Directly unlocks one category entry without activating or claiming it
/codex admin reset <player> [category/entry]	emakicodex.admin	Resets one category entry, or all category-entry state when the composite id is omitted
/codex debug ...	emakicodex.debug or emakicodex.admin	Manages the advancement debug module. Detailed subcommands are provided by CoreLib DebugCommand

Examples

/codex
/codex codex
/codex open
/codex reload
/codex grant Steve example/first_step
/codex grant Steve emakicodex:example/challenge
/codex revoke Steve example/first_step
/codex admin unlock Steve example/first_blood
/codex admin reset Steve example/first_blood
/codex admin reset Steve
/codex debug advancement on
/codex debug advancement off

Note: grant and revoke require the target player to be online because the current implementation matches online player names exactly. admin unlock/reset also require an online target. Vanilla advId supports two forms:

Form	Example	Description
page/node	example/first_step	Recommended short form for server administrators
Full NamespacedKey	emakicodex:example/first_step	Matches the underlying vanilla advancement key

Category-entry commands use the composite id from codex/*.yml, not a vanilla NamespacedKey (the unique path the vanilla game assigns to each advancement):

<category_id>/<entry_id>

For example, example/first_blood. Keep the three-step order in mind: admin unlock changes only the unlocked state, a left click in the GUI activates attribute rewards, and a right click performs the one-time rewards.actions claim

Reload behavior

/codex reload performs these operations:

1. Releases missing default resources, controlled by config.yml > release_default_data
2. Reloads config.yml, lang/*.yml, advancements/*.yml, codex/*.yml, and GUI templates
3. Removes and re-registers dynamic advancements under the EmakiCodex namespace, then rebuilds category entries and reward providers
4. If PacketEvents is available, re-pushes the vanilla advancement tree to online players; otherwise online players may need to reconnect to see advancement UI changes
5. Keeps player category-entry data in data/<uuid>.yml and derives attribute rewards again from the new configuration

Permission nodes

The four permission nodes and their defaults are listed below:

Permission	Default	Covers
emakicodex.use	true	Use help, the category-entry GUI (codex/open), and the normal command entry
emakicodex.reload	op	Use /codex reload. Can be replaced by emakicodex.admin
emakicodex.debug	op	Use /codex debug .... Can be replaced by emakicodex.admin
emakicodex.admin	op	Use grant, revoke, and admin unlock/reset, and override use/reload/debug checks

Common LuckPerms examples:

/lp group default permission set emakicodex.use true
/lp group admin permission set emakicodex.admin true
/lp group admin permission set emakicodex.reload true
/lp group admin permission set emakicodex.debug true

Common failure cases

Match your error against this table first:

Case	Explanation
Player not found	The grant / revoke target is offline, or the name is not an exact match
Advancement ... is not registered or unchanged	The advancement ID is wrong, the page failed to load, or the player's progress did not change
category/entry is not found	The category file did not load, the composite id is misspelled, or the entry has not been unlocked
admin unlock succeeds but no attributes appear	unlock changes only the unlocked state; activate the entry in the GUI, and ensure it declares rewards.attributes
A right-click claim fails	The entry is locked, has no rewards.actions, or has already been claimed; claims are one-time
Online players cannot see new nodes after reload	PacketEvents is missing or resync failed; players should reconnect
Node coordinates do not apply	PacketEvents must be installed and advancement.packet_coordinates: true must be enabled