FreeMinecraftModels Konfiguration

Die YAML-Einstellungen der Modelle werden beim Neuladen der Inhalte gemeinsam vorbereitet. Lade nach einer Änderung der Prop-YAML erfolgreich neu, bevor du einen neuen Prop erzeugst. Gib jeder Modell-YAML über alle Modellordner hinweg einen eindeutigen Dateinamen. Haben zwei Dateien denselben Dateinamen (ohne Berücksichtigung von Groß- und Kleinschreibung), auch in verschiedenen Unterordnern, lädt FMM die Datei, deren absoluter Pfad in der Sortierung zuerst kommt, und überspringt die anderen mit einer Warnung Duplicate content filename. Eine übersprungene Kopie, deren Werte alle mit der geladenen Datei übereinstimmen, wird ohne Warnung übersprungen.

Diese Seite behandelt die aktuellen Einstellungen in config.yml und shop_config.yml, die Einrichtung, Rendering, Spielerinteraktion und den optionalen Möbelshop wesentlich beeinflussen. Haustiereinstellungen in pets.yml werden unter Haustiere behandelt.

Dateispeicherorte

plugins/FreeMinecraftModels/config.yml
plugins/FreeMinecraftModels/shop_config.yml
plugins/FreeMinecraftModels/pets.yml

shop_config.yml wird beim ersten Start generiert; der Shop selbst bleibt deaktiviert, bis du ihn aktivierst. pets.yml wird beim ersten Start im Modus COSMETIC generiert, in dem wilde Haustiere nur bei nächtlichen Wanderungen erscheinen. Die Lua-Module, die Haustiere ausführen, liegen in plugins/FreeMinecraftModels/pet_behaviors/; siehe Haustier-Verhaltensmodule.

Minimale Serverversion

plugin.yml deklariert api-version: 1.21.4, Minecraft 1.21.4 ist also die minimal unterstützte Serverversion. Die Unterstützung für ältere Versionslinien wurde eingestellt; Legacy-Render-/Ausgabezweige existieren im Code weiterhin, sind aber auf einem Server, der das Plugin laden kann, nicht mehr erreichbar.

config.yml-Einstellungen

setupDone

• Standard: false
• Steuert, ob die Ersteinrichtungsführung als abgeschlossen gilt
• Spieler mit freeminecraftmodels.* erhalten etwa 10 Sekunden nach jeder Anmeldung eine Erinnerung, solange dieser Wert false bleibt und sie noch online sind
• Das Öffnen von /fmm setup speichert serverweit true und beendet weitere Erinnerungen. Eine Abschlussoption in /fmm initialize speichert den Wert ebenfalls; er belegt weder eine Paketinstallation noch den Empfang durch Clients

nightbreak.autoDownloadPluginUpdates

• Standard: false
• Gemeinsame MagmaCore-Einstellung (befindet sich im nightbreak:-Abschnitt von config.yml)
• Wenn true, lädt FreeMinecraftModels verfügbare Plugin-Jar-Updates und Inhalts-Update-Dateien beim Start automatisch herunter
• Heruntergeladene Plugin- und Inhalts-Updates werden nach dem Server-Neustart angewendet, sofern nightbreak.applyPluginUpdatesWithoutRestart das Plugin-Update nicht schon früher anwendet
• Automatische Plugin-Downloads erfordern ein gültiges Nightbreak-Konto-Token und eine aktive Supporter-Patreon-Mitgliedschaft. Ohne beides lasse dies auf false und verwende stattdessen den Update-Button im Spiel
• Der automatische Inhaltsdurchlauf aktualisiert installierte Pakete und verschiebt deren Reload. Er installiert nicht wie /fmm downloadall sämtliche zugänglichen Pakete. Schalte die Einstellung über /fmm setup oder manuell um

nightbreak.applyPluginUpdatesWithoutRestart

• Standard: never
• Gemeinsame MagmaCore-Einstellung (befindet sich im nightbreak:-Abschnitt von config.yml). Sie legt fest, wann ein heruntergeladenes Plugin-Update ohne Neustart angewendet wird
• never: Das Update wartet auf den nächsten Neustart. Du kannst es trotzdem mit /fmm applypluginupdate manuell anwenden
• when-empty: Das Update wird angewendet, sobald keine Spieler mehr online sind. FMM prüft dies alle 30 Sekunden
• immediately: Das Update wird angewendet, sobald der Download abgeschlossen ist
• Jeder andere Wert zählt als never
• Beim Anwenden eines Updates werden FreeMinecraftModels und jedes MagmaGuy-Plugin, das davon abhängt, deaktiviert, das Jar wird ersetzt, und danach werden sie wieder geladen und aktiviert. Laufende Bosse, Arenen und Dungeon-Instanzen enden, wenn diese Plugins neu geladen werden
• Ein Plugin eines anderen Autors, das von FreeMinecraftModels abhängt, blockiert den Austausch; das Update wartet dann auf einen Neustart. Lässt sich das neue Jar nicht aktivieren, wird das vorherige Jar wieder geladen und das Update bleibt für den nächsten Neustart vorgemerkt. Siehe Befehle

