#Prélude(Prélude)
Nous sommes ici dans une section présentation des mod en développement.
De ce fait, nous n’entameront pas une présentation user-friendly avec de ‘zolie image y tout’, mais une présentation très technique.
Le code sources est disponible à l’adresse suivante : https://github.com/Jodge65/ElementalLibrary.
Si vous avez des remarques, des suggestions, des améliorations, n’hésitez surtout pas !
Ce nom peut vous inspirez beaucoup de chose, mais un seul mot importe : ‘Elemental’.
Vous l’aurez peut-être devinez, le but de ce mod est d’ajouter un principe d’élément, entraînant alors Faiblesse & Résistance.
Ce mod, bien qu’il puisse fonctionner seul, aura pour vocation d’être accompagné d’autre mod qui lui permettrons alors de dévoilé toute sa puissance.
Il faut dire qu’as l’heure actuel, à part quelque changement sur les valeurs final de dommage (ce qui peut changer le nombre de coup nécessaire pour tuer), les changements sont invisible a l’œil nus.
#Fonctionnement(Fonctionnement)
Ce mod modifie fondamentalement la méthode de calcul des dégâts.
Il utilise pour ça des matrices d’éléments.
Le principe est assez simple :
Entité A attaque Entité B avec une Arme C, le tous situé dans un environnement D avec :
On effectue alors le calcul de matrice simple : C x A x B x D.
Dans un souci pratique, et afin d’évité la division par 0, on ne divise pas B (matrice de résistance) mais on suppose que toute résistance < 1.0F réduira les dommages.
On addition ensuite chaque valeur positive dans une variable dommage, et chaque valeur négative dans une variable soin.
La variable dommage sert simplement à faire le lien avec Minecraft (les dégâts sont infligé en une seul fois).
La variable soin permet d’ajouté un concept d’absorption. Imaginons un Blaze. C’est un monstre qui vit dans le feu, l’attaqué avec de l’eau sera donc on ne peut plus efficace. En revanche, l’attaquer avec du feu aura pour effet de le soigner.
#Particularité(Particularité)
En plus de modifier la méthode de calcul des dommages, le mod offre la possibilité de modifier les caractéristiques d’un monstre.
Chaque matrice est enregistré dans le dossier monsterData de la map et peut-être modifié manuellement (pour les joueurs, cela si situe dans le dossier playerData). Chaque monstre possède son propre dossier pour une raison simple : renommé une entité, et elle obtiendra les caractéristiques enregistré dans le fichier ayant le même nom qu’elle. Cela offre la possibilité au map maker de personnalité encore plus les monstres en leurs offrants les résistances/faiblesses souhaitées.
L’autre particularité de ce mod est d’être programmer de façon algorithmique. Cela signifie 2 choses :
#Gameplay(Gameplay)
Certain changement de gameplay sont à prévoir avec cette nouvelle mécanique.
Je détaillerai cette section ultérieurement, mais pour ne pas vous laissez en plan, voila l’exemple le plus marquant :
L’armure de diamant offre une très bonne protection, en revanche, elle est résiste mal à la chaleur (elle chauffe, et donc l’utilisateur se retrouvé étouffé).
En revanche l’armure d’or offre une très bonne protection contre le feu (parce que minecraft:pigmen)
Il sera donc bien plus intéressant de prendre quelque équipement en or lors d’une sortie Néther car ces dernier offrirons une bien meilleur défense contre les monstre locaux.
Autre point qu’il sera intéressent de constater, les armure d’or et de fer sont fait a partir de métaux conducteur. Il vas de soit que les attaques électrique seront particulièrement efficace contre ! (Vanilla, seul l’éclaire pourra vous frapper avec la foudre)
#Avancement (Avancement )
Fonctionnel (tous ce qui attrait à des parties fonctionnels. Ne signifient pas qu’elles sont optimisées)[list
je trouve que c’est un très bon mod j’attend de voir la suite 
Le concept est vraiment intéressant, et le code est dans l’ensemble pas trop dégelasse et bien commenté, à quelque exception :
Sinon comme je l’ai dit une library fort intéressante, j’attends de la voir plus aboutie
@☆Phenix246☆
Concernant les conventions de nommage, tu dis “les” mais à part le package Area que j’avais complètement zapper (et je t’en remercie ^^") je n’en ai pas vue d’autre…
Concernant les conditions, si tu fait référence à celle dans DamageEvent:onAttack, les //TODO ne sont pas la pour faire jolie ^^
J’ai juste parcourue ton code rapidement, après il me semble avoir vu du français avec de l’anglais, mais bon ce sont des mots qui sont quasiment identique donc ça passe ^^.
Le concept est intéressant, faut voir la suite.
Stylé ma foi ! 
Enfin on pourra faire du pvp intelligent ^^
@‘Tristepin’:
Enfin on pourra faire du pvp intelligent ^^
hey !! tu penses comme moi X)
Il y a eu quelque modification majeurs sur le code source : la majeurs partie des données sont désormais gérée ServerSideOnly (reste certaines données non implémentés à l’heure actuel qui ne sont toujours pas gérée).
Le client ne devient qu’un esclave qui fonctionnera avec les données fournis lors de la connexion.
Evidemment, le client se charge de purger les variables à la déconnexion. Un nouveau chargement des données est donc nécessaire si vous vous reconnectez au même serveurs, mais aucune modification de config ou redémarrage ne sera nécessaire pour allez sur un autre serveur.
Qu’est ce que cela signifie ?
La prochaine étape vas consisté à implémenter sous forme de JSON dans le dossier de la map chacun de ces données. Ainsi, chaque données sera propre au serveur/sauvegarde.
Chaque admin pourra alors personnalisé les éléments, les effets par défaut, et d’autre données qui arriveront au fur et a mesure.
L’autre nouveauté concerne les effets par défaut (en cours de dev).
Le fonctionnement est tous aussi simple : lorsqu’un coup est porté, 2 boolean seront disponibles (onDamage et onHeal). Par défaut, lorsqu’un coup Vanilla est modifié, les valeurs seront à “true”.
Certain éléments disposent alors de certain effet si le boolean est a true.
Par exemple, l’élément feu, dispose d’une probabilité d’enflammer la cible lorsqu’il inflige des dégâts. A chaque coup de type feu porté, la cible aura une probabilité de s’enflammer.
A contrario l’élément eau dispose d’une probabilité de donner l’effet fire résistance lors d’un soin. Ainsi a chaque soin de type eau, la cible aura une probabilité d’être immunisé au feu.
Ces effets sont la principalement pour palier aux manques sur la conversion des dégâts Vanilla. Ainsi, il sera possible de désactivé cette fonctionnalité très aisément afin de ne pas avoir d’effet parasite sur les attaque custom.
Autre petit changement, toute les données gérée sont initialisé dans le fichier VanillaInitialization.java.
Oui c’est moche, mais il n’y a pas vraiment de solution miracle ^^’
Dans tous les cas, les données ici sont celle qui sont auto-initialisé lors de la premier apparition d’une entité.
Comme vous pouvez le constatez, seul les données en lien directe avec les données Vanilla sont présentes. Ce qui pose certaine problème : tout ce qui n’est pas référencé utilisé l’élément d’ID 0 pour fonctionné (normal par défaut). Cela me gêne un peu puisqu’il limite grandement le fonctionnement de mon mod.
J’aurai donc besoin de votre avis : comment données des valeurs par défaut à tous ce qui n’est pas référencé ?
(actuellement, la solution la plus raisonnable me semble être d’utilisé la même solution que vanilla, mais pour un mod spécifique. Ce qui demande une intégration manuel du mod… Donc pas forcément pratique…)
Ce que je te conseille, c’est de leur donner un id qui peut changer selon la session en jeu mais un nom unique lors de la sauvegarde (String choisi par l’auteur ou UUID, comme tu veux).
Tu fais référence à quoi ?
Si tu fait référence au élément, le fonctionnement que tu propose n’est pas possible : les éléments sont généré (il n’existe donc pas) à partir des données fournis coté serveur. Ce que je suis en train d’ajouté, c’est justement l’implémentation de la lecture du fichier json qui contiendra les éléments (il ne me manque que ces P*** de PotionEffect ou je galère T-T).
Pour éviter les bug, je génère en dur des éléments lors du premier lancement, si il n’existe pas de fichier à lire (tous comme les entités : je génère leurs fiche la premier fois si elle n’existe pas, sinon je la lis). Le mod est donc utilisable en l’état sans configuration.
Lentement, mais surement, le mod avance.
Avant de pouvoir sortir une premier version fonctionnel, il me reste principalement 2 gros block à gérer : Gestion propre de l’armure et Gestion des sources de dégâts sans entité (type dispenser)
Le premier devrai être plutôt simple étant donnée que le système se rapprochera de celui des armes.
Le second est plus problématique, j’ai quelque difficulté à comprendre la manières dont sont éjecté les projectiles (Étrangement, il semble que tout soit éjecté sous forme de d’EntityItem lorsque je suis le chemin logique…)
Une fois ceci fait, le mod pourra fonctionné. Je pense proposer une version Alpha au téléchargement.
Restera ensuite le problème sur les IProjectile qui rebondissent (qui n’est autre qu’un bugfixe sur le quelle je ne me suis pas encore penché), l’application des effet par défaut (idem, bugfixe), et la modification du système pour les entité de type golem (à l’heure actuel, on récupère la variable “amount” de l’évent comme valeur de dégât. Cela risque de resté tel qu’elle, si il n’y a pas de problème avec d’autre entité. Je pense notamment à l’EnderDragon qui a quelque particularité dans sa gestion…)
Lorsque ces bug auront été fixé, je pense qu’une premier Béta sera possible.
A l’issus de cette Béta, je pourrai fixer les valeurs par défaut (ré-équilibrage), et le mod pourra sortir en version Release.
Restera évidemment des nouvelles fonctionnalité à ajouté, et d’autre à modifié (notamment pour optimisé certain calcul).
Une fois fait, il restera la ‘meilleur partie de tout les temps’ tousse la documentation…
Le concept est vraiment intéressant, et le code est dans l’ensemble pas trop dégelasse et bien commenté, à quelque exception :
Sinon comme je l’ai dit une library fort intéressante, j’attends de la voir plus aboutie
