Kyokalith

Every anti-X-Ray plugin picks a poison. Packet obfuscation burns CPU and loses to freecam. Wiping ores and regenerating them means chunk scanning, and chunk scanning eats your TPS. Kyokalith picks neither:

Fully buried vanilla ores are decoys. They generate exactly where vanilla puts them. X-Ray, freecam, and seed-map sites can all find them, but those positions are no longer guaranteed to contain real ore.

The final block is resolved only when that position is exposed for the first time. A deterministic function keyed by a private per-server salt generates a separate hidden ore field: a vanilla ore may resolve into its base block, while a position that was originally plain stone may resolve into ore.

Resolution happens before the newly exposed block is sent to any client, so honest players never see an ore suddenly turn into stone.

A cheater tunnels directly toward an ore visible through the wall and may find stone. An honest player exploring a cave always sees stable blocks, because anything already exposed during world generation is never modified.

What this gets you

• Defeats X-Ray texture packs, X-Ray mods, freecam, and seed-map tools for every fully buried ore
• Zero packet interception: no per-player obfuscation cost and no ProtocolLib
• Zero chunk scanning: per-event cost is constant, removed blocks × 6 neighbor checks, one tick later
• World generation untouched; block writes happen only at the moment of first exposure
• Cover-up exploits handled: player-placed blocks are tracked as dirty and never re-resolved, and pistons cannot be used to peek
• Deterministic ore veins rather than an independent random roll for every block
• Region-aware Folia support: the same JAR runs on Spigot/Paper 26.2 and Folia 26.1.2
• Data-driven config: 11 vanilla ore types bundled (Overworld + Nether), with support for custom entries
• Customizable messages with bundled English and Traditional Chinese locales
• Integration API: OreCheckTriggerEvent fires when a tracked ore is mined. Build custom mining rewards on top, while remaining silently inactive if nothing listens

Performance, measured An earlier prototype used the classic wipe-and-regenerate approach: 121 force-loaded chunks dragged TPS down to 18.9. The current model deleted the entire scanning pipeline and instead performs a constant amount of work for each block-change event. On Folia, world access is dispatched through the scheduler that owns the affected region. It has been running in production on a survival server for weeks.

Requirements Spigot/Paper 26.2 or Folia 26.1.2 · Java 25 · no plugin dependencies The same JAR detects the platform at runtime and uses either the Bukkit scheduler or Folia's regionized schedulers. The Kotlin standard library and SQLite driver are fetched through the Bukkit library loader at startup. Compiled against the Spigot API, with Folia-specific code isolated in a separate adapter. Production-tested on Paper and runtime-tested on Spigot and Folia. Folia currently targets Minecraft 26.1.2, so its supported Minecraft version differs from the Spigot/Paper build.

Commands & permissions Everything lives under /kyokalith (alias /kyo) and is gated by kyokalith.admin (default: op): stats, inspect, preview, sample, resolve, suspend/resume, and QA token tools. kyokalith.bypass skips only the reward-check path. Decoy resolution always runs. The full command reference is available in the GitHub README.

⚠ One warning The first startup generates a random salt inside plugins/Kyokalith/kyokalith.db. Never delete or reset it. The salt is what separates the real ore field from your world seed. Resetting it re-rolls every position that has not yet been exposed.

Docs & source GitHub: source, English/繁體中文 documentation and issues: https://github.com/TinyYana/Kyokalith Config reference: https://github.com/TinyYana/Kyokalith/blob/main/docs/CONFIG.md Developer API: https://github.com/TinyYana/Kyokalith/blob/main/docs/API.md

FAQ

Q: Does it edit or scan my world ahead of time? No. World generation is untouched, no chunks are scanned, and no world files are preprocessed. A buried position is resolved only when it is exposed for the first time. Any required block change happens before the resulting block state is sent to a client.

Q: Can an honest player see a decoy ore turn into stone? No. When mining exposes a new block face, Kyokalith resolves that position before the client receives it. If a buried vanilla ore resolves into stone, the player sees stone from the first frame. Only someone who already knew the original hidden ore position can tell that it was a decoy.

Q: Can an honest strip miner encounter decoy positions? Yes, but they do not see them as ores first. A buried vanilla ore may resolve into its base block. In the other direction, a position that was originally plain stone may resolve as part of Kyokalith's hidden ore field. Kyokalith does not simply delete ores from honest players. It replaces predictable vanilla ore positions with a separate hidden distribution.

Q: Does every ore block roll independently? Will every vein contain only one ore? No. Kyokalith derives deterministic ore veins from 16×16×16 cells, with configurable vein size, density, height preferences, and per-cell chances. A miner may occasionally expose only one block at the edge of a vein, just as with normal generation, but the system is not an independent per-block lottery.