CoreStructuresX

CoreStructuresX is a Paper-only modular structure plugin for Minecraft servers. It lets administrators build structures from validated WorldEdit or FastAsyncWorldEdit schematic packs, then expand them through marked connection points in automatic or player-proximity mode.

The goal is to make modular structures controlled, repeatable, and recoverable without tying them to world generation. Every structure is started manually by an administrator, while pack settings define how its modules can continue to expand.

For pack authoring, marker formats, configuration examples, commands, and troubleshooting, visit the CoreStructuresX documentation.

Warning: Work in Progress

CoreStructuresX is currently under active development and should be considered a work in progress.

The plugin is not yet feature-complete and may contain bugs, incomplete functionality, unexpected behavior, or breaking issues. Future updates may modify commands, configuration files, pack formats, marker behavior, persistence data, expansion logic, or other parts of the plugin without maintaining full backward compatibility.

Before using CoreStructuresX on a production server:

test the plugin and all structure packs in a separate environment;

keep regular backups of worlds, pack files, configuration files, and instance JSON data;

review release notes before updating;

do not assume that configurations or structures created with an earlier version will continue to work unchanged.

CoreStructuresX is currently recommended primarily for testing, development, and controlled environments.

What CoreStructuresX Does

Loads modular structure packs from the plugin data folder.
Uses WorldEdit or FastAsyncWorldEdit .schem files as structure modules.
Validates pack files, schematic references, marker signs, groups, and placement settings before a structure starts.
Uses [CSX] marker signs for origins, module connectors, and post-paste console commands.
Supports weighted schematic groups, fallback groups, and closing groups.
Supports AUTOMATIC and PLAYER_PROXIMITY expansion modes.
Checks transformed schematic bounds to prevent unwanted module overlap.
Supports optional block whitelist checks and connector lookahead checks.
Pastes large schematics through configurable chunked jobs.
Can pause automatic expansion when server TPS or MSPT crosses configured limits.
Persists instances, generated modules, connectors, triggers, and command state in JSON.
Includes administration commands for validation, pack listing, structure starts, and instance management.

Stats

How To Use

Install CoreStructuresX together with WorldEdit or FastAsyncWorldEdit on a Paper server, then start the server once to generate the plugin folders and default config.yml.

Create a pack under plugins/CoreStructuresX/packs/<pack-id>/ with its YAML definitions, schematic files, and [CSX] marker signs. Run /csx validate and correct every reported error before starting the structure with /csx start <pack-id>.

Structures are not added to biome, chunk, seed, or terrain generation. An administrator always chooses when and where the first module is placed.

Because CoreStructuresX is still under active development, test new packs and plugin updates on a separate server before using them in an existing production world.

Modular Structure Packs

Each pack defines one structure type and separates its responsibilities across focused files:

pack.yml identifies the pack and its referenced files.
structure.yml controls the start group, generation mode, placement rules, limits, and performance settings.
groups.yml defines weighted schematic candidates, fallback groups, and closing groups.
commands.yml defines optional weighted console commands used by command markers.
schematics/ contains the WorldEdit or FAWE .schem modules.

Strict validation prevents invalid packs from starting. This catches missing files, unresolved groups, invalid markers, unsupported settings, and other authoring problems before blocks are pasted into the world.

Validation reduces the risk of invalid placements but does not guarantee that a pack is free from logical, visual, or runtime problems. Pack authors should always test complete expansion paths before public or production use.

Marker-Driven Expansion

CoreStructuresX reads three marker types from signs saved inside schematics:

ORIGIN defines the module placement origin. If it is omitted, the saved schematic clipboard origin is used by default.
CONNECTOR creates a one-use expansion point linked to a schematic group.
COMMAND runs one weighted command-group entry from the server console after placement or when its proximity trigger activates.

Marker signs are replaced during paste, while the connector and trigger data needed by the running structure is saved to its instance JSON.

Only trusted administrators should be allowed to author packs or use structure-start commands, especially when a pack contains console command markers.

Marker syntax and behavior may change while the plugin remains under development. Pack authors should review the documentation and release notes after every update.

Expansion And Placement Safety

AUTOMATIC mode continues through open connectors while respecting the pack's job delay, generation limits, placement checks, and server-stability thresholds.

PLAYER_PROXIMITY mode activates a specific connector or command when a player enters its configured radius in the same world.

Before placing a candidate module, CoreStructuresX can check its transformed schematic bounds against generated and pending modules. Packs can also enable block whitelist checks, lookahead checks, fallback candidates, and closing groups to control how structures finish or recover from rejected placements.

These safeguards are intended to reduce invalid or unwanted placements, but they should not be treated as a substitute for backups and controlled testing. Bugs, incorrect pack settings, or unexpected schematic geometry may still cause undesirable world modifications.

Persistence And Administration

Each running structure is stored as JSON under plugins/CoreStructuresX/data/instances/. Persisted state includes generated modules, open connectors, proximity triggers, command records, limits, and current instance status, allowing the plugin to restore its runtime state after a normal restart.

Administrators can:

reload configuration and packs with /csx reload
validate all packs or one selected pack with /csx validate
list loaded packs with /csx packs list
start an instance with /csx start <pack-id>
inspect active instances with /csx instances list and /csx instance info <instance-id>
pause, resume, or stop an instance with /csx instance <pause|resume|stop> <instance-id>

Back up instance JSON before manual recovery or repair. CoreStructuresX does not automatically delete corrupted persistence data.

Persistence formats may change between development versions. Before updating, back up the entire plugins/CoreStructuresX/ folder and review the release notes for migration requirements or compatibility warnings.

Current State

CoreStructuresX is currently under active development and is not yet considered feature-complete or production-stable.

Existing features, commands, configuration options, pack formats, persistence structures, and generation behavior may change during development. Bugs and incomplete functionality may still be present, and updates may require pack, configuration, or instance-data adjustments.

CoreStructuresX currently:

supports Paper 1.21.11 and above
requires Java 21 or newer
requires WorldEdit or FastAsyncWorldEdit to be installed and loaded
supports manual structure starts only
supports WorldEdit or FAWE .schem packs
stores runtime instance state in local JSON files
does not integrate with biome, chunk, seed, or terrain generation
does not support Folia in version 2026.1.0
reports anonymous usage statistics through the server-wide bStats configuration

The listed functionality describes the current development version and may be changed, expanded, replaced, or removed in future releases.

Summary

CoreStructuresX is built for server administrators and pack authors who want modular schematic structures with strict validation, controlled expansion, placement safeguards, and restart-safe state.

It provides a focused Paper workflow: define modules and connections in a pack, validate the pack, start an instance at a chosen location, and let CoreStructuresX manage its configured expansion rules.

CoreStructuresX remains a work in progress. It should currently be used with appropriate testing, backups, and awareness that future updates may introduce behavioral changes or require existing packs and configuration files to be updated.

Also try

CoreToolsX

CoreArmorX

CoreChatX

CoreCaseX

CoreExtractionX