# Mining & Re-Deploying ## Mining and re-deploying The mine + re-place mechanic is the feature that makes this plugin fundamentally different from "vanilla trial spawners but config". Players who buy or earn a spawner aren't getting a one-time spawn at a fixed location — they're getting a portable, **stateful** asset they can move with them as they explore the world. This page covers how the mechanic works, what state is preserved, and how to configure it. ### What "state-preserving" actually means When a player mines a wild spawner, the dropped item carries the spawner's complete runtime state in its PDC tags: * **Preset id** — which preset the spawner belongs to. * **Owner UUID + name** — the original placer (informational only; re-place gives the new placer fresh ownership). * **Ominous flag** — whether this is the ominous variant. * **Tracked players** — every player currently in the spawner's "you've already cleared this wave" list. Vanilla normally clears this on cooldown end; we preserve it across the item↔block round-trip. * **Cooldown remaining** — if the spawner was on cooldown when mined, how many ticks were left. When the item is re-placed, all of the above is restored. Vanilla's cooldownEnd field can't be set on a freshly placed block via Bukkit, so the plugin writes a `tcpws:forced_cooldown_until` tag on the new block; the `ForcedCooldownListener` cancels `CreatureSpawnEvent` calls until the epoch passes. Functionally identical to a "real" cooldown. Practical upshot: a player can mine their spawner mid-cycle, walk to a different region, re-place it, and the spawner picks up exactly where it left off. ### How mining works mechanically Vanilla doesn't expose a "block hardness" for trial spawners — they literally cannot be mined. The plugin works around this with a manual mining simulation: 1. `BlockDamageEvent` cancels the vanilla mining attempt. 2. The plugin counts ticks (20/sec) while the player keeps holding left-click on the block. 3. `player.sendBlockDamage()` drives the crack animation visible to the player. 4. After `mining.hardness-seconds × 20` ticks of continuous damage, the plugin: * Serialises the current TileState into PDC tags on a new ItemStack. * Drops the item at the block's location. * Removes the hologram. * Sets the block to AIR. If the player stops mining before the timer elapses, the counter resets. They have to start over from zero. ### Preview vs real mining The `/tcpws preview` command places a 30-second trial spawner at the crosshair. **Preview spawners can't be mined** — the plugin tracks preview blocks separately and refuses to fire the mining flow on them. The block disappears cleanly when the timer expires. ### Permission gates | Gate | Effect | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | `tcpws.mine: false` (negated) | Player can't initiate mining at all — `BlockDamageEvent` fires but the plugin no-ops. | | `mining.owner-only: true` (config) | Only the player whose UUID matches the spawner's `tcpws:owner_uuid` PDC tag can mine. Others see "this is X's spawner — you can't mine it." | | `griefing-protection: true` (per-preset) | Same effect as `mining.owner-only` but applied per-preset rather than globally. | | `tcpws.mine.bypass-owner` | Overrides both `owner-only` and `griefing-protection` — useful for staff cleanup. | Default config (`mining.enabled: true`, `owner-only: false`, permission `tcpws.mine: true`) lets anyone mine any wild spawner they encounter. Lock things down per your server's needs. ### Cooldown preservation across mining Suppose a spawner has 5 minutes of cooldown left. Player A mines it at minute 2 of the cooldown — the dropped item has 3 minutes of "forced cooldown" stamped on it. Player A picks up the item, walks across the map, and re-places it. The new block has `tcpws:forced_cooldown_until = (now + 3 minutes)`. For the next 3 real-time minutes, any `CreatureSpawnEvent` triggered by this block (vanilla TRIAL\_SPAWNER reason) gets cancelled. After the epoch passes, the tag is lazily removed and the spawner activates normally. **Net effect:** the cooldown moved with the spawner. The player can't reset it by mining and re-placing — the wave-completion state is preserved. ### What about ominous-bottle activation? The ominous flag is a BlockData property of the trial spawner block. Mining serialises it into the item PDC; re-place restores it from the PDC. So an ominous spawner stays ominous through the mine-and-re-place cycle. If a player drinks an ominous bottle near a non-ominous spawner, the spawner becomes ominous (vanilla behaviour). That ominous state is now part of the spawner's BlockData and rides along on the next mine. ### What about mid-wave mining? If a player mines a spawner **while a wave is in progress**, the behaviour matches vanilla: the block disappears, all tracked entities become orphaned (no spawner to return to), the wave can never complete, and any mobs in the world remain until killed normally. The dropped item still preserves the original cooldown / tracked- players state — but the orphaned mobs are gone from `trackedEntities` the moment the spawner block is removed. So re-placing the item gives you a spawner whose tracked-players list might reference players who've since left the area. In practice this is fine: vanilla's wave logic re-evaluates tracked players on each scan, and the plugin's tether goal doesn't care about wave state. Just don't mine spawners mid-fight if you want a clean experience. ### Worked example A donor on your server gets a `legendary_dragon_lair` spawner via the donor crate (which used VaultCrates' `wild-spawner` loot type to trigger `/tcpws give`). 1. They place it in their base. Hologram appears. 2. Other players show up. The activation range engages, mobs spawn, players fight. 3. They clear the first wave. Cooldown starts: 30 minutes. 4. At minute 12 of the cooldown, they decide they want to move the base. They mine the spawner. 5. The dropped item carries: * `tcpws:preset_id = legendary_dragon_lair` * `tcpws:spawner_ominous = 0` * `tcpws:cooldown_remaining_ticks = 21600` (18 minutes worth) 6. They walk to the new base and re-place the spawner. 7. The new block stamps `tcpws:forced_cooldown_until = now + 18 minutes`. For 18 real-time minutes, `CreatureSpawnEvent` is cancelled for this block. 8. After the 18 minutes, the spawner activates normally on the first nearby player. The spawner's "first wave" was already cleared at the old location. Re-placing it doesn't reset that progress — vanilla's "first-time-encountering-this-vault" rewards have already paid out and they don't pay out again. ### Configuration See `config.yml` reference → Mining section for every mining-related toggle. The most-tweaked setting: `mining.hardness-seconds`. Default 10.0; servers with a "spawners are valuable, not consumables" philosophy sometimes raise it to 15 or 30, making mining a deliberate commitment. *** Next: **messages.yml →** · **VaultCrates integration →** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://darkstarworks.gitbook.io/plugins/mc/tcp-documentation/tcp-wildspawners/your-first-spawner/mining-and-re-deploying.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.