> For the complete documentation index, see [llms.txt](https://matt-creppet.gitbook.io/matt-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://matt-creppet.gitbook.io/matt-docs/regeneration.md). # Regeneration modes ## Overview | Mode | Trigger | Scope | | ------------ | ---------------------------------------------------------------------- | ------------------------------------------------- | | `interval` | Every `interval-seconds` after the previous completed full restoration | Scans the full region; writes only differences | | `changes` | At the configured interval, when tracked changes exist | Checks only tracked positions | | `block` | Each position's individual deadline | Checks eligible tracked positions | | `inactivity` | No tracked event for `inactivity-seconds` | Restores tracked positions after the quiet period | Change a mode with `/rz set mode `. The original mode remains available. Existing arenas without a `mode` key use `interval`. ## Interval ``` /rz set practice mode interval /rz set practice interval-seconds 300 ``` This mode checks the entire saved volume every cycle. It is useful when changes may come from plugins that write directly to the world without emitting events. Unchanged blocks are not rewritten, but the scan still costs work proportional to arena size. ## Change-only interval ``` /rz set practice mode changes /rz set practice interval-seconds 60 ``` When no positions are pending, Regen Zone does not enqueue a restoration, load chunks for that cycle or announce a reset. Once there are tracked changes, the next eligible interval restores those positions in bounded batches. A direct block change also marks immediate neighboring positions as candidates. This catches common attached blocks and multi-block structures. Neighbors that still match the original are not rewritten. This small local check is not a full-region scan. ## Individual block timers ``` /rz set practice mode block /rz set practice block-delay-seconds 10 /rz set practice break-delay-seconds 5 /rz set practice place-delay-seconds 30 /rz material practice WHITE_WOOL 3 ``` Delay precedence: 1. A matching material entry in `material-delays`. 2. `place-delay-seconds` for placements, or `break-delay-seconds` for other tracked causes. 3. `block-delay-seconds` when the category value is `-1`. The material is the one observed by the event, such as the placed material during a placement or the original broken material during a direct break. Natural events may expose a pre-change state. Each position has one current deadline. Changing that same position again restarts its deadline. Changing a different position does not restart existing neighbors' deadlines. Changing a configured delay affects future events; it does not rewrite existing pending deadlines. Per-block jobs are silent and do not lock the whole arena. A block that would overlap a player is postponed for at least one second. With `protect-player-floor: true`, removal of a block supporting a player's feet is also postponed. These checks favor caution; they do not simulate every collision shape or guarantee that every possible movement is risk-free. Set `block-wait-until-empty: true` if individual restoration should wait for the whole arena to be empty. This setting is independent of `wait-until-empty`. ## Inactivity ``` /rz set practice mode inactivity /rz set practice inactivity-seconds 20 ``` The quiet period starts again whenever an accepted tracked event occurs. After twenty seconds without such an event, pending positions can be restored. Waiting-for-empty rules still apply. This measures tracked changes, not player presence or movement. If players keep modifying the area, restoration keeps waiting. There is no countdown announcement specific to inactivity mode. `warning-seconds` is used by interval-based modes. ## Which changes are tracked? Direct player block breaks are always observed when a saved arena exists. `track-placements` and `track-explosions` default to `true`. `track-natural-changes` defaults to `false` and covers the plugin's registered growth, flow, fire, leaf, entity and piston events. Cancelled events are ignored. Changes made directly by another plugin may not emit these events. Internal game mechanics may have additional effects outside the immediate neighbor checks. Use a manual `/rz regen ` when a full reconciliation is needed. ## Filters, deferred work and manual commands Material filters and protected tile positions are applied before writes. A filtered position is considered processed; changing a filter later does not resurrect every previously skipped position. Use a full manual restoration to reconsider the entire region. `/rz regen` and `/rz reintentar` request full-region restoration regardless of the automatic mode. A custom integration can veto an actual write; that position is retained as pending. Selective modes can retry it later. In interval mode it is also revisited by the next full cycle. `enabled: false` stops automatic scheduling. It does not cancel a job already queued. Pause first, then use `/rz cancelar` if needed. Cancellation leaves already completed writes in place and keeps unprocessed tracked positions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://matt-creppet.gitbook.io/matt-docs/regeneration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.