Aller au contenu principal

Avant de commencer !

FreeMinecraftModels (FMM) est actuellement en développement actif ! Cela signifie que certaines fonctionnalités ne sont pas encore terminées et font activement l'objet de travaux.

Cependant, à l'heure actuelle, le cœur du plugin est entièrement fonctionnel - la conversion des fichiers bbmodel, la génération de packs de ressources, l'apparition d'entités en jeu et la gestion de leurs animations, la capacité de placer des accessoires persistants, tout cela fonctionne principalement.

Envisagez de soutenir le développement sur https://www.patreon.com/magmaguy !

Le contenu des packs de ressources exportés est sous licence CC0 du côté de FreeMinecraftModels, aucun droit réservé. Vous êtes libre d'utiliser, de distribuer, de modifier à toutes fins sans restrictions ni besoin d'attribution.

Utilisation de ce plugin

Que peut faire FreeMinecraftModels (FMM) pour les administrateurs de serveur Minecraft ?

Il peut :

  • Importer des modèles .bbmodel ou fmmodel (format personnalisé de FFM)
  • Générer des packs de ressources avec des modèles qui dépassent les limites normales des packs de ressources Minecraft (jusqu'à 112x112x112 unités ou 7x7x7 blocs en jeu, fonctionnellement illimité lors de l'utilisation de plusieurs os)
  • Afficher ces modèles en jeu, en envoyant des paquets spécifiques compatibles avec bedrock aux clients bedrock tout en envoyant également des entités d'affichage aux clients java 1.19.4+
  • Animer ces modèles comme ils ont été configurés pour être animés dans Blockbench
  • Gérer les animations d'état par défaut sans nécessiter d'autres plugins (marche, inactif, mort, attaque, apparition)
  • Gérer les boîtes de collision qui tournent avec l'entité sous-jacente et ont un axe x et z différent
  • Gérer trois types de modèles : statiques, dynamiques et accessoires
    • Les accessoires sont persistants et peuvent être placés dans le monde de manière à persister même si le serveur est redémarré, et il est possible de distribuer des cartes avec des accessoires vers d'autres serveurs
    • Les modèles dynamiques sont destinés aux modèles qui ont besoin d'une entité vivante sous-jacente pour fonctionner, idéalement utilisés par des plugins de boss personnalisés ou des plugins d'animaux de compagnie
    • Les modèles statiques sont destinés aux modèles non persistants qui ne devraient pas se déplacer, donc essentiellement des décorations ou effets temporaires

Comment ajouter un modèle existant ?

Pour importer un modèle, il suffit de glisser le fichier .bbmodel dans le dossier imports et de faire /fmm reload. Cela générera un fichier .fmmodel dans le dossier models et ajoutera le modèle au pack de ressources dans le dossier outputs.

Vous devrez utiliser ce pack de ressources pour visualiser le modèle correctement ! C'est un pack de ressources normal, donc tout ce que vous devez faire est de le mettre dans votre dossier de packs de ressources. Les serveurs Minecraft ont un moyen d'héberger des packs de ressources. Je recommande d'utiliser mon plugin, ResourcePackManager, qui récupère automatiquement les fichiers et les héberge à distance pour vous, les fusionnant même avec les fichiers d'autres plugins.

Comment visualiser le modèle en jeu ?

Il est important de noter que bien que FreeMinecraftModels puisse être utilisé comme un plugin autonome pour visualiser des accessoires (essentiellement des modèles personnalisés que vous pouvez placer dans le monde), le plugin est généralement à son meilleur lorsqu'il est associé à un plugin tel que EliteMobs où les modèles sont activement utilisés pour quelque chose de concret, dans ce cas des combats de boss.

Il existe trois types de modèles : statiques, dynamiques et accessoires.

  • Les accessoires sont persistants et peuvent être placés dans le monde de manière à persister même si le serveur est redémarré, et il est possible de distribuer des cartes avec des accessoires vers d'autres serveurs
  • Les modèles dynamiques sont destinés aux modèles qui ont besoin d'une entité vivante sous-jacente pour fonctionner, idéalement utilisés par des plugins de boss personnalisés ou des plugins d'animaux de compagnie
  • Les modèles statiques sont destinés aux modèles non persistants qui ne devraient pas se déplacer, donc essentiellement des décorations ou effets temporaires

Visualisation des modèles statiques en jeu

Pour visualiser les modèles statiques en jeu, utilisez la commande /fmm spawn static <id> où l'id est le nom du fichier du modèle, en minuscules et sans l'extension de fichier.

Visualisation des modèles dynamiques en jeu

Pour visualiser les modèles dynamiques en jeu, utilisez la commande /fmm spawn dynamic <id> où l'id est le nom du fichier du modèle, en minuscules et sans l'extension de fichier.

