CannonRTP (WorldCannon)

CannonRTP ist ein Multi-Kanonen-Zufallsteleportations-Plugin für Minecraft-Server. "WorldCannon" ist ein älterer Name bzw. der Name dieses Wiki-Abschnitts; das Plugin registriert sich in Bukkit als CannonRTP, wird als CannonRTP.jar ausgeliefert und das ist der Name, den Spieler und Admins sehen.

Wichtige Namensdetails:

• Plugin-Name: CannonRTP
• Hauptbefehl: /cannonrtp
• Aliase: /crtp, /wc
• Berechtigungen: cannonrtp.admin, cannonrtp.use
• Konfigurationsordner: plugins/CannonRTP/

Was es macht

CannonRTP ist ein Multi-Kanonen-Zufallslandesystem statt eines einzelnen festen Launchers. Jede konfigurierte Kanone kann an einer oder mehreren Stellen in der Welt platziert werden, und jede Platzierung überwacht Spieler, die in ihren Auslöseradius treten.

Jede Kanone kann:

• mehrfach über /wc create und /wc place platziert werden -- eine einzige Kanonenkonfiguration steuert jede Platzierung
• Spieler erkennen, die einen kanonenspezifischen Auslöseradius betreten (Standard 1,75 Blöcke)
• eine Warteschlange sicherer Landeorte in einer konfigurierten Zielwelt vorladen und pflegen (weltenübergreifendes Targeting wird unterstützt)
• unsicheres Gelände, blockierte Räume, geschütztes Land und Orte außerhalb der Weltgrenze ablehnen
• optional eine zusätzliche kanonenspezifische Berechtigung erfordern
• Spieler durch eine fünfphasige cinematische Sequenz starten
• ein FreeMinecraftModels 3D-animiertes Kanonenmodell anzeigen (pro Kanone customModel oder über eine globale Prioritätsliste); fällt auf farbwechselnde Orbitpartikel zurück, wenn FMM nicht installiert ist
• ein schwebendes, billboardiertes Statuslabel über der Kanone anzeigen (Ready / Charging / Maintaining / Exhausted / Disabled)

Startablauf

Erzeuge oder erkunde vor der Nutzung den konfigurierten Suchbereich in der Zielwelt. CannonRTP lädt vorhandene Chunks ohne neue Landschaft zu generieren; ein unerforschter Suchradius kann deshalb ohne Ziele bleiben.

Die Startsequenz wird von einer fünfphasigen Zustandsmaschine gesteuert (SEARCHING -> FIRING -> TELEPORTING -> DROPPING -> LANDING). Wenn ein Spieler den Auslöseradius einer berechtigten Kanone betritt:

