SMP Spawners v0.0.5

What is SMP Spawners?

SMP Spawners is a high-performance stacked spawner system built for survival, economy, Lifesteal, Box, and competitive SMP servers.

Instead of creating hundreds or thousands of living entities, managed spawners calculate their configured loot directly. The resulting items are inserted into a hopper below the spawner or delivered through a deterministic nearby output route.

This gives players the progression and economy value of stacked spawners without filling chunks with mobs, pathfinding tasks, entity collisions, AI processing, or uncontrolled item loss.

Every managed spawner stores its own identity, type, owner, stack amount, production timing, pending output, upgrades, XP balance, location, and runtime status.

The core system works without a database or mandatory third-party plugin.

Built for High-Performance SMP Economies

• Eliminate unnecessary mob entities — managed spawners produce configured loot instead of spawning mobs.
• Support massive stacks — combine thousands of logical spawners into one physical block.
• Reduce entity lag — avoid mob AI, pathfinding, collisions, activation ranges, and crowded grinder chambers.
• Deliver output directly — items are inserted into a hopper below before any world item is created.
• Protect generated loot — blocked output is retained as pending debt and retried instead of silently disappearing.
• Control your economy — configure intervals, loot materials, chances, minimums, maximums, prices, and stack limits.
• Give players clean management tools — included menus show stack size, production status, destinations, pending items, loot, and XP.
• Operate safely on Folia — region, entity, global, and asynchronous work is routed through the correct scheduler.

Core Features

• Entity-free production — managed spawners produce loot directly instead of creating mobs.
• 75 bundled spawner definitions — includes passive, hostile, aquatic, Nether, End, boss, and modern Minecraft entities.
• Spawner stacking — combine matching spawners into one physical block.
• Large stack limits — default maximum is 100,000 logical spawners per block.
• Batch stacking — stand to add one or sneak to add a configurable batch, default 64.
• Batch breaking — stand to remove one or sneak to remove a configurable batch.
• Encoded spawner items — custom spawner type and logical amount are stored in the item.
• Same-type validation — different spawner types cannot be merged accidentally.
• Owner tracking — every placed managed spawner records its owner.
• Per-chunk limits — default limit is 32 physical managed spawners per chunk.
• World restrictions — disable managed spawner placement in selected worlds.
• Silk Touch requirements — breaking requires a pickaxe and Silk Touch by default.
• Tool durability consumption — valid breaking can consume tool durability.
• Inventory delivery — broken spawners are returned directly to the player where possible.
• Inventory overflow fallback — leftover spawner items are dropped safely at the player.
• Natural spawner conversion — convert vanilla spawners into managed spawners through interaction or breaking.
• Explosion protection — managed spawners can be protected from explosion removal.
• Probabilistic loot tables — every loot entry supports an independent chance and minimum/maximum amount.
• Per-type production intervals — every spawner definition controls its own production timing.
• Catch-up processing — missed production cycles are processed within configurable safety limits.
• Asynchronous calculation — large loot calculations can be moved away from the server thread.
• Pending-output protection — blocked items are retained and retried.
• Break protection while blocked — players cannot break a spawner with pending output and accidentally destroy its loot.
• YAML persistence — each managed spawner is stored as an individual YAML record.
• Atomic file writes — temporary files and atomic moves reduce corruption risk.
• Corruption quarantine — malformed records can be isolated automatically.
• Chunk-backed hot cache — the plugin does not need to load every spawner into memory at startup.
• Generic YAML menu engine — bundled menus can be edited without recompiling the plugin.
• Dynamic menu commands — menu files can register their own commands at runtime.
• Private My Spawners browser — players can browse only the spawners owned by their UUID.
• Spawn-egg browser icons — browser entries use matching entity eggs with cross-version fallbacks.
• Permission-aware tab completion — players only receive suggestions for commands they can use.
• MiniMessage support — messages, menus, names, and lore support modern formatting.
• Multilingual architecture — language bundles, client locale detection, manual selection, and fallback handling are included.
• Runtime diagnostics — inspect active records, blocked output, pending items, definitions, menus, scheduler mode, and storage health.

Entity-Free Loot Production

Managed spawners do not create living entities.

Each configured production cycle calculates loot for every logical spawner in the stack. Loot entries are rolled independently using their configured chance, minimum amount, and maximum amount.

For example, a Zombie Spawner can produce Rotten Flesh every cycle while independently rolling smaller chances for Iron Ingots and Carrots.

