API

StaffService is how another plugin asks whether a player is vanished, frozen or on duty, and how it runs one of the staff member's own actions without going through a command.

ExyliaAPI.get(StaffService.class).ifPresent(staff -> {
    if (staff.isVanished(target.getUniqueId()) && !staff.canSee(viewer, target)) {
        event.setCancelled(true);
    }
});

Every feature is a module, and a module can be off

Staff mode, vanish, freeze, staff chat and the rest are separate modules the owner switches on and off in config.yml or at runtime. A question about a module that is off answers as though nobody is in that state — false, 0, GlobalChatMode.OFF — and an action on a module that is off does nothing. Nothing here throws because a feature is missing, because a feature being missing is the owner's decision rather than an error. Ask isModuleEnabled(String) when the difference matters.

Everything that returns a value is a memory read off the module caches, safe from a placeholder, a scoreboard line or a combat listener. Everything that acts runs the same flow the staff member's own command runs — the permission checks, the messages they see, the hotbar redraw, the session log — so call those on the main thread and no more often than a player could trigger them.

State

Vanish

canSee is the check anything that lists, targets or renders players wants — it is what keeps an admin hidden from a helper who is otherwise allowed to see vanished staff.

Chat

Rosters

Both are this server only: staff working on another server of the network are not online here and have no Player to read a permission from. Both lists are unmodifiable.

Modules

Ids are the ones the owner writes in config.yml: staffmode, vanish, freeze, staffchat, globalchat, mining, xrayvision and the rest. The set changes at runtime — an owner may switch a module off without restarting — so read it when you need it rather than caching it.

Actions

Each of these runs the same flow the staff member's own command runs, permission checks and player messages included. When one reports a boolean it is whether the flow ran, not whether it succeeded in some deeper sense: a refusal has already been said to the player.

GlobalChatMode

Each step includes the one before it, so a cycle only ever adds reach.

bypasses() is true for anything but OFF, and it is the reason a chat plugin cares: a staff member above OFF reads the chats a match, an arena or an event isolates, so a plugin that hides lines from other players has to let these through.

Events

Two events, in net.exylia.lib.api.staff.event. Both fire after the change or the action has already happened, on the thread of the player they are about, and neither is cancellable — they report, they do not gate. Because they fire afterwards, receiving one is a guarantee: the service already answers the new way by the time your listener runs. To refuse a change, gate the permission that allows it.

ExyliaStaff's own modules use these instead of calling each other — the hotbar redraws its vanish item, the log counts a freeze, the scoreboard updates a line — which is why they live in the public API rather than inside the plugin. Anything that wants an audit trail, a webhook or a per-staff scoreboard listens to the same two.

StaffStateChangeEvent.Kind

Every module that owns a per-player switch reports it here rather than defining an event of its own, so this list grows as modules are added. A listener that cares about one kind filters; one that switches over all of them should have a default arm.

@EventHandler
public void onState(StaffStateChangeEvent event) {
    if (event.getKind() == StaffStateChangeEvent.Kind.STAFF_MODE && !event.isEnabled()) {
        // the shift ended
    }
}

StaffActionEvent

getAction() is a short id such as freeze, report_resolve or punish. New ids appear as modules are added, so treat an unfamiliar one as an action this version of the plugin has and yours does not know about, rather than as an error. getTarget() is null for an action about nobody in particular.

What it does not expose

No menu openers, no editor flows, no punishment or report rows, no configuration writes. Reports, helpop, inspect and the punishment history are read and driven from inside the plugin, and the staff log is filled by StaffActionEvent rather than by a method you call.

If an integration genuinely needs something that is not here, ask on Discord — a method added to a service is a minor release.