Visualisation des accessoires en jeu

Pour visualiser les modèles dynamiques en jeu, utilisez la commande /fmm spawn prop <id> où l'id est le nom du fichier du modèle, en minuscules et sans l'extension de fichier.

Que peut faire FreeMinecraftModels (FMM) pour les modélisateurs ?

FMM suit les règles standard des packs de ressources pour la génération de packs de ressources. De plus, il essaie d'être aussi compatible que possible avec les modèles compatibles avec ModelEngine afin d'essayer de normaliser la création de modèles entre les plugins.

Fonctionnalités / restrictions de génération de modèles

Si vous avez déjà créé des modèles pour ModelEngine, vous serez familier avec beaucoup des restrictions de génération de packs de ressources Minecraft :

Cubes :

Les cubes sont les mêmes ici que dans Blockbench, ce sont les cubes qui composent le modèle.

  • Les cubes peuvent aller jusqu'à 112x112x112 "pixels" (unités Blockbench) ou 7x7x7 blocs en jeu (restrictions normales de Minecraft contournées en utilisant des tailles d'affichage, bientôt à être encore plus contournées pour 1.19.4+ grâce aux entités d'affichage)
  • Les rotations légales pour les cubes sont 0, 22.5, -22.5, 45 et -45. Aucune autre rotation ne fonctionne.
  • Les cubes ne tournent que dans un axe, ce qui signifie qu'une rotation de [22.5, 0, 0] est correcte, une rotation de [22.5, 0, 45] ne fonctionnera pas complètement et ne tournera que sur un axe.

Os :

Les os sont ce que Blockbench appelle des "groupes". Ils servent à regrouper les cubes ensemble, et devraient être utilisés pour regrouper les os ensemble pour les animationsBlueprint.

  • Les os peuvent aller jusqu'à 112x112x112 "pixels" (unités Blockbench) ou 7x7x7 blocs en jeu. Veuillez noter que la taille des os est définie par ce qu'ils contiennent, donc si vous avez des cubes qui sont à plus de 7 blocs l'un de l'autre, vous dépasserez probablement cette limite de taille. Contourner cette limite est aussi simple que de mettre les blocs dans un boneBlueprint différent non contenu dans le premier boneBlueprint !
  • Peuvent avoir n'importe quelle rotation ! Cependant, il est recommandé d'éviter d'utiliser des rotations par défaut de 90, -90, 180 et -180, car celles-ci peuvent souvent conduire à un comportement inattendu. Notez que cela ne s'applique pas vraiment aux animations, juste à la position de repos par défaut des os.

Les os sont nettement plus flexibles que les cubes, mais vous devriez utiliser le moins d'os possible ! Dans FMM, en raison des limitations de Minecraft, chaque os est une entité différente. À grande échelle, cela affectera assez rapidement les performances ! Utilisez toujours le moins d'os possible, et soyez conscient du nombre de ce modèle que vous prévoyez de faire apparaître - plus vous en prévoyez, moins vous devriez avoir d'os !

Os virtuels

Les Os virtuels est une terminologie de model engine pour les os qui ont des métadonnées spécifiques, généralement sous la forme d'un nom spécifique, qui est utilisé dans un but précis.

Les os virtuels suivants ont été implémentés dans FreeMinecraftModels :

  • Boîtes de collision / hauteur des yeux : un os appelé "hitbox" avec un cubeBlueprint qui définit les limites, et a la même valeur x et z (la plus grande valeur sera choisie si elles ne sont pas identiques) définit la boîte de collision. Le niveau des yeux est défini au point de pivot du boneBlueprint de la boîte de collision.
  • Étiquette de nom : un os dont le nom commence par "tag_". Honnêtement, je préférerais être plus spécifique ici et aller avec " tag_name" afin d'utiliser des balises pour d'autres choses, mais cela sera sérieusement envisagé plus tard.
  • Tête : un os dont le nom commence par h_ . C'est un os virtuel qui est utilisé pour définir la tête du modèle, qui tournera en fonction de la rotation de la tête de l'entité sous-jacente.

Distribution de fichiers plus sûre, plus facile et non modifiable

Une chose que FMM essaie d'aborder est le réutilisage par les utilisateurs de modèles qu'ils ont obtenus pour les modifier de manière que le créateur du modèle ne voulait pas qu'ils modifient, spécifiquement afin de reconfigurer ou autrement modifier légèrement un modèle et potentiellement essayer de le revendre comme une création originale.

À cette fin, FMM utilise le format de fichier .fmmodel qui vise à réduire les fichiers .bbmodel au point où ils peuvent être utilisés par le plugin mais ne peuvent pas être modifiés dans Blockbench.