• No mob AI — no pathfinding or target calculations.
• No entity collisions — no crowded grinder chambers.
• No activation-range dependence — production behavior is controlled by SMP Spawners.
• No mob-cap pressure — managed production does not consume the normal entity population.
• No kill chamber required — output is produced directly.
• No mandatory nearby player — nearby-player activation is configurable and disabled by default.
• No lost production cycles — bounded catch-up processing handles elapsed production time.

SMP Spawners is designed for direct loot economies. Managed spawners are not intended to reproduce vanilla mob behavior, combat, AI, or physical grinder mechanics.

Master Output Protocol

SMP Spawners uses a deterministic output protocol so generated items have a predictable destination.

1. Hopper directly below — items are inserted directly into the hopper inventory without creating an item entity.
2. Empty air below — output is dropped in the block below when no hopper is present.
3. Empty air above — used when the lower destination is unavailable.
4. Empty air north — configurable horizontal fallback.
5. Empty air east — configurable horizontal fallback.
6. Empty air south — configurable horizontal fallback.
7. Empty air west — configurable horizontal fallback.
8. Blocked state — output is retained and retried when every route is unavailable.

The horizontal order is configurable. The default order is North, East, South, and West.

Direct Hopper Insertion

When a hopper exists directly below a managed spawner, SMP Spawners attempts to insert generated items directly into its inventory.

• No temporary item entities — successfully inserted output never needs to exist in the world.
• Partial-stack filling — compatible existing hopper stacks are filled first.
• Empty-slot calculation — remaining items are distributed into available slots.
• Partial acceptance — inserted output is recorded separately from rejected output.
• Full-hopper handling — rejected items remain pending when spill-to-air is disabled.
• Configurable spill behavior — server owners can decide whether a full hopper may fall back to an air destination.
• Material validation — unresolved materials are retained and reported instead of silently discarded.

The default setting is:


This means a full hopper does not unexpectedly spray items around the spawner. Undelivered items remain pending until capacity becomes available.

Pending Output and Item-Loss Protection

When output cannot be delivered, SMP Spawners stores it as bounded pending debt.

• Pending item tracking — undelivered material amounts are stored with the spawner.
• Pending cycle tracking — delayed production cycles remain accounted for.
• Automatic retries — blocked spawners retry after the configured delay.
• Bounded item debt — global and per-pass limits prevent unlimited processing.
• Bounded cycle debt — catch-up work cannot monopolize a server tick.
• Blocked status — menus and diagnostics identify blocked spawners.
• Break denial — normal breaking is denied while pending output exists.
• Administrative force removal — authorized staff can deliberately remove a blocked spawner and discard pending output.
• Rate-limited logging — prolonged blocked output and failures can be logged without console spam.

Default pending limits:


Spawner Stacking

Matching managed spawners can be combined into a single physical block.

• Stand and right-click — add one logical spawner by default.
• Sneak and right-click — add up to 64 logical spawners by default.
• Matching types only — a Zombie Spawner cannot be stacked into a Skeleton Spawner.
• Item amount awareness — encoded spawner items can contain multiple logical spawners.
• Partial acceptance — only the amount that fits within the configured stack limit is consumed.
• Default maximum — 100,000 logical spawners per physical block.
• Hard safety maximum — 250,000 by default.
• Per-type override support — individual spawner definitions can set their own maximum.
• Permission bypass — administrators can bypass normal stack limits.
• Optional proximity merge — sneak placement can search for a nearby matching spawner and merge into it.

Breaking and Recovering Spawners

Spawner recovery behavior is fully controlled through configuration and permissions.

• Pickaxe requirement — enabled by default.
• Silk Touch requirement — enabled by default.
• Tool durability — successful breaking consumes durability by default.
• Stand to remove one — recover one logical spawner from the stack.
• Sneak to remove a batch — recover up to 64 by default.
• Direct inventory delivery — recovered spawners are placed into the player's inventory.
• Overflow fallback — items that do not fit are dropped safely.
• Pending-output denial — blocked spawners cannot be broken normally.
• Ownership enforcement — only the owner may break the spawner when enabled.
• Tool bypass permission — selected staff can bypass tool requirements.

75 Bundled Spawner Types

SMP Spawners includes 75 enabled spawner definition files.

Each definition can independently configure:

• Spawner ID and entity type.
• Aliases.
• Display material and legacy fallback.
• Display name and lore.
• Production interval.
• Minimum production interval.
• Maximum stack size.
• Loot materials.
• Legacy material fallbacks.
• Minimum and maximum loot amounts.
• Independent loot chances.