useDisplayEntitiesWhenPossible

• Standard: true
• Weist FreeMinecraftModels an, das Display-Entity-Rendering zu bevorzugen, wenn Server und Client-Pfad dies unterstützen
• false wählt für Java-Clients das Bone-Rendering mit Rüstungsständern. Der alte Zweig für Versionen vor 1.19.4 bedeutet keine Unterstützung älterer Server
• Bei aktivierten Bedrock-Modellen und verfügbarer nativer Anbindung für benutzerdefinierte Entitäten erhalten Bedrock-Spieler diese Darstellung. Andernfalls verwendet ihr Bone-Rendering Rüstungsständer. Diese Einstellung erzwingt nicht für jeden Spieler dasselbe Backend

maxModelViewDistance

• Standard: 60
• Legt die normale Sichtweitenbegrenzung fest. In Welten mit wenigen Modellen umgeht die Ausnahme für Entfernungen unter 10 Blöcken sowohl diese Grenze als auch die Verdeckungsprüfung; Werte unter 10 bilden dort deshalb keine strikte Grenze
• Niedrigere Werte reduzieren die Paket- und Client-Renderinglast in dicht modell-gefüllten Bereichen
• Einzelne Entitäten können dies zur Laufzeit über ModeledEntity.setViewDistanceOverride(int) überschreiben — siehe das API-Handbuch

maxInteractionAndAttackDistance

• Standard: 3
• Gilt für statische und dynamische modellierte Entitäten
• Wird von den Laufzeit-Interaktions- und Trefferprüfungen verwendet

maxInteractionAndAttackDistanceForProps

• Standard: 6
• Gilt für Prop-Entitäten
• Dies ist getrennt von der Interaktionsdistanz statischer/dynamischer Entitäten

sendCustomModelsToBedrockClientsV2

• Standard: true
• Steuert, ob FreeMinecraftModels versucht, benutzerdefinierte Modelle an Bedrock-Clients zu senden
• Dieser Schlüssel ersetzt den älteren sendCustomModelsToBedrockClients (dessen Standard false war). Die Umbenennung in V2 kehrt den Standard um, sodass Bedrock-Spieler Modelle standardmäßig sehen; falls du zuvor den alten Schlüssel explizit gesetzt hast, kannst du ihn löschen, und der neue V2-Schlüssel übernimmt
• Bei Deaktivierung fallen Bedrock-Spieler auf die zugrunde liegende Vanilla-Entität zurück, wo diese existiert (und Verkleidungen werden für sie nicht gerendert)
• Wenn du dies aktivierst, stelle sicher, dass dein Bedrock-/Geyser-/Floodgate-Ressourcenpaket-Pfad tatsächlich für diese Clients bereit ist
• Bedrock-Diagnoselogging ist kein Konfigurationsschlüssel. Schalte es mit /fmm debug bedrock on|off um und nach der Beweissammlung ausdrücklich aus. /fmm reload setzt das Flag nicht zurück; ein neuer Serverstart schon. Siehe Befehle

skipUnchangedBoneUpdates

• Standard: true
• Bei true werden Bewegungs- und Metadatenupdates ausgelassen, wenn die erfassten Transformationen innerhalb der Vergleichstoleranz unverändert bleiben. Display-Bones erfassen Position, Rotation und Skalierung; Rüstungsständer-Bones erfassen Position und Rotation
• Unbewegte Bones überspringen diese Updates normalerweise, doch ausdrücklich markierte Änderungen wie die Einfärbung erzwingen ein erneutes Senden
• Die regelmäßige vollständige Resynchronisierung korrigiert weiterhin Client-Abweichungen; diese Option unterdrückt nicht jede Art von Modellpaket
• Setze es nur auf false, um zum alten Verhalten „immer jeden Bone in jedem Tick erneut senden" zum Debuggen zurückzukehren

useDeltaMetadataPackets

• Standard: true
• Wenn true, sendet das Metadatenpaket pro Tick für Display-Entity-Modell-Bones nur die geänderten Werte (die Transformation des Bones), statt in jedem Tick den gesamten Item-Display-Blob (Item-Modell + Custom Model Data) neu zu serialisieren
• Der vollständige Zustand wird weiterhin gesendet, wenn ein Spieler ein Modell zum ersten Mal sieht, sowie bei der periodischen Resynchronisierung
• Setze es auf false, um zum alten Verhalten mit vollständigem Snapshot pro Tick zum Debuggen oder Vergleichen zurückzukehren

