Network
Announcing a server's events to the whole network, and walking players to them.
A single server needs nothing on this page. Left off — which is how it ships — no channel is opened, nothing is published, and every join takes the same local path it always took.
Turned on, a server announces its events to the rest of the network. A player standing in the lobby reads that an event is waiting on the arena server, clicks the same line every server prints, and is connected and put into it. What travels is the announcement and the intent to join, never a location: once the player is on the server that owns the event, the ordinary local teleport to that event's lobby spawn takes over.
What it needs
| Requirement | Why |
|---|---|
Redis, on in database.yml on every server | The channel the announcements travel on. |
A different server-id on every server | How the proxy and the announcements address a backend. |
ExyliaProxyUtils on the proxy | What actually moves the player between servers. |
| The same database on every server | Arenas and statistics are read from one place. |
With any of those missing the plugin stays quiet, says so once in the console, and keeps working as a single server.
database.redis and network.enabled are separate switches on purpose. A server may well share a
cache with the network and still want its events to itself.
Turning it on
network:
enabled: true
return-on-end: trueenabledbooleanpor defecto falseWhether this server announces its events to the rest of the network, and accepts the players other servers send to them.
return-on-endbooleanpor defecto trueWhether a player the network brought here is sent back to the server they came from once their event lets go of them — it ended, they left, or they arrived to find it already full. Only ever undoes a move this plugin made: a player who walked onto this server by themselves is never moved. Turn it off on a server players are meant to stay on.
Arenas belong to a backend
An arena records the server it was configured on. That server is the only one that may edit it, start it, or write it back — the rule that keeps a shared database safe, since no other backend has the world the arena is in and would save a row full of places it cannot see.
- The admin configuration list shows each arena's server.
/events start <id>on an arena that lives elsewhere hands the start to the server that owns it, and reports back whether it started. Every limit — cooldowns, event caps — is applied by the server that owns the arena, not by the one that asked.- Tab completion offers the whole network's startable arenas, local and remote alike.
An arena configured before any of this names no server, and the world decides instead: it belongs to whichever backend has the world it is in. On a lone server that is always the local one, so nothing an admin already configured changes or has to be touched.
Arena ownership is stored inside the arena's existing settings, so an existing database is not altered and nothing has to be migrated.
One lobby per backend
The main lobby is stored per server-id in events_server_settings. Backends sharing one database
used to share one lobby row, so the last admin to set theirs moved everybody else's — to a world only
their server has. Each server now answers for its own and reads nobody else's.
The single row an older version wrote is adopted once, by the one server whose world it is actually in. On a lone server that is always true and the lobby is kept without anyone doing anything.
Network-wide event ids
An event that travels is addressed as server:event. Ids without a server in them are local, which
is every id an admin ever types — a configuration id can only contain a-z, 0-9, _ and -, so
the two can never be confused.
Messages stay local
Only the facts travel: the event, its type, its state, how many players it holds and who started it.
Every server renders them through its own messages.yml, so a network running two languages keeps
both.
Something missing on this page? Tell us on Discord