Bundled definitions:

Allay, Armadillo, Axolotl, Blaze, Bogged, Breeze, Camel, Cat, Chicken, Cod, Cow, Creeper, Dolphin, Donkey, Drowned, Elder Guardian, Ender Dragon, Enderman, Endermite, Evoker, Frog, Glow Squid, Goat, Guardian, Hoglin, Horse, Husk, Iron Golem, Llama, Magma Cube, Mooshroom, Mule, Ocelot, Panda, Parrot, Phantom, Pig, Piglin, Piglin Brute, Pillager, Polar Bear, Pufferfish, Rabbit, Ravager, Salmon, Sheep, Shulker, Silverfish, Skeleton, Skeleton Horse, Slime, Sniffer, Snow Golem, Spider, Squid, Stray, Strider, Tadpole, Trader Llama, Tropical Fish, Turtle, Vex, Villager, Vindicator, Wandering Trader, Warden, Witch, Wither, Wither Skeleton, Wolf, Zoglin, Zombie, Zombie Horse, Zombie Villager, and Zombified Piglin.

Configurable Loot Tables

Every spawner type has its own YAML file inside the spawners directory.

The bundled Zombie Spawner definition demonstrates independent loot entries:


This setup produces Rotten Flesh every logical roll while separately rolling a 2.5% chance for an Iron Ingot and a 2.5% chance for a Carrot.

Private My Spawners Browser

Players can open a paginated menu containing their managed spawners.

• Owner-private queries — results are always scoped to the player's UUID.
• No base-location leakage — players cannot browse another player's managed spawners.
• Entity spawn-egg icons — each entry uses the matching entity egg where supported.
• Cross-version icon fallback — modern eggs, legacy eggs, and generic fallback materials are supported.
• Spawner location — shows the world and coordinates of the player's own spawner.
• Spawner type — displays the localized entity type.
• Stack amount — shows the current logical stack.
• Runtime status — identifies active and blocked spawners.
• Pending output — shows retained item debt when present.
• Pagination — handles large player spawner collections.
• Filters — switch between all, blocked, and pending spawners.
• Refresh control — reload the current result set.
• Teleport action — players can teleport to spawners they own.
• Asynchronous queries — storage browsing does not block the main server thread.
• Stale-result protection — request sequencing prevents older asynchronous callbacks from replacing newer results.
• Session cleanup — browser state is removed when the menu closes or the player disconnects.

Included Menu System

SMP Spawners contains a generic YAML inventory-menu engine.

Bundled menus include:

• Root menu — access My Spawners, available types, command help, and close controls.
• Spawner information menu — view type, stack, owner, location, production timing, destination, pending output, loot, and XP.
• My Spawners browser — browse and filter owned spawners.
• XP menu — view and claim stored XP when the XP module is enabled.
• Upgrade menu foundation — configurable interface for upgrade actions.
• Loot preview menu foundation — configurable loot presentation.
• Diagnostics menu — display registry, active, blocked, orphaned, pending, and due-queue information.

Menu files support:

• Configurable rows or inventory size.
• MiniMessage and legacy-colored titles.
• Modern and legacy material fallbacks.
• Custom display names and lore.
• Single slots, slot lists, and slot ranges.
• Item priority.
• Click cooldowns.
• Permission requirements.
• Runtime placeholders.
• Left, right, shift, and general click actions.
• Player commands.
• Console commands.
• Menu navigation.
• Menu refresh.
• Close actions.
• Spawner-specific upgrade and XP actions.
• Dynamic command registration.

The bundled root menu also registers:


Dynamic menu commands enforce the permission configured in the corresponding menu file.

Spawner Information Menu

Interacting with a managed spawner can open its information menu.

• Spawner identity — type, stack amount, owner, and location.
• Production timer — time remaining until the next cycle.
• Current destination — hopper, air direction, or blocked.
• Pending items — exact retained item count.
• Pending cycles — number of delayed production cycles.
• Loot preview — configured output entries.
• Stored XP — visible when the XP module is enabled.
• Live refresh — menu content can update automatically.

Natural Spawner Conversion

Existing vanilla spawners can be converted into managed SMP Spawners.

• Convert on interaction — enabled by default.
• Convert on breaking — enabled by default.
• Entity type detection — the natural spawner's configured entity is mapped to a loaded definition.
• Managed ownership — converted spawners enter the same ownership and persistence system.
• Configurable vanilla-spawn cancellation — server owners control how unmanaged natural spawners behave.
• Unknown-definition protection — conversion is rejected when a matching definition is unavailable.