displayBonesRideTheirEntity

• Standard: true
• Bei true reiten die Display-Bones eines dynamischen Modells auf Java-Clients als Passagiere auf seiner Entity. Der Client platziert jeden Bone von derselben geglätteten Position aus, die er für die Entity und ihre Reiter verwendet, sodass Reittiere, Reiter und bewegte Modelle zusammenbleiben, statt hinterherzuhinken, und die Bones senden keine Positionspakete
• Das gilt für Reittiere wie /fmm mount und für Modelle, deren versteckte Entity über modelViewersTrackHiddenBodies verfolgt wird. Bones reiten nur, solange der Client jedes Java-Betrachters die Entity verfolgt. Ein Betrachter kann ein Modell weiter entfernt sehen, als der Server seine Entity verfolgt (Modelle erscheinen bis zu maxModelViewDistance, standardmäßig 60 Blöcke, während Spigot Monster standardmäßig bis 48 Blöcke verfolgt), und Plugins können die Entity vor einem Betrachter verstecken. In diesen Fällen und solange das Modell stirbt, wechseln die Bones zurück zu Teleports pro Bone
• Bedrock-Spieler sind nicht betroffen
• Setze es auf false, um jedes Modell wie bisher bei Teleports pro Bone zu belassen

riddenBoneInterpolationTicks

• Standard: 1
• Wie viele Ticks ein Java-Client braucht, um einen reitenden Bone zu seiner nächsten Animationspose gleiten zu lassen. 0 springt in jedem Tick. 1 gleitet über einen Tick, was auch Rotationen glättet
• Nur Bones, die auf ihrer Entity reiten, verwenden ihn; siehe displayBonesRideTheirEntity
• /fmm boneglide <ticks> ändert ihn bis zum nächsten Neuladen von FMM, ohne diese Datei zu bearbeiten. Siehe Befehle

modelViewersTrackHiddenBodies

• Standard: true
• Bei true erhält jeder Java-Spieler, der ein dynamisches Modell mit versteckter Entity sehen kann, diese Entity zusätzlich als unsichtbaren Körper ohne Ausrüstung. Die Bones des Modells können dann auf ihm reiten, wie unter displayBonesRideTheirEntity beschrieben
• Andere Spieler und Bedrock-Spieler behalten die Entity wie bisher versteckt
• Setze es auf false, um versteckte Entities unverfolgt und ihre Bones bei Teleports pro Bone zu belassen

idleWalkBlendTicks

• Standard: 5
• Experimentell. Wie viele Ticks ein Modell braucht, um zwischen seinen Animationen idle und walk überzublenden. Beide Animationen laufen während der Überblendung weiter
• 0 wechselt sofort, wie ältere Versionen
• Bedrock-Spieler erhalten dieselbe Überblendzeit. Sie wird in die erzeugten Bedrock-Animations-Controller geschrieben, sie sehen eine Änderung also erst, nachdem das Ressourcenpaket neu erzeugt wurde
• Siehe Animationen überblenden

deathBlendTicks

• Standard: 4
• Experimentell. Wie viele Ticks ein Modell braucht, um aus der gehaltenen Pose in seine death-Animation überzublenden. 0 wechselt sofort, wie ältere Versionen
• Bedrock-Spieler erhalten dieselbe Überblendzeit, sobald das Ressourcenpaket neu erzeugt wurde

weightedTurning

• Standard: true
• Experimentell. Bei true dreht sich ein dynamisches Modell mit Trägheit in die Blickrichtung seines Mobs: Es beschleunigt, dreht mit begrenzter Geschwindigkeit und bremst dann ab, um ohne Überschwingen auf der neuen Blickrichtung zu landen. Größere Modelle drehen sich langsamer
• Nur das Modell dreht sich so. Der Mob selbst dreht sich und läuft weiterhin genau wie zuvor
• Ein Modell dreht sich sofort, solange ein Spieler seinen Mob direkt reitet oder auf einem seiner m_-Sitze sitzt
• Setze es auf false, damit sich Modelle wie in älteren Versionen sofort mit ihrem Mob drehen
• Wie die Größe die Grenzen verändert, steht unter Drehträgheit

turnSpeedCap

• Standard: 30
• Experimentell. Höchste Drehgeschwindigkeit in Grad pro Tick eines Modells mit einem Block Größe
• Die Obergrenze wird durch die Quadratwurzel der Modellgröße geteilt und überschreitet nie 90 Grad pro Tick

turnAcceleration

