From problem to decision

Technical use cases

Six situations, each tied to documented plugin behaviour: the problem, what the plugin decides, the result and the limits.

Each flow is an example written from the plugin documentation. It is a simplified illustration, not live data from a server and not a promise for every setup.

Catch a Java mismatch before the restart

PluginGuardReleased
Starting problem
A plugin update is now compiled for a newer Java than your server runs. The JVM would refuse to load it, and the cause is buried in a long startup log.
What the plugin decides
PluginGuard reads the class-file version inside every jar in plugins/ and compares it with the Java the server reports. It never executes or changes a jar.
Result
The scan reports a critical JAVA_VERSION_TOO_NEW finding for that plugin, and the fix list says to run a newer Java or use a build made for yours.
Limits to keep in mind
PluginGuard runs inside a server that is already up. Scan after copying the jar and before you restart; it cannot help a server that no longer boots.

Example flowIllustration, not live data

  1. Copy the new jar into plugins/
  2. Run /pluginguard scan
  3. Critical finding: Java version too new

Tell a crash from a moderator kick

VelorFailoverReleased
Starting problem
Velocity raises the same event for a crashed backend, a moderator kick and a ban. Redirecting on that event would send banned players to the lobby.
What the plugin decides
VelorFailover pings the server. If it answers, Velocity handles the kick as usual. Only a failed ping, with a fallback that answers, moves players.
Result
After a real crash, players wait on the fallback and return once the server passes the configured number of consecutive checks.
Limits to keep in mind
If the fallback is also down, nothing is redirected. Planned stops are recognised only when your stop message contains a configured text.

Example flowIllustration, not live data

  1. A player is kicked from survival
  2. Ping survival: answer or no answer
  3. Answer: normal kick. No answer: move to lobby

Hold a suspicious reward for review

ReferralTrackAwaiting approval
Starting problem
Two players on the same address refer each other, and the welcome reward would be paid out automatically.
What the plugin decides
With the optional fraud review enabled, ReferralTrack scores explainable signals (same IP, mutual referral, recent first join, low playtime) and holds the referral when the score reaches your threshold.
Result
A held referral cannot validate or release rewards until staff approve or reject it with a reason, and the decision is written to an audit log.
Limits to keep in mind
Fraud review is off by default. The signals set review priority; they do not prove alternate accounts.

Example flowIllustration, not live data

  1. A referral is created
  2. Signals are scored against your threshold
  3. Held for staff: approve or reject with a reason

Roll back an update that fails its command check

VeloRoadAwaiting approval
Starting problem
You replace a plugin live. The new version enables, but its commands never register.
What the plugin decides
VeloRoad runs preflight checks, makes a SHA-256 verified backup, loads the new jar and compares the commands it registered with its descriptor.
Result
If loading, enabling or the command check fails, the previous verified version is restored automatically when a backup exists.
Limits to keep in mind
A full restart is still the safest choice for critical plugins and plugins that keep deep live references.

Example flowIllustration, not live data

  1. Preflight and verified backup
  2. Load the new jar and check its commands
  3. Check fails: previous version restored

One YAML file, three menu surfaces

CrossMenuAwaiting approval
Starting problem
Java and Bedrock players need the same shop, and keeping three separate menus in sync is a chore.
What the plugin decides
CrossMenu reads one menu definition and shows it as a chest on Java, as a native dialog where the server provides the Dialog API, and as a native form for Geyser or Floodgate players.
Result
Each player gets the native surface for their client from the same file.
Limits to keep in mind
Bedrock forms are static once open. Java dialogs need Dialog API support; older servers fall back to the chest menu. Minecraft 1.20.5 or newer is required.

Example flowIllustration, not live data

  1. Write one menu file
  2. CrossMenu detects the client
  3. Chest, dialog or Bedrock form is shown

Move data with a dry run and a way back

MigrateComing soon

This plugin is not released yet. There is no purchase link until it is.

Starting problem
You are switching from one plugin to another and want to keep homes, warps, balances or punishments.
What the plugin decides
Migrate is designed to plan the run, show it in a dry run, write a verified backup, write the data, read it back to verify it and keep what it wrote reversible.
Result
A report lists what was moved and what was skipped, and why.
Limits to keep in mind
Migrate is not released. Supported plugins, versions and platforms will be announced with the release; none is promised here.

Example flowIllustration, not live data

  1. Dry run: see what would change
  2. Backup, write, read back and verify
  3. Report; roll back if needed

Not sure which one you need?

Answer eight short questions and get up to three suggestions.