Ownership and Server Protection

Every managed spawner records its owner UUID.

Default ownership behavior:

• Owner-only breaking — enabled.
• Owner-only stacking — enabled.
• Owner-only menu access — disabled by default and configurable.
• Private browser access — browser queries always remain owner-scoped.
• Ownership bypass — available for administrators.

Additional controls include:

• Per-chunk physical spawner limits.
• Denied-world lists.
• Maximum and hard-maximum stack limits.
• Explosion protection.
• Tool and Silk Touch requirements.
• Pending-output break protection.
• Storage mutation reservations.
• Click cooldown bypass.
• Optional WorldGuard build and use checks.

YAML Persistence

No external database is required.

Managed spawners are persisted as individual YAML files organized by world and chunk.


Persistence features:

• One record per spawner — avoids one enormous monolithic data file.
• World and chunk organization — records can be loaded according to spatial demand.
• Chunk-backed hot cache — no startup load-all requirement.
• Dirty batching — modified records are queued and flushed in bounded batches.
• Revision-aware writes — stale state is not allowed to replace newer mutations.
• Atomic file moves — writes use temporary-file staging.
• Queue saturation protection — storage work has a configurable limit.
• Retry backoff — failed writes retry with configurable exponential delays.
• Corruption quarantine — malformed files can be moved out of active storage.
• Temporary-file cleanup — stale staging files can be removed automatically.
• Graceful shutdown flushing — pending data is given a configurable shutdown window.

Performance Architecture

SMP Spawners is designed to keep production work bounded.

• Global due index — spawners are dispatched according to their next production time.
• Due-index compaction — stale scheduling entries can be cleaned without rebuilding every record.
• Maximum spawners per dispatch — default 32.
• Maximum catch-up cycles per pass — default 64.
• Maximum logical rolls per pass — default 250,000.
• Asynchronous calculation threshold — large calculations can be moved to a worker executor.
• Immutable production tickets — asynchronous calculations operate on stable snapshots.
• Region batching — due spawners are grouped by world and chunk before region work is scheduled.
• Inactive-spawner retirement — unavailable or orphaned spawners are not repeatedly processed as normal.
• Output-failure throttling — recurring failures are logged at controlled intervals.
• No mandatory startup scan — storage is loaded according to chunk demand.

Folia Support

SMP Spawners declares Folia support and uses capability-based scheduler routing.

• Region scheduler — blocks, chunks, hoppers, production output, and world mutations.
• Entity scheduler — player inventories, player messages, menus, and player-owned actions.
• Global scheduler — server-wide dispatching and console-owned operations.
• Asynchronous executors — YAML storage and large production calculations.
• Runtime capability detection — automatically falls back to Bukkit or Paper scheduling when Folia is unavailable.
• Region ownership preservation — world operations are routed to the owning region instead of being executed from arbitrary threads.

Optional Economy Module

The economy module is included but disabled by default.

When enabled with Vault and a compatible economy provider, it supports:

• Reflective Vault integration — Vault is not a hard dependency.
• Configurable material prices — define sale values in prices.yml.
• Money formatting — values can be displayed in readable abbreviated formats.
• Sell wand integration — hopper contents can be sold using configured wand tiers.
• Transactional results — successful and failed economy operations are reported cleanly.
• No-economy fallback — core spawner production continues without Vault.

Optional Upgrade System

The upgrade module is included but disabled by default.

Four upgrade types are supported:

• Speed — reduces the production interval.
• Yield — increases generated output.
• Efficiency — reduces blocked-output retry delay.
• Capacity — increases the spawner's pending-output ceiling.

Every upgrade can define:

• Maximum level.
• Per-level costs.
• Per-level multipliers.
• Purchase validation.
• Economy withdrawal.
• Current and next-level menu placeholders.
• Per-spawner upgrade state.

The bundled upgrades.yml starts with zero levels so server owners can define an economy appropriate for their own server rather than receiving arbitrary production multipliers.

Optional XP Module

Spawner definitions can produce XP independently from item output.

• Stored XP balance — XP can accumulate on the managed spawner.
• Pending XP handling — XP production can remain pending under configured limits.
• Player claim menu — players can collect stored experience.
• Mending support — claimed XP can repair eligible equipment.
• XP balance limits — global safety ceilings prevent unbounded accumulation.
• Per-spawner control — definitions can enable, disable, or configure XP production.

