Zum Hauptinhalt springen

Java-zu-Bedrock-Konvertierung

ResourcePackManager kann das zusammengeführte Java-Ressourcenpaket in ein Bedrock-Ressourcenpaket umwandeln, damit GeyserMC-Clients unterstützte benutzerdefinierte Inhalte aus dem Java-Paket sehen. Diese Funktion ist standardmäßig aktiviert.

Wann die Konvertierung läuft​

Die Konvertierung ist daran gebunden, dass ein Bedrock-Ziel vorhanden ist. RSPM betrachtet ein Ziel als vorhanden, wenn eines der folgenden zutrifft:

  1. Geyser-Spigot ist auf diesem Backend installiert (Bedrock-Spieler treffen lokal auf Geyser).
  2. Floodgate ist auf diesem Backend installiert (typisches Proxy-Backend-Setup — Floodgate läuft lokal, Geyser ist anderswo).
  3. Der Netzwerkmodus ist aktiv — RSPM hat erkannt, dass es hinter einem Velocity-/BungeeCord-Proxy läuft. Das Backend erzeugt sein Bedrock-Paket und stellt es über einen kleinen HTTP-Server bereit, damit das Proxy-Plugin es abholen kann.

Die Konvertierung muss außerdem mit bedrockConversionEnabled aktiviert sein. Ist sie deaktiviert oder fehlt ein Ziel, zieht RSPM eine vorherige Bedrock-Ausgabe zurück und überspringt die Konvertierung. /rspm status zeigt, warum das Paket nicht erzeugt wurde.

Was konvertiert wird​

Der Konverter ist namespace-agnostisch. Er durchläuft jede assets/<namespace>/items/**/*.json-Datei im Items-Definitionsformat 1.21.4+, rekursiv und einschließlich des minecraft-Namespace.

Auswahl zwischen flacher Darstellung und 3D​

Für jedes Blattmodell entscheidet der Konverter, welche von zwei Pipelines verwendet wird. Modelle, die auf minecraft:item/generated oder minecraft:builtin/generated zurückgehen, bleiben auf dem flachen Pfad. Bei jeder anderen Elternkette geht ein Modell nur dann durch die 3D-Pipeline, wenn das zusammengeführte Modell ein nicht-leeres elements-Array trägt; ein Modell ohne Geometrie ist ein 2D-Sprite.

  • Flach — die layer0-Textur des Modells wird direkt nach textures/items/<hash>.png kopiert und als Geyser-Symbol registriert. Bedrock verwendet diese Ebene als 2D-Sprite im Inventar und in der Hand; beliebige zusätzliche Java-Ebenen oder Modellzweige bleiben dadurch nicht erhalten.
  • 3D — der Konverter fügt einen Texturatlas zusammen, konvertiert die Java-Quader in Bedrock-Geometrie, erzeugt Halte-/Kopf-Animationen, rendert softwareseitig ein 64×64-Inventarsymbol und schreibt ein Attachable pro Zuordnung (Modell × Basis-Item × Item-Definition × Prädikatform).

Warum die Geometrieprüfung wichtig ist: Ein flaches handgeführtes Werkzeug (Elternteil minecraft:item/handheld mit nur einer layer0-Textur und ohne Elemente) ist trotzdem ein 2D-Sprite. Frühere Versionen schoben flache handgeführte Items in die 3D-Pipeline, wo sie am Geometrieschritt scheiterten und auf Bedrock verschwanden oder auf das Vanilla-Basis-Item-Symbol zurückfielen. Besonders betroffen waren ItemsAdder-Pakete, die viele flache handgeführte Items ausliefern. Da elements aus der zusammengeführten Elternkette gelesen wird, wird ein nicht-generiertes Modell, das seine Geometrie von einem Elternteil erbt, weiterhin nach 3D geleitet.

