FAQ FreeMinecraftModels

Si vous avez une question qui n'est pas listée ici, jetez un œil à la barre latérale pour voir si elle a une page dédiée dans le wiki !

Premiers pas

Comment installer et utiliser FreeMinecraftModels ?

Info

Installation :

1. Téléchargez FreeMinecraftModels.jar et placez-le dans votre dossier plugins
2. Redémarrez votre serveur pour générer les dossiers du plugin
3. Exécutez /fmm setup pour le menu de configuration initiale / gestion de contenu
4. Si vous utilisez les packs de contenu officiels, liez Nightbreak avec /nightbreaklogin <token>
5. Utilisez /fmm setup ou /fmm downloadall pour le contenu officiel géré par Nightbreak
6. Pour importer des modèles seuls, placez les fichiers portant l'extension minuscule .bbmodel directement dans ~/plugins/FreeMinecraftModels/imports/ et exécutez /fmm reload. Les modèles accompagnés d'autres fichiers doivent utiliser le dossier de modèles actif ou un import empaqueté ; consultez les notes de création
7. Trouvez le resource pack généré dans ~/plugins/FreeMinecraftModels/output/FreeMinecraftModels.zip

Distribution du Resource Pack :

Choisissez l'une de ces méthodes :

• Option A (Recommandée) : Installez Resource Pack Manager pour une distribution automatique
• Option B : Configurez manuellement via server.properties ou un service d'hébergement

Faire apparaître des modèles :

• /fmm spawn static <id> - Fait apparaître un modèle décoratif temporaire
• /fmm spawn dynamic <id> - Fait apparaître un modèle attaché à une entité
• /fmm spawn prop <id> - Fait apparaître un modèle persistant dans le monde

Gestion :

• /fmm - Ouvre le menu d'objets craftables (nécessite freeminecraftmodels.menu)
• /fmm setup - Ouvre le menu de gestion de contenu / configuration initiale
• /fmm recommendedplugins - Parcourt les plugins compagnons qui se marient bien avec FMM
• /fmm downloadall - Télécharge la dernière mise à jour du plugin, puis le contenu accessible manquant ou obsolète ; le jar prend effet après un redémarrage ou après /fmm applypluginupdate
• /fmm downloadallcontent - Télécharge le contenu accessible manquant ou obsolète sans le jar du plugin
• /fmm updatecontent - Met à jour le contenu officiel obsolète
• /fmm downloadpluginupdate - Télécharge uniquement la dernière mise à jour du jar du plugin
• /fmm applypluginupdate - Applique une mise à jour du plugin déjà téléchargée sans redémarrer le serveur
• /fmm forcereinstallcontent <package|all> : retélécharge le contenu sélectionné quelle que soit sa version ; utilisez directement le slug d'un pack entièrement absent
• /fmm reload - Recharge le plugin et convertit les nouveaux modèles
• /fmm version - Affiche la version du plugin
• /fmm stats - Affiche les statistiques de nombre d'entités
• /nightbreaklogin <token> / /nightbreaklogout : commandes communes de MagmaCore pour enregistrer ou effacer le jeton du compte Nightbreak ; nécessitent nightbreak.login
• /freeminecraftmodelschangelog [dismiss|disable] : consulte les notes de version FMM non lues en jeu, pour les administrateurs uniquement ; également proposé sous forme de message cliquable à la connexion

Fonctionnalités joueur :

