> For the complete documentation index, see [llms.txt](https://docs.onelitefeather.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onelitefeather.net/antiredstoneclock-remastered/background/static-and-dynamic-tracking.md). # Static and dynamic tracking `check.mode` accepts `static` and `dynamic`. Both count triggers the same way; they differ in how they remember *which* block they are counting. ## Static: remember the position Static tracking keys its counters by block position. A block at those coordinates triggers, the counter at those coordinates goes up. This is simple, costs nothing beyond a map in memory, and is forgotten when the server stops. Its blind spot is a clock that moves. A flying-machine style construction, or any build where the triggering component is pushed along, presents a new position on every cycle, and every position starts its own counter from zero. Such a build never reaches the limit anywhere. ## Dynamic: remember the block Dynamic tracking gives the observed block an identifier and stores it *in the block itself*, using the world's block data. The counter follows the block when its position changes, so a moving construction accumulates triggers across the whole path it travels. The price is that the identifier is written into the world. It survives a restart, and it stays on the block until the block is broken. ## What this means in practice Static is the cheaper and more predictable of the two, and it is what the plugin falls back to whenever `check.mode` cannot be read — including when the value is misspelled. If the plugin seems to be running in a different mode than you configured, check the spelling: an unknown value does not raise an error, it silently selects static. The mode the plugin actually started in is printed to the console on every startup. ## What this is not The mode is not a strictness setting. Neither mode detects more clocks than the other on a stationary build, and switching modes is not a way to make detection more or less eager — for that, see [Tune how quickly a clock is detected](/antiredstoneclock-remastered/how-to-guides/tune-how-quickly-a-clock-is-detected.md). Related: [How detection works](/antiredstoneclock-remastered/background/how-detection-works.md) · [Configuration reference](/antiredstoneclock-remastered/reference/configuration.md) --- # 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://docs.onelitefeather.net/antiredstoneclock-remastered/background/static-and-dynamic-tracking.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.