RSPM leitet für jede Zuordnung (Modell × Basis-Item × Item-Definition × Prädikatform) einen Bedrock-Identifikator ab. So werden die verschiedenen Basis-Item- und Prädikatvarianten eines Schwertmodells getrennt, und zwei Item-Definitionen, die dasselbe Modell verwenden, erhalten getrennte Identifikatoren. Erzeugte Dateinamen verwenden kurze Hashes der Quellidentifikatoren, nicht der Dateiinhalte, um Geysers Warnung bei Paketpfaden ab 80 Zeichen zu vermeiden.

Unterstützte Item-Modellzweige​

Die Konvertierung unterstützt Knoten vom Typ model, condition, range_dispatch und select, jeweils mit oder ohne Präfix minecraft:. Andere Knotentypen, darunter composite und special, werden übersprungen. Dass ein Java-Paket korrekt dargestellt wird, bedeutet nicht, dass sich jeder Zweig auf Bedrock abbilden lässt.

KnotenUnterstützte Properties und Fallback-Verhalten
conditionbroken, damaged, fishing_rod_cast, has_component, custom_model_data. Bei using_item bleibt nur on_false als Ruhemodell erhalten. Bei anderen nicht unterstützten Bedingungen werden beide Zweige übersprungen.
range_dispatchdamage, count, bundle_fullness, custom_model_data. Bei use_duration und anderen nicht unterstützten Properties bleibt nur fallback erhalten, sofern vorhanden.
selectcharge_type, trim_material, context_dimension, custom_model_data. Bei display_context bleibt der Fall gui erhalten oder dessen Fallback, wenn kein GUI-Fall existiert. Bei anderen nicht unterstützten Properties bleibt nur ihr Fallback erhalten.

Damit bleiben Java-Bogenspannstufen und getrennte Modelle pro Anzeigekontext nicht automatisch bei der Konvertierung erhalten. Aktiviere bedrockConverterDebug, um Meldungen zu übersprungenen Knoten und Properties zu sehen, und prüfe das erzeugte Item in einem Bedrock-Client.

Veraltete Pakete vor 1.21.4​

Der Scanner für das alte Format liest JSON-Dateien direkt in assets/minecraft/models/item/ und erzeugt Range-Dispatch-Definitionen aus Overrides mit einem numerischen predicate.custom_model_data. Er durchsucht keine Unterordner des alten Formats und übernimmt keine weiteren Prädikate des Overrides. Ein Override, der zusätzlich vom Spannzustand eines Bogens abhängt, verliert beispielsweise diese Bedingung. Die Anzahl der alten Items erscheint nur bei aktiviertem bedrockConverterDebug. Verwende für gepflegte Pakete das Item-Definitionsformat ab 1.21.4 und prüfe seine Zweige anhand der obigen Unterstützungstabelle.

Basis-Items​

Geyser ordnet jedes benutzerdefinierte Item einem oder mehreren Java-Basis-Items zu. RSPM wählt sie so aus:

  • Eine Override-Datei im alten Format und eine Definition assets/minecraft/items/<item>.json auf oberster Ebene werden diesem Vanilla-Item zugeordnet.
  • Andere Definitionen werden anhand ihres Dateinamens zugeordnet. Waffen- und Werkzeugbegriffe verweisen auf verwandte Vanilla-Items: sword auf die sechs Schwerter, pickaxe auf die sechs Spitzhacken, wand oder staff auf minecraft:stick, spear auf minecraft:trident und so weiter. Rüstungsnamen verwenden die Ausrüstungsdatei des Namespace oder Slot-Begriffe wie helmet und boots. Alles andere verwendet einen Ersatzsatz: Papier, Stock, Namensschild, Kompass und die sechs Schwerter.
  • Definitionen im Namespace freeminecraftmodels werden zusätzlich unter minecraft:leather_horse_armor zugeordnet, dem Item, das FreeMinecraftModels zur Darstellung von Modell-Bones verwendet.
  • Ein erzeugendes Plugin kann die echten Basis-Items in assets/<namespace>/rspm_item_bases/<path>.json deklarieren, wobei <path> zu items/<path>.json passt. Die Datei enthält {"base_items": ["minecraft:blaze_rod"]}. Nur minecraft:-IDs werden gelesen, und sie werden zur Auswahl anhand des Dateinamens hinzugefügt. FreeMinecraftModels schreibt eine solche Datei für jedes benutzerdefinierte Item mit dem Material, das seine Konfiguration nennt, sodass ein Zauberstab auf BLAZE_ROD sein Modell auf Bedrock darstellt.

