Compatibility#
VonixGuardian audits through the vanilla event bus that every mod already uses. It does not patch other mods, and it does not need per-mod integration.
Server software#
VonixGuardian runs on the vanilla Minecraft server jar with one of these mod loaders installed:
| Loader | Works |
|---|---|
| Fabric | ✅ 1.18.2, 1.19.2, 1.20.1, 1.21.1, 26.1.2, 26.2, 26.3 |
| Forge | ✅ 1.18.2, 1.19.2, 1.20.1 |
| NeoForge | ✅ 1.21.1, 26.1.2, 26.2, 26.3 |
It does not run on Bukkit, Spigot, Paper, Purpur, Pufferfish, or any other Paper fork. Those are a different plugin API; use CoreProtect there.
Hybrid servers (Mohist, Magma, Arclight) are unsupported and untested. They may work. If they do not, that is not a bug in VonixGuardian.
Clients do not need the mod. A vanilla client can join a server running it.
Why most mods work automatically#
A block placed by a Create deployer still goes through
Level.setBlock / Level.destroyBlock. An entity killed by a Pixelmon battle is
still LivingEntity#die. Because VonixGuardian hooks those vanilla paths rather
than individual mod callbacks, any mod that drives the world through them is
audited without special support.
Where the responsible player is not obvious — a contraption, a colony citizen, a mounted dragon — the attribution chain traces back through the mod's own ownership model to the player who started it.
Mod-specific notes#
| Mod | Status | Behaviour |
|---|---|---|
| Create | ✅ | Contraption assembly and disassembly are captured. Drills, deployers, and saws are attributed to the player who started the contraption. |
| WorldEdit / FAWE | ✅ | //set, //replace, //cut, //paste produce per-block rows owned by the command's executor. A //set over 100 blocks is 100 rows. |
| FTB Chunks | ✅ | Claim data is unaffected. Claimed-area protection is enforced by FTB; VonixGuardian only records what happened. |
| FTB Teams | ✅ | No interaction. Team membership does not change attribution. |
| LuckPerms | ✅ | Auto-detected by reflection; soft dependency. See Permissions. |
| Pixelmon | ✅ | Pokémon as entities use standard LivingEntity spawn/death paths, so catches, kills, and releases are logged. Apricorn trees and shrine blocks are vanilla events. |
| Dragon Mounts | ✅ | Tamed and ridden dragons are LivingEntity at the event layer. Deaths and removals are captured, with the owning player attributed where the event provides it. |
| Ice and Fire | ✅ with opt-in | Dragons break blocks through LivingDestroyBlockEvent. Add them to the allowlist — see below. |
| Isle of Berk / HTTYD packs | ✅ with opt-in | The pack that motivated the coalescer. Allowlist the dragon namespaces. |
| MineColonies | ✅ | Citizen block placement flows through vanilla events; the colony owner is attributed. Hut block placement is a direct player action. |
| Twilight Forest | ✅ | Portal creation, boss-room changes, and structure interaction ride the vanilla bus. |
| Prometheus exporters | ✅ | No interaction; both can run on the same server. |
| WorldBorder | ✅ | No interaction. |
Modded mob griefing needs an explicit opt-in
On Forge and NeoForge, LivingDestroyBlockEvent is a prospective permission
query — it fires per mob tick for every block a mob's hitbox passes over, even
when nothing is destroyed. A single flying dragon can fire it hundreds of
thousands of times per second.
So recording is fail-closed: vanilla mobs known to genuinely change blocks are recorded, and everything else must be allowlisted.
/vg entitylog add iceandfire:*
/vg entitylog add isleofberk:*
/vg entitylog add minecraft:wither
Do not use entityChangeLogAllEntities: true to shortcut this. It records
everything and re-opens the flood the coalescer exists to absorb.
Running alongside CoreProtect#
You cannot, in practice. CoreProtect requires Bukkit/Spigot/Paper and VonixGuardian requires a modded loader. The server families are mutually exclusive. Stacking both would double storage and queue overhead without adding a feature.
WorldEdit specifics#
r:#we and r:#worldedit resolve your live selection at query time, so you can
scope a lookup or rollback to exactly what you selected with //wand:
/vg rollback t:15m r:#worldedit
Requirements:
- WorldEdit installed on the server.
- A player source (console has no selection).
- An active selection.
Each failure mode has its own message:
| Condition | Message |
|---|---|
| WorldEdit absent | WorldEdit is not installed — r:#we / r:#worldedit requires WorldEdit on the server |
| No selection | you have no active WorldEdit selection — make a selection with //wand first |
| Console source | the standard player-position requirement |
Large WorldEdit operations generate a row per affected block. A //set over a
1,000-block region is 1,000 rows in one burst. Size queue.maxSize and your
retention horizon accordingly — an aggressive terraforming session can produce more
rows in a minute than a day of normal play.
Performance expectations#
VonixGuardian keeps the server thread free. Each event builds a payload on the server thread with no I/O, then hands it to a bounded queue. All JDBC work happens on a writer thread.
| Server profile | Approx. monthly database growth |
|---|---|
| Small / casual, 5–15 concurrent | 20–100 MB |
| Busy public, 30–80 concurrent | 100–500 MB |
| Heavy automation packs (Create, Mekanism hubs) | 500 MB – 2 GB |
Those figures assume the default actions toggles with logWaterFlow and
logLavaFlow off. Turning fluid logging on can multiply growth several-fold.
Sustained ingestion on SQLite has been measured at roughly 50,000 events/second on SSD-backed storage before the single-writer model becomes the bottleneck. If you exceed that, move to MySQL or PostgreSQL.
RAM: the queue is a fixed-capacity ring, so the memory ceiling is bounded by
queue.maxSize (50,000 events, roughly a few megabytes). A 2 GB heap is plenty for
VonixGuardian itself.
Known limitations#
Custom world-mutation code paths. A mod that bypasses Level.setBlock and
writes chunks directly — rare, and usually a bug in that mod — will not be recorded.
VonixGuardian will not crash; the worst case is a silent gap in history.
Non-reversible action types. Chat, commands, signs, sessions, and username changes are recorded for investigation only. Rollback and restore act on world state. A rollback whose filter matches only those rows reports zero applied steps with no error.
Explosion granularity. Explosion rows record the blast centre, not each
destroyed block. A rollback with a tight radius can miss splash damage whose centre
falls outside it. rollback.explosionSupplementalReach (16 by default) pads the
pre-filter, and rows are still verified against the blast's affected list.
Modded dimensions. r:#world_<key> accepts any registered dimension key,
including modded ones (r:#world_twilightforest:twilight_forest). Lookups and
rollbacks default to the world you are standing in, so cross-dimension work needs an
explicit selector.
Reporting a compatibility problem#
Include:
- the loader and Minecraft version,
- the mod name and version that is not being logged,
- the exact action you performed,
/vg statusoutput,- the startup log lines around
Booting VonixGuardian.
Redact database credentials and any coordinates you do not want public.