Compatibility

How to read this page

The table below is generated from the compatibility data we maintain as we test builds, so it reflects what we have actually run rather than what we expect to work. Each entry carries one of three verdicts.

• Compatible: the plugin has been run alongside Ecstacy without either side misbehaving. Install it normally; nothing extra is required.
• Incompatible: the two conflict in a way we cannot work around from our side. In practice this almost always means the other plugin also intercepts packets and rewrites or cancels the same ones our checks read, which either blinds a detection or produces false flags. Running both is not a configuration problem you can tune your way out of.
• Ticket required: it can work, but the setup depends on details we cannot guess: your server version, the other plugin's configuration, or the order plugins load in. Open a ticket and we will tell you what the combination needs.

An absent plugin is not a verdict. It means nobody has reported the combination yet. Ask on Discord and we will test it and add a row.

Server requirements

Ecstacy runs on Paper, Purpur, Pufferfish, Spigot and Folia, against the 1.21 API. Folia's threaded regions are supported natively; you do not need a different build or a separate configuration for it.

PacketEvents is a hard dependency, not an optional integration. It is declared as depend in our plugin.yml, so a server missing it will refuse to enable Ecstacy at all rather than starting in a degraded state. The minimum version we accept is shown above and is enforced at startup.

The only networking requirement is outbound TCP to cloud.ecstacy.ac:5001. Ecstacy dials out to our cluster; it never listens for inbound connections, so there is no port to open, forward or firewall on your side. If your host blocks arbitrary outbound TCP, that single destination is all you need allowed.

Proxies, Bedrock and version bridges

On a network, our checks run on the backend servers, because that is where the packets we analyse are produced and where player state actually lives. A proxy-only installation of a protocol bridge is therefore not enough: install ViaVersion and Floodgate/Geyser on the backend servers as well, so the packets reaching Ecstacy are already translated into the form the checks expect. Skipping this is the single most common cause of odd behaviour on cross-version networks.

Bedrock players connected through Geyser are handled, but note that their input model differs from Java's. Our combat models were trained on Java packet behaviour, so detections are weighted accordingly and Bedrock clients are not held to Java timing signatures.

Anticheats running alongside Ecstacy

Ecstacy is not a general-purpose movement anticheat and does not try to be. It targets the combat-side problems that simulation cannot solve. Crystal Aura, Anchor Macro, Auto Totem. And it coexists deliberately with movement-focused anticheats rather than competing with them. Running one of those for movement, fly and speed alongside Ecstacy for combat is a supported and recommended setup, and the table below lists which ones we have verified.

Two anticheats sharing a server does need one decision from you: who punishes. Two systems each banning on their own thresholds produces duplicate punishments and staff arguing about which one was right. The usual arrangement is to let the movement anticheat keep its own enforcement and set punish.enable: false on the Ecstacy families while you learn its flag rate, then turn enforcement on for the combat checks only. Nothing about detection changes either way.

When something behaves oddly

Before assuming a plugin conflict, rule out the three things that produce conflict-shaped symptoms without being one:

• The cloud link. Detections are scored off-server, so a dropped link looks exactly like a check that stopped working. /ecstacy cloud shows the state and /ecstacy doctor diagnoses it.
• Exemption. A player nobody can get flagged is usually exempt, not undetectable. /ecstacy exempt <player> lists per-check exemptions, and the ecstacy.exempt.* permission node exempts them from everything at once.
• Protocol translation. On a cross-version network, packets that reach a backend server untranslated behave like a conflict. That is the ViaVersion and Geyser placement point above, and it is the most common cause of odd behaviour we see.

If none of those explain it, open a ticket with the output of /ecstacy doctor pasted verbatim, your server software and version, the other plugin and its version, and whether the problem started after an update. That is enough for us to reproduce it; a description without the doctor output usually is not.

Common questions

Does Ecstacy replace my current anticheat? No, and it is not meant to. It detects combat automation. Fly, speed and reach stay the job of a movement anticheat, and the two are designed to run together.

Do I need it on the proxy? No. Install it on the backend servers, where the packets are produced and player state lives. There is no proxy module.

Will it work on my fork? Forks of the supported platforms generally work, because the plugin talks to the API rather than to internals. A fork that rewrites packet handling is the case we cannot predict. Ask, and we will test it.

What happens if the cloud is unreachable? By default the plugin keeps running and retries; alerts and punishments resume when the link returns. If you would rather it disable itself than run without detections, cloud.disable-on-startup-connect-failure in settings.yml does that.

Is one licence enough for a network? One licence covers multiple servers, each with its own download from the Client Area, up to the instance limit of your plan. Reputation and the known-cheaters list are shared across servers on the same licence.