Manual Imports vs In-Game Management

Nightbreak-managed plugins now prefer in-game setup and content management, but manual imports still exist as a fallback.

Recommended: In-Game Management

Use the setup menu plus a linked Nightbreak token when you want:

• access-aware content browsing
• one-click or menu-driven installation
• bulk download and update commands
• automatic outdated-package checks
• a workflow that matches the current codebase

This is the preferred path for:

• EliteMobs
• BetterStructures
• FreeMinecraftModels
• EternalTD
• ResurrectionChest
• WorldCannon

All six run the shared importer, so all six also accept the manual fallback below.

Fallback: Manual Imports

Manual imports are still useful when:

• you already have package zips downloaded
• you are moving files between servers
• you want to work offline from Nightbreak during testing
• a package is intentionally being distributed outside the in-game download path

Bulk Nightbreak downloads also end up in the plugin imports folder. The difference is that the in-game path handles the access checks and download step for you.

Import Folder Map

Plugin	Import Folder
EliteMobs	plugins/EliteMobs/imports
BetterStructures	plugins/BetterStructures/imports
FreeMinecraftModels	plugins/FreeMinecraftModels/imports
EternalTD	plugins/EternalTD/imports
ResurrectionChest	plugins/ResurrectionChest/imports
WorldCannon	plugins/CannonRTP/imports

WorldCannon's plugin folder is named CannonRTP — that is the plugin's internal name, and it is where both its imports folder and its installed content live.

Manual Import Rules

• Keep the downloaded package zipped unless the plugin-specific docs say otherwise.
• Put the package into the correct imports folder.
• Reload or restart the plugin if the plugin-specific docs require it.
• Re-open the setup menu afterward so you can confirm the install state.

The shared importer can process:

• .zip packages placed in imports
• certain already-unzipped folders if they include pack.meta
• .bbmodel files for FreeMinecraftModels

Archives are extracted into a hidden staging folder inside imports and only installed from there. The importer deletes that staging folder after success or failure, so normal failed imports leave the original zip ready for retry rather than a visible half-extracted package beside it.

What The Importer Accepts

pack.meta decides where content goes

A package can ship a pack.meta file at the top level naming the plugin platform it targets — elitemobs, betterstructures, freeminecraftmodels, eternaltd, extractioncraft, resurrectionchest, megablocksurvivors, or worldcannon (also accepted as cannonrtp or world_cannon). That name is matched case-insensitively and surrounding whitespace, line endings and a leading byte-order mark are ignored, so a file saved by a Windows editor works fine.

If the archive has no pack.meta, it is treated as a package for the plugin whose imports folder it was dropped into.

If pack.meta names something the importer does not know, the package is rejected and the zip is left in imports so you can fix it and try again.

Top-level folder names must be recognized

The importer routes each top-level folder in the package to a destination by name. Some names work for every platform:

Folder	Goes to
worldcontainer	The server's world container (each subfolder becomes a world)
models or modelengine	FreeMinecraftModels' models folder, or ModelEngine's blueprints folder if only ModelEngine is installed
scripts	plugins/FreeMinecraftModels/scripts
freeminecraftmodels, elitemobs, betterstructures	That plugin's data folder (plugins/FreeMinecraftModels, plugins/EliteMobs or plugins/BetterStructures). Lay the folder out like the data folder, for example freeminecraftmodels/enchantments/
pack.meta	Ignored — it is metadata, not content

Models under freeminecraftmodels/models/ go to whichever models folder FreeMinecraftModels reads, including an older install's Models folder.

The importer resolves every other top-level folder for the platform the package targets. Each folder goes to the folder of the same name in the plugin's data folder, unless the table says otherwise:

