Zum Hauptinhalt springen

Geyser-Erweiterung & benutzerdefinierte Bedrock-Entities

Die Konvertierung des Ressourcenpakets verschafft Bedrock-Spielern die richtigen Texturen und Modelle für Items. Damit sie echte benutzerdefinierte Entities bekommen — einen modellierten Boss, der gerendert und animiert wird, statt als Armor Stand zu erscheinen — muss Code innerhalb von Geyser selbst laufen. Genau das macht die Geyser-Erweiterung von RSPM.

Du lädst sie nicht separat herunter. Dieselbe ResourcePackManager.jar, die du als Plugin installierst, ist die Erweiterung.

Eine Jar, drei Rollen​

ResourcePackManager.jar ist gleichzeitig:

  • das Bukkit-/Paper-Backend-Plugin,
  • das Velocity- und BungeeCord-/Waterfall-Proxy-Plugin,
  • und eine Geyser-Erweiterung.

Welcher Loader sie auch öffnet, sie wählt den passenden Einstiegspunkt. Ältere Releases lieferten eine separate ResourcePackManager-GeyserBridge.jar aus; diese Datei ist ausgemustert und RSPM räumt Überbleibsel automatisch auf.

Wie sie installiert wird​

RSPM installiert die Erweiterung für dich, wo immer es kann. Was passiert, hängt davon ab, wo Geyser läuft:

Dein SetupWas RSPM tut
Geyser-Spigot auf demselben ServerKopiert die laufende Jar nach plugins/Geyser-Spigot/extensions/ResourcePackManager.jar. Liegt dort bereits eine andere Version, wird die neue stattdessen über Geysers eigene Update-Warteschlange unter extensions/update/ bereitgestellt. In beiden Fällen erhältst du eine Konsolenzeile mit der Bitte um einen einmaligen Neustart.
Geyser auf dem Proxy (Geyser-Velocity / Geyser-BungeeCord)Die Proxy-Rolle macht dasselbe im Ordner Geyser-*/extensions/ des Proxys.
Floodgate lokal, Geyser extern (Geyser läuft in einem separaten Prozess)RSPM kann diesen Prozess nicht erreichen. Es exportiert eine Kopie nach plugins/ResourcePackManager/geyser-extension/ und warnt dich, genau diese Jar in den extensions/-Ordner des externen Geyser zu kopieren und Geyser neu zu starten.
Weder Geyser noch Floodgate vorhandenNichts zu tun — RSPM protokolliert eine Informationszeile und überspringt die Installation.

Eine neuere Version, die bereits in extensions/ liegt, wird niemals von einer älteren überschrieben.

Die Installation erfordert immer einen Neustart. Geyser lädt Erweiterungen beim Start, daher bewirkt eine frisch kopierte oder bereitgestellte Jar nichts, bis der Server oder Proxy neu startet.

Die automatische Installation abschalten​

Jede Rolle hat ihren eigenen Schalter, und sie sind voneinander unabhängig:

WoEinstellungStandard
Backend plugins/ResourcePackManager/config.ymlgeyserExtensionAutoInstalltrue
Proxy config.ymlgeyser-extension-auto-installtrue

Einen der beiden auf false zu setzen hindert diese Rolle daran, die Erweiterung zu installieren oder ein Update dafür bereitzustellen, und sie protokolliert eine entsprechende Zeile. Lies die Semantik genau:

  • Es verhindert künftige Installationen und Update-Bereitstellungen.
  • Es entfernt keine Erweiterungs-Jar, die bereits in extensions/ liegt. Geyser hat diese Datei geöffnet. Um die Bridge wirklich zu deaktivieren, setze das Flag auf false, stoppe Geyser, lösche die RSPM-Jar von Hand aus extensions/ und starte es wieder.
  • Das Abschalten hat keine Auswirkung auf die Paketkonvertierung oder die Paketauslieferung. Items, Texturen und Modelle werden weiterhin konvertiert und ausgeliefert; nur benutzerdefinierte Bedrock-Entities funktionieren dann nicht mehr.

