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.

Q: Can an X-Ray tool that only highlights exposed ores bypass it? Partially. Anything already visible during world generation is intentionally left untouched because an honest player could already have seen it. Kyokalith therefore does not claim to eliminate exposed-only ore highlighting. Its main purpose is to make information about ores hidden behind solid blocks unreliable.

Q: Do TNT mining, pistons and tunnel-boring machines still work? Yes. Player mining, explosions, and piston activity can all expose new block faces. Those positions are resolved before their resulting states are shown to players. Kyokalith makes hidden ore information unreliable; it does not disable legitimate mining methods.

Q: Does it reproduce biome-specific vanilla ore generation? Not currently. Ore height, density, vein size, and related properties are configurable, but biome-specific distributions such as the additional gold found in Badlands are not currently reproduced. This is an implementation and gameplay trade-off.

Q: What happens if I uninstall it? Your world remains a normal vanilla world. Unresolved decoys are simply the vanilla ores that originally generated there. Blocks that were already resolved stay in their current states. Nothing becomes corrupted and no conversion process is required.

Q: Can I combine it with Paper's built-in anti-xray engine modes? Yes.

Kyokalith does not modify packets, so the two systems operate at different layers. Paper's anti-xray controls what block information is sent to clients. Kyokalith makes buried block information unreliable even if a client manages to obtain it.

Q: Doesn't publishing the source let cheaters calculate the real ores? No. The hidden ore field is derived using a deterministic hash keyed by a random per-server salt. That salt is generated on first startup and stored only in the server's database. Knowing the algorithm without knowing the salt does not reveal the ore positions.

Q: What is the TPS impact? For each block-change event, Kyokalith performs at most: removed blocks × 6 neighbor checks, followed by an in-memory deterministic calculation. The work is constant-time. On Spigot/Paper it runs through Bukkit's main scheduler; on Folia it runs through the scheduler that owns the affected region. Exposure resolution is deferred by one tick. There are no scheduled scanning tasks, no chunk-load scans, and no database access on the block-event path.

Q: Does it support Folia? Yes. Kyokalith 1.2.0 added region-aware Folia scheduling. The same JAR supports Spigot/Paper 26.2 and Folia 26.1.2 without requiring a separate Folia build. Block resolution and related world access are dispatched through the scheduler that owns the affected region. One administrative limitation remains: Folia RCON commands that need to cross region boundaries may complete without returning their delayed response text to the RCON client. This affects command feedback, not normal ore resolution or player gameplay. For player-targeted QA commands such as giveeligible, keep the target player online until the scheduled operation completes.

License: TinyYana Universal Software License 1.0 Free to use, modify, integrate, and redistribute, including on commercial servers. You may NOT sell the plugin itself or repackage it as a paid product or service without written permission.