BetterModel ist reines Java — Bedrock sieht nichts davon
Die aufwendig gebauten Portale und Objekte waren für die Hälfte der Spieler unsichtbar. Der Nachweis dauerte zehn Minuten, die Lösung mehrere Tage — und besteht aus vier Teilen, von denen keiner fehlen darf.
Blackzack915 Wörter · 5 Min. Lesezeit
- minecraft
- bedrock
- eigenbau
Auf meinem Server stehen aufwendig gebaute Objekte: Portale mit Animation, Altäre, dekorative Modelle. Sie kommen aus einem Modell-Plugin und sehen gut aus.
Auf Bedrock sieht man nichts davon. Nicht falsch dargestellt — gar nichts.
Der Nachweis
Ich hätte lange raten können. Der Nachweis hat zehn Minuten gedauert:
Das Plugin auspacken und nach jedem Hinweis auf die Bedrock-Anbindung durchsuchen. Ergebnis: kein einziger Treffer. Kein Bezug zur Übersetzungsschicht, keine Bedrock-Kennungen, nichts.
Zur Gegenprobe dasselbe auf der anderen Seite: In den ausgelieferten Bedrock-Paketen des Livebetriebs nach den Kennungen der Modelle suchen. Ebenfalls kein Treffer.
Damit war die Sache eindeutig, und zwar ohne einen einzigen Versuch im Spiel.
Die Verwechslung, die dahintersteckt: Solche Plugins tragen manchmal „Bedrock" im Namen oder in der Beschreibung. Gemeint ist das Dateiformat der Modelle — das aus einem verbreiteten Modellierungswerkzeug stammt und historisch nach der Bedrock-Fassung von Minecraft benannt ist. Nicht die Spielfassung.
Warum das so ist
Ein Modell-Plugin auf Java-Seite baut seine Objekte aus Anzeige-Elementen zusammen und schickt sie als Pakete an den Client. Der Java-Client kennt diese Elemente und kann sie darstellen.
Die Übersetzungsschicht für Bedrock übersetzt Standardinhalte. Sie kann kein Konstrukt aus dutzenden Anzeige-Elementen in etwas übersetzen, das der Bedrock-Client versteht — dort gibt es dieses Konzept nicht.
Was der Bedrock-Client kann: eigene Wesen mit eigener Geometrie darstellen, wenn sie in einem Bedrock-Paket definiert sind und die Übersetzungsschicht sie kennt.
Das ist der Weg. Er bedeutet: Die Modelle müssen umgerechnet werden — von Java-Anzeige-Elementen in echte Bedrock-Geometrie.
Die vier Teile
Die Lösung besteht aus vier Bausteinen, und das Unangenehme ist: Fehlt einer, passiert stillschweigend gar nichts. Keine Fehlermeldung, keine Warnung. Die Objekte bleiben unsichtbar, genau wie vorher.
1. Ein Umrechner. Er liest die Modelldateien und erzeugt daraus Bedrock-Geometrie und -Animationen.
2. Ein Bedrock-Paket, das diese Geometrien enthält, samt einer Liste der Kennungen.
3. Eine Erweiterung für die Übersetzungsschicht, die diese Kennungen anmeldet. Ohne Anmeldung verwirft die Übersetzungsschicht das Paket.
4. Eine Verbindung zwischen Server und Übersetzungsschicht, über die der Server mitteilt, welches Objekt gerade wo steht.
Die drei kontraintuitiven Stellen
Die Anmeldung geht nur auf der Proxy-Seite. Nicht vom Spielserver aus. Wer die Kennungen dort registrieren will, sucht vergeblich nach einer Schnittstelle.
Die Reihenfolge der Erweiterungen ist nicht zugesichert. Wer sich zu spät anmeldet, wird eingetragen, aber nicht mehr verarbeitet. Erkennbar ist das an einer Zahl im Protokoll: Die Übersetzungsschicht meldet beim Start, wie viele eigene Wesen definiert sind. Ist die Zahl zu klein, ist die Anmeldung zu spät gekommen. Diese Zahl ist die einzige verlässliche Rückmeldung im ganzen Vorgang — ich habe sie mir als Prüfwert notiert.
Ein unsichtbarer Träger bleibt auch als eigenes Wesen unsichtbar. Die Modelle hängen an einem Träger-Objekt, das auf Java-Seite unsichtbar gemacht wird. Die Zuordnung tauscht die Gestalt aus — nicht die Sichtbarkeit. Wer das nicht bedenkt, meldet alles korrekt an und sieht weiterhin nichts.
Warnung
Bei der Umrechnung gibt es eine Achsenspiegelung zwischen den beiden Welten. Sieht ein Objekt auf Bedrock spiegelverkehrt aus, liegt es daran — und die Spiegelung ist für Geometrie und Animation zugleich zu ändern. Wer nur eines von beiden anfasst, bekommt ein Modell, dessen Teile sich in die falsche Richtung bewegen. Das war der Fehler, der mich am längsten gekostet hat, weil das Ergebnis „fast richtig" aussieht.
Die Prüfzahlen, die diesen Aufbau bedienbar machen
Bei einer Kette aus vier Teilen, deren Fehlen zu Stille führt, ist die wichtigste Arbeit, jeden Teil einzeln prüfbar zu machen. Das sind die Stellen, an denen ich messe.
Nach der Umrechnung: Wie viele Modelle wurden erzeugt, wie viele Animationen? Eine Zahl, die man mit der Zahl der Ausgangsdateien vergleichen kann.
Nach dem Paketbau: Enthält das Paket die erwartete Zahl an Geometrien? Ein Blick in das Archiv, kein Client nötig.
Nach dem Start der Übersetzungsschicht: Wie viele eigene Wesen sind angemeldet? Diese Zahl im Protokoll ist die einzige Rückmeldung darüber, ob die Anmeldung rechtzeitig kam.
Im Spiel: Sieht ein Bedrock-Client das Objekt?
Die ersten drei Prüfungen brauchen keinen Spieler und keinen Neustart des Livebetriebs. Erst die vierte braucht einen echten Client — und wenn die ersten drei stimmen, ist die vierte fast immer eine Bestätigung.
Was ich über Bedrock-Grenzen gelernt habe
Nach dieser Arbeit habe ich eine klarere Vorstellung davon, was auf der Bedrock-Seite geht und was nicht.
Geht gut: eigene Wesen mit eigener Geometrie und eigenen Animationen. Eigene Gegenstandsbilder. Menüs als Formulare. Serverseitige Texte.
Geht mit Aufwand: dreidimensionale Gegenstände in der Hand. Rüstungsoptik.
Geht nicht: Anzeigeelemente, wie sie auf Java für Modelle benutzt werden. Anklickbare Chat-Verweise. Eigene Verzauberungen. Anzeigen am Bildschirmrand.
Die mittlere Kategorie ist die, in der die Arbeit steckt. Und die entscheidende Erkenntnis daraus: Auf Bedrock muss alles ausdrücklich vorhanden sein. Es gibt keine Übersetzung von etwas, das aus Bausteinen zusammengesetzt ist — es gibt nur die Möglichkeit, dieselbe Sache noch einmal in Bedrock-Formaten zu beschreiben.
Wer das im Kopf hat, plant Crossplay-Server anders: Mechanik überall, Optik dort, wo man bereit ist, sie zweimal zu bauen.
Was ich daraus mitnehme
Die Frage „unterstützt das Bedrock?" ist bei Minecraft-Plugins fast immer mit nein zu beantworten — und der Nachweis dauert zehn Minuten. Ein Blick in die Datei ist billiger als ein Nachmittag Ausprobieren.
Wenn eine Kette aus vier Teilen besteht und ein fehlendes Teil zu Stille führt, braucht man eine Prüfzahl. Ohne die Zahl im Protokoll hätte ich nicht sagen können, welcher der vier Teile klemmt.
Doppelte Pflege ist der Preis für Crossplay mit eigener Optik. Das war mir vorher theoretisch klar. Praktisch heißt es: Jedes Modell existiert zweimal, in zwei Formaten, und beide müssen zusammenpassen.