Es auf dem Backend abzuschalten überspringt außerdem das Bereitstellen eines heruntergeladenen RSPM-Updates in der Update-Warteschlange eines lokalen Geyser-Spigot, sodass Erweiterung und Plugin in ihrer Version auseinanderdriften können — genau der Zustand, den der Kompatibilitätsschutz weiter unten abfangen soll.

Was die Erweiterung tatsächlich tut​

  • Registriert RSPMs benutzerdefinierte Bedrock-Entity-Definitionen bei Geyser beim Start, indem sie die Entity-Identifikatoren aus dem erzeugten Bedrock-Paket ausliest.
  • Tauscht die Bedrock-Definition spawnender Entities aus, sodass eine modellierte Entity als ihre benutzerdefinierte Bedrock-Entity spawnt statt als Vanilla-Fallback.
  • Wendet Live-Entity-Daten und Property-Overrides an, solange die Entity existiert.
  • Initialisiert Geysers Rezept-Netzwerk-IDs frühzeitig, was eine Klasse von Problemen mit kollidierenden Rezept-IDs auf Geyser 2.11 vermeidet.

Die Bedrock-seitigen Assets, auf die diese Definitionen verweisen, stammen aus den Entity-Bundles, die unter Bedrock-Konvertierung beschrieben sind — ein Plugin liefert native Bedrock-Entity-Dateien unter assets/<namespace>/rspm_bedrock_pack/ aus, und RSPM übernimmt sie in das erzeugte Paket.

Geyser-Versionsanforderungen​

Die Erweiterung zielt auf Geyser 2.11+.

Ihr Deskriptor deklariert bewusst ein niedrigeres Geyser-API-Level (2.9.0), sodass ein älteres Geyser sie bereitwillig lädt, statt die Jar rundweg abzulehnen. Die eigentliche Anforderung wird zur Laufzeit durchgesetzt: Die Erweiterung prüft, ob die benötigten Klassen vorhanden sind, und deaktiviert sich, wenn sie fehlen — das ergibt eine klare Meldung statt einer Ladezeit-Ablehnung, die ein Betreiber nicht deuten kann.

Sie ist so ausgelegt, dass sie bei Klassen-/Linkage-Inkompatibilität sicher abschaltet, statt Geyser mit in den Abgrund zu reißen. Die Erweiterungs-Hülle referenziert nur langjährig stabile Geyser-API-Typen; versionsabhängige Klassen werden geprüft, bevor der Kern startet. Liefert dein Geyser-Build eine Klasse nicht mit, die die Bridge benötigt, deaktiviert sich die Bridge selbst und meldet das:

Disabled the RSPM custom Bedrock entity bridge: this Geyser build does not ship <class>. Geyser itself is unaffected, but custom Bedrock entities will not appear until a ResourcePackManager update matches this Geyser version.

Items, Texturen und Modelle werden in diesem Zustand weiterhin normal konvertiert und ausgeliefert — betroffen sind nur benutzerdefinierte Entities. Die Lösung ist, Geyser zu aktualisieren oder auf das RSPM-Release zu warten, das zu deinem Geyser-Build passt.

Frühere RSPM-Versionen erreichten dasselbe Ergebnis, indem sie eine mitgelieferte Kopie eines von Geysers internen Paket-Übersetzern in Geysers Registry einschleusten. Dieser Übersetzer-Austausch ist Geschichte: Die Erweiterung nutzt jetzt die öffentlichen Entity-Lebenszyklus-/Events von Geyser 2.11 für Registrierung und den Austausch der Spawn-Definition. Der Kern prüft weiterhin eine begrenzte Menge an Geyser-Internas, die zum Erzeugen von Definitionsinstanzen und zum Empfang nachgelagerter Plugin-Nachrichten verwendet werden — deshalb sind der Kompatibilitätsschutz und die exakte Übereinstimmung der RSPM-/Geyser-Versionen weiterhin wichtig.