The XP module is disabled by default.

Optional Hologram Module

Spawner status can be displayed above managed spawners.

Available providers:

• TextDisplay — uses modern Minecraft display entities where supported.
• DecentHolograms — integrates with DecentHolograms when installed.
• Automatic provider fallback — the plugin can use a no-operation provider when no compatible hologram system is available.
• Configurable lines — show type, stack, production state, output, or other placeholders.
• Update throttling — holograms respect a configurable minimum update interval.

The hologram module is disabled by default.

Optional Sell Wands

Sell wands can sell compatible items from the hopper directly below a managed spawner.

• Finite-use wands — configure a limited number of uses.
• Unlimited wands — create permanent tiers.
• Permission requirements — each wand can require its own permission.
• Cooldowns — control repeated use.
• Sale multipliers — create premium wand tiers.
• Hopper validation — only the connected hopper inventory is processed.
• Ownership validation — prevent unauthorized sales.
• WorldGuard validation — protection checks can be applied.
• Spawner reservation — conflicting mutations are prevented during a sale.
• Escrow behavior — sale processing protects against partial item or economy failures.
• Configurable item presentation — material, name, lore, model data, and uses can be customized.

The module and all wand tiers are disabled by default until configured in sellwands.yml.

Optional Isolation Bonus

The isolation module can reward separated spawners with additional output.

• Configurable radius — search for nearby managed spawners.
• Configurable multiplier — increase production when the spawner is isolated.
• Disabled by default — does not affect normal production unless explicitly enabled.

Optional Proximity Auto-Merge

When enabled, sneak-placement can search for a nearby matching managed spawner.

• Configurable search radius — default configuration uses eight blocks.
• Matching type requirement — only compatible spawners are merged.
• Normal stack limits — maximum limits remain enforced.
• Ownership checks — existing ownership rules still apply.
• Physical-block reduction — helps players consolidate nearby spawner layouts.

The feature is disabled by default.

Optional WorldGuard Protection

WorldGuard is supported as a soft dependency.

When protection integration is enabled, SMP Spawners can validate:

• Spawner placement.
• Spawner stacking.
• Spawner breaking.
• Spawner menu interaction.
• Sell wand usage.
• Administrative or player actions in protected regions.

Staff can use the configured bypass permission when necessary.

Multilingual Support

SMP Spawners uses language bundles stored inside the lang directory.

• Default language — configurable in config.yml.
• Client locale detection — automatically use the player's Minecraft language when a matching bundle exists.
• Manual language selection — players can choose an available language.
• Automatic mode — players can clear their manual preference and return to locale detection.
• Persistent player selection — language choices are stored locally.
• Fallback chain — player selection, client locale, configured default, then English.
• Localized menus — menu titles, names, lore, destinations, statuses, and entity names can use language keys.
• Console language handling — console messages resolve through the configured default bundle.

MiniMessage and Formatting

SMP Spawners uses Adventure and MiniMessage for modern text formatting.

• MiniMessage colors — named colors, hexadecimal colors, gradients, decorations, and styled text.
• Legacy ampersand colors — existing & formatting remains usable.
• Legacy section colors — § formatting is supported.
• Menu titles — inventory titles can be localized and formatted.
• Spawner names — customize display names for every type.
• Spawner lore — configure item and menu lore.
• Messages — customize every user-facing response.
• Branded command header — the bundled help output identifies SMP Spawners by ArkFlame Studios.

Commands

The main command aliases are /sps and /spawners.

• /smpspawners — display the command help.
• /smpspawners help — display command help.
• /smpspawners types — list every loaded spawner definition.
• /smpspawners info — inspect the managed spawner being targeted.
• /smpspawners menu — open the root SMP Spawners menu.
• /smpspawners browser — open the private My Spawners browser.
• /smpspawners language — display the current language.
• /smpspawners language <language> — select a language.
• /smpspawners language available — list available languages.
• /smpspawners language auto — return to automatic locale selection.
• /smpspawners give <player> <type> [amount] — give encoded managed spawner items.
• /smpspawners givewand <player> <tier> [amount] — give configured sell wands.
• /smpspawners setstack <amount> — set the stack amount of the targeted managed spawner.
• /smpspawners remove — administratively remove the targeted managed spawner.
• /smpspawners remove force — remove the spawner and deliberately discard pending output.
• /smpspawners inspect — display exact targeted spawner state.
• /smpspawners diagnose — display scheduler, storage, registry, output, definition, and menu diagnostics.
• /smpspawners reload — reload settings, messages, definitions, and menus.
• /spawnersmenu — open the bundled root menu through its dynamic command.