• /fmm disguise <modelID> [player] - Transforme votre apparence (ou celle d'un joueur cible) en un modèle personnalisé
• /fmm undisguise [player] - Retire le déguisement d'un joueur
• /fmm disguiselist - Liste tous les joueurs actuellement déguisés
• /fmm itemify <model> <material> - Crée un objet plaçable qui fait apparaître le modèle spécifié
• /fmm craftify <modelID> - Ouvre un éditeur de recette interactif pour créer une recette de craft pour un prop
• /fmm shop - Ouvre la boutique de mobilier optionnelle adossée à Vault (uniquement lorsqu'activée dans shop_config.yml)
• /fmm mount <modelID> - Fait apparaître un cheval chevauchable déguisé en modèle personnalisé (expérimental)

Débogage :

• /fmm hitbox visualize [duration] - Visualise les hitboxes proches avec des particules pendant un nombre de ticks (100 par défaut, les valeurs nulles ou négatives donnent 100, maximum 1200)
• /fmm location - Rapporte les fournisseurs de protection / donjon enregistrés et les teste sur votre position actuelle
• /fmm debug bedrock [on|off] - Définit l'état du flux détaillé [FMM-BedrockDebug], ou l'indique si aucun état n'est fourni. Cet état est conservé après /fmm reload et désactivé au démarrage du serveur
• /fmm debug props [on|off] - Active les diagnostics de props empilés au démarrage, au chargement des entités et avant leur apparition, ou indique leur état. L'état est conservé après /fmm reload et réinitialisé au démarrage du serveur
• /fmm packetdebug [ticks] - Mesure les paquets des entités modélisées pendant le nombre indiqué de ticks de l'horloge des modèles (1 par défaut, plage 1–200 ; une entrée invalide donne 1) : paquets par tick, diffusion par spectateur, destinataires les plus sollicités et types de paquets
• /fmm filmic [on|off] - Envoie temporairement chaque modèle chargé à chaque joueur dont le chunk est chargé, pour les enregistrements ReplayMod. Déconseillé en dehors des enregistrements. Voir le mode filmique

Administratif :

• /fmm deleteall [radius] - Supprime toutes les entités modélisées chargées et les props (à utiliser avec précaution - pas de prompt de confirmation). Un [radius] optionnel réservé aux joueurs limite la suppression à ce rayon de blocs

Permissions :

• freeminecraftmodels.* (défaut : OP) - Wildcard qui accorde freeminecraftmodels.admin, freeminecraftmodels.deleteall, freeminecraftmodels.disguise.self, freeminecraftmodels.disguise.others et freeminecraftmodels.bypassregionprotection. C'est aussi la permission littérale requise par /fmm reload, /fmm stats, /fmm spawn, /fmm itemify, /fmm craftify, /fmm mount, /fmm hitbox visualize, /fmm debug, /fmm packetdebug, /fmm filmic, /fmm location, /fmm setup, /fmm initialize, /fmm recommendedplugins, /fmm downloadall, /fmm downloadallcontent, /fmm updatecontent, /fmm downloadpluginupdate, /fmm applypluginupdate et /fmm forcereinstallcontent
• freeminecraftmodels.admin (défaut : OP) - /fmm admin (le navigateur de contenu admin) et /fmm giveitem
• freeminecraftmodels.disguise.self (défaut : OP) - Permet à un joueur de se déguiser/dé-déguiser uniquement lui-même
• Les commandes disguise et undisguise visant un joueur nécessitent à la fois freeminecraftmodels.disguise.self et freeminecraftmodels.disguise.others. disguiselist ne nécessite que .others.
• freeminecraftmodels.deleteall (défaut : OP) - Requis pour /fmm deleteall (enfant du wildcard)
• freeminecraftmodels.bypassregionprotection (défaut : OP) - Contourne la vérification de protection de région de FMM. Cela ne neutralise ni tous les gestionnaires d'événements des autres plugins ni la vérification de l'espace libre
• freeminecraftmodels.menu (défaut : true) - Permet à tous les joueurs d'ouvrir le navigateur d'objets craftables via /fmm
• freeminecraftmodels.shop (défaut : true) - Permet à tous les joueurs d'ouvrir /fmm shop (toujours conditionné par l'activation de la boutique)
• nightbreak.login (défaut : OP) - Enregistrée par MagmaCore, pas par plugin.yml. Requise par /nightbreaklogin et /nightbreaklogout

Les commandes sont OP uniquement par défaut sauf indication contraire. Accordez ces permissions aux joueurs non-OP si nécessaire.

Fonctionnalités et limites de modèle

Quelles sont les limites de taille et de rotation des modèles ?

Info

Limites de taille :

• La taille est vérifiée sur l'ensemble des cubes de chaque os, plutôt que sur le modèle entier
• Le convertisseur multiplie les coordonnées des cubes par 0.4 et recentre chaque os. Le seuil d'avertissement est 192 dans ces coordonnées mises à l'échelle ; il ne constitue pas une limite d'affichage vérifiée de 192 pixels de modèle ou de 12 blocs
• L'avertissement ne rejette ni ne redimensionne l'os. Si la géométrie ne s'affiche pas correctement, réduisez les cubes, rapprochez-les ou répartissez-les sur plusieurs os, puis examinez le modèle généré sur le client cible
• Un modèle peut s'étendre sur plusieurs os ; l'absence d'avertissement ne prouve pas la validité de la géométrie du pack généré

Limites de rotation des cubes :

• Minecraft 1.21.6 et plus récent : le convertisseur accepte un reste quelconque compris dans ±45° après décomposition de l'angle en une transformation de base (0°, ±90°, ±180°, intégrée à la géométrie). Gardez les angles créés dans la plage habituelle de −180° à 180° et examinez le résultat ; une décomposition acceptée ne vérifie pas l'affichage
• Minecraft 1.21.4 / 1.21.5 : le reste doit tomber sur une valeur que Minecraft accepte nativement (−45°, −22,5°, 0°, 22,5°, 45°), les angles autorisés sont donc 0°, ±22,5°, ±45°, ±67,5°, ±90°, ±112,5°, ±135°, ±157,5°, ±180° — tous les multiples de 22,5°
• Rotation sur un seul axe, sur toutes les versions. La boucle parcourt les axes de Z à X en remplaçant son choix : le premier axe non nul dans l'ordre X/Y/Z l'emporte
• Exemple : [22.5, 0, 45] conserve la rotation X et perd la rotation Z
• Un angle que FMM ne peut pas décomposer est journalisé sous la forme Could not decompose rotation angle ... for model name <model> et appliqué brut, ce qui rend généralement mal

Rotation des os :

• Les os supportent n'importe quel angle de rotation
• Rotation multi-axes supportée
• Les os visibles ajoutent du travail d'affichage et d'envoi de paquets par spectateur ; les os structurels et de métadonnées ne sont pas tous affichés

Note de performance :

Limitez si possible le nombre d'os visibles et de spectateurs. Java affiche les os visibles au moyen d'entités transmises par paquets ; le moteur Bedrock utilise une autre représentation. Le nombre d'os ne correspond pas au nombre d'entités Bukkit ordinaires.

Quelles animations sont prises en charge ?

Info

FreeMinecraftModels lie cinq noms d'animation à des états d'exécution automatiques :

Animations d'état :

• spawn — se joue une fois à la création du modèle, puis enchaîne sur idle
• idle : boucle jusqu'à ce que l'entité sous-jacente ait une vitesse non nulle sur X ou Z
• walk : boucle pendant le mouvement horizontal ; revient à idle lorsque l'entité est au sol avec une vitesse nulle sur X et Z
• attack — se joue une fois, puis revient à idle
• death — se joue une fois lors de la suppression via removeWithDeathAnimation()

Tout autre nom d'animation dans le modèle est une animation personnalisée : elle ne se déclenche jamais d'elle-même, mais peut être jouée par son nom depuis l'API ou depuis Lua.

À propos de jump

JUMP existe dans l'énumération AnimationStateType et l'état walk le demande bien lorsque l'entité quitte le sol, mais aucun état de saut n'est enregistré dans le gestionnaire d'animations : cette transition automatique ne fait donc actuellement rien. Une animation littéralement nommée jump fonctionne toujours si vous la déclenchez vous-même — elle passe simplement par le chemin des animations personnalisées, comme n'importe quel autre nom.

Comment ça fonctionne :

• Créez des animations dans BlockBench en utilisant les noms en minuscules ci-dessus afin que FMM les lie automatiquement à l'état correspondant
• Le plugin lit les keyframes d'animation depuis les fichiers .bbmodel à l'importation et les précalcule en images par tick
• Les animations d'état se déclenchent automatiquement en fonction de l'état de l'entité
• Les développeurs peuvent déclencher n'importe quelle animation programmatiquement en utilisant playAnimation(animationName, blend, loop) sur un ModeledEntity, ou context.prop:play_animation(name, blend, loop) depuis Lua

Les déguisements de joueurs sont différents :

Un modèle utilisé avec /fmm disguise sélectionne cinq noms — attack, jump, sneak, walk, idle — dans cet ordre de priorité avant l'exécution du moteur de lecture partagé. sneak et jump se déclenchent automatiquement sur les déguisements ; les modèles ordinaires peuvent toujours les jouer explicitement comme animations personnalisées. Les animations ponctuelles suspendent toute nouvelle sélection pendant 20 ticks. Sans idle, un modèle de déguisement produit un avertissement et peut rester sur la dernière image lorsqu'aucune autre action n'est active. Voir Déguisements des joueurs.

Voir Animations pour les modes de boucle, les types d'interpolation, le timing des keyframes et l'IK.

Cas spécial :

Les entités Evoker détectent les Evoker Fangs proches pour déclencher automatiquement les animations d'attaque.

Que sont les os virtuels et comment fonctionnent-ils ?

Info

Les os virtuels sont des os spéciaux avec des noms réservés qui ajoutent des fonctionnalités à vos modèles :

Os de hitbox :

• Nom : hitbox (nom exact, insensible à la casse)
• Crée des zones d'interaction et des boîtes de collision
• Son cube définit la largeur, la profondeur et la hauteur ; X et Z peuvent différer. Il ne modifie pas la hitbox d'un joueur déguisé
• Doit être un os de premier niveau dans l'outliner — un os hitbox imbriqué dans un autre groupe est traité comme un os ordinaire
• Doit contenir exactement un cube. Les cubes supplémentaires produisent has more than one value defining a hitbox! Only the first cube will be used ; un groupe vide produit has a hitbox bone but no hitbox cube! et laisse les dimensions à zéro. La position et la rotation du cube ne décalent pas la hitbox
• Jamais animé, jamais rendu, et exclu de l'export de géométrie Bedrock

Os de nametag :

• Préfixe : tag_
• Affiche du texte au-dessus des modèles
• Utilisé pour nommer les entités
• Ancrage facultatif créé par l'auteur. Sans cet os, la plaque de nom utilise une position de repli au-dessus de la hitbox. Consultez Pourquoi mon modèle n'a-t-il pas de nom ?
• L'os n'a besoin d'aucun cube ; c'est seulement un ancrage de position pour l'affichage de texte, généralement placé au-dessus de la tête

Os de rotation de tête :

• Préfixe : h_
• Tourne en fonction de la position de la tête du joueur/entité
• Suit le mouvement de la tête automatiquement

Os cachés / structurels :

• Préfixe : b_
• Masqués par le moteur d'affichage des os Java ; l'exportateur de géométrie Bedrock ne filtre pas les os b_
• Utilisez-les pour les os structurels, organisationnels ou purement descriptifs qui doivent tout de même participer à la hiérarchie du squelette sans produire de géométrie

Os de point de monture :

• Préfixe : m_
• Chaque os m_ devient une position de siège chevauchable sur le modèle, gérée par MountPointManager
• Le siège suit l'os à travers les animations
• Plusieurs os m_ créent plusieurs sièges
• Exclus de l'export de géométrie Bedrock
• Voir Que sont les os de point de monture ? ci-dessous

Utilisation :

Créez un os dans BlockBench avec l'un de ces noms spéciaux, et le plugin appliquera automatiquement la fonctionnalité correspondante.

FAQ de dépannage

Au lieu de modèles personnalisés, je ne vois que de l'armure de cheval.

Info

Une armure de cheval à la place du modèle signifie que l'apparence personnalisée attendue n'est pas appliquée. Vérifiez que FMM a généré le modèle, que le pack actuel le contient et que le client a téléchargé et accepté ce pack. Un conflit de fusion est une cause possible parmi d'autres.

MagmaGuy a développé un plugin appelé Resource Pack Manager (RSPM) qui peut fusionner automatiquement les resource packs pour vous. Vous pouvez le télécharger depuis Spigot ici.

RSPM peut fusionner, héberger et distribuer le pack généré. Suivez son guide d'installation, vérifiez les sources de packs activées et l'accessibilité de l'adresse d'hébergement, puis reconnectez un client et confirmez que le modèle apparaît.

Pourquoi est-ce que je ne vois pas mon modèle après avoir ajouté le fichier .bbmodel ?

Info

Si votre modèle n'apparaît pas, vérifiez ces problèmes courants :

1. Oublié de recharger

Exécutez /fmm reload après avoir placé les fichiers .bbmodel dans le dossier imports. Vérifiez la console : si la validation du contenu candidat échoue, le moteur actuel est conservé. La commande seule ne prouve donc pas que le nouveau contenu a été appliqué.

2. Resource pack non appliqué

Les joueurs doivent avoir le resource pack FMM actif pour voir les modèles.

• Vérifiez ~/plugins/FreeMinecraftModels/output/FreeMinecraftModels.zip pour le pack généré
• Installez Resource Pack Manager pour une distribution automatique
• OU distribuez manuellement via server.properties ou un service d'hébergement

3. Mauvais emplacement de fichier

Les imports de fichiers .bbmodel seuls vont directement dans ~/plugins/FreeMinecraftModels/imports/. Cette voie conserve la source et peut la reconvertir lors de rechargements ultérieurs. Elle n'importe pas les fichiers YAML voisins et ne parcourt pas les sous-dossiers arbitraires. Les modèles accompagnés d'autres fichiers peuvent être placés dans models/ ou arriver dans un import correctement empaqueté.

Si vous utilisez les packs de contenu officiels à la place, utilisez /fmm setup ou /fmm downloadall plutôt que de déposer les fichiers manuellement.

4. Le modèle contient des erreurs

Vérifiez les logs de console pour les messages d'erreur durant /fmm reload. Les problèmes courants incluent des rotations non supportées, des modèles surdimensionnés ou des problèmes de texture.

5. Problème de fusion de resource pack

Si le client possède un pack mais affiche encore le matériau de base, vérifiez la définition générée, les chemins de textures, le résultat fusionné et la version du pack du client. Resource Pack Manager peut gérer la fusion et la distribution, mais son installation seule ne prouve pas leur réussite.

6. Collision d'identifiant de modèle

Recherchez [FMM Models] Rejected normalized model ID collision dans la console. Deux fichiers de modèles ou plus se normalisent vers le même identifiant et ont un contenu différent : tous ont donc été rejetés. Voir Pourquoi mon modèle a-t-il été rejeté pour une collision d'identifiant ? ci-dessous.

Pourquoi mon modèle a-t-il été rejeté pour une collision d'identifiant ?

Info

FreeMinecraftModels normalise chaque nom de fichier de modèle avant de l'utiliser comme identifiant de modèle à l'exécution et comme nom de fichier dans le resource pack : il met le nom en minuscules, puis remplace chaque caractère hors de a-z, 0-9, ., _ et - par un underscore.

Cela signifie que tous ceux-ci se réduisent au même identifiant, my_table :

My Table.bbmodel
my table.bbmodel
my_table.bbmodel
MY_TABLE.bbmodel

Avant le début de la conversion, FMM balaie l'arborescence des modèles à la recherche de ces collisions. Si tous les fichiers en collision sont identiques octet par octet, par exemple le même modèle fourni par deux packs de contenu, FMM en charge une copie et ignore les autres sans avertissement. Sinon, tous les fichiers en collision sont rejetés, pas seulement les surnuméraires, de sorte que vous n'obtenez jamais un résultat imprévisible du type « c'est le dernier chargé qui l'emporte ». La console affiche :

[FMM Models] Rejected normalized model ID collision '<id>'. These files normalize to the same ID: <paths>. Rename the files so every normalized model ID is unique; no colliding model was loaded.

La correction : renommez les fichiers pour que leurs identifiants normalisés diffèrent, puis exécutez /fmm reload. L'avertissement liste les chemins absolus exacts concernés.

Comment l'éviter : utilisez des noms uniques en minuscules avec des underscores (stone_table.bbmodel) dans toute l'arborescence des modèles. Des dossiers différents ne rendent pas uniques des noms de base répétés, et un autre nom de fichier peut encore se normaliser vers le même identifiant.

Les modèles rejetés sont ignorés partout — aucune sortie dans le pack Java, ni bundle d'entités personnalisées Bedrock.

Pourquoi mon modèle n'a-t-il pas de nom ?

Le moteur actuel n'exige plus d'os tag_ pour afficher un nom. Il utilise le premier os de ce type par ordre alphabétique s'il existe ; sinon, il place le nom au-dessus de la hitbox du modèle.

Vérifiez que le plugin propriétaire définit un nom d'affichage non vide et n'a pas masqué la plaque de nom. Si le nom est mal placé, examinez la hitbox ou ajoutez un ancrage tag_name sans cube dans Blockbench. Plusieurs os de nom ne produisent pas de noms répétés. Consultez la création des plaques de nom.

ViaVersion peut entraîner un affichage incorrect des resource packs.

Info

FreeMinecraftModels nécessite actuellement un serveur Minecraft 1.21.4 ou plus récent. Autoriser des clients récents au moyen d'un traducteur de protocole ne rend pas un ancien serveur compatible avec FMM.

Pour diagnostiquer un problème de pack, commencez par le reproduire avec un client de la même version que le serveur pris en charge. Vérifiez qu'il a téléchargé le pack actuel et peut afficher son format de modèles d'objets, puis comparez le comportement du client utilisant la traduction de protocole. Relevez les versions du serveur, du client et du plugin de protocole plutôt que d'attribuer systématiquement les modèles manquants à ViaVersion.

Pourquoi mes modèles provoquent-ils des ralentissements ou des problèmes de performance ?

Info

Les modèles comportant beaucoup d'os visibles ajoutent du travail de transformation, d'envoi de paquets et d'affichage côté client. Le nombre de spectateurs compte aussi.

Conseils d'optimisation :

• Minimisez le nombre d'os dans vos modèles
• Limitez le nombre de modèles apparaissant
• Utilisez des modèles statiques lorsqu'aucune entité vivante sous-jacente n'est nécessaire ; les modèles statiques peuvent tout de même être animés
• Évitez de faire apparaître de nombreux modèles à grand nombre d'os à proximité

Explication technique :

L'affichage Java utilise des entités transmises par paquets pour les os, en excluant les voies d'affichage masquées ou réservées aux métadonnées. Le moteur Bedrock peut représenter un modèle entier par une entité personnalisée. Un modèle de 50 os ne crée pas forcément 50 entités serveur ordinaires et n'envoie pas forcément 50 entités visibles à chaque client.

Bonnes pratiques :

• Concevez des modèles avec moins d'os
• Testez les performances avec des nombres d'apparition réalistes
• Surveillez le TPS du serveur lors de l'ajout de nouveaux modèles

Comment le mesurer :

Exécutez /fmm packetdebug 20 dans la zone concernée. La commande compte les paquets et leur diffusion par spectateur pendant les 20 prochains ticks de l'horloge des modèles, avec les destinataires les plus sollicités et les types de paquets. Ces chiffres aident à examiner le trafic ; ils ne constituent ni un profil CPU ni une preuve d'affichage des paquets par les clients.

Optimisations de paquets intégrées :

Trois clés de config.yml contrôlent les optimisations côté paquets. Toutes utilisent par défaut le comportement optimisé — les réglages alternatifs existent pour le débogage, pas comme conseil de réglage :

• skipUnchangedBoneUpdates (défaut true) — ignore les mises à jour de transformation inchangées, sauf si l'os a été explicitement marqué comme modifié, par exemple pour une teinte. Cela ne supprime pas tout traitement du modèle ni tout trafic lié aux spectateurs
• useDeltaMetadataPackets (défaut true) — le paquet de métadonnées par tick ne transporte que la transformation modifiée au lieu de re-sérialiser tout le bloc d'affichage d'item
• maxModelsForProximityOverride (défaut 25) — les modèles à moins de 10 blocs sont normalement toujours affichés, en sautant le raytrace de ligne de vue pour éviter les apparitions brusques. Dès qu'un monde contient ce nombre de modèles chargés, cette surcharge est désactivée dans ce monde afin que l'élimination par occlusion s'exécute même de près. C'est la clé à examiner pour les hubs de PNJ à plusieurs étages où les joueurs devenaient spectateurs de modèles situés à d'autres étages

Voir Configuration pour les descriptions complètes.

Fonctionnalités avancées

Ai-je besoin de Resource Pack Manager (RSPM) ?

Info

Resource Pack Manager (RSPM) est optionnel mais fortement recommandé.

Ce que fait RSPM :

• Fusionne automatiquement les resource packs de plusieurs plugins
• Héberge les resource packs (pas besoin d'hébergement externe)
• Distribue les packs aux joueurs automatiquement à la connexion
• Réduit la gestion manuelle des packs ; il faut toujours vérifier la sélection des sources, l'hébergement et l'acceptation par les clients

Sans RSPM :

Vous devez manuellement :

• Fusionner le resource pack FMM avec tout resource pack serveur existant
• Héberger le pack fusionné à une URL de téléchargement accessible
• Configurer server.properties ou un autre expéditeur de packs pour transmettre cette URL aux joueurs ; server.properties n'héberge pas de fichiers
• Mettre à jour le pack chaque fois que vous ajoutez de nouveaux modèles

Pourquoi utiliser RSPM :

RSPM fournit un processus commun pour fusionner, héberger et envoyer les packs. Lorsqu'un modèle manque, vérifiez le résultat généré et son affichage sur un vrai client.

Téléchargez RSPM : https://www.spigotmc.org/resources/resource-pack-manager.118574/

Développé par MagmaGuy, le même auteur que FreeMinecraftModels.

Puis-je utiliser FreeMinecraftModels dans mon propre plugin ?

Info

Oui, FreeMinecraftModels fournit une API pour les développeurs.

Intégration Maven/Gradle :

Dépôt : https://repo.magmaguy.com/releases

Artefact :

• GroupId : com.magmaguy
• ArtifactId : FreeMinecraftModels
• Scope : provided (doit être installé sur le serveur, ne pas shade)

Classes API principales :

• ModeledEntity (classe de base)
• StaticEntity
• DynamicEntity
• PropEntity

Exemple d'utilisation :

StaticEntity staticEntity = StaticEntity.create(id, location);
if (staticEntity == null) {
    Bukkit.getLogger().warning("Failed to create model");
    return;
}
staticEntity.setRightClickCallback(...);
staticEntity.remove();

Important :

Ne shadez pas FreeMinecraftModels dans votre plugin. Il doit être installé séparément sur le serveur.

Pour une documentation API détaillée, voir le README officiel.

Comment déguiser un joueur en modèle personnalisé ?

Info

La commande /fmm disguise transforme l'apparence d'un joueur en n'importe quel modèle personnalisé.

Commandes :

/fmm disguise <modelID> [player]
/fmm undisguise [player]
/fmm disguiselist

Comment ça fonctionne :

• Rend le joueur invisible aux autres joueurs
• Superpose le modèle personnalisé sur la position du joueur
• Le modèle suit les mouvements du joueur
• Parfait pour les serveurs de roleplay ou les événements spéciaux

Exemples :

/fmm disguise dragon              # Disguise yourself
/fmm disguise dragon Steve         # Disguise another player
/fmm undisguise Steve              # Undisguise Steve
/fmm disguiselist                  # List everyone currently disguised

Prérequis :

• Auto-ciblage : freeminecraftmodels.disguise.self (défaut : OP)
• Les commandes disguise et undisguise visant un joueur nécessitent à la fois freeminecraftmodels.disguise.self et freeminecraftmodels.disguise.others. disguiselist ne nécessite que .others.
• La console peut exécuter la forme ciblée tant qu'un nom de joueur est fourni
• modelID doit correspondre exactement à un modèle chargé
• Les plugins tiers peuvent piloter les déguisements via la DisguiseAPI publique

Notes :

• La hitbox du joueur reste inchangée (même boîte de collision)
• Les autres joueurs voient le modèle personnalisé au lieu de votre skin de joueur
• Déguiser à nouveau alors qu'il est déjà déguisé remplace proprement le déguisement précédent
• FMM rétablit l'invisibilité après les changements d'effets concernés uniquement si ce déguisement avait ajouté l'effet. Un effet préexistant n'est pas rétabli. Voir Déguisements des joueurs

Comment créer des objets de modèle plaçables ?

Info

La commande /fmm itemify crée des objets spéciaux que les joueurs peuvent utiliser pour placer des modèles dans le monde.

Commande :

/fmm itemify <model> <material>

Paramètres :

• model - Tout ID de modèle valide depuis votre dossier models
• material - Tout matériau Minecraft (STICK, PAPER, DIAMOND, etc.)

Exemple :

/fmm itemify lamp_post STICK

Ce qu'il crée :

• Un objet personnalisé avec un nom d'affichage décoré or formaté (par ex. « ✦ Wolf ✦ »)
• Du lore descriptif expliquant l'objet
• L'objet est ajouté directement à votre inventaire ; laissez de la place, car le surplus n'est pas déposé au sol
• Faites un clic droit depuis la main principale pour placer le prop, sous réserve des vérifications de placement de FMM. Hors mode créatif, l'objet est consommé après une apparition réussie

Cas d'utilisation :

• Donner aux joueurs des objets pour décorer leurs constructions
• Créer des « œufs de spawn » personnalisés pour le mobilier
• Distribuer des objets de placement tout en conservant les vérifications de protection configurées
• Kits de configuration pour la construction créative

Prérequis :

• Permission : freeminecraftmodels.*
• Le joueur doit être en jeu (pas la console)

Comment déboguer les hitboxes des modèles ?

Info

La commande /fmm hitbox visualize visualise les hitboxes de modèle avec des particules.

Commande :

/fmm hitbox visualize [duration]

Paramètres :

• duration est facultatif et vaut 100 ticks par défaut. Une valeur nulle ou négative donne 100 ticks ; le maximum est 1200
• 20 ticks = 1 seconde

Exemples :

/fmm hitbox visualize 100      # Show for 5 seconds
/fmm hitbox visualize 200      # Show for 10 seconds

Comment ça fonctionne :

• Recherche les modèles dans un rayon de 10 blocs autour de vous
• Affiche les limites de la boîte englobante orientée (OBB) avec des particules
• Montre à la fois le modèle et ses limites de collision
• Utile pour vérifier la taille et la rotation de hitbox

La détection des projectiles teste le segment entre les positions suivies pour détecter les traversées d'OBB fines ; sans position précédente, elle teste le chevauchement. Les impacts sont traités du plus proche au plus éloigné. Un projectile ordinaire dispose d'un impact sur une cible modélisée ; une flèche avec Perforation dispose de pierce level + 1 impacts sur des cibles modélisées distinctes. Annuler l'impact empêche son callback ou les dégâts par défaut, mais consomme tout de même cette cible dans le budget. Voir l'API des projectiles.

Quand utiliser :

• Tester si les hitboxes correspondent aux modèles visuels
• Déboguer les problèmes d'interaction
• Vérifier les rotations de hitbox
• Dépanner la détection de clic

Prérequis :

• Permission : freeminecraftmodels.*

Note : Les hitboxes dans FMM tournent avec le modèle, contrairement aux AABBs Minecraft standard.

Puis-je créer des modèles personnalisés chevauchables ?

Info

Oui, utilisez la commande /fmm mount pour créer des modèles personnalisés chevauchables (fonctionnalité expérimentale).

Commande :

/fmm mount <modelID>

Ce qu'elle fait :

• Fait apparaître un cheval à votre position
• Déguise le cheval en votre modèle personnalisé
• Apprivoise automatiquement le cheval et ajoute une selle
• Tente de vous faire monter un tick plus tard : directement sur le cheval sans point de monture, ou par un porte-armure marqueur si le modèle possède un point de monture

Exemple :

/fmm mount dragon

Prérequis :

• Permission : freeminecraftmodels.*
• ID de modèle valide

Notes importantes :

• Cette fonctionnalité est marquée comme expérimentale
• Utilise un cheval adulte apprivoisé avec une vitesse de base de 0.3 et une force de saut de base de 0.7
• La hitbox du cheval reste inchangée
• Fonctionne mieux avec des modèles conçus pour les montures

Cas d'utilisation :

• Montures personnalisées pour serveurs de roleplay
• Transport spécial pour joueurs VIP
• Créatures chevauchables uniques pour cartes d'aventure

Que sont les os de points de monture ?

Info

Les points de monture vous permettent de définir des positions chevauchables directement sur votre modèle en utilisant des os spécialement nommés.

Comment créer des points de monture :

Dans Blockbench, nommez un os avec le préfixe sensible à la casse m_ (par ex. m_seat, m_back). Chacun définit une position de siège gérée pour un joueur.

Comment ça fonctionne :

• La position de monture suit l'emplacement de l'os, y compris les animations
• Plusieurs os m_ créent plusieurs sièges
• Le gestionnaire accepte des joueurs via l'API ou les scripts Lua et choisit le premier siège libre. Les sièges utilisent des entités Interaction temporaires de taille nulle, mises à jour lorsqu'ils sont occupés

Test :

Pour un siège de prop, faites apparaître ou placez le prop et cliquez dessus avec le bouton droit, ou appelez context.prop:mount(player) en Lua. /fmm mount <modelID> crée une monture expérimentale reposant sur un cheval ; c'est un mécanisme de monture distinct.

Cas d'utilisation :

• Véhicules à plusieurs sièges (bateaux, calèches)
• Créatures chevauchables avec positions de siège spécifiques
• Animaux ou compagnons montés sur l'épaule

Objets personnalisés

Que sont les objets personnalisés ?

Les objets personnalisés sont des objets tenus définis par un champ material: dans le YAML voisin du modèle. Ils portent l'identité fmm_item_id, tandis que les objets de placement de props créés par /fmm itemify portent model_id.

Créez un modèle et un YAML de même nom, définissez material, puis ajoutez éventuellement name, lore et des enchantments avec espace de noms :

isEnabled: true
material: DIAMOND_SWORD
name: "&6Flame Blade"
enchantments:
  - "minecraft:fire_aspect,2"

Utilisez /fmm giveitem <id> ou /fmm admin avec freeminecraftmodels.admin.

Les objets personnalisés exécutent-ils encore des scripts Lua ?

Non. L'ancien moteur d'objets équipés et ses 22 hooks ont été retirés. Une définition d'objet tenu avec une liste scripts: non vide est ignorée, tout comme une ancienne entrée d'enchantement sans espace de noms telle que FIRE_ASPECT,2. Le fichier n'est ni converti ni réécrit. Les scripts Lua des props restent inchangés.

Utilisez les enchantements gérés par des fournisseurs pour les effets des objets et les définitions d'armes magiques pour les baguettes et les bâtons.

Menus

Quels menus FMM fournit-il ?

Info

FreeMinecraftModels fournit ces deux menus de navigation, ainsi que des menus distincts pour la configuration, la création de recettes et la boutique optionnelle.

Menu joueur — /fmm

• Permission : freeminecraftmodels.menu (défaut : true, tous les joueurs peuvent l'utiliser)
• N'affiche que les entrées dont les recettes ont été enregistrées avec succès ; registerCraftingRecipes: false les retire de ce navigateur
• Cliquez sur un objet pour voir une vue détaillée avec un aperçu de grille de craft spatiale 3x3
• Permet d'examiner les recettes des objets en papier servant à placer des props ; ils sont distincts des objets tenus définis par l'auteur

Menu admin — /fmm admin

• Permission : freeminecraftmodels.admin (défaut : OP)
• Navigateur de contenu complet affichant :
  • Les packs activés dont le contenu est chargé
  • Les dossiers de modèles non packagés
  • Les modèles au niveau racine
  • Les objets personnalisés enregistrés avec succès
• Les entrées de packs et de dossiers ouvrent des listes ; les entrées individuelles donnent des objets. Utilisez /fmm setup pour activer et télécharger des packs

Modèles d'affichage

Que sont les modèles d'affichage ?

Info

Les modèles d'affichage permettent aux objets personnalisés d'afficher un modèle 3D dans l'inventaire et la main du joueur, au lieu de l'apparence par défaut du matériau.

Comment configurer un modèle d'affichage :

1. Dans Blockbench, utilisez File > Export > Java Block/Item pour exporter un fichier de modèle .json
2. Placez le fichier .json à côté du fichier .bbmodel avec le même nom de base (par ex. magic_sword.json à côté de magic_sword.bbmodel)
3. Exécutez /fmm reload

Comment ça fonctionne :

• Un modèle d'affichage enregistré peut remplacer l'apparence en main ou dans l'inventaire lorsque le client accepte le pack généré
• Les références de texture sans espace de noms utilisent la clé numérique correspondante de la table. Si elle manque, une texture extraite disponible est utilisée, sans garantie qu'il s'agisse de l'index zéro. Les références avec espace de noms sont conservées
• Si aucun fichier .json n'existe, l'objet retombe sur l'apparence simple du matériau
• Le plugin actuel nécessite Minecraft 1.21.4 ou plus récent ; les anciennes branches de rendu ne rendent pas les serveurs antérieurs compatibles

Prérequis :

• Serveur exécutant Minecraft 1.21.4 ou plus récent
• Un export Blockbench « Java Block/Item » valide (.json) placé à côté du modèle ; un JSON mal formé n'est pas enregistré. Les groupes d'états d'arcs et d'arbalètes nécessitent tous les modèles d'état et fichiers JSON d'affichage correspondants