Platform	Folders for that plugin	Folders for another plugin
elitemobs	custombosses, customitems, customtreasurechests, content_packages (dungeonpackages also goes there), customevents, customspawns, customquests, customarenas, npcs, npc_scripts, behaviors, transport_routes, transport_networks, wormholes, powers, world_blueprints, resource_pack, enchantments	None
betterstructures	content_packages, schematics, spawn_pools, components, modules, module_generators, treasures, generators	EliteMobs: custombosses, customitems, customtreasurechests, powers, enchantments
freeminecraftmodels	content_packages, recipes, enchantments	EliteMobs: customitems, skipped when EliteMobs is not enabled
eternaltd	npcs, levels, waves, worlds, content_packages, content_markers	None
resurrectionchest	content_packages	None
worldcannon	content_packages, cannons (fun_rtps also goes there), and cannonrtp, worldcannon or world_cannon for the data folder itself (plugins/CannonRTP)	None
extractioncraft	content_packages, loot_pools, loot_tables	EliteMobs: customquests, npcs, custombosses, customitems, customtreasurechests, powers, enchantments, npc_scripts, behaviors. BetterStructures: schematics, spawn_pools, components, modules, module_generators, treasures, generators
megablocksurvivors	content_packages, npcs, schematics, worlds, content_markers, and megablocksurvivors for the data folder itself (plugins/MegaBlockSurvivors)	None

An enchantments/ folder holds enchantment definitions and their local Lua effects, and never uses the global scripts/ route. To ship FreeMinecraftModels enchantments in another platform's package, use freeminecraftmodels/enchantments/.

A top-level folder the importer does not recognize for that platform causes the whole package to be rejected rather than partially installed, and the archive is retained. If your package will not import, the console names the offending folder.

Imports into another plugin's folder

Plugins read their content folders at startup or reload. When a package imports files into another plugin's folder:

• FreeMinecraftModels reloads its imported content automatically.
• BetterStructures reloads the new content once its own startup has finished. If it is still starting 10 minutes later, the console asks you to run /bs reload.
• A BetterStructures package that imports EliteMobs content reloads EliteMobs.
• When Extractioncraft imports packages, it reloads BetterStructures, and also EliteMobs when a package added EliteMobs content.

In other cases, reload or restart the plugin that owns the folder.

Updating a loaded world

Before replacing a loaded world, the importer moves its players to the spawn of another loaded world and asks the server to unload the target. If no other world is available, a teleport fails, or the server refuses the unload, the import stops and retains the archive. Move players out and resolve the reported problem before retrying.

Retired files in an import

The owning plugin checks for retired configuration formats before and after imports. Matching files are preserved in plugins/MagmaCore/outdated files/, outside the active content folders. If an older package installs retired content, download its updated version. See retired configuration files.

Files a package update stops shipping

Imports copy and overwrite files, so on their own they would leave behind a file that a newer package version dropped, and the plugin would keep loading it. MagmaCore therefore records the files each package installs under the plugins folder in plugins/MagmaCore/import manifests/, one JSON file per package. It names the package after the zip or folder without .zip and without a trailing version such as _v22, so the-vampire-manor_v22.zip and the-vampire-manor_v23.zip are the same package.

When the next import of that package no longer ships a file the previous import installed, the importer moves the file to plugins/MagmaCore/outdated files/<plugin folder>/<time>-<package>/, keeping its path inside the plugin folder, and the console lists the moved files. The move is part of the import transaction, so a failed import puts the files back. Files are moved rather than deleted, so edits you made to them stay in the archived copy.

A file stays in place when:

• another package's record still lists it
• the previous and current imports share no files, which means an unrelated package reused the name
• it is outside the plugins folder, such as a world folder, which imports replace whole

A package's first recorded import archives nothing. Cleanup starts with its next update.

Failed imports roll back

If rollback is incomplete, MagmaCore retains the recovery directory and logs its path and the destinations it could not restore. Preserve those recovery files and resolve the reported failures before retrying the import.

An import is applied as one transaction. Existing files are backed up before being replaced, replaced world folders are moved aside rather than deleted, and a failure part-way through triggers rollback of every destination the package touched. The zip stays in imports for a retry after the failure is resolved. If the rollback itself encounters a filesystem error, the console explicitly reports that rollback was incomplete and tells you to inspect the logged destinations before retrying.

The archive is only deleted once the import has fully committed. If you see a package still sitting in imports after a reload, that is the importer telling you it did not install — check the console for the reason.

Important Differences

In-game path

• token aware
• can show locked and outdated content
• usually reloads automatically after bulk operations
• reflects the current intended admin workflow

Manual path

• works without in-game download access
• requires you to manage zip files yourself
• may still require a plugin reload
• can leave content in a downloaded-but-not-enabled state depending on the plugin
• may expose package-shape issues that the in-game access flow would normally hide until install time