• Standard: 6
• Experimentell. Um wie viele Grad pro Tick ein Modell mit einem Block Größe in jedem Tick an Drehgeschwindigkeit gewinnt oder verliert
• Sie wird durch die Modellgröße geteilt, größere Modelle beschleunigen und bremsen also langsamer
• Ein Wert von 0 oder weniger, ebenso wie ein turnSpeedCap von 0 oder weniger, lässt Modelle sich sofort drehen

maxModelsForProximityOverride

• Standard: 25
• Pseudo-Lastverteiler für die Nahbereichs-Sichtbarkeitsüberschreibung
• Normalerweise umgeht ein Modell in weniger als 10 Blöcken Entfernung die Distanz- und Verdeckungsprüfungen zur Auswahl der Betrachter; andere Sichtbarkeitsregeln gelten weiterhin
• In einem dichten Bereich (zum Beispiel einem mehrstöckigen NPC-Hub) werden dadurch für Dutzende Modelle in jedem Tick Pakete an den Spieler gesendet, obwohl er sie auf anderen Etagen oder hinter Wänden gar nicht sehen kann
• Enthält eine Welt mindestens so viele geladene Modelle, wird die Nahbereichsausnahme dort deaktiviert. Betrachter müssen auch aus der Nähe die eingestellten Distanz- und Sichtbarkeitsprüfungen bestehen. Die Sichtprüfung prüft die Modellmitte und Hitbox-Ecken; eine fehlende Hitbox besteht sie. Welten mit wenigen Modellen behalten die Ausnahme
• Die Entscheidung fällt pro Welt, nicht global, sodass eine überfüllte Hub-Welt ruhige Welten nicht bestraft
• Setze den Wert sehr hoch, um faktisch das Immer-Überschreiben wiederherzustellen; setze ihn auf 0, um immer Sichtlinie zu verlangen
• /fmm packetdebug ist das vorgesehene Werkzeug, um die Wirkung zu messen — siehe Befehle

filmicMode

Warnung

Außerhalb von Aufnahmen nicht empfohlen. Der Filmic-Modus sendet jedem Spieler weit mehr Pakete und lässt den Server jedes geladene Modell animieren. Auf ausgelasteten Servern ist mit Lag zu rechnen.

• Standard: false
• Zum Aufnehmen von Trailern und Videos mit ReplayMod oder einem ähnlichen Aufnahme-Mod
• Normalerweise erhält ein Spieler ein Modell nur, solange es innerhalb von maxModelViewDistance liegt und die Sichtlinienprüfung besteht. Verdeckte Modelle werden von diesem Client entfernt und hören auf zu animieren. Ein Replay enthält nur, was der aufnehmende Client empfangen hat, daher fehlen diese Modelle oder sind eingefroren, wenn die Replay-Kamera auf sie gerichtet ist
• Bei true erhält jeder Spieler jedes geladene Modell in den Chunks, die er geladen hat, und diese Modelle animieren weiter, auch hinter Wänden oder jenseits von maxModelViewDistance. Der Bereich der geladenen Chunks ist die Sichtweite der Welt, begrenzt durch die Renderdistanz des Clients, plus ein Chunk. Modelle in ungeladenen Chunks erscheinen weiterhin nicht
• Um den Modus nur für eine Aufnahmesitzung einzuschalten, verwende /fmm filmic on|off, statt diese Datei zu bearbeiten. Siehe Befehle

particleEffectsEnabled

• Standard: true
• Bei false wird auf Modellen, Props und gehaltenen Items kein Blockbench-Partikeleffekt abgespielt. Modelle werden wie gewohnt geladen und animiert
• Die Änderung greift nach /fmm reload oder einem Neustart. Java-Spieler sehen sie, sobald FMM neu geladen hat. Bedrock-Spieler sehen sie, sobald sie das neu erzeugte Ressourcenpaket erhalten, denn ihre Effekte werden im Paket ausgeliefert
• Siehe Partikel

maxParticlesPerEmitter

• Standard: 100
• Obergrenze aktiver Partikel für einen Partikeleffekt auf einem Modell. Ist das eigene max_particles einer Partikeldatei niedriger, gilt dieser Wert
• Jedes Partikel, das ein Java-Spieler sieht, ist eine Paket-Entität, hohe Werte kosten daher Bandbreite

maxParticlesPerViewer

• Standard: 400
• Obergrenze aktiver Partikel, die einem Java-Spieler über alle Modelle hinweg angezeigt werden
• Ist sie erreicht, werden neue Partikel für diesen Spieler übersprungen, bis ältere verschwinden. Bedrock-Spieler zeichnen Partikel auf ihrem eigenen Client und werden nicht mitgezählt

preventPropPlacementInProtectedRegions

