Zum Hauptinhalt springen

FreeMinecraftModels Ressourcenpaket-Ausgabe

FreeMinecraftModels schreibt sein generiertes Paket derzeit nach output, nicht outputs.

Standard-Ausgabepfade

Das Plugin baut diesen Ordner beim Start und bei /fmm reload neu auf:

plugins/FreeMinecraftModels/output/FreeMinecraftModels

Es zippt diesen Ordner anschließend in:

plugins/FreeMinecraftModels/output/FreeMinecraftModels.zip

Dieser Zip-Pfad ist derjenige, den ResourcePackManager erwartet, wenn er sich mit FreeMinecraftModels integriert.

Was generiert wird

Der generierte Ordner enthält immer:

  • pack.mcmeta
  • pack.png
  • assets/minecraft/atlases/blocks.json
  • assets/freeminecraftmodels/... Modell- und Textur-Ausgabe

Für Minecraft 1.21.4+ generiert FreeMinecraftModels Item-Modell-Definitionsdateien unter:

assets/freeminecraftmodels/items

Für ältere Server fällt es auf den Legacy-Pfad für das Leder-Pferderüstungs-Override-Modell zurück.

Display-Modell-Ausgabe (1.21.4+)

Wenn ein Modell eine begleitende .json-Display-Modelldatei hat (siehe Hinweise zur Modellerstellung), kopiert FMM diese JSON (mit Textur-Referenzen, die so umgeschrieben sind, dass sie mit den extrahierten Texturen übereinstimmen) nach:

assets/freeminecraftmodels/models/display/{modelId}.json

Es generiert außerdem eine entsprechende Item-Definition unter:

assets/freeminecraftmodels/items/display/{modelId}.json

Die DisplayModelRegistry verfolgt zur Laufzeit, welche Modelle Display-JSONs haben, sodass ItemMeta.setItemModel() auf ItemStacks aufgerufen werden kann, um ihnen das korrekte Aussehen in der Hand und im Inventar zu geben.

Bedrock-Custom-Entity-Bundle

Neben den Java-Paket-Assets exportiert FreeMinecraftModels für jedes konvertierte Modell ein Bedrock-Custom-Entity-Bundle nach:

plugins/FreeMinecraftModels/output/FreeMinecraftModels/assets/freeminecraftmodels/rspm_bedrock_pack

Jedes Modell steuert seine Texturen, Geometrie, seinen Render-Controller, Animationen, Animations-Controller und seine Entity-Definition bei, alles unter dem Namespace freeminecraftmodels: (freeminecraftmodels:<model_id>).

Beim Erstellen relevante Hinweise:

  • Ein Modell ohne Texturen wird übersprungen, mit Skipping Bedrock custom entity export for <id>: model has no textures. in der Konsole
  • Die Bedrock-Geometrie schließt Reitpunkt-Bones (m_), erzeugte Nametag-Bones (fmm_nametag_bone_*) und hitbox aus. Selbst erstellte tag_-Anker bleiben enthalten, häufig ohne Würfel.
  • Ein Modell ohne Animationen exportiert trotzdem einen einzelnen idle-Animationsslot
  • Laufzeit-Hitbox-Breite und -Höhe für die Bedrock-Entity stammen vom hitbox-Bone des Modells; ohne einen solchen wird auf 1.0 x 2.0 zurückgefallen

Das Bedrock-Laufzeit-Backend benötigt ein aktiviertes Plugin namens floodgate, Geyser-Spigot oder Geyser. Die Prüfung ignoriert Groß- und Kleinschreibung, akzeptiert aber keine anderen Plugin-Namen. Auf einem reinen Java-Server exportiert FMM weiterhin die Bundle-Dateien, erstellt und tickt dieses Backend jedoch nicht.

Bedingte Item-Ausgabe für Bogen und Armbrust

Wenn FMM einen Satz von Bogen- oder Armbrust-Zustandsmodellen erkennt (siehe Hinweise zur Modellerstellung), generiert es eine einzelne Item-Definitions-JSON für das _idle-Modell, die auf Ressourcenpaket-Ebene bedingt zwischen allen Zuständen umschaltet. Es ist keine serverseitige Paketarbeit nötig -- der Client behandelt Zustandsübergänge nativ.

Bogen-Ausgabe

Bei Bögen verwendet die generierte Item-Definition minecraft:condition auf using_item mit einer minecraft:range_dispatch auf use_duration (Skalierung 0.05):

BedingungVerwendetes Modell
Item wird nicht benutzt_idle
Wird benutzt, Fallback (gerade gestartet)_draw_start
Wird benutzt, Schwellwert 0.65_draw_half
Wird benutzt, Schwellwert 0.9_draw_full

Armbrust-Ausgabe

Bei Armbrüsten verwendet die generierte Item-Definition minecraft:select auf charge_type. Wenn geladen (Pfeil oder Rakete), zeigt sie das _charged-Modell. Der ungeladene Fallback verwendet minecraft:range_dispatch auf crossbow/pull:

BedingungVerwendetes Modell
Wird nicht benutzt, nicht geladen_idle
Wird benutzt, Fallback (gerade gestartet)_draw_start
Wird benutzt, Schwellwert 0.58_draw_half
Wird benutzt, Schwellwert 1.0_draw_full
Geladen (Pfeil oder Rakete)_charged

Ausgabe-Speicherort

Die generierte bedingte Item-Definition wird neben anderen Item-Definitionen geschrieben unter:

assets/freeminecraftmodels/items/display/{baseModelId}_idle.json

Nur das _idle-Modell erhält eine Item-Definitionsdatei. Die Draw- und Charged-Modelle werden darin als bedingte Einträge referenziert.

Kompatibilitätsfixes für Minecraft 26.1+

Der Paket-Generator wendet zwei automatische Kompatibilitätsfixes für Minecraft 26.1 und neuer an:

  • UV-Klemmung: Flächen-UVs werden auf die eigenen Pixelgrenzen der Quelltextur geklemmt (0textureWidth / 0textureHeight), bevor sie in Minecrafts 16x16-UV-Raum umskaliert werden. Manche .bbmodel-Autoren lassen negative oder übergroße UVs in Flächen zurück — ein Atlas wurde neu skaliert, Auto-UV ist über den Rand hinausgeschossen und so weiter —, was der strengere Validator von 26.1 ablehnt. Das Klemmen lässt das Modell backen; eine Fläche mit UVs außerhalb der Grenzen verliert höchstens ein paar Pixel Texturdetail.
  • Leere und reine Anker-Bones werden übersprungen: Ein Bone ohne Cubes schreibt keine Geometrie-JSON, sodass eine Item-Modell-Definition für ihn eine hängende Referenz hinterlassen würde. 1.21.x tolerierte das still; 26.1+ protokolliert jede davon als Missing block model: freeminecraftmodels:.... Der Generator überspringt jetzt sowohl die Geometriedatei als auch die Item-Definition für solche Bones. Das deckt auch hitbox-Bones (nur Kollision), tag_name-Positionsanker, FMMs automatisch erzeugte fmm_nametag_bone_*-Varianten und reine Wrapper-/Anker-Bones ab.

Diese Fixes werden automatisch angewendet; keine Konfiguration erforderlich.

Hinweis

Genau deshalb benötigt ein tag_-Namensschild-Bone nie Cubes — er ist ein Positionsanker, und der Generator schreibt bewusst nichts für ihn. Siehe Namensschilder benötigen einen tag_-Bone.

Deterministische Ausgabe

Das erzeugte Paket ist byte-stabil: Eine Neugenerierung aus unveränderten Modellen ergibt ein identisches Zip und damit einen identischen SHA1.

Das ist wichtig, weil ResourcePackManager das erneute Hochladen eines Pakets überspringt, dessen SHA1 bereits dem entspricht, was der Remote-Host hat. Wenn die Bytes schwanken, greift diese Prüfung nie, RSPM lädt bei jedem Neustart erneut hoch, und jeder Spieler lädt ein Paket erneut herunter, dessen Inhalt sich nicht geändert hat.

An zwei Stellen schreibt der Generator JSON direkt auf die Festplatte, sodass die Iterationsreihenfolge seiner Maps tatsächlich die Byte-Reihenfolge der Datei bestimmt:

  • die Item-Modell-Definitionen pro Bone unter assets/freeminecraftmodels/items
  • der display-Block der Modell-JSON pro Bone unter assets/freeminecraftmodels/models

Beide verwenden jetzt Maps mit Einfügereihenfolge. Zuvor verwendeten sie Map.of, das von java.util.ImmutableCollections gestützt wird — dieses setzt einen zufälligen Salt pro JVM und sondiert von einem salt-abhängigen Index aus, sodass dieselbe Handvoll Schlüssel bei jedem Serverstart in einer anderen Reihenfolge herauskam. Schlüssel wie translation / scale sowie type / index / default tauschten bei jedem Boot die Plätze und schrieben jede Item-Definition und jede Modelldatei ohne Grund neu.

Wenn du zuvor beobachtet hast, dass Spieler nach jedem Neustart das Ressourcenpaket erneut heruntergeladen haben, obwohl du nichts geändert hattest, war das der Grund.

Hinweis

Determinismus gilt nur bei unverändertem Modellsatz. Ein Modell hinzuzufügen, zu entfernen, umzubenennen oder zu bearbeiten ändert die Paket-Bytes zu Recht und sollte einen erneuten Upload auslösen.

Reload-Verhalten

Wenn FreeMinecraftModels neu lädt:

  • führt es den Inhaltsimportschritt erneut aus
  • baut es den Ordner output/FreeMinecraftModels neu auf
  • regeneriert es output/FreeMinecraftModels.zip
  • versendet es resourcepackmanager reload, falls ResourcePackManager installiert ist

Aus diesem Grund benötigen moderne FMM- + ResourcePackManager-Setups nicht mehr den alten manuellen Zip-Kopie-Workflow.