Permission-Aware Tab Completion

Tab completion is included for the complete command tree.

• Only subcommands the sender may use are suggested.
• Online player names are suggested for give commands.
• Loaded spawner definition IDs are suggested dynamically.
• Loaded sell wand tier IDs are suggested dynamically.
• Available language IDs are suggested dynamically.
• Common give amounts are suggested.
• Common stack amounts are suggested.
• The force-removal argument is only suggested to authorized administrators.
• Dynamic menu commands include their own tab completion and permission enforcement.

Permissions

• smpspawners.use — use the main SMP Spawners command.
• smpspawners.place — place managed spawners.
• smpspawners.stack — stack managed spawners.
• smpspawners.break — break managed spawners.
• smpspawners.menu — open SMP Spawners menus.
• smpspawners.info — view managed spawner information.
• smpspawners.types — list loaded spawner types.
• smpspawners.browser — browse owned managed spawners.
• smpspawners.language — select a language.
• smpspawners.sellwand.use — use configured sell wands.
• smpspawners.upgrade — purchase spawner upgrades.
• smpspawners.xp — claim stored spawner XP.
• smpspawners.admin — parent permission for administrative functions.
• smpspawners.admin.give — give managed spawner items.
• smpspawners.admin.givewand — give sell wand items.
• smpspawners.admin.setstack — modify a targeted spawner stack.
• smpspawners.admin.remove — administratively remove managed spawners.
• smpspawners.admin.force-remove — remove managed spawners while discarding pending output.
• smpspawners.admin.reload — reload plugin content.
• smpspawners.admin.diagnose — run runtime diagnostics.
• smpspawners.admin.inspect — inspect exact managed spawner state.
• smpspawners.admin.browser — compatibility permission for opening the owner-private browser.
• smpspawners.bypass.stack-limit — bypass normal stack limits.
• smpspawners.bypass.chunk-limit — bypass the physical per-chunk limit.
• smpspawners.bypass.ownership — bypass ownership restrictions.
• smpspawners.bypass.protection — bypass protection-provider checks.
• smpspawners.bypass.tool — bypass pickaxe and Silk Touch requirements.
• smpspawners.bypass.cooldown — bypass configured click cooldowns.

Configuration Control

Server owners can configure:

• Capability logging.
• Default language and locale detection.
• Player language selection.
• Production enabled state.
• Dispatcher interval.
• Maximum spawners processed per dispatch.
• Maximum catch-up cycles.
• Maximum logical loot rolls.
• Asynchronous production calculation.
• Asynchronous calculation threshold.
• Nearby-player activation.
• Nearby-player radius.
• Output retry timing.
• Pickup delay.
• Maximum pending items.
• Maximum pending cycles.
• Horizontal output order.
• Recognized air materials.
• Full-hopper spill behavior.
• Standing and sneaking stack amounts.
• Maximum and hard-maximum stack sizes.
• Standing and sneaking break amounts.
• Pickaxe requirements.
• Silk Touch requirements.
• Tool durability.
• Inventory delivery.
• Experience drops.
• Per-chunk limits.
• Denied worlds.
• Natural-spawner conversion.
• Ownership rules.
• Explosion protection.
• Storage queue limits.
• Storage flush intervals.
• Storage batch sizes.
• Retry backoff.
• Shutdown timeout.
• Corruption quarantine.
• Temporary-file cleanup.
• Proximity merging.
• Menus and interaction behavior.
• Dynamic menu commands.
• Click cooldowns.
• Help-command menu interception.
• Diagnostics logging.
• Economy integration.
• Upgrade levels and multipliers.
• XP production.
• Hologram providers.
• Isolation bonuses.
• Sell wand tiers.
• WorldGuard protection.
• Every spawner's loot and interval.
• Every message, menu, display name, and lore line.

Default Core Configuration

The following is the bundled core config.yml. Optional modules are present but disabled by default so they do not change server behavior until deliberately configured.


Safe Configuration Reloading

• Asynchronous preparation — reloadable content is prepared away from world operations.
• Previous-state preservation — a failed reload keeps the previous valid runtime content active.
• Truthful reload result — success is only reported after the new content is accepted.
• Definition reload — spawner files can be updated without a full server restart.
• Message reload — language and message changes can be applied.
• Menu reload — menu definitions and dynamic commands are refreshed.
• Safe default migration — outdated YAML defaults can be migrated with a timestamped backup.