• Standard: true
• Wenn true, fragt FreeMinecraftModels die bei MagmaCore registrierten Schutz-Provider, ob dieser konkrete Spieler in der Zelle bauen darf, die der Prop einnehmen würde, und lehnt die Platzierung ab, wenn die Antwort nein lautet
• Spieler mit der Berechtigung freeminecraftmodels.bypassregionprotection (Standard: op) überspringen diese FMM-Schutzprüfung. Platzprüfungen und Einschränkungen anderer Plugins gelten weiterhin
• Die eingebauten spielerbezogenen Provider unterstützen WorldGuard und GriefPrevention. Andere Plugins können Provider registrieren. Eine Ablehnung oder ein Providerfehler verhindert die Platzierung; MagmaCore lehnt außerdem Orte mit geschütztem Standortbesitz ab. Ohne ablehnenden Provider und ohne geschützten Besitz fügt die Prüfung keine Einschränkung hinzu
• Die Ablehnungsnachricht lautet You don't have permission to place a model here!

Der Provider prüft, ob dieser Spieler bauen darf; eine Claim-Mitgliedschaft kann die Platzierung daher erlauben. Geschützter Standortbesitz ist eine separate Prüfung ohne spielerbezogene Ausnahme. Hier werden registrierte Integrationen abgefragt, kein Vanilla-Blockplatzierungsereignis simuliert. Die Prüfung bildet deshalb nicht die Platzierungsregeln jedes Plugins nach.

Jede Platzierung erhält eine Einzelzellenprüfung; voxelisierte Props zusätzlich eine volumenweite:

Prop-Typ	Geprüfte Zellen
Normaler (freiformiger) Prop	Die einzelne Zelle neben der angeklickten Blockfläche — die Zelle, die der Prop einnehmen wird
Prop mit voxelize: true	Zuerst dieselbe Nachbarzelle, dann jede Zelle im rotierten Grundriss des Props (Breite x Höhe x Tiefe) rund um den rasterausgerichteten Platzierungspunkt. Ist irgendeine Zelle in diesem Volumen tabu, wird die gesamte Platzierung abgelehnt

Die Volumenprüfung existiert, weil ein voxelisierter Prop mehrere Blöcke breit sein kann; nur die angeklickte Zelle zu prüfen würde einem Spieler erlauben, eine Claim-Grenze zu überspannen und einen großen Prop in den Bau eines anderen zu setzen. Sie läuft nach der Freiraumprüfung, sodass Not enough space to place this model! weiterhin Vorrang hat, wenn der Grundriss physisch blockiert ist.

Der geprüfte Platzbedarf rundet jede Hitbox-Abmessung mit Math.round auf mindestens einen Block. Das Volumen der per Paket gesendeten Barrieren verwendet dagegen ceil(size - 0.4) und kann abweichen; die Platzierungsprüfung garantiert keine identische Abdeckung aller clientseitigen Kollisionszellen.

Hinweis

Die Berechtigung wird vor der Provider-Abfrage geprüft. Mit freeminecraftmodels.bypassregionprotection kannst du Teammitglieder von FMMs Schutzprüfungen ausnehmen und die Einstellung für andere Spieler aktiv lassen. Platzprüfungen und Ereignisabbrüche anderer Plugins werden dadurch nicht umgangen.

registerCraftingRecipes

• Standard: true
• Setze den Wert für eine reine Kaufwirtschaft auf false und starte neu. Gültige aktivierte Rezepteinträge bleiben im Shopkatalog, ihre Bukkit-Crafting-Rezepte werden jedoch entfernt
• Das Spielermenü für herstellbare Items unter /fmm und die Rezeptdetails benötigen ein tatsächlich registriertes Rezept. Einträge mit deaktiviertem Crafting fehlen dort deshalb
• isEnabled: false in einem einzelnen Rezept entfernt es aus dem geladenen Rezeptkatalog einschließlich Shop. shopEnabled: false blendet es nur beim Kauf aus

shop_config.yml

Der optionale Vault-gestützte Möbelshop hat eine eigene Konfiguration, sodass er unabhängig vom Verhalten des Hauptplugins aktiviert oder angepasst werden kann. Der Shop verweigert die Registrierung, wenn Vault oder ein Wirtschafts-Provider fehlt.

Schlüssel der obersten Ebene

Schlüssel	Standard	Beschreibung
enabled	false	Haupt-Umschalter für /fmm shop. Der Befehl registriert sich nur, wenn dies true ist und Vault + ein Wirtschafts-Provider beide vorhanden sind
defaultPrice	100.0	Standard für Rezepte ohne shopPrice; bei null oder negativen Werten wird 100.0 verwendet. Bereits gespeicherte Rezeptpreise ändern sich durch diesen Standard nicht
menuTitle	&8FMM - Furniture Shop	Titel, der oben im Shop-Inventar angezeigt wird (unterstützt &-Farbcodes)
priceLoreFormat	&7Price: &e{price}	Lore-Zeile, die an jedes Shop-Item angehängt wird und seinen Preis zeigt. Platzhalter: {price}
clickToBuyLoreFormat	&aClick to purchase	Lore-Zeile, die an jedes Shop-Item angehängt wird und zum Kauf auffordert

