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.mcmetapack.pngassets/minecraft/atlases/blocks.jsonassets/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_*) undhitboxaus. Selbst erstelltetag_-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 auf1.0x2.0zurü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):
| Bedingung | Verwendetes 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:
| Bedingung | Verwendetes 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 (
0–textureWidth/0–textureHeight), 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 auchhitbox-Bones (nur Kollision),tag_name-Positionsanker, FMMs automatisch erzeugtefmm_nametag_bone_*-Varianten und reine Wrapper-/Anker-Bones ab.
Diese Fixes werden automatisch angewendet; keine Konfiguration erforderlich.
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 unterassets/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.
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/FreeMinecraftModelsneu 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.