Reine Java-Items​

Ein erzeugendes Plugin kann Items aus der Konvertierung heraushalten, indem es eine Datei unter assets/<namespace>/rspm_item_java_only/<path>.json ablegt. Es zählt nur, dass die Datei existiert. Sie schließt items/<path>.json und jede Item-Definition unter items/<path>/ aus, sodass diese Items weder ein Geyser-Mapping noch ein Symbol oder Attachable erhalten. FreeMinecraftModels verwendet das für die Sprite-Items hinter seinen Partikeleffekten, die nur von Java-Item-Displays genutzt werden; Bedrock-Spieler sehen stattdessen den nativen Partikel. Ein Paket, dessen Items alle reine Java-Items sind, löst die Warnung zum alten Format nicht aus.

Handgeschriebene Bedrock-Entity-Bundles​

Ein Plugin kann native Bedrock-Entity-Ressourcen unter assets/<namespace>/rspm_bedrock_pack/ in seinem Java-Paket ablegen. RSPM importiert die Dateien in das erzeugte Bedrock-Paket. Erlaubt sind nur Entity-Verzeichnisse (entity, models/entity, animations, animation_controllers, render_controllers, materials, particles, textures/entity), sodass das Plugin weder Manifest noch Symbolatlas ersetzen kann. Unterstützte Pfade ab 80 Zeichen werden gekürzt und exakte JSON-Pfadverweise innerhalb dieses Bundles angepasst. Andere Dateien werden wie geliefert kopiert. Erzeugen zwei Namespaces unterschiedliche Bytes am selben Ziel, schlägt der Import fehl.

Das ist der Mechanismus hinter echten benutzerdefinierten Bedrock-Entities — siehe Geyser-Erweiterung & benutzerdefinierte Entities. Ein Paket, das nur Entity-Bundles und null Item-Mappings enthält, wird trotzdem ausgeliefert.

Die Konvertierung getragener Rüstung läuft auf dem flachen Item-Pfad für ein Rüstungs- oder Elytra-Basis-Item. Sie entfernt ein erkanntes Slot-Suffix vom Dateinamen der Item-Definition, um <material> abzuleiten, und sucht dann assets/<namespace>/equipment/<material>.json im Namespace des Blattmodells. Verwendet wird die erste Texturebene aus humanoid, bei Beinschutz aus humanoid_leggings oder bei Elytren aus wings, falls vorhanden. Die zugehörige PNG muss im zusammengeführten Paket liegen. Das erzeugte Attachable verwendet die Vanilla-Rüstungsgeometrie von Bedrock. Eine Ausrüstungsdatei allein, zusätzliche Texturebenen oder eine davon unabhängige Ausrüstungs-Asset-ID garantieren keine Rüstungskonvertierung.

Die Header-/Modul-UUIDs im Manifest des Bedrock-Pakets werden deterministisch aus dem Versionsstring des Plugins abgeleitet (Seeds rspm_bedrock_header:<pluginVersion> und rspm_bedrock_module:<pluginVersion>), sodass sie über Rebuilds derselben Plugin-Version stabil bleiben und sich nur ändern, wenn sich die Plugin-Version ändert. Der sichtbare Header-Name ist das feste ResourcePackManager Bedrock Pack; er ist nicht Teil der UUID. Das Versions-Tripel wird pro Build aus einem Cache-Bust-Token hochgezählt, das aus einem SHA-256-Inhalts-Digest des bereitgestellten Bedrock-Pakets abgeleitet wird — identische Inhalte ergeben dieselbe Version (sodass No-Op-Rebuilds Geysers Cache nicht aufwirbeln), während echte Inhaltsänderungen Bedrocks über (uuid, version) indizierten Paket-Cache invalidieren. Die Build-Zeit (System.currentTimeMillis()) wird nur als Fallback verwendet, wenn der Inhalts-Digest nicht berechnet werden kann.