Nachrichten-Schlüssel (messages.*)

Alle Nachrichtenstrings unterstützen &-Farbcodes.

Schlüssel	Standard	Platzhalter
messages.purchaseSuccess	&aPurchased &f{item} &afor &e{price}&a. Balance: &e{balance}&a.	{item}, {price}, {balance}
messages.insufficientFunds	&cYou need &e{price} &cto buy &f{item}&c. Balance: &e{balance}&c.	{item}, {price}, {balance}
messages.shopDisabled	&cThe furniture shop is currently unavailable.	keine
messages.itemNotForSale	&cThat item is not currently for sale.	{item}
messages.inventoryFull	&eYour inventory was full; &f{item} &ehas been dropped at your feet.	{item}

Shop-Felder pro Rezept

Jede Rezeptdatei in plugins/FreeMinecraftModels/recipes/<model_id>.yml erhält zwei zusätzliche Felder:

Feld	Standard	Beschreibung
shopEnabled	true	Ob dieses Rezept in /fmm shop sichtbar ist. false allein deaktiviert Crafting nicht; die Rezeptaktivierung und registerCraftingRecipes gelten weiterhin
shopPrice	defaultPrice aus shop_config.yml	Vault-Währungskosten für dieses spezifische Item

Der Rezept-Builder (/fmm craftify) schreibt beim Speichern beide Felder, sodass eine Preisanpassung nur eine Textbearbeitung entfernt ist.

Berechtigungen

In plugin.yml registriert

Berechtigung	Standard	Beschreibung
freeminecraftmodels.*	op	Wildcard, die Admin-, Deleteall-, Selbst-/Fremd-Verkleidungs-, Regionsschutz-Umgehungs- und Haustier-Admin-Berechtigungen gewährt
freeminecraftmodels.admin	op	Zugriff auf /fmm admin (den Admin-Inhaltsbrowser) und /fmm giveitem. Andere Admin-/Debug-Befehle (/fmm location, /fmm spawn, /fmm mount, /fmm itemify, /fmm craftify, /fmm reload, /fmm stats, /fmm hitbox visualize, /fmm debug, /fmm packetdebug, /fmm filmic, /fmm boneglide, /fmm setup, /fmm initialize, /fmm recommendedplugins, /fmm downloadall, /fmm downloadallcontent, /fmm updatecontent, /fmm downloadpluginupdate, /fmm applypluginupdate, /fmm forcereinstallcontent) prüfen stattdessen die Wildcard freeminecraftmodels.*
freeminecraftmodels.deleteall	op	Kind der Wildcard; Zugriff auf /fmm deleteall
freeminecraftmodels.disguise.self	op	Erlaubt /fmm disguise / /fmm undisguise auf den Sender
freeminecraftmodels.disguise.others	op	Erlaubt gezielte Verkleidung/Enthüllung sowie /fmm disguiselist
freeminecraftmodels.bypassregionprotection	op	Umgeht FMMs Schutzprüfungen für Platzierung und Interaktion, auch bei aktivem preventPropPlacementInProtectedRegions; überschreibt keine Ereignisabbrüche anderer Plugins oder Platzanforderungen
freeminecraftmodels.menu	true	Zugriff auf das /fmm-Menü craftbarer Items
freeminecraftmodels.shop	true	Zugriff auf /fmm shop
freeminecraftmodels.pets	true	Zugriff auf /fmm pets
freeminecraftmodels.pets.admin	op	Kind der Wildcard; Zugriff auf /fmm petadmin und /fmm petmigrate
nightbreak.login	op	Wird von MagmaCore registriert, nicht von plugin.yml. Erforderlich für die gemeinsamen Befehle /nightbreaklogin und /nightbreaklogout
nightbreak.plugins	op	Wird von MagmaCore registriert, nicht von plugin.yml. Erforderlich für den gemeinsamen Befehl /nightbreak plugins

Die Haustierbefehle sind unter Haustiere beschrieben.

Modell-YML-Konfiguration

Die begleitende .yml-Datei eines Modells hat denselben Basisnamen wie seine .bbmodel-Datei und liegt im selben Verzeichnis. Props und gehaltene Items verwenden unterschiedliche Teile dieser Konfiguration.

Props

isEnabled: true
name: "&6Oak Table"
lore:
  - "&7Seats four"
voxelize: true
solidify: true
scripts:
  - my_prop.lua

