Commands and Administration

Commands and administration

Admin commands, browser inventory titles, safe reloads and schema-preserving configuration migration.

Documentation for VoxelCore v1.0.0. Home · Installation · Compatibility

Admin commands

/voxelcore admin content info
/voxelcore admin content reload
/voxelcore admin content rl

/voxelcore admin item list
/voxelcore admin item info <content-id>
/voxelcore admin item give <content-id> [amount] [player]
/voxelcore admin item ui
/voxelcore admin item identify
/voxelcore admin item id
/voxelcore admin item verify <content-id>
/voxelcore admin item test <content-id>

/voxelcore admin block list
/voxelcore admin block info <content-id>
/voxelcore admin block give <content-id> [amount] [player]
/voxelcore admin block ui
/voxelcore admin block identify

/voxelcore admin pack info
/voxelcore admin pack host [status|test]
/voxelcore admin pack send <online-player>
/voxelcore admin pack validate [target]
/voxelcore admin pack build [java|bedrock|all] [target]
/voxelcore admin pack stop

When [target] is omitted, VoxelCore uses the current server version only when an exact validated pack profile exists. Otherwise specify a target explicitly.

pack build publishes the completed ZIP atomically, preserving the previous successful artifact when compilation fails. After a successful build it also performs the safe content reload below, so new items and :name: UI placeholders become active without a second command. If live reload validation fails, the built ZIP is retained while the previous runtime revision stays active and the command reports both outcomes.

pack build with no scope (or all) builds both packs as before. pack build java builds, hosts and reloads only the Java pack, skipping the slower Bedrock conversion; pack build bedrock only converts and publishes the Bedrock pack for the running server's version (run java first after content changes, so render allocations are current). Only one pack build runs at a time: starting another reports the running one. pack stop (alias cancel) ends the running build at its next checkpoint (each converted item, zip entry or download chunk) without publishing anything; a Java compile already in progress finishes first, and a build that has started publishing completes instead.

pack host reports the bind address, active socket, advertised URL, hosted file size, and SHA-1. pack send <online-player> (alias pack push) sends the current pack request immediately, independent of the join setting; the global required/prompt settings still apply. A successful command means the request was issued, while the host request log shows whether the client connected to download it. pack host test downloads the file through the local listener and verifies its byte count and SHA-1; this confirms the host inside the Minecraft process/container, but does not test Docker/Pterodactyl port exposure or a public tunnel. Startup logs report the same details and include bind exceptions. With resource_pack.host.debug: true, each HTTP request is logged with its remote address, method, path, response status, and bytes sent.

The final pack is size-optimized deterministically: JSON and pack.mcmeta whitespace is removed without modifying string values, PNGs are losslessly re-encoded only when the result is smaller, and each ZIP entry uses maximum DEFLATE compression only when it beats storing the optimized bytes directly. Rebuilding identical content therefore produces identical pack bytes without inflating already-compressed images.

item list reports only concrete definitions. Abstract definitions can still be inspected directly with item info and used as inheritance parents; bound does not affect list visibility.

item ui and block ui open a six-row administrative content browser. The first five rows contain up to 45 real VoxelCore item previews per page; the bottom row is reserved for navigation and close controls. Item browsing shows every concrete item definition. Block browsing shows every concrete custom block that has a giveable matching item definition.

Clicking a content entry creates a fresh canonical ItemStack through ItemManager; the preview's informational lore is never copied into the received item. A normal click takes one item and Shift-click takes one full natural stack. Previous/next page controls occupy the bottom-left and bottom-right slots. The browser is read-only, so players cannot move preview/control items into their inventory.

Browser contents are rebuilt from the active runtime snapshot whenever a page opens. If a content reload publishes a new revision while a browser is already open, the next click refreshes that browser before performing an action.

Configurable item/block browser titles

Both browser title templates live in plugins/VoxelCore/config.yml under ui.browser. The defaults retain the familiar "VC Items 1/3" and "VC Blocks 1/3" titles, but can be replaced with custom resource-pack font glyphs and offsets:

ui:
  browser:
    titles:
      items: '&f:offset_-8::vc_items_page_{page}:'
      blocks: '&f:offset_-8::vc_blocks_page_{page}:'
    page_titles:
      items:
        '1': '&f:offset_-8::vc_items_first_page:'
      blocks: {}

• {page} is the 1-based current page number.
• {pages} is the total page count; {total} is the number of available entries.
• {type} expands to Items or Blocks.
• page_titles.items.<number> / page_titles.blocks.<number> (1-based) can replace a specific page's title without changing other pages; other pages fall back to the per-type titles template.
• Tokens expand before VoxelCore's :glyph: and :offset_<pixels>: resolution, allowing a glyph named vc_items_page_2 to be selected from a template containing :vc_items_page_{page}:. Traditional & chat colors are supported. Titles are read from the current configuration each time a page opens, so a VoxelCore admin reload picks up edits without rebuilding a resource pack unless the glyph artwork itself has changed.

The six-row inventory size and pagination buttons remain unchanged. For older existing installations, the v7 config migration preserves authored settings and adds the browser title defaults.

Safe reloads

Reload builds the candidate revision in isolation:

1. discover and parse packs
2. resolve inheritance
3. compile immutable definitions
4. reconcile stable item and block allocations
5. preflight every definition through the active platform adapter
6. persist the validated allocation state
7. atomically publish the new snapshot

Any failure before publication leaves the existing runtime revision active.

Configuration migration

config.yml contains a schema version. When the bundled schema changes, VoxelCore backs up the old file as config.yml.old, config.yml.old.1, etc., adds newly introduced defaults, updates the schema version, and preserves existing user values instead of replacing the configuration wholesale.