Live-Auslieferung pro Session (eigenständig)​

Bei aktivierter Konvertierung und Geyser-Spigot auf demselben eigenständigen Backend registriert RSPM einen SessionLoadResourcePacksEvent-Subscriber. Er bietet jedem beitretenden Spieler das neueste freigegebene Bedrock-Paket von der Festplatte an. Textur- oder Geometrieänderungen können beim nächsten Beitritt ohne Serverneustart ankommen, wenn die registrierten Item-Mappings unverändert bleiben. Backends im Netzwerkmodus überlassen die Auslieferung dem Proxy, selbst wenn Geyser-Spigot zusätzlich lokal installiert ist.

Geysers Custom-Item-Mappings, die JSON-Datei in custom_mappings/, werden beim Start festgelegt. Neue oder entfernte Items, geänderte Modellverweise und geänderte Prädikate können neue Mappings und damit einen Neustart erfordern. Bei aktiviertem Auto-Deploy stellt RSPM die vorherige freigegebene Mapping-Datei früh beim Start bereit. Starte Geyser nach der ersten erfolgreichen Konvertierung neu, um die neu erzeugten Mappings zu laden, und verbinde anschließend den Bedrock-Client erneut.

Aktuell verbundene Bedrock-Spieler behalten das Paket, das sie zum Zeitpunkt ihres Beitritts erhalten haben — das ist eine Einschränkung des Bedrock-Protokolls, nichts, was das Plugin mitten in der Session überschreiben kann.

Wie es im Proxy-Modus funktioniert​

In einem Proxy-Netzwerk registriert das Backend selbst keinen SessionLoadResourcePacks-Subscriber (es gibt kein lokales Geyser, bei dem man sich registrieren könnte). Stattdessen:

  1. Das Backend erzeugt output/ResourcePackManager_Bedrock.zip und, sofern Item-Mappings existieren, output/rspm_geyser_mappings.json.
  2. Das Backend startet einen kleinen HTTP-Server (automatisch abgeleiteter Port, standardmäßig mcPort + 1), der die Routen /bedrock.zip und /mappings.json bereitstellt, die bei jeder Anfrage die Datei frisch einlesen, und kündigt dem Proxy den genauen Port an, an den es gebunden hat.
  3. Das Proxy-Plugin pollt alle 5 Sekunden, bevorzugt starke ETags über If-None-Match und behält die If-Modified-Since-Kompatibilität für ältere Backends bei. Es lädt die Ausgaben jedes Backends herunter, wenn sie sich ändern, und wartet, bis der Posteingang stabil ist.
  4. Das Proxy-Plugin führt das Bedrock-Paket jedes Backends zu einem einzigen netzwerkweiten Paket zusammen und liefert es über das Geyser des Proxys an Bedrock-Clients aus.
  5. Wenn der Proxy den HTTP-Port eines Backends nicht direkt erreichen kann (häufig bei Shared-/Managed-Hosting, wo benachbarte Ports durch eine Firewall blockiert sind), schiebt das Backend seine Dateien an einen magmaguy.com-Relay-Endpunkt, und der Proxy holt sie dort ab.

Siehe Proxy-Netzwerke für die Einrichtung. Das Zusammenführen auf der Proxy-Seite läuft automatisch und hat keinen Aktivierungsschalter. Die Proxy-Konfiguration hat nur zwei Einstellungen: network-http-offset-v2, den Fallback-Port-Offset, der verwendet wird, bevor eine Endpunkt-Ankündigung eines Backends vorliegt, und geyser-extension-auto-install, das proxy-seitige Gegenstück zu geyserExtensionAutoInstall.

Ausgabedateien​

