Portale, die hochkant stehen müssen

Die Lobby braucht Portale: drei Durchgänge, die zu den drei Servern führen. Optisch soll es nach Portal aussehen, technisch soll es einen Serverwechsel auslösen, wenn jemand hindurchgeht.

Klingt nach einer halben Stunde. Es waren drei Abende, und die Gründe sind gute Beispiele für Minecraft-Eigenheiten.

Welcher Block eignet sich?

Die naheliegende Wahl für ein Portal ist der Blocktyp, der auch im Spiel für Portale steht. Davon gibt es zwei, und der Unterschied ist entscheidend:

Der eine lässt sich nur waagerecht platzieren. Er liegt flach auf dem Boden, wie eine Pfütze. Ein Rahmen aus diesen Blöcken, senkrecht aufgestellt, ist nicht möglich — er nimmt die Ausrichtung nicht an.

Der andere kann hochkant stehen. Damit lässt sich eine senkrechte Fläche bauen, durch die man hindurchgeht.

Ich habe mit dem falschen angefangen, eine 3×3-Fläche gesetzt, und alles lag flach auf dem Boden. Das ist kein Fehler im Befehl, sondern eine Eigenschaft des Blocks — und man findet sie in keiner Fehlermeldung, sondern nur, indem man das Ergebnis ansieht.

Die Auslösung

Ein Portal ist kein Ereignis. Es gibt keinen Auslöser, der meldet, dass jemand hindurchgegangen ist.

Der Weg ist deshalb: Auf Bewegung horchen, prüfen, ob die neue Position in einem definierten Bereich liegt, und dann den Wechsel auslösen.

Zwei Dinge, die dabei wichtig sind:

Die Prüfung muss billig sein. Bewegungsereignisse feuern sehr häufig — bei jedem Schritt jedes Spielers. Eine Prüfung, die dabei jedes Mal eine Liste durchgeht oder etwas aus einer Datei liest, ist eine Belastung für den ganzen Server. Bei mir ist es eine Ganzzahlprüfung gegen wenige Bereiche, mit einer Vorprüfung, ob sich der Block überhaupt geändert hat.

Es braucht eine Sperre pro Spieler. Sonst löst der Wechsel bei jedem Schritt innerhalb des Bereichs erneut aus, und der Spieler bekommt eine Kaskade von Weiterleitungen.

Der Spawnpunkt, der ein eigenes Modul braucht

Ein Nebenthema, das mich einen Abend gekostet hat: Wer die Lobby betritt, soll am Spawn landen — egal, wo er sich abgemeldet hat.

Die Einstellung dafür stand in der Konfiguration eines verbreiteten Grundplugins, und sie hatte keine Wirkung. Der Grund: Die Funktion steckt in einem eigenen Zusatzmodul, das separat installiert werden muss. Der Kern liest die Einstellung nicht einmal.

Sie stand also monatelang in einer Konfigurationsdatei und wurde von niemandem ausgewertet. Kein Fehler, keine Warnung — die Einstellung existiert schlicht in einer Datei, für die sich niemand zuständig fühlt.

Das ist eine Fehlerklasse, die mir bei Minecraft-Plugins mehrfach begegnet ist: Eine Konfiguration ohne die zugehörige Programmdatei ist stumm. Der Prüfweg ist entsprechend banal und wirksam: nachsehen, ob es zu dem Konfigurationsordner überhaupt eine Programmdatei gibt. Ein Ordner unter den Plugins beweist gar nichts.

Die Kennung, die nirgends steht, wo man sie sucht

Beim Setzen des Spawnpunkts verlangte die Konfiguration nicht den Namen der Welt, sondern deren eindeutige Kennung. Ohne sie brach das Laden mit einem Fehler ab, und der Spawn war stumm weg.

Die Frage war: Woher bekommt man diese Kennung bei einer frisch angelegten Welt?

Nicht aus den Weltdaten — dort steht sie in aktuellen Fassungen nicht mehr. Nicht aus einer eigenen Datei daneben — die gibt es nicht mehr. Gefunden habe ich sie schließlich in den Spielerdaten eines Plugins, wo die zuletzt bekannte Position samt Weltkennung gespeichert ist.

Das ist die Art von Wissen, die man einmal mühsam erarbeitet und danach in eine Notiz schreibt. Genau dafür habe ich das Zweitgehirn angelegt — und dieser Fall ist der erste, bei dem ich beim Schreiben gemerkt habe, dass er sonst spurlos verschwunden wäre.

Die Prüfung, die ich mir für Plugins angewöhnt habe

Der Fund mit der Konfiguration ohne Programmdatei hat zu einer Kontrolle geführt, die ich seitdem auf jedem Server regelmäßig laufen lasse.

Sie vergleicht zwei Listen: die Ordner unter den Plugins und die tatsächlich vorhandenen Programmdateien. Jeder Ordner ohne passende Datei ist ein Kandidat.

Bei mir kamen dabei drei Fälle heraus, und die Einordnung ist jedes Mal eine andere:

Reste eines entfernten Plugins. Der Ordner kann weg — nach einem Blick hinein, ob dort Daten liegen, die man behalten will.

Ein Plugin, das es für die aktuelle Version nicht gibt. Der Ordner bleibt, die Funktion fehlt. Das gehört ausdrücklich notiert, weil die Konfiguration sonst weiterhin so aussieht, als sei alles eingerichtet.

Ein Plugin, das falsch benannt eingespielt wurde. Selten, aber schnell behoben.

Der zweite Fall ist der gefährliche. Bei mir hing daran eine Schutzfunktion, deren Fehlen erst im Ernstfall auffällt — und Gutscheine, die eine Berechtigung für ein Plugin vergeben, das gar nicht läuft.

Warum ich Konfiguration von Wirkung trenne

Aus diesen Fällen ist eine Denkweise geworden, die über Minecraft hinausgeht: Eine Konfiguration ist eine Absicht, keine Wirkung.

Eine Einstellung in einer Datei sagt, was gelten soll. Ob es gilt, hängt daran, ob jemand sie liest, ob die zuständige Komponente existiert, ob sie richtig geschrieben ist und ob nicht eine andere Stelle sie überschreibt.

Die Prüfung muss deshalb immer an der Wirkung ansetzen: Ist der Spieler tatsächlich am Spawn gelandet? Wird der Bereich tatsächlich geschützt? Antwortet der Server tatsächlich mit den erwarteten Werten?

Ich habe dafür inzwischen für jeden wichtigen Punkt eine beobachtbare Prüfung — und für die meisten braucht es keinen Client, sondern nur eine Abfrage oder einen Blick in die Daten.

Was am Ende steht

Drei Portale, je eine senkrechte 3×3-Fläche, mit einem Bereich dahinter, der den Wechsel auslöst. Ein Spawnpunkt, der zuverlässig greift. Und drei Notizen über Dinge, die ich beim nächsten Mal nicht wieder herausfinden muss.