Feld	Beschreibung
isEnabled	Gibt an, ob die Definition aktiviert ist; Standard: true
name	Anzeigename des Platzierungsitems des Props. Unterstützt Farbcodes. Ohne ihn trägt das Item den Namen des Modells, etwa ✦ Oak Table ✦
lore	Lore des Platzierungsitems. Unterstützt Farbcodes. Jeder lore-Schlüssel ersetzt die Standard-Lore (Hinweise zum Platzieren und Aufnehmen plus die Modell-ID), und eine leere Liste (lore: []) entfernt sie
scripts	Unabhängige Lua-Skripte für Props aus plugins/FreeMinecraftModels/scripts/
voxelize	Richtet die Platzierung am Blockraster und an 90-Grad-Drehschritten aus; prüft den gesamten gedrehten Platzbedarf auf freien Raum
solidify	Sendet bei aktivierter Voxelisierung rein paketbasierte Barrier-Blöcke für clientseitige Kollision; diese sind keine Weltblöcke und werden mit dem Prop entfernt

name und lore des Platzierungsitems gelten überall, wo FMM das Item erzeugt: /fmm itemify, Ergebnis von Rezepten, Shop-Käufe und Items aus den Admin-Menüs. Menüeinträge, etwa die Angebote des Shops und seine Kaufmeldungen, zeigen weiterhin den aus der Modell-ID gebildeten Namen. Items, die sich bereits in Inventaren befinden, behalten ihren alten Namen und ihre Lore.

Gehaltene Items

isEnabled: true
material: DIAMOND_SWORD
name: "&bFrost Blade"
lore:
  - "&7A sword forged in ice"
enchantments:
  - "minecraft:sharpness,3"
  - "minecraft:unbreaking,2"

material wählt ein Bukkit-Item-Material und registriert ein gehaltenes Item anstelle eines Props. name und lore unterstützen Farbcodes. Verzauberungen verwenden kleingeschriebene IDs mit Namensraum und positive ganzzahlige Stufen. Ist eine Verzauberung ein Itemset, zeigt die Lore des Items die Teile des Sets in der Lore-Zeile mit $itemSet, oder nach der Lore, wenn keine Zeile diesen Platzhalter enthält. Registrierte Items erhältst du über /fmm giveitem <id> oder das Admin-Menü. Prop-Rezepte und der Shop erzeugen Platzierungsitems aus Papier, nicht diese vom Autor definierten gehaltenen Items.

Um Lederrüstung zu färben, hänge wie bei EliteMobs-Ausrüstung eine RGB-Hexfarbe ohne # an das Material an: material: LEATHER_CHESTPLATE:ff8800. Das Suffix funktioniert nur bei Materialien, deren Name mit LEATHER_ beginnt, etwa Lederrüstungsteilen und Lederpferderüstung. Ein Suffix an einem anderen Material oder ein Wert, der nicht aus ein bis sechs Hexziffern besteht, lässt den Item-Katalog scheitern: /fmm reload behält den aktuellen Katalog und die Konsole nennt die Datei. Items, die sich bereits in Inventaren befinden, behalten ihre alte Farbe.

Kompatibilität beim Upgrade

Lua-Skripte für ausgerüstete Items wurden eingestellt. Eine Definition für ein gehaltenes Item wird mit einer Diagnosemeldung übersprungen, wenn sie eine nicht leere scripts:-Liste, alte Verzauberungen ohne Namensraum wie SHARPNESS,3 oder ein auf diesem Server nicht verfügbares Material enthält. FMM lässt die erstellte Datei unverändert. Entferne die Bindung an das eingestellte Item-Skript und definiere Effekte über Verzauberungsdefinitionen. Prop-Skripte werden weiterhin unterstützt.

Ergänze für Zauberstäbe und Magierstäbe eine Definition für magische Waffen. Waffenverhalten gehört weder in ein Prop-Skript noch in die eingestellten Item-Hooks.

Betriebshinweise