Nach einem erfolgreichen Mix liegen die Bedrock-Dateien in:

plugins/ResourcePackManager/output/ResourcePackManager_Bedrock.zip
plugins/ResourcePackManager/output/rspm_geyser_mappings.json  # only when item mappings exist

Wenn Auto-Deploy aktiviert ist und ein lokaler Geyser-Datenordner erkannt wurde, wird die Mapping-Datei zusätzlich kopiert nach:

<geyser-folder>/custom_mappings/rspm_geyser_mappings.json

Die Bedrock-Paket-ZIP wird nicht nach <geyser-folder>/packs/ kopiert — sie wird stattdessen live pro Session ausgeliefert. Wenn ein älteres RSPM-Release eine ResourcePackManager_Bedrock.zip in Geysers Paketverzeichnis hinterlassen hat, löscht das aktuelle Plugin sie nicht, während Geyser läuft: Geyser hat diesen Pfad bereits gescannt und hält die Datei möglicherweise noch im Speicher. RSPM überspringt für diesen Boot die Registrierung des Live-Providers und gibt den genauen Altpfad aus. Fahre den Server vollständig herunter, lösche nur diese Altdatei und starte den Server dann wieder. Ein /reload genügt nicht.

Gibt es keine konvertierbaren Item-Mappings und keine erlaubten Entity-Dateien, zieht RSPM die Veröffentlichung zurück und versucht, frühere lokale Ausgaben sowie sein in Geyser bereitgestelltes Mapping zu löschen. Eine gesperrte zurückgebliebene Datei bleibt nicht zur Auslieferung freigegeben. Die Backend-Route /bedrock.zip liefert 404, um anzuzeigen, dass dieses Backend keinen Bedrock-Inhalt beiträgt. Reine Entity-Pakete werden weiterhin veröffentlicht. Einfache Java-Block- oder Vanilla-Texturersetzungen erzeugen kein konvertiertes Paket; dafür ist ein separat erstelltes Bedrock-Paket nötig.

Beim Abgleich nach dem Deaktivieren von bedrockAutoDeployToGeyser entfernt RSPM sein zuvor bereitgestelltes Mapping. Eine Änderung von bedrockGeyserFolder bereinigt auch das zuvor von RSPM verwaltete Ziel. Beides ändert keine Mappings, die ein laufendes Geyser bereits geladen hat. Starte Geyser neu, um den neuen Mapping-Satz anzuwenden.

Einstellungen in config.yml​

# Toggles Java-to-Bedrock conversion altogether.
bedrockConversionEnabled: true

# Copies the Geyser custom mappings file into the detected Geyser folder's
# custom_mappings/ directory on each mix.
bedrockAutoDeployToGeyser: true

# Manual override for the Geyser data folder. Empty = auto-detect.
# Relative values are tried from the server working directory first, then
# relative to plugins/. Absolute paths work directly.
bedrockGeyserFolder: ""

# Installs and updates the universal ResourcePackManager.jar in Geyser's
# extensions/ folder, which is what makes custom Bedrock ENTITIES render
# instead of armor stands. Separate from pack conversion above — items,
# textures and models convert and serve normally either way.
# Setting this false stops future installation and update staging; it does NOT
# remove an extension jar that is already installed. Delete that by hand while
# Geyser is stopped. See the Geyser extension page.
geyserExtensionAutoInstall: true

# Verbose per-item / per-bone progress logging from the Bedrock pipeline.
# Default false — a clean run emits a single "Bedrock conversion complete: N
# mappings" summary instead of dozens to hundreds of per-item lines. Flip on
# when debugging a specific conversion issue.
bedrockConverterDebug: false

Die automatische Erkennung des Geyser-Ordners prüft in dieser Reihenfolge:

  1. bedrockGeyserFolder, falls gesetzt (wird zuerst genau so verwendet, wie er geschrieben steht, sodass relative Pfade vom Arbeitsverzeichnis des Servers aus aufgelöst werden; existiert der nicht, wird er relativ zu plugins/ versucht). Absolute Pfade funktionieren ebenfalls.
  2. plugins/Geyser-Spigot/
  3. plugins/Geyser-*/ (jede Variante)
  4. config/Geyser-*/ (für Fabric-/NeoForge-Setups)

