Minecraft anticheat guide
Vulcan Anticheat and FairPlay Hooks for Combat Review
How Vulcan users can evaluate hook context, mitigation, and combat-focused FairPlay checks.
Vulcan opt-in steps for FairPlay admins
First confirm the installed Vulcan build and read its current primary documentation for the flag events it emits. Then enable the FairPlay Vulcan hook in configuration, map the relevant event classes to notification-only actions, and watch staff channels during normal play before anything consequential.
Only after event delivery is confirmed should an admin attach triggers such as commands, mitigation, or compensation. Each step needs its own review: event arrival, alert readability, duplicate enforcement, and finally punishment ownership.
How the Vulcan hook works
The FairPlay defaults identify Vulcan and list two observed event class names from the Vulcan API: the flag event and the post-flag event. This is evidence of the classes FairPlay is configured to observe, not a statement that every Vulcan version emits them or that the integration passed a runtime test.
Separately, the client-sync documentation says an enabled Vulcan plugin disables FairPlay's transaction packet channel. That is an ownership rule, not a Vulcan transaction API integration, and it must not be read as compatibility proof.
Plugin Developer evidence still required
Check the Vulcan documentation for event details that matter to your setup. Start with notifications and confirm the events arrive before enabling consequential actions.
Re-check this evidence after every Vulcan or FairPlay update, since event classes and behavior can change between releases.
FAQ
What should I check before enabling Vulcan actions?
Confirm the hook receives the expected Vulcan events on your server, then review its notification and action settings.
What should be enabled first, notifications or triggers?
Notifications. Confirm events arrive and read cleanly, then add triggers only after duplicate-enforcement review.