En tant que modélisateur, vous avez maintenant le choix de publier un fichier .fmmodel non modifiable, un fichier .bbmodel modifiable ou même de faire une tarification différentielle ou des conditions d'utilisation de distribution pour les deux.

Générer un .fmmodel est aussi simple que de mettre votre .bbmodel dans le dossier ~/plugins/FreeMinecraftModels/imports et de recharger le plugin avec /fmm reload ou de redémarrer le serveur. Votre .fmmodel se trouvera alors dans le dossier ~/plugins/FreeMinecraftModels/models.

Que peut faire FreeMinecraftModels (FMM) pour les développeurs qui souhaitent l'intégrer dans leurs plugins ?

FMM a un dépôt maven ! Maven:


<repository>
<id>magmaguy-repo-releases</id>
<name>MagmaGuy's Repository</name>
<url>https://repo.magmaguy.com/releases</url>
</repository>

<dependency>
<groupId>com.magmaguy</groupId>
<artifactId>FreeMinecraftModels</artifactId>
<version>LATEST.VERSION.HERE</version>
</dependency>

Gradle:

maven {
name = "magmaguyRepoReleases"
url = uri("https://repo.magmaguy.com/releases")
}

compileOnly group : 'com.magmaguy', name: 'FreeMinecraftModels', version: 'LATEST.VERSION.HERE'

Notez que FreeMinecraftModels est destiné à être utilisé comme une API, et nécessitera l'installation du plugin sur le serveur. Ne l'intégrez pas dans votre plugin !

Utilisation de l'API

FMM vise à être aussi facile que possible à utiliser en tant qu'API.

Pour le moment, si vous souhaitez utiliser FreeMinecraftModels comme une API pour avoir accès à l'utilisation de modèles personnalisés, il n'y a que quatre classes que vous devez connaître :

  • ModeledEntity - la classe de base pour toutes les entités
  • StaticEntity - pour quand vous voulez utiliser un modèle statique non permanent
  • DynamicEntity - pour quand vous voulez déguiser une autre entité vivante avec un modèle
  • PropEntity - pour quand vous voulez placer un modèle dans le monde qui persiste même si le serveur est redémarré

Voici un extrait pour gérer un modèle statique :

import org.bukkit.Bukkit;

public class FreeMinecraftModelsModel {
private StaticEntity staticEntity = null;

//Create the model
public FreeMinecraftModelsModel(String id, Location location) {
//This spawns the entity!
staticEntity = StaticEntity.create(id, location);
//This checks if the entity spawned correctly
if (staticEntity == null) Bukkit.getLogger().warning(("FMM failed to find a model named " + id + " !"));
}

public void remove() {
//This removes the entity
staticEntity.remove();
}
}

Gardez à l'esprit que les modèles statiques sont destinés à rester en place et à agir comme un élément décoratif dans un emplacement fixe ( les animations ne comptent pas comme 'mouvement' ici). Bien qu'il soit possible de les déplacer, envisagez si vous ne voudriez pas plutôt utiliser un modèle dynamique si tel est votre objectif.

Et voici comment EliteMobs, mon plugin de boss personnalisés, utilise les entités dynamiques :

package com.magmaguy.elitemobs.thirdparty.custommodels.freeminecraftmodels;

import com.magmaguy.elitemobs.thirdparty.custommodels.CustomModelInterface;
import api.com.magmaguy.freeminecraftmodels.ModeledEntityManager;
import customentity.com.magmaguy.freeminecraftmodels.DynamicEntity;
import lombok.Getter;
import org.bukkit.entity.LivingEntity;

public class CustomModelFMM implements CustomModelInterface {
@Getter
private DynamicEntity dynamicEntity;

public CustomModelFMM(LivingEntity livingEntity, String modelName, String nametagName) {
dynamicEntity = DynamicEntity.create(modelName, livingEntity);
if (dynamicEntity == null) return;
dynamicEntity.setName(nametagName);
}

public static void reloadModels() {
ModeledEntityManager.reload();
}

public static boolean modelExists(String modelName) {
return ModeledEntityManager.modelExists(modelName);
}

@Override
public void shoot() {
if (dynamicEntity.hasAnimation("attack_ranged")) dynamicEntity.playAnimation("attack_ranged", false);
else dynamicEntity.playAnimation("attack", false);
}

@Override
public void melee() {
if (dynamicEntity.hasAnimation("attack_melee")) dynamicEntity.playAnimation("attack_melee", false);
else dynamicEntity.playAnimation("attack", false);
}

@Override
public void playAnimationByName(String animationName) {
dynamicEntity.playAnimation(animationName, false);
}

@Override
public void setName(String nametagName, boolean visible) {
dynamicEntity.setName(nametagName);
dynamicEntity.setNameVisible(visible);
}

@Override
public void setNameVisible(boolean visible) {
dynamicEntity.setNameVisible(visible);
}

@Override
public void switchPhase() {
dynamicEntity.stopCurrentAnimations();
}
}

