ElementalLibrary

Jodge

#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 !

ElementalLibrary

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 :

A Matrice de bonus en dégât de l’entité (pourcentage)
B Matrice de résistance de l’entité (pourcentage de dégât reçus)
C Matrice de dégât brut de l’arme (Constante de dégât fixe)
D Matrice de modificateur environnemental (pourcentage)

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 :

Le mod palliera l’absence de données du mieux qu’il le peu
L’ajout de nouvelle caractéristique peut se faire simplement. Un panel de fonctionnalité est fournis afin que n’importent qu’elles mods puissent intégrer ses propres valeurs, sans pour autant exigé que ce mod soit présent (dans certaine limite : l’ajout d’un élément nécessitera forcément la présence du mod). Ainsi, les données seront présentes si ce mod est inclus, ou seront simplement ignorer le cas échéant.
Des mod modifiant les éléments pourront être disponible ServerSide Only (sous réserve ne de pas modifier de mécanique)
Le principal avantage est de grandement simplifier l’ajout/suppression. Server Side Only reste néanmoins problématique pour certaine valeur (l’environnement par exemple et gérer procéduralement de chaque coté. On a donc le même résultat, mais on code en dur les éléments pour cela.

#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

Gestion des sources de dégâts simple* Fonctionnalité de Matrice par défaut personnalisé pour les Armes* Fonctionnalité des matrices par défauts personnalisés pour les entités.* Génération des données manquante* Fonctionnalité de lecture/écriture des données de sauvegarde* Génération de la matrice environnemental (Prend en compte Température & Humidité du Biome)* Fonctionnalité d’auto-génération des données manquantes (Entité Vanilla + Item)* Gestion des sources des sources de dégât ‘autre’ (suffocation, lave, feu…) (DamagesSources Vanilla)* Gestion des données ServerSide Only (auparavant, les éléments était synchronisé, ce qui posé diverse problème, notamment pour la personnalisation)* Modification des caractéristiques lors de l’utilisation d’un NameTag (Utile au MapMaker)* Gestion propre de l’armure avec fonctionnalité de Matrice de résistance par défaut personnalisé pour les armures (incluant effet d’inversion, c’est a dire les dommages soignent, et les soin font des dégâts)]
Semi-Fonctionnel (tous ce qui attrait à des parties en cours de développements)[list
Gestion des sources de dégâts par projectile (persiste un problème sur les flèches qui rebondissent)* Fonctionnalité d’effet par défaut pour un élément (actuellement initialisé, mais non appliqué (effet de potion)/mal appliqué(lorsqu’on est en feu, dégât de feu, du coup ré-application de l’effet infinis ^^'))]
Non-Fonctionnel (tous ce qui attrait à des parties non développé mais prévue)[list
Gestion des sources de dégât sans entité (Dispenser)* Gestion des Enchantements* Gestion des cas ‘spéciaux’ d’entité (Golem & Boss) /!\ Problème : les Golems n’ont pas de valeur de dégât prédéfinis et accessible. Une valeur random différente est tiré a chaque fois…]
Idée (tous ce qui attrait à des parties actuellement non prévue, mais qui pourrait être développé. Le mod est supposé être fonctionnel sans)[list
Matrice Mondial (Matrice propre à une dimension, ex dégât d’eau = 0 dans le Nether)* Fonctionnalité de Matrice de résistance par défaut personnalisé pour les armures* Matrice Brute (bonus/malus de dégât brute et non en %)* Gestion des données intégralement par Fichier (fichier de config ServerSide Only contenant TOUTE les données possible : Élément, Effet, Damage Source…). (Dépendra de la facilité a convertir des Tag en Json, et d’outrepasser les problèmes d’absence)* Fonctionnalité d’auto-génération des données manquantes (Entité Non-Vanilla) /!\ Problème : Comment gérer une auto génération des entités dans ce cas ? Un Blaize d’eau aura des résistances et faiblesses diamétralement opposé au Blaize normal. Utilisé une vérification par ‘instanceof’ est donc difficilement envisageable dans ce cas…* Gestion des sources des sources de dégât ‘autre’ (suffocation, lave, feu…) (DamagesSources Vanilla) /!\ Problème : idem qu’entité…]

Yeyvo

je trouve que c’est un très bon mod j’attend de voir la suite

Phenix246

Le concept est vraiment intéressant, et le code est dans l’ensemble pas trop dégelasse et bien commenté, à quelque exception :

les conventions de nommage en java pas respecté (Area)
des conditions malles écrites ( if(condition) { // commentaire / rien } else { des actions } )

Sinon comme je l’ai dit une library fort intéressante, j’attends de la voir plus aboutie

Jodge

@☆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 ^^

Phenix246

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 ^^.

AymericRed

Le concept est intéressant, faut voir la suite.

Ama

Stylé ma foi !

Tristepin

Enfin on pourra faire du pvp intelligent ^^

Yeyvo

@‘Tristepin’:

Enfin on pourra faire du pvp intelligent ^^

hey !! tu penses comme moi X)

Jodge

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…)

AymericRed

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).

Jodge

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.

Jodge

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…