Reihenfolge: Warum manchmal ein Neustart nötig ist​

Geyser registriert Entity-Definitionen während seines eigenen Startfensters. Wenn RSPM die Erzeugung des Bedrock-Pakets nach dem Schließen dieses Fensters abschließt — was bei einer brandneuen Installation genau der Fall ist, weil beim Booten noch kein Paket existiert —, kommen die Definitionen zu spät, um noch in Geysers eingefrorene Registries zu gelangen. RSPM hebt sie für den nächsten Start auf und warnt dich:

RSPM custom Bedrock entity definitions became available after Geyser closed its startup registration windows ... restart the proxy once to activate the newly generated custom models.

Starte den Server- oder Proxy-Prozess, der Geyser beherbergt, nach der ersten erfolgreichen Paketerzeugung einmal neu. Ein bloßes Neuverbinden kann Definitionen, die das Startfenster verpasst haben, nicht aktivieren. Bei nachfolgenden Boots stimmt die Reihenfolge, weil das Paket bereits existiert, wenn Geyser seine Registrierungsfenster öffnet.

Überprüfen, ob es funktioniert​

  1. Prüfe, ob der Ziel-Ordner extensions/ tatsächlich ResourcePackManager.jar enthält.
  2. Beim Booten sollte Geyser die Erweiterung als geladen auflisten, und RSPM protokolliert, wie viele benutzerdefinierte Bedrock-Entity-Definitionen es registriert hat.
  3. Verbinde dich über Bedrock und sieh dir eine modellierte Entity an. Armor Stands statt Modellen bedeuten entweder, dass die Erweiterung nicht geladen ist, dass das Paket den Client nicht erreicht hat oder dass die Definitionen zu spät kamen — prüfe die obigen Warnungen in dieser Reihenfolge.

Fehlerbehebung​

„Erweiterung geladen, aber Entities sind immer noch Armor Stands." Das Paket und die Erweiterung sind zwei getrennte Hälften. Vergewissere dich zuerst, dass das Bedrock-Paket selbst den Client erreicht hat (siehe Bedrock-Konvertierung); ohne die Entity-Assets des Pakets gibt es für die Definitionen nichts zu rendern.

„Es hat funktioniert, dann habe ich Geyser aktualisiert und die Entities waren kaputt." Halte nach der oben genannten Selbstdeaktivierungs-Meldung Ausschau. Ein Geyser-Update kann die API-Oberfläche verschieben, nach der die Bridge sucht.

„Es wurde nie etwas in extensions/ installiert." Sieh in der Konsole nach Automatic Geyser extension installation is disabled by geyserExtensionAutoInstall (Backend) oder ... by geyser-extension-auto-install (Proxy). Jemand hat den Schalter abgeschaltet. Sind Geyser und Floodgate beide lokal nicht vorhanden, siehst du stattdessen Geyser-Spigot and Floodgate were not detected locally; skipping automatic Geyser extension installation — das ist RSPM, das korrekt entscheidet, dass es nichts gibt, worin installiert werden könnte.

„Ich habe RSPM aktualisiert, aber die Erweiterung ist immer noch die alte Version." Die Erweiterung wird nur beim Neustart ersetzt, und wenn RSPM sie über Geysers Update-Warteschlange bereitgestellt hat, braucht es einen Neustart, damit sie eingewechselt wird. Halte die Plugin-Jar und die Erweiterungs-Jar auf derselben Version — es ist dieselbe Datei, also genügt es, das Plugin erneut zu kopieren.

Auf Velocity greift Geysers automatisches Erweiterungs-Abonnement nicht so wie auf anderen Plattformen, daher leitet das Proxy-Plugin die Lebenszyklus-Events selbst weiter. Das wird intern gehandhabt und erfordert keine Konfiguration.

Nächste Schritte​