ElementalLibrary
-
@☆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…