Changes to fundamental storage behavior should still be planned carefully and backed up before deployment.

Soft Dependencies

SMP Spawners does not require another plugin for its mandatory production, stacking, menu, or persistence systems.

Optional integrations:

• Vault — economy bridge and sell wand payments.
• WorldGuard — placement, break, stack, menu, and use protection.
• DecentHolograms — hologram presentation provider.
• PlaceholderAPI — external placeholders inside configured menus.

The plugin continues running when these dependencies are absent.

Compatibility

• Bukkit — supported.
• Spigot — supported.
• Paper — supported.
• Purpur and compatible forks — supported through the Bukkit/Paper compatibility layer.
• Folia — declared and region-scheduler compatible.
• Minecraft 1.8–1.21+ — cross-version materials, entities, blocks, inventory items, and scheduler behavior are handled through compatibility bridges.
• Java 8 bytecode — shared plugin classes do not require a modern Java language level.
• Modern material fallback — new materials can use legacy alternatives.
• Spawn-egg fallback — browser icons resolve across modern, legacy, and generic item systems.
• No mandatory database — YAML storage is included.
• No mandatory menu plugin — the complete menu engine is included.

Diagnostics and Administration

The diagnostics command reports:

• Plugin readiness.
• Detected scheduler mode.
• Persistence backend.
• Dirty persistence record count.
• Managed registry size.
• Active spawner count.
• Blocked spawner count.
• Total pending item count.
• Loaded definition count.
• Loaded menu count.

The included diagnostic architecture also tracks:

• Production attempts.
• Completed production cycles.
• Blocked output events.
• Production failures.
• Orphaned spawners.
• Due-queue state.
• Stale scheduling entries.
• Storage queue saturation.
• Repeated output failures.

Orphaned Spawner Protection

A managed spawner can outlive the definition file that originally created it.

SMP Spawners preserves this state instead of silently converting or deleting the record.

• Orphaned status — the spawner is marked as unavailable.
• Production disabled — unknown definitions do not continue producing invalid output.
• Item preservation — encoded items retain their definition ID and logical amount.
• Restoration path — restoring the matching definition allows the spawner type to become valid again.
• Diagnostic visibility — administrators can identify orphaned records.

Why Server Owners Choose SMP Spawners

• Better performance — replace large mob farms with bounded loot calculations.
• Cleaner farms — players only need a spawner and an output destination.
• Massive progression — support stacks up to 100,000 by default.
• Predictable output — hopper-first delivery and deterministic air fallbacks.
• Reduced item loss — blocked output is retained and retried.
• Private player management — players can browse only their own spawners.
• Cross-version deployment — one plugin architecture covers legacy and modern Bukkit-family servers.
• Folia-safe operations — world and player actions use appropriate scheduler ownership.
• No database setup — YAML storage works immediately.
• No mandatory dependencies — core production works independently.
• Full economy control — every interval, chance, amount, price, multiplier, and stack limit is configurable.
• Expandable modules — enable upgrades, XP, holograms, sell wands, isolation bonuses, and protection when needed.
• Operational visibility — inspect blocked output, pending items, registry state, and storage health.

Best Uses

• Survival SMP — add long-term spawner progression without entity-heavy grinders.
• Lifesteal SMP — create valuable raidable economy infrastructure.
• Box SMP — support large production stacks and direct item economies.
• Economy servers — control material generation through exact loot tables and intervals.
• Competitive SMP — make spawners valuable without allowing uncontrolled mob farms.
• Skyblock-inspired SMP — provide stackable production systems without requiring a full Skyblock core.
• Seasonal servers — rebalance loot files between seasons.
• High-player-count servers — reduce entity pressure in heavily developed chunks.
• Folia servers — use region-compatible production and inventory scheduling.
• Legacy networks — deploy on older Bukkit and Spigot versions with compatibility fallbacks.

FAQ

Does SMP Spawners create real mobs?
No. Managed spawners produce their configured loot directly. This is the primary performance model of the plugin.

Can I configure the generated loot?
Yes. Every spawner type has its own YAML definition with independent materials, chances, minimum amounts, maximum amounts, and production intervals.

How many spawner types are included?
The bundled configuration includes 75 enabled spawner definitions.

Can players stack spawners?
Yes. Matching types can be stacked into one physical block. Standing adds one by default, while sneaking adds up to 64.