1. CannonRTP prüft cannonrtp.use.
2. Es prüft die optionale requiredPermission der Kanone.
3. Es prüft die spielerbezogene Start-Abklingzeit (runtime.launchCooldownSeconds, Standard 30 Sekunden). Die Sperre gilt über alle Kanonen hinweg und verbraucht kein Ziel aus der Warteschlange.
4. Es verifiziert, dass die Kanone mindestens einen vorgeladenen Landeort in der Warteschlange hat. (Deaktivierte Kanonen, Kanonen in einer nicht geladenen Welt und Kanonen in einem nicht geladenen Chunk erreichen diesen Punkt nie -- sie werden vollständig aus der Tick-Schleife ausgeschlossen und lassen sich daher gar nicht auslösen.)
5. Es entnimmt einen vorgeladenen sicheren Landeort aus der Warteschlange dieser Kanone.
6. Es feuert CannonRTPLaunchEvent (abbrechbar). Wenn ein Listener es abbricht, wird das Ziel an die Warteschlange zurückgegeben und es startet keine Abklingzeit.
7. Suchphase (Standard 42 Ticks, konfigurierbar über launchWarmupTicks): Der Spieler erhält Levitation, die Kanone spielt ihre fire-Animation ab, falls ein benutzerdefiniertes Modell aktiv ist, und zufällige Koordinatenvorschauen flackern durch Titel/Untertitel. Solange ein Modell aktiv ist, erhält der Spieler außerdem Unsichtbarkeit, damit die Animation klar zu sehen ist.
8. Feuerphase (Standard 45 Ticks über verticalBoostTicks): Levitation/Unsichtbarkeit werden entfernt, der Abschuss-Sound wird abgespielt, ein Flammen-+Rauch-+Explosionsausbruch erscheint, und verticalBoostVelocity wird bei jedem Tick angewendet. Die echten Zielkoordinaten werden offenbart.
9. Teleportphase (einzelner Tick): Das Ziel aus der Warteschlange wird erneut validiert (Geländesäule, Schutz-Integrationen, API-Listener). Besteht es weiterhin, wird der Spieler exakt 50 Blöcke darüber teleportiert und Langsamer Fall wird angewendet. Die Abwurfhöhe wird nie gedeckelt -- der Landevalidierer stellt bereits sicher, dass der Ankunftsblock unterhalb der maximalen Welthöhe liegt, und ein Ziel, das nicht mehr validiert, bricht den Start ab und rettet stattdessen den Spieler.
10. Fallphase: Der Spieler treibt mit einer Rauchspur (LARGE_SMOKE + CAMPFIRE_SIGNAL_SMOKE) nach unten.
11. Landephase: Wird betreten, sobald der Spieler den Boden berührt. Langsamer Fall wird entfernt, ein Aufschlagsausbruch wird abgespielt (Wolken-Schockwelle, Flammenring, Staubübergang), und CannonRTPLandingEvent wird gefeuert. Läuft der Fall stattdessen über seine maximale Dauer hinaus (slowFallingSeconds x 20 Ticks), rettet CannonRTP den Spieler und es wird kein Landeereignis ausgelöst.

Landesicherheitsregeln

Bevor ein Ort in die Vorladewarteschlange aufgenommen wird, prüft der aktuelle Code in dieser Reihenfolge:

• die Zielwelt ist geladen (solange das nicht der Fall ist, stoppt die Kanone das Vorladen und meldet Target world <name> is not loaded.)
• das Suchzentrum lässt sich auflösen -- das konfigurierte searchCenter, sonst der eigene Standort der Kanone, wenn sie in der Zielwelt steht, sonst der Spawn der Zielwelt
• der Kandidat liegt innerhalb der Weltgrenze
• der Kandidaten-Chunk ist geladen (bei Bedarf geladen, ohne zu generieren)
• ein höchster nicht-leerer Block existiert in der Kandidatenspalte
• der Oberflächenblock direkt unter dem Landepunkt ist fest und nicht-flüssig
• dieser Oberflächenblock steht nicht in der konfigurierten Liste unsicherer Bodenmaterialien und ist nicht das Nether-Bedrock-Dach
• der Landepunkt liegt auf oder über der minimalen Welthöhe, und der Ankunftsblock 51 Blöcke darüber bleibt unterhalb der maximalen Welthöhe
• jeder Block der 52 Blöcke hohen Abwurfsäule (vom Landepunkt bis hinauf zum Kopfblock der Ankunft) ist Luft oder passierbar
• kein Block in dieser Säule steht in der konfigurierten Liste unsicherer Körpermaterialien
• alle aktivierten Schutz-Plugin-Integrationen erlauben den Ort
• kein CannonRTPLocationValidationEvent-Listener verwirft den Kandidaten

Im Nether lehnt CannonRTP das Bedrock-Dach ab und sucht abwärts nach einem freiliegenden Höhlenboden, dessen komplette Abwurfsäule sicher ist. Das ermöglicht Nether-Ziele, ohne den Spieler über der Decke oder durch festes Gelände abzuwerfen.

Suchversuche sind global auf einen pro Tick (20/Sek.) ratenbeschränkt und werden über Round-Robin fair auf alle aktiven Kanonen verteilt. Jede Kanone hat ihren eigenen Timeout-Zähler (searchTimeoutAttempts, Standard 100, Minimum 10).

Kanonenzustände

Jede Kanone hat einen internen Zustand, der über /wc status oder /wc list sichtbar ist:

Anzeige	Interner Zustand	Bedeutung
Disabled	--	Die Kanone ist in ihrer Konfiguration explizit deaktiviert
Charging	SEARCHING (Warteschlange leer)	Lädt noch ihren ersten Stapel sicherer Orte vor
Maintaining	SEARCHING (Warteschlange nicht leer)	Hat einige Orte, füllt aber noch verbrauchte Plätze auf
Ready	READY	Hat genügend vorgeladene Orte (>= chargedLocationsPerCannon), um Spieler zu starten
Exhausted	EXHAUSTED	Hat searchTimeoutAttempts aufgebraucht, ohne die Reserve zu füllen

Der interne Suchzustand ist genau einer von drei Werten (READY, SEARCHING, EXHAUSTED); Disabled wird entschieden, bevor er überhaupt herangezogen wird, und Charging / Maintaining sind die zwei Darstellungen von SEARCHING. Ready gewinnt gegen Exhausted -- eine Kanone, die ihre aufgeladene Reserve noch hält, wird als Ready angezeigt, selbst wenn ihr letztes Suchfenster abgelaufen ist.

Es gibt keinen separaten Zustand für eine "ungültige Konfiguration". Wenn die targetWorld einer Kanone nicht aufgelöst werden kann, behält die Kanone ihre aktuelle Suchzustands-Bezeichnung und die $reason-Spalte von /wc status wird zu Target world <name> is not loaded. (Der Nachrichtenschlüssel statusLabels.invalid existiert in messages.yml, aber im aktuellen Build rendert ihn nichts.)

Eine Kanone startet Spieler, sobald sie mindestens ein Ziel in der Warteschlange hat. Der Schwellenwert chargedLocationsPerCannon betrifft nur das visuelle READY-Label.

Laufzeitanforderungen

• Minecraft: plugin.yml deklariert api-version: 1.21.4; der aktuelle Quellbaum wird gegen die Spigot-API 26.2-R0.1-SNAPSHOT gebaut
• Java: 21
• Empfohlene Serversoftware: Paper oder ein aktueller kompatibler Fork
• MagmaCore: 2.2.0 oder neuer (gemeinsam genutzte Bibliothek, in das Plugin geshaded)
• Optionale Abhängigkeit: FreeMinecraftModels (für 3D-animierte Kanonenmodelle)

Robustheit

CannonRTP hält seine Visuals und Warteschlangen über Welt- und Chunk-Lebenszyklusereignisse hinweg konsistent:

• wenn der Chunk einer Kanone entladen wird, werden ihr Label und Modell entfernt; sie tauchen beim erneuten Laden des Chunks wieder auf
• wenn die Welt einer Kanone entladen wird, wird die Kanone ausgesetzt; sie erwacht wieder, wenn die Welt erneut geladen wird
• wenn FreeMinecraftModels mitten in einer Sitzung aktiviert oder deaktiviert wird, wird der Modell-Cache invalidiert und die Visuals werden im nächsten Tick aktualisiert
• vor der Abwurf-Teleportation wird das Ziel aus der Warteschlange erneut gegen Gelände, Schutz-Integrationen und API-Listener geprüft; ist es unsicher geworden, rettet der Start den Spieler, statt sich auf veraltete Koordinaten festzulegen
• die Start-Aufräumung entfernt nur die Effekte Levitation, Unsichtbarkeit und Langsamer Fall, die CannonRTP noch gehören, und stellt einen älteren Effekt wieder her, den es vorübergehend ersetzt hat, statt den neueren Zustand eines anderen Plugins zu löschen
• wenn ein Start nicht fortgesetzt werden kann, weil seine Zielwelt entladen wird, rettet CannonRTP den Spieler zum Kanonensitz oder zum Spawn einer anderen geladenen Welt und behält Langsamer Fall bei, wenn keine sichere Rettungswelt verfügbar ist

Hier starten

• Befehle und Berechtigungen
• Konfiguration
• Content-Pakete
• Nachrichten und Titel
• Schutz-Integrationen
• API-Events