• /fmm reload importiert und validiert zunächst die definierten Items, Verzauberungen und Prop-Rezepte, während der bisherige Katalog aktiv bleibt. Eine fehlgeschlagene Validierung lehnt den Reload ab; bei Erfolg folgt die vollständige Neuinitialisierung einschließlich config.yml, shop_config.yml, pets.yml, Rezepten, Modellen, Haustierarten, Haustier-Verhaltensmodulen und Paketausgabe. Gleichzeitige Initialisierungs- und Reload-Anfragen werden abgelehnt
• Eine erfolgreiche vollständige Initialisierung plant FmmReloadedEvent 40 Ticks später ein, damit abhängige Plugins ihre Anhänge erneut binden können. Der begrenztere, vom Importer ausgelöste Inhaltsreload sendet es bei Erfolg. Er baut Modelle, Items, Verzauberungen, Prop-Skripte und Rezepte neu auf, liest config.yml und shop_config.yml aber nicht erneut ein. Ein Fehler nach dem Leeren der aktiven Register in diesem Inhaltspfad deaktiviert FMM. Eine Ausnahme ist ein Fehler bei den Prop-Rezepten: FMM protokolliert Prop recipe catalog rejected und lässt die bisherigen Rezepte aktiv. Eine abgelehnte Validierung ist kein abgeschlossener Reload
• Beim Entladen einer Welt entfernt FMM die Laufzeitmodelle der Props und behält ihre persistenten Träger-Rüstungsständer. Wenn diese Entitäten erneut geladen werden, entfernt es Duplikate und stellt die Props wieder her. Das ist ein anderer Vorgang als das dauerhafte Aufnehmen oder Zerstören eines Props.
• Feste ZIP-Zeitstempel und geordnete Modell-Maps reduzieren unnötige Änderungen. Die Reihenfolge der Dateisystemeinträge kann ZIP-Bytes und SHA1 dennoch ändern, auch bei unveränderten Modellen. Identische Ausgabe ist nicht garantiert. Siehe Ressourcenpaket-Ausgabe.
• FreeMinecraftModels generiert das Ressourcenpaket nur; es hostet es nicht selbst.
• ResourcePackManager bleibt der empfohlene Auslieferungsweg für Java-Clients und der sicherste dokumentierte Pfad für gemischte Setups.
• WorldGuard, WorldEdit, GriefPrevention, Vault, floodgate und Geyser-Spigot sind als softdepend in plugin.yml deklariert. WorldGuard und GriefPrevention liefern die eingebauten Schutzabfragen; WorldEdit ist kein separater Schutz-Provider. Vault mit einem Wirtschafts-Provider aktiviert den Shop. Für die entsprechende Bedrock-Darstellung müssen Clienterkennung, Rendering-Anbindung und Paketauslieferung verfügbar sein

Wann du diese Werte ändern solltest

Verwende diese Konfiguration für die Feinabstimmung des Laufzeitverhaltens, nicht für die Verwaltung von Inhaltspaketen.

• Verwende /fmm setup, /fmm downloadall und /fmm updatecontent für den Lebenszyklus offizieller Pakete
• Verwende den imports-Ordner für manuelle .bbmodel- oder andere lokale Inhaltsimport-Arbeit
• Verwende config.yml, wenn du Rendering-Modus, Sichtweite, Interaktionsdistanz, Bedrock-Verhalten, die Durchsetzung des Regionsschutzes oder automatische Update-Downloads anpassen musst
• Verwende skipUnchangedBoneUpdates, useDeltaMetadataPackets und maxModelsForProximityOverride zur Paket-/Bandbreiten-Feinabstimmung in modelldichten Welten. Alle drei stehen standardmäßig auf dem optimierten Verhalten; die false- bzw. sehr hohen Einstellungen existieren zum Debuggen und für A/B-Vergleiche, nicht als empfohlene Produktivwerte
• Verwende filmicMode (oder /fmm filmic on) nur während Videoaufnahmen und schalte ihn danach wieder aus
• Verwende idleWalkBlendTicks, deathBlendTicks, weightedTurning, turnSpeedCap und turnAcceleration, um die Animation und das Drehen von Modellen abzustimmen. Setze die Überblendzeiten auf 0 und weightedTurning auf false, um das sofortige Wechseln und Drehen älterer Versionen zu erhalten
• displayBonesRideTheirEntity und modelViewersTrackHiddenBodies sind standardmäßig an. Setzt du sie auf false, kehren die älteren Teleports pro Bone zurück, bei denen bewegte Modelle und Reittiere hinter ihrer Entity herhinken können
• Senke maxParticlesPerEmitter und maxParticlesPerViewer oder setze particleEffectsEnabled: false, wenn partikelreiche Modelle zu viel Bandbreite kosten
• Verwende shop_config.yml (und die shopEnabled/shopPrice-Felder pro Rezept), um den Möbelshop anzupassen, ohne Code zu berühren

Bekannte Einschränkungen

• Das Bedrock-Verhalten hängt sowohl von sendCustomModelsToBedrockClientsV2 als auch von deinem umfassenderen Floodgate-/Geyser-/Ressourcenpaket-Setup ab; bleibe also bei Aussagen konservativ, sofern du nicht genau deinen Stack getestet hast.
• Ist der Shop aktiviert, fehlt aber Vault oder ein Wirtschafts-Provider, bleibt er nicht verfügbar und protokolliert beim Start eine konkrete Warnung. /fmm version meldet nur die Pluginversion; prüfe diese Warnungen, wenn /fmm shop fehlt.