Posen gehaltener Items​

Jedes 3D-Attachable erhält Animationen für die Ego-Perspektive, die Third-Person-Perspektive und den Kopf. Die Halteposen stammen aus den Transformationen display.firstperson_righthand und display.thirdperson_righthand des Java-Modells. RSPM bildet jede Transformation über das Vanilla-Spieler-Rig von Bedrock ab, sodass das gehaltene Modell dort landet, wo Java es zeichnet, mit derselben Position, Ausrichtung und Skalierung pro Achse. Ein Slot, den das Modell nicht definiert, verwendet die Identitätstransformation von Java. Die Kopfanimation stammt aus display.head.

Es gibt nichts einzustellen. Um zu ändern, wie ein Item in der Hand liegt, ändere die display-Transformationen des Java-Modells; Java und Bedrock folgen dann denselben Werten. Das Rig verwendet den breiten Arm (Steve), daher kann Bedrock bei Skins mit schmalen Armen um einen halben Pixel von Java abweichen.

Frühere Versionen fügten von Hand eingestellte Offsets aus plugins/ResourcePackManager/bedrock_display_offsets.yml hinzu. Diese Datei und ihre Einstellungen firstPerson* und thirdPerson* werden nicht mehr gelesen, und RSPM erzeugt zwischengespeicherte Bedrock-Pakete nach dem Update neu. Eine alte Kopie der Datei kann gelöscht werden.

Partikel gehaltener Items​

Ein erzeugendes Plugin kann einem gehaltenen 3D-Item über eine Begleitdatei unter assets/<namespace>/rspm_item_particles/<model path>.json Partikel anhängen, wobei <model path> der Pfad des gehaltenen Java-Modells ist (display/wand für freeminecraftmodels:display/wand). Die Begleitdatei ordnet Effektnamen Partikelbezeichnern zu, die das Plugin in seinem Entity-Bundle ausliefert, listet Locators in Java-Modellpixeln auf und enthält eine geloopte Partikel-Timeline. RSPM fügt die Locators der Item-Geometrie hinzu und spielt die Timeline als zusätzliche Attachable-Animation ab, sodass Bedrock-Clients die Partikel in der Ego- und der Third-Person-Perspektive an der Hand zeichnen. FreeMinecraftModels schreibt diese Begleitdateien für Items mit Partikeleffekten. Eine nicht lesbare Begleitdatei wird mit einer Warnung übersprungen.

Debug-Protokollierung​

Es stehen zwei Debug-Oberflächen zur Verfügung:

  • Backend: bedrockConverterDebug: true in der config.yml aktiviert Protokollzeilen des Konverters pro Item, pro Attachable und pro Mapping. Nützlich, wenn du wissen musst, warum ein bestimmtes Item nicht ins Bedrock-Paket gelangt ist. Das ist getrennt von verboseLogging, das das Zusammenführen und Hosten von Paketen abdeckt statt der Bedrock-Pipeline — bei einem Konvertierungsproblem willst du bedrockConverterDebug.
  • Proxy (Velocity und BungeeCord): /rspm debug bedrock on schaltet den [RSPM-BedrockDebug]-Log-Stream um, der vom GeyserBinder des Proxys ausgegeben wird. Nützlich, wenn Bedrock-Spieler den Proxy betreten, aber das Paket nicht sehen. Die Einstellung wird bei einem Proxy-Neustart auf „aus" zurückgesetzt, damit sie nicht versehentlich aktiviert bleiben kann.