Les modèles dynamiques sont construits sur une entité vivante, qui peut être fournie soit lors de l'utilisation de la méthode create comme dans l'exemple ci-dessus, soit lors de l'exécution de la méthode spawn sur une entité Dynamic.

Contribuer au projet FreeMinecraftModels (FMM) en tant que développeur

FMM est distribué sous licence GPLV3 et les contributions de code sont les bienvenues. Voici les directives de contribution de base :

  • Suivez les conventions de nommage existantes, maintenez le niveau de verbosité existant et ajoutez suffisamment de documentation pour que votre contribution soit facile à comprendre
  • Gardez les contributions pertinentes par rapport à la portée du plugin. Si vous ne savez pas si cela sera pertinent, n'hésitez pas à demander à l'avance.
  • Soyez conscient de l'impact sur les performances de votre code. Certaines contributions peuvent être refusées si elles sont soit trop non optimisées ou causent autrement un impact trop important sur les performances.

Structure générale du plugin

Pour vous faire gagner du temps, voici une ventilation rapide du flux logique de FMM :

  1. Lire le dossier imports
  2. Déplacer les fichiers du dossier imports dans le dossier models. Si le fichier est un .bbmodel, il est converti en .fmmodel dans le dossier models.
  3. Lire les fichiers dans le dossier models.
  4. Interpréter toutes les structures de modèles, en créant des Skeletons qui contiennent des groupes de Bones, et ces os contiennent des groupes de Bones enfants et de Cubes. Les Cubes et les Bones génèrent les données JSON du pack de ressources auxquelles ils sont chacun liés. Cela signifie que les Cubes génèrent le JSON spécifique aux cubes et les Bones génèrent l'aperçu et les fichiers individuels de boneBlueprint. Notez qu'un boneBlueprint résulte en un fichier de pack de ressources. Les modèles sont ajoutés à une liste au fur et à mesure qu'ils sont générés.
  5. Toujours dans le Skeleton, interpréter toutes les Animations dans le modèle, le cas échéant
  6. Toutes les données ont maintenant été initialisées, le pack de ressources a été généré dans le dossier outputs et le plugin est prêt à être utilisé.

Astuces utilisées dans ce plugin :

Les astuces utilisées ici sont assez bien établies et normalisées, mais seront listées néanmoins car elles peuvent être contre-intuitives.

Veuillez noter que ces astuces sont toutes complètement invisibles pour les utilisateurs et les créateurs de modèles ; les restrictions et les solutions de contournement sont uniquement listées pour vous aider à comprendre comment FMM contourne diverses limitations de Minecraft.

  • Tous les modèles sont agrandis de 4x puis la taille et le point de pivot sont réajustés dans le code afin d'étendre la taille maximale théorique du modèle
  • Parce que les modèles de packs de ressources ne peuvent avoir que des modèles allant de -16 à +32 en taille, les modèles sont décalés en arrière-plan. Cela est complètement invisible pour les joueurs.
  • L'armure en cuir pour chevaux est utilisée pour créer des modèles avec une teinte qui peut être influencée par le code (c'est-à-dire pour les indications de dégâts). L'armure de cheval doit être définie sur blanc pour afficher les couleurs correctes !
  • Blockbench utilise un système spécifique d'IDs pour les textures, mais lit en fait les textures séquentiellement depuis la config. Les IDs sont attribués ici en fonction de leur position dans la liste des textures, suivant la façon dont Blockbench le fait.
  • Chaque os est une entité différente en raison des limitations de Minecraft
  • L'armure en cuir pour chevaux est sur l'emplacement de tête du support d'armure
  • Les supports d'armure et les entités d'affichage sont utilisés pour les éléments statiques par défaut ; les clients bedrock obtiennent les supports d'armure, et les clients 1.19.4+ obtiennent les entités d'affichage (les clients plus anciens obtiendront des supports d'armure)

Contribuer au projet FreeMinecraftModels (FMM) en général

FMM est en fait financé par les merveilleuses personnes sur https://www.patreon.com/magmaguy ! Toutes les contributions aident plus que vous ne l'imagineriez ;)

Fonctionnalités actuellement prévues :

  • Génération de RSP pour client Bedrock
  • Gestion RSP avec intégration geyser
  • tag_projectile comme méta-os à partir desquels des projectiles peuvent être lancés (peut avoir plus d'un par modèle)

Limitations étranges actuelles qu'il serait bon de corriger :

  • La TransformationMatrix est un désordre, mais aucune meilleure solution n'a été développée pour le moment. Elles ont besoin de travail de la part de quelqu'un qui est bon en matrices.