MCME is one Minecraft network. Players connect to a Velocity proxy, which passes them on to several Paper game servers (the "backends"). Around the game sit a live map, the websites, a Maven repository for our own libraries and a Discord bot. This page shows how that code connects: which plugin depends on which, which messages travel between the proxy and the game servers, and what the web pieces read. It does not cover machines, hosts or which plugin runs on which server; that is in Network topology (operators only).

Every plugin named here has its own page under Developers. Start there for build steps, config and commands.

The game network

Several MCME plugins come in two halves: one runs on the Velocity proxy, the other on the Paper servers. The halves talk over plugin channels: named message channels that Minecraft carries over the player's connection between the proxy and a backend. A plugin message needs a player online on that backend to travel.

graph LR
  subgraph proxy["Velocity proxy"]
    CP["MCME-Connect"]
    WV["MCME-Warps (Velocity half)"]
    GV["thegaffer-velocity"]
    IV["MCME-Introduction (proxy half)"]
    TV["WebTeleport (Velocity)"]
    AV["AccountLink (Velocity)"]
  end
  subgraph paper["Paper servers"]
    CB["MCME-Connect"]
    WP["MCME-Warps (Paper half)"]
    GP["TheGaffer"]
    IP["MCME-Introduction"]
    TP["WebTeleport (Paper)"]
  end
  CB ---|"mcme:connect"| CP
  WP ---|"mcme:warp, mcme:player-location, mcme:misc"| WV
  GP ---|"mcme:gaffer"| GV
  IP -->|"mcme:intro"| IV
  TV -->|"mcme:webteleport"| TP

Not every Paper server runs every plugin. The table lists what each channel carries.

Who builds against whom

MCME plugins compile against each other's published jars, which come from the Maven repository. None of them bundles (shades) another MCME plugin or library: the dependency must be installed on the server as its own plugin.

graph TB
  BASE["MCME-Base"]
  PU["PluginUtils"]
  CON["MCME-Connect"]
  ARCH["MCME-Architect"]
  INTRO["MCME-Introduction"]
  PVP["MCME-PvP"]
  GB["Guidebook"]
  GAF["TheGaffer"]
  CON --> BASE
  CON --> PU
  ARCH --> PU
  ARCH --> CON
  INTRO --> ARCH
  INTRO --> CON
  PVP --> PU
  GB --> PU
  ARCH -.->|"reflection, by method name"| GAF

Solid arrows are Maven or Gradle dependencies; the dotted arrow is a runtime call without a compile-time dependency.

Perks and RankBoard are in private repositories; their pages describe them.

TheGaffer's build-protection API

MCME-Architect asks TheGaffer whether a player may build before its tools act, and tells TheGaffer about blocks it places so they count towards the player's job. There is no compile-time dependency: Architect looks up three static methods on com.mcmiddleearth.thegaffer.TheGaffer by name.

Because the lookup is by name, renaming or changing one of these methods does not break the build: it silently switches off Architect's job checks. Treat the three signatures as a contract and change both repositories together. TheGaffer's ProtectionApiContractTest pins them.

Around the game

graph LR
  DYN["Dynmap on the Paper servers"]
  ARCH["MCME-Architect"]
  WARP["MCME-Warps"]
  MAP["LiveAtlas map"]
  WT["WebTeleport (Velocity)"]
  AV["AccountLink (Velocity) /mcmeverify"]
  BOT["Discord bot (qBot)"]
  PERKS["Perks"]
  FORUM["Forum and its Pledge system"]
  FRONT["Front page"]
  RPS["ResourcePackScripts release automation"]
  GH["GitHub releases"]
  CI["GitHub Actions"]
  MVN["Maven repository"]
  ARCH -->|"marker layers"| DYN
  WARP -->|"warp layer"| DYN
  DYN -->|"tiles and JSON files"| MAP
  MAP -->|"teleport requests"| WT
  AV -->|"link codes"| BOT
  PERKS -->|"linked accounts, Patreon data"| BOT
  PERKS -->|"Pledge totals"| FORUM
  FRONT -->|"reads"| FORUM
  ARCH -->|"/rp release runs"| RPS
  RPS -->|"pack zips"| GH
  CI -->|"publishes jars"| MVN

• The live map. Each mapped Paper server runs Dynmap, which writes map tiles and small JSON files to disk. The LiveAtlas front end reads those files directly; Dynmap's own web server is not used. Architect and Warps draw their layers through Dynmap's marker API, so they appear on the map without any map-side code. A click on the map can teleport the player in game through the WebTeleport plugins.
• Account linking. A player asks the Discord bot for a code and types /mcmeverify <code> in game. The AccountLink Velocity plugin sends the code to the bot, which stores the link between the Discord account and the Minecraft UUID. Perks later reads the links, and the bot's Patreon data, to grant perks.
• The front page. The front page reads the forum (sign-in, the staff list, news), the Pledge system, Patreon, Discord events and a few public JSON files, always through scheduled jobs that cache the results. A page view never waits on an outside service.
• Resource packs. Staff run /rp release in game. MCME-Architect starts ResourcePackScripts' release automation, which builds the pack zips and publishes them as a GitHub release. See The release pipeline.
• Shared artifacts. GitHub Actions in each library and plugin repository publish release jars to the Maven repository, and every MCME build resolves its MCME dependencies from there.

When you add a connection

• Decide the data contract first: channel name, message layout, or method signatures. Write it down in both repositories.
• Plan for the other side being absent. A plugin on another server may be missing, older, or restarting; a web service may be down. Prefer a soft dependency and a clear log line over a crash.
• Plugin channels use the mcme: namespace. A single channel per plugin, with a leading string that names the operation, keeps registration simple; MCME-Connect and TheGaffer work that way.
• Version both halves of a split plugin together and release them together.
• Add the connection to this page.