Einschränkungen und bekanntes Verhalten​

  • 3D-Inventarsymbole werden softwareseitig aus der display.gui-Transformation des Java-Modells gerendert. Das Ergebnis ist passabel, aber nicht pixelgenau; wenn das Symbol falsch aussieht, ist die häufigste Ursache eine fehlende/falsch benannte Texturdatei, auf die das Modell verweist.
  • Flipbook-Texturen, die als Item-Symbole verwendet werden, werden auf Frame 0 zugeschnitten — Bedrocks item_texture.json unterstützt keine animierten Symbole, sondern nur animierte Block-/Terrain-Texturen über flipbook_textures.json.
  • Die Geometrie-Formatversion von Attachables ist fest auf 1.21.0 festgelegt; aktualisiere Geyser, falls deine Installation sie nicht parsen kann.
  • Veraltete Vanilla-Item-Model-Override-Dateien (alles unter assets/minecraft/models/item/, einschließlich shield.json und crossbow.json) werden paketübergreifend zusammengeführt, statt ein Paket vollständig gewinnen zu lassen: Es werden nur die overrides-Arrays kombiniert (dedupliziert nach Override-Schlüssel), während Nicht-Override-Felder weiterhin „höchste Priorität gewinnt" folgen. Keine Datei wird für eine Sonderbehandlung herausgegriffen.
  • Wenn der Konverter eine referenzierte Textur- oder Modelldatei nicht auflösen kann, wird dieses Blatt übersprungen und die restliche Pipeline läuft weiter. Aktiviere bedrockConverterDebug für detaillierte Auflösungs-Traces. Eine normale Warnung wird ausgegeben, wenn ein Item am Ende überhaupt keine gültigen Custom-Texturen hat oder ein referenziertes Modell-JSON nicht geparst werden kann.
  • Nicht parsbares Item-Definitions-JSON bricht die Konvertierung mit Bedrock conversion failed: ... ab. Gültiges JSON ohne Modell oder mit einem nicht unterstützten Knoten kann dagegen mit einer Debug-Meldung übersprungen werden. Prüfe den Fehler und die erzeugte Mapping-Anzahl; nicht jede übersprungene Definition ist ein fataler Parserfehler.
  • Banner- und Redstone-Basis-Items werden übersprungen. Benutzerdefinierte Items, deren Basis eines der 16 gefärbten Banner oder minecraft:redstone ist, erhalten kein Geyser-Custom-Item-Mapping, weil Geyser aus diesen Basen einen ungültigen Block-Platzierer ableitet. Bedrock zeigt für sie das Vanilla-Symbol. Die Konsole nennt die betroffenen Items, wenn das passiert.
  • Die Konvertierung ist kooperativ abbrechbar. RSPM bereitet ZIP und Mappings vor und ersetzt die Veröffentlichung als zusammengehörigen Satz. Bei einem Fehler oder Abbruch während der Ersetzung versucht es, den vorherigen Satz wiederherzustellen; ein Konvertierungsfehler vor der Ersetzung zieht die alte Ausgabe zurück. Veröffentlichte Hashes und Satzmetadaten erlauben es den Empfängern, veraltete oder gemischte Generationen abzulehnen. Eine ZIP-Datei auf der Festplatte beweist weder ihre aktuelle Freigabe noch ihre Darstellung durch einen Bedrock-Client.
  • Enthält das zusammengeführte Paket weder konvertierbare Item-Mappings noch erlaubte Entity-Dateien, zieht RSPM die vorherige Veröffentlichung zurück und versucht, ihre Ausgaben zu löschen. Ein reines Entity-Paket wird auch mit null Item-Mappings erzeugt.

Optimierung der Paketgröße​

Bevor RSPM ein Bedrock-Paket veröffentlicht, dedupliziert es byteweise identische Texturdateien mit derselben Dateiendung und schreibt exakte JSON-Texturverweise auf die beibehaltene Datei um. Aliase werden bewusst beibehalten, wenn ein Verweis mehrdeutig ist, in einen größeren String eingebettet ist oder in fehlerhaftem/undurchsichtigem JSON gefunden wird, sodass die Optimierung keine Ressourcenverweise stillschweigend zerstört.