What is the default maximum stack?
The global default maximum is 100,000, with a hard maximum of 250,000. Individual definitions may override the normal maximum.

Does it insert items into hoppers?
Yes. A hopper directly below the spawner is always the first output destination.

Does hopper output create item entities?
No. Successfully accepted output is inserted directly into the hopper inventory.

What happens when the hopper is full?
With the default configuration, rejected output remains pending and is retried. It does not spill into nearby air.

What happens if every output location is blocked?
The generated output is retained as pending debt. The spawner enters a blocked state and retries later.

Can a player break a blocked spawner?
Not through normal breaking while pending output exists. This prevents generated items from being silently destroyed.

Can staff remove a blocked spawner?
Yes. Authorized staff can use /smpspawners remove force, which deliberately discards the pending output.

Does it support Silk Touch?
Yes. A pickaxe and Silk Touch are required by default.

Can I change the stacking and breaking amounts?
Yes. Standing and sneaking amounts are independently configurable.

Can it convert vanilla spawners?
Yes. Conversion on interaction and conversion on breaking are enabled by default.

Can players browse their spawners?
Yes. The My Spawners menu provides a paginated, filtered view of the player's owned spawners.

Can players see other players' bases through the browser?
No. Browser queries and teleport validation are scoped to the requesting player's UUID.

Does the browser use entity eggs?
Yes. It attempts to use the matching entity spawn egg and falls back safely on versions where that item is unavailable.

Does it support custom menus?
Yes. Menus are loaded from YAML and support materials, lore, placeholders, click actions, requirements, cooldowns, and dynamic commands.

Does it support PlaceholderAPI?
Yes. PlaceholderAPI can be used as an optional hook for menu placeholders.

Does it support multiple languages?
Yes. It supports language bundles, client locale detection, manual player selection, persistent preferences, and fallback handling.

Does it support MiniMessage?
Yes. MiniMessage, legacy ampersand colors, and legacy section colors are supported.

Does it require Vault?
No. Vault is only required when the optional economy features are enabled.

Does it support sell wands?
Yes. The module supports finite or unlimited uses, permissions, cooldowns, multipliers, hopper sales, and economy escrow. It is disabled and unconfigured by default.

Does it include upgrades?
Yes. Speed, Yield, Efficiency, and Capacity upgrade types are included. The module is disabled by default and requires server-defined levels and prices.

Can spawners store XP?
Yes. The optional XP module supports stored XP, claims, limits, and Mending repair.

Does it support holograms?
Yes. TextDisplay and DecentHolograms providers are included as optional integrations.

Does it support WorldGuard?
Yes. WorldGuard can protect placement, stacking, breaking, menu access, and sell wand use.

Does it require a database?
No. Managed spawners are stored as YAML files organized by world and chunk.

How does it protect stored data?
It uses queued dirty writes, revision checks, temporary-file staging, atomic moves, retry backoff, shutdown flushing, and optional corruption quarantine.

Does it load every spawner at startup?
No. It uses chunk-backed loading and a hot registry rather than requiring a complete startup load.

Does it support Folia?
Yes. SMP Spawners declares Folia support and routes region, player, global, and asynchronous work through the appropriate scheduler.

Which Minecraft versions are supported?
The project is designed for Bukkit 1.8 through modern Paper and Folia 1.21+ servers.

Are third-party plugins mandatory?
No. Vault, WorldGuard, DecentHolograms, and PlaceholderAPI are optional soft dependencies.


SEO keywords: SMP Spawners, Minecraft spawner plugin, stacked spawners plugin, stackable spawners, virtual spawner plugin, entity free spawners, loot spawner plugin, direct loot spawners, hopper spawner plugin, direct hopper output, Bukkit spawner plugin, Spigot spawner plugin, Paper spawner plugin, Purpur spawner plugin, Folia spawner plugin, Minecraft 1.8 spawner plugin, Minecraft 1.21 spawner plugin, survival SMP spawners, Lifesteal spawner plugin, Box SMP spawner plugin, economy spawner plugin, high performance spawners, lag free spawners, configurable loot tables, massive spawner stacks, YAML spawner plugin, Silk Touch spawners, natural spawner conversion, private spawner browser, My Spawners menu, spawn egg menu icons, MiniMessage spawner plugin, multilingual Minecraft plugin, Vault spawner economy, sell wand plugin, spawner upgrades, spawner XP, spawner holograms, WorldGuard spawners, ArkFlame Studios.