Non ca ne vient pas de 0.7, c'est une erreur (enfin disons plutôt un oubli dans la notice d'utilisation ^o^') de 4G+.

Vous avez le droit de sauter tout mon baratin inutile ci dessous pour vous rendre directement à la solution du problème... Je vous y encourage même ^o^

En effet, dans PSP0.7, les faiblesses / résistances, sur lesquelles sont basés le calcul des dégâts se calculaient en fonction des types 1 & 2 du pokémon, tandis que dans 4G+, depuis que j'ai intégré la table des types (qui liste les faiblesses / résistances pour chaque poké, et non plus pour chaque type) et ainsi remplacé le type (qui servait à renvoyer la table du type) par cette table individuelle.

Donc, dans PSP0.7, en changeant la valeur de l'un et / ou l'autre type, cette modification avait un impact sur le calcul des dégâts. Mais, en ce qui concerne 4G+, depuis que la table des types a remplacé les n° des types dans le calcul des dégâts, le fait de changer les types n'a plus aucun effet... La table des types étant générée au moment de la création du pokémon (à un moment où il a ses types de base) elle n'est pas affectée par un changement de types ultérieur (même 1 frame après la création du pokémon, c'est déjà trop tard, le changement d'un de ses types (ou des 2) n'a plus d'effets sur sa table des types !)

Certes, j'avais intégré une commande (d'évènement) pour pouvoir intervenir assez facilement sur cette table des types, mais je me suis rendu compte aujourd'hui qu'elle avait 2-3 défauts de conception ^o^" Et comme je n'ai jamais eu un seul retour sur ce problème, j'en déduis qu'elle n'a pas souvent été utilisée, ce qui fait que ces problèmes ont duré, même après 4G+C3...

En outre, je n'avais pas pensé aux changements de types après la création du pokémon, et du coup je n'avais pas non plus imaginer ce petit défaut...

Mais après tout ce baratin plus ou moins utile où je ne fais que rabâcher le pourquoi de ce bug, j'en viens à la seule partie réellement intéressante pour nous tous (oui oui, elle m'intéresse aussi, sauf que moi je la connais déjà :p !)

---

---

Lexique
Coefficients (ou coeffs en abrégé) : Par ce terme, je désigne soit une faiblesse / résistance / immunité, soit l'ensemble des faiblesses / résistances / immunités de chaque type ou pokémon. C'est plus court à taper en plus :p

I) Introduction
Comme l'auront déjà compris ceux qui ont tout de même lu (malgré mes encouragements et mes recommandations ! :() mon terrible baratin, le problème de ce bug (qui n'en est pas un, en fait !) c'est que le changement de types ne met pas à jour la table des types du pokémon, celle là même qui sert de base au calcul des coefficients dans 4G+ ! Cette table, modifiable manuellement bien entendu, est créée au même moment que le pokémon, et une fois créée, elle n'est plus mise à jour toute seule !
J'avais prévu une commande d'évènements pour mettre à jour assez facilement cette table (qui obéit à des règles précises, que je détaillerai plus loin, dans ma partie "pour les scripteurs") mais pour l'avoir testée cette après midi (oui, ce problème est remonté une nouvelle fois à mes oreilles, et pour une fois j'ai eu le temps et l'occasion de tester en direct, me permettant ensuite de faire un lien avec la manière dont j'ai reprogrammé le calcul des dégâts, donc j'ai essayé de chercher une solution... en me basant sur mes codages existants...) elle a plusieurs soucis et comme elle n'était pas forcément très facile d'utilisation, j'ai préféré reprendre un codage propre, donc repartir de 0 pour obtenir un résultat qui me convient désormais, puisque fonctionnel. Et c'est ce fameux résultat, que je vous propose d'installer afin d'enrayer un bête oubli de codage de ma part.

II) Installation de la méthode set_types et des deux méthodes liées
NB : Je tiens à rappeler, pour le cas où ca serait nécessaire, que ces méthodes NE PEUVENT PAS ÊTRE INSTALLEES SOUS PSP0.7, car ces fonctions se basent sur des éléments qui n'existent pas sous PSP0.7 !
En outre, pas d'inquiétude, ce problème ne touchent que PSP4G+ et PSP4G+C3, et ce qui suit est une facon de corriger de ce problème. Pour les utilisateurs de PSP0.7 qui en seraient arrivé jusque là, je ne vous interdit pas de lire, mais je préfère vous prévenir : les commandes installées / expliquées ci dessous ne sont pas utilisables sur 0.7. De plus, elles n'auraient aucune utilité dans PSP0.7 où il suffit de modifier le type du pokémon pour obtenir le même effet.
Tout ce qui sera indiqué dans cette deuxième partie se passera dans le script 'Pokemon'.
Pour commencer, cherchez ceci :

Code:

#------------------------------------------------------------     # Désignation du sexe     #------------------------------------------------------------

et juste avant, collez ceci :

Code des méthodes set_types, multiplier_tables et diviser_tables

Code:

#------------------------------------------------------------     # Modification du type et mise a jour de la table des types     #------------------------------------------------------------     def set_types(type1 = nil, type2 = nil, mode = "remplacer")       case mode       when "ajouter"         if type1 != nil           @type1 = type1           multiplier_tables(@type1)         end         if type2 != nil           @type2 = type2           multiplier_tables(@type2)         end       when "remplacer"         if type1 != nil           diviser_tables(@type1)           @type1 = type1           multiplier_tables(@type1)         end         if type2 != nil           diviser_tables(@type2)           @type2 = type2           multiplier_tables(@type2)         end       end     end         def multiplier_tables(*type)       return false if type.compact.empty?       for n in 0...type.size         int = Interpreter.new         if type[n].type == Fixnum           if type[n] > $data_table_type.size             type[n] = nil             next           end           type[n] = $data_table_type[type[n]]         elsif type[n].type == String           type[n] = int.type_conv(type[n])           if type[n] > $data_table_type.size             type[n] = nil             next           end           type[n] = $data_table_type[type[n]]         elsif type[n].type == Array           type[n] = nil if type[n].size != $data_table_type.size         else           type[n] = nil         end       end       type.compact!       return false if type.empty?       for i in type         for j in 0...i.size           if i[j] == 0             ntx = self.table_type[j] / 10**5           elsif self.table_type[j] == 0             ntx = i[j].to_f / 10**5           else             ntx = self.table_type[j] * i[j].to_f           end           self.table_type[j] = ntx         end       end       return true     end         def diviser_tables(*type)       return false if type.compact.empty?       for n in 0...type.size         int = Interpreter.new         if type[n].type == Fixnum           if type[n] > $data_table_type.size             type[n] = nil             next           end           type[n] = $data_table_type[type[n]]         elsif type[n].type == String           type[n] = int.type_conv(type[n])           if type[n] > $data_table_type.size             type[n] = nil             next           end           type[n] = $data_table_type[type[n]]         elsif type[n].type == Array           type[n] = nil if type[n].size != $data_table_type.size         else           type[n] = nil         end       end       type.compact!       return false if type.empty?       for i in type         for j in 0...i.size           if i[j] == 0             ntx = self.table_type[j] * 10**5           else             ntx = self.table_type[j] / i[j].to_f           end           self.table_type[j] = ntx         end       end       return true     end

III) Utilisation des nouvelles méthodes installées
Voilà, c'est installé... Mais maintenant, il s'agit là encore de les utiliser correctement, et rassurez vous je vais tout vous expliquer.

Tout d'abord, parlons de la commande, set_types(type1, type2, mode), qui sert à modifier les types du pokémon, en mettant à jour sa table des types. Pour utiliser cette commande, il suffit de faire :

Code:

POKEMON.set_type(type1, type2, mode)

où :
- POKEMON est un objet de la classe pokémon.
- type1 et type2 sont les numéros des nouveaux types du pokémon, ou nil pour ne pas changer le type.
- mode représente le type de modification. Il peut prendre 2 valeurs : "ajouter" ou "remplacer".

Le mode "ajouter" permet de modifier le(s) type(s) du pokémon en intégrant ses nouveaux types à sa table des types, tout en conservant les coefficients de son / ses ancien(s) type(s).
Le mode "remplacer" permet de modifier le(s) type(s) du pokémon en intégrant ses nouveaux types à sa table des types, mais en retirant les coefficients de son / ses ancien(s) type(s).
NB : set_type(type1, type2, "remplacer") et set_type(type1, type2) auront strictement le même effet ! ("remplacer" est la valeur par défaut de mode, il n'est donc pas indispensable de le préciser )
Exemple :
Soit POKEMON, un pokémon quelconque, de type ELECTRIQUE / PLANTE :

Code:

POKEMON.set_types(nil, 2, "ajouter")

le type1 de POKEMON sera conservé, tandis que le type2 de POKEMON sera remplacé par le type n°2 : FEU.
Le mode étant "ajouter", la table des types de POKEMON contiendra le résultat du mélange des coeffs des types ELECTRIQUE (type1), PLANTE (ancien type2) et FEU (nouveau type2).
Si le mode avait été "remplacer" (ou non précisé), alors les coeffs du type PLANTE auraient été retirés.

Passons maintenant aux commandes multiplier_tables et diviser_tables. Ces commandes sont utilisées par set_types, mais peuvent être utilisées à part également. Elles servent à intégrer (multiplier_tables) ou à retirer (diviser_tables) les coefficients des types passés en argument.
Pour utiliser ces commandes, il suffit de faire :

Code:

POKEMON.multiplier_table(type1, ..., typeN) POKEMON.diviser_table(type1, ..., typeN)

où :
- POKEMON est un objet de la classe pokémon.
- type1 est un nom (entre "") ou un numéro (sans "") de type.
Vous pouvez préciser un seul type (il en faut au moins un) mais vous pouvez également en préciser plusieurs (il n'y a pas de limite).
Exemple :

Code:

POKEMON.multiplier_table("EAU") #Ajoutera les coeffs du type eau dans la table des type du pokémon POKEMON.diviser_table(17, "FEU", "ACIER", [1, 2, 0.25, 4, 0.5, 2, 1, 1, 1, 2, 1, 1, 4, 1, 0.25, 1, 1, 1, 1]) #Retirera les coeffs du type 17 (ténèbres), du type feu, du type acier, # et du tableau [1, 2, 0.25, 4, 0.5, 2, 1, 1, 1, 2, 1, 1, 4, 1, 0.25, 1, 1, 1, 1] de la table des types du pokémon

Comme le montre ces deux exemples, vous pouvez aussi bien préciser une seule liste de coefficients à intégrer ou à retirer de la table des types du pokémon, ou bien plusieurs.
Je dis liste de coefficients car dans mon exemple, j'ai bien sur pris des noms et des n° de types, mais j'ai aussi pris une liste de coefficients ([1, 2, 0.25, 4, 0.5, 2, 1, 1, 1, 2, 1, 1, 4, 1, 0.25, 1, 1, 1, 1]) car une des choses à savoir, c'est que les coefficients intégrés peuvent être ceux d'un type que le pokémon a déjà intégré (>> exemple, un NIDOKING sur lequel j'utiliserais la commande multiplier_tables("SOL", "POISON")) ou bien ceux d'un type que le pokémon n'a pas, ou encore un tableau de coefficients définis (le tableau [1, 2, 0.25, 4, 0.5, 2, 1, 1, 1, 2, 1, 1, 4, 1, 0.25, 1, 1, 1, 1], que j'ai utilisé dans mon exemple précédent) sous réserve, bien sur, que ce tableau de coeffs ait exactement autant de nombres (1 >> pas de modifications, 2 => coeff existant dans la table des types x2, 0.5 => coeff existant dans la table des types /2, ...) qu'il y a de types dans votre jeu. Dans 4G+ il y a 19 types (j'ai activé les types LUMIERE & COSMIQUE, les fakes de la démo de PSP0.7, pour faire la démonstration d'une autre fonction : l'affichage de la table des types du pokémon, que j'ai réadapté pour contenir plus de 18 types (et c'est pour ca que ces 2 fakes m'arrangeaient bien...) Mais je m'égare un peu donc je reprends là où j'en étais) donc je dois mettre 19 coefficients dans le tableau que je vais mettre dans cette fonction. La fonction ne buggerait pas, si j'en avais pas mit exactement 19, mais, tout comme dans le cas où j'aurais mis un nom ou un n° de type inexistant, la fonction se contentera de ne pas en tenir compte, et de passer à la suite, ou de se terminer si elle n'a plus ni type ni tableau de coeffs après.

J'ajouterai ceci : Vous pouvez modifier manuellement (et sans passer par multiplier_tables ou diviser_tables) la table des types du pokémon, elle est accessible grace à cette commande :

Code:

POKEMON.table_type # => renvoie la table des types entière. POKEMON.table_type = [...] # => remplacer les ... par les nouveaux coeffs qui vont prendre la place de l'ancienne liste, en verrant bien à # ce qu'il y ait le même nombre d'éléments que de types dans votre jeu, sachant que trop d'éléments, c'est inutile mais ca buggera pas, # mais pas assez d'éléments, ca finira par bugger (>> ca ne buggera pas immédiatement, mais ca buggera tôt ou tard !) POKEMON.table_type[X] # => renvoie l'élément placé à l'index X de la table des types du pokémon # (si X > au nbre de types de votre jeu, renvoie nil) POKEMON.table_type[X] = ... # => remplacer les ... par le nouveau coefficient qui va prendre la place de  l'ancien coeff placé à l'index X

Cependant je vous déconseille fortement d'agir directement sur cette table si vous ne savez pas ce que vous faites (et si vous n'avez pas été voir le point IV ci dessous) ! Si vous n'êtes pas absolument sûr de votre modif, utilisez plutôt les commandes multiplier_tables et diviser_tables.

Un dernier mot pour cette partie : set_type modifie les types et met à jour la table des types du pokémon, mais multiplier_tables et diviser_tables n'ont d'effets que sur la table des types du pokémon ! Ces deux dernières fonctions ne modifieront jamais un seul des types du pokémon !

IV) Règles de la table des types individuelle
Si vous préférez passer directement au point V), c'est par ici !

Vous êtes restés ? Bien, alors commencons : la table des types utilise certaines règles que vous vous devez de respecter si vous voulez intervenir directement sur cette fameuse table.
Passons en revue les généralités déjà :
Dans pokémon, on utilise généralement les coeffs 0, 0.25, 0.5, 1, 2 et 4 pour lister l'ensemble des relations entre types :

Citation:

0 => Immunité, annulation des dégâts 0.25 => Double résistance, dégâts divisés par 4 (>> utilisés pour des pokémons à double type uniquement) 0.5 => Résistance simple, dégâts divisés par 2 1 => Pas de modifications des dégâts 2 => Faiblesse simple, dégâts multipliés par 2 4 => Double faiblesse, dégâts multipliés par 4 (>> utilisés pour des pokémons à double type uniquement)

Ok, ca vous le saviez avant de vous taper toute cette lecture... Mais si je le rappelle, c'est que la table des types de chaque pokémon reprend ces banalités, et les complètent par des règles particulières. En effet, la commande multiplier_tables, décrite plus haut, intègre des coeffs, tandis que la commande diviser_tables, elle aussi décrite plus haut, retire des coeffs.
Bon, tant que c'est des ajouts de faiblesses (coeff existant x 2), de résistances (coeff existant / 2), ajouts sans modifications (coeff existant x 1), ou bien des retraits de faiblesses (coeff existant / 2, on annule le x 2), de résistances (coeff existant x 2, on annule le /2) ou des retraits sans modifications (coeff existant /1, on annule le x1... mais juste vraiment pour pas s'embêter... pour la forme, quoi...), lorsqu'on en vient à ajouter des immunités (coeff existant x 0 ? ) voire à en retirer (coeff existant / 0 ?!?!? :shock:) ca se complique...
Eh bien pas tant que ca en fait... Tout ce qu'il faut trouver, c'est un moyen pour pouvoir multiplier, et diviser par 0... Pas dur ca... Ah, je vois que vos yeux commencent à se sauver, donc je vais vous expliquer...
En effet, multiplier par 0 est faisable, mais c'est irréversible... Diviser par 0, par contre, j'en parle même pas, le premier qui essaie jle sors =)

En outre, pour les ajouts / retraits de faiblesses & résistances, on peut revenir à la case départ assez vite !
Exemple :
Un ONIX (coeff contre le sol = 2, faiblesse simple) auquel j'applique les commandes suivantes :

Code:

ONIX.multiplier_tables("PLANTE", "INSECTE", "FEU", "EAU") ONIX.diviser_tables("FEU", "INSECTE")

verra les changements suivants :

Code:

=begin La commande multiplier_tables va lire chacune des listes de coeffs (ici ce sont uniquement des types) pour les intégrer à la table des types d'ONIX, donc ici cette fonction intègrera d'abord le type PLANTE,puis le type INSECTE, puis le type FEU, puis le type EAU. NB : l'ordre n'a aucune importance, j'aurais ainsi pu mettre le FEU, ou bien l'EAU en première place, mais il fallait bien un ordre alors j'ai arbitrairement choisi celui ci =) La commande diviser_tables va faire de même, elle va lire une à une les différents coeffs des types FEU puis INSECTE. NB : là encore, l'ordre n'est pas important (x / 2 * 4 sera toujours équivalent à x * 4 / 2 !) mais il en faut un ^o^ Pour la suite, je m'intéresserai qu'au coeff d'ONIX contre le type SOL, qui est, je vous le rappelle, de 2 (faiblesse simple) à l'origine quand j'ai créé mon ONIX. Désormais, ce coeff portera le nom de CSOL CSOL = 2 Le type plante a une résistance au type sol (coeff 0.5), donc lorsque multiplier_tables va intégrer les coeffs plante à la table des types d'ONIX, le nouveau coeff sera le suivant : CSOL = CSOL (=2, ancien coeff) * 0.5 (coeff ajouté) = 1 (une faiblesse combinée à une résistance s'annulent, c'est pour ca que les pokémons SOL / EAU n'ont ni faiblesse ni résistance face aux attaques EAU. Quoi, vous le saviez déjà, ca aussi ? Bon ben je continue alors =)) CSOL = 1 Ensuite la commande va intégrer le type INSECTE. Ce type possède une résistance face au sol (coeff = 0.5) donc : CSOL = 1 * 0.5 Et voilà notre ONIX devenu résistant face au sol ! Le type feu possède une faiblesse sol. Lorsqu'il sera intégré, ca donnera ceci : CSOL = 0.5 * 2 = 1 Et voilà notre ONIX qui vient de perdre sa résistance fraichement acquise... Enfin la fonction multiplier_tables va intégrer le type EAU, type qui ne possède ni faiblesse ni résistance face au sol (coeff = 1) CSOL = 1 * 1 = 1 A la fin de l'exécution de la commande multiplier_table, ONIX aura un coeff de 1 contre le type sol, il ne sera ni faible ni résistant face à ce type. Ensuite c'est la commande diviser_table (la 2° commande que j'ai mis tout à l'heure) qui va s'activer, afin de retirer les coeffs des types FEU & INSECTE. Vous avez compris comment marchait la multiplication ? Eh bien là on fait l'inverse ! CSOL valait 1 tout à l'heure, voyons maintenant ce qu'il devient : CSOL = CSOL (1) / coeff retiré (2) = 0.5 Et revoilà notre résistance ! Maintenant, la commande va retirer le type INSECTE d'ONIX, donc même principe : CSOL = CSOL (0.5) / coeff retiré (0.5) = 1 Et voilà, CSOL vaut 1 à la fin des deux commandes ! =end

Bien sur, et bien que ca ne soit pas spécialement logique, j'aurais pu utiliser diviser_tables("FEU") bien avant d'utiliser multiplier_tables("FEU") !

Mais reste encore le problème des immunités ! Comment la commande ONIX.multiplier_tables("VOL") fera pour que derrière, ONIX.diviser_table("VOL") puisse annuler cette multiplication ?
CSOL = 2 (coeff d'origine) * 0 (ajout de l'immunité) / 0 (retrait de l'immunité) ?

Mais là vous aurez non pas 1 (si, je sais que vous en aviez au moins trouvé un !) ni 2 (des fois que des ptits malins auraient pu trouver le 2°) mais bien 3 problèmes !
CSOL = 2 * 0 (ajout de l'immunité) = 0 !

Le 2 a totalement disparu, il ne sera plus jamais récupérable, donc ca ne convient pas !
En outre, 0 / 0 est une opération aussi absurde qu'impossible !
Enfin, si j'utilise la commande ONIX.multiplier_tables("VOL", "VOL"), CSOL sera égal à (2 x 0) x 0 = 0 ! Comment vous pourriez déterminer le nombre d'immunités qu'ONIX a contre le type SOL ? Parce que même avec un moyen de diviser 0 par 0, comment savoir si 0 / 0 = 2 (ONIX n'a plus d'immunités SOL) ou si 0 / 0 = 0 (ONIX a encore des immunités SOL) ?

Voici comment j'ai contourné ce problème... Comment avoir des dégâts nuls, avec un coefficient qui ne soit pas égal à 0 ? Ah, certains ont déjà la réponse : on prend un nombre extrêmement proche de 0 !
0.1 peut être ? Non...
0.01 ? Trop grand...
0.001 ? Non plus...
En fait, j'ai pris un coefficient égal à 0.00001 pour symboliser l'immunité.

Ainsi :

Code:

ONIX.multiplier_tables("VOL", "VOL") ONIX.diviser_tables("VOL")

rendra le résultat suivant :
CSOL = 2 * 0.00001 * 0.00001 = 0.0000000002 ! Le 2 est toujours là, et puis (2 * 0.00001 * 0.00001) donne un résultat différent de (2 * 0.00001) ! Ca permet ainsi de déterminer s'il reste ou non une (ou plusieurs ?) immunité(s) !

Derrière, la commande diviser_tables("VOL") va simplement retirer une immunité :
CSOL = 0.0000000002 / 0.00001 = 0.00002 !

Et ce calcul marche ! Ca y est, aussi absurde que ce soit, on a fait l'équivalent de 2 * 0 / 0 = 2 =)
En outre, j'ai mis une petite protection : si le coeff du pokémon (ici ONIX) par rapport à l'attaque qu'il recoit (admettons SEISME) est inférieur à 0.001 (soit tout de même un coeff de 100 combiné à une seule immunité, et encore, sous réserve que l'attaque inflige 1000 dégâts, pour que ca fasse perdre 1 PV !!! Ca laisse de la marge, je pense ! ^o^) alors les dégâts tombent automatiquement à 0, l'attaque est inefficace.

Donc voici un petit rappel des coeffs généraux qu'utilise les commandes multiplier_tables et diviser_tables ainsi que la table des types du pokémon :

Citation:

0.0001 => Immunité 0.5 => Résistance 1 => Pas de modification 2 => Faiblesse Ces coeffs marchent aussi bien en tant que multiplicateur (pour ajouter une faiblesse / résistance / immunité / rien) qu'en tant que diviseur (pour retirer une faiblesse / résistance / immunité / rien) ! C'est, je crois, un bon moyen de vous rappeler de ces règles, et ce, même si x / 0.5 = x * 2

Voilà, c'en est fini du fonctionnement de la table des types...

V) Solution alternative ?
Je vois déjà les pauvres désespérés, qui auront vaillamment réussis à lutter contre tous ces mots, pour arriver jusque là, me dire :
"Euh, pourquoi t'as pas simplement fait une simple petite mise à jour automatique de cette fichue table des types au début de chaque combat ?"
Eh bien c'est pour une raison simple :

• Si j'avais voulu que la table des types du pokémon ait le même effet que le système de PSP0.7 se basant sur le type du pokémon, c'est à dire recréer la table des types de chaque pokémon de l'équipe du joueur, à partir de ses types, en écrasant ainsi l'ancienne table des types, je pouvais simplement ne pas intégrer la table des types...

A cela, vous pourriez répondre :
"Ben suffit d'intégrer la nouvelle table des types à l'ancienne, et ainsi ne pas l'effacer, et puis c'est bon !"

• A la base, un pokémon ACIER a une résistance (0.5) contre les attaques plante, et une faiblesse (2) contre les attaques feu... Si, au début du match, je cumule la nouvelle table des types à l'ancienne, ca va faire ACIER.multiplier_tables("ACIER") et le résultat sera celui ci :
  CPLANTE = 0.5 * 0.5 = 0.25 (Double résistance)
  CFEU = 2 * 2 = 4 (Double faiblesse)
  
  2° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER") :
  CPLANTE = 0.25 * 0.5 = 0.125
  CFEU = 4 * 2 = 8
  
  3° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER", "ACIER") :
  CPLANTE = 0.125 * 0.5 = 0.0625
  CFEU = 8 * 2 = 16
  
  4° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER", "ACIER", "ACIER") :
  CPLANTE = 0.0625 * 0.5 = 0.3125
  CFEU = 16 * 2 = 32
  
  5° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER", "ACIER", "ACIER", "ACIER") :
  CPLANTE = 0.03125 * 0.5 = 0.015625
  CFEU = 32 * 2 = 64
  
  6° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER", "ACIER", "ACIER", "ACIER", "ACIER") :
  CPLANTE = 0.015625 * 0.5 = 0.0078125
  CFEU = 64 * 2 = 128
  
  7° match, ca fera ACIER.multiplier_tables("ACIER", "ACIER", "ACIER", "ACIER", "ACIER", "ACIER", "ACIER") :
  CPLANTE = 0.0078125 * 0.5 = 0.00390625
  CFEU = 128 * 2 = 256
  
  ... Je m'arrête là, mais je tenais à arriver à ces résultats extrêmes (CPLANTE = 00390625, donc presque une immunité selon le logiciel, et dégâts divisés par 256, si bien que même TEMPETEVERTE n'a (presque) plus d'effet ! et CFEU = 256, si bien qu'une petite attaque FLAMMECHE devient (presque) une OHKO ! En outre, et bien que je ne l'aie pas cité en exemple, ca multiplierait l'immunité contre le POISON par 7 ! Difficile, avec autant d'immunités, de pouvoir un jour rendre ce poké acier sensible au venin !) Vous voyez le pb ?

Aucune solution simple ne permettait à la fois de conserver les modifications éventuelles qu'un maker aurait pu apporter à la table des types d'un de ses pokémons, tout en mettant correctement à jour un éventuel changement de type. Rien de plus simple que de mettre :

Code:

ACIER.set_types(nil, "VOL")

à la place de

Code:

ACIER.type2 = 10

pour être plus exact.

VI) Le mot de la fin
Tout d'abord, bravo à ceux qui auront entièrement lu l'ensemble de ce post, et pis pas grave pour les autres Sous 4G+, donc, si vous devez modifier l'un ou l'autre des types de votre pokémon, voire les deux peut être, sachez d'avance que type1 = ou type2 = n'aura aucun effet au niveau des coeffs de votre pokémon ! il vous faudra utiliser set_types pour mettre à jour sa table des types.
Je vous remercie d'avoir accepté de perdre autant de temps à lire mon terrible roman, et je vous dis bonne nuit à tous !

Oulà, je lirait plus tard xP


Sphinx : Pichu, arrête de flooder en dehors de Libre, stp
J'ai tous lu, tu fais des trop gros pavés xP Mais moi perso, j'utiliserai pas j'aime pas les formes ...

Sphinx : han, t'as pas l'droit de changer ma couleur :( snif

:shock: Sphinx, c'est super ! Tu es un dieu ! Félicitation !

C'est vrai que c'est très bien.
Mais comment on pourrait mettre à jour la table des types automatiquement en fonction des types des POKéMON après une évolution ou un échange ?
J'ai justement remarqué que quand un POKéMON évolue, sa table des types reste la même, et cela pose problème quand le type change à l'évolution.
Par exemple, quand EVOLI évolue en PYROLI, celui-ci garde comme faiblesse le COMBAT et comme immunité le SPECTRE sans avoir de faiblesse EAU non plus, ce qui pose problème à cause du type feu de PYROLI.
Sinon, après un échange, j'ai remarqué que la table des types faisait n'importe quoi. Celle-ci est toujours la même : [1, 2, 0.5, 0.5, 0.25, 2, 0.5, 1, 1, 2, 2, 2, 1, 1, 1, 1, 1] en ne prenant en compte que les types par défaut.
Merci beaucoup.

ah oui ! le système d'échange a été créé sous PSP0.7 Et c'est vrai que je ne l'ai jamais mis à jour

>> pour l'évolution, en effet, c'est un problème auquel je n'avais pas non plus pensé mais ca sera rapidement corrigé lol ^o^"


merci pour le signalement, sirius



edit :

Le pb de l'évolution est facilement réglable. Voici la manip :

Script pokémon :
remplacer

Code:

archetype(@id)         @hp = max_hp - hp_lost         refresh_skill       end     end         def evolve_check(mode = "", param = "")       # Pas d'évolution       if evolve_list[1] == [] or evolve_list[1] == nil or evolve_list[1][0] == ""         return false       end

par :

Code:

archetype(@id)         set_types(@type1, @type2)         @hp = max_hp - hp_lost         refresh_skill       end     end         def evolve_check(mode = "", param = "")       # Pas d'évolution       if evolve_list[1] == [] or evolve_list[1] == nil or evolve_list[1][0] == ""         return false       end

Par contre, en ce qui concerne l'échange, ca va me demander plus de boulot...

Je viens de tester pour l'évolution et cela ne fonctionne pas. La table reste tout simplement inchangé.  :?

ah... :!


>> je vais tester alrs, pour comprendre pk ca ne marche pas

Eh bien, je pense avoir trouvé, cela fonctionne et n'a pas encore buggé ^^ :

 

Code:

archetype(@id)          #Mise à jour de la table des types          for i in 0...$data_table_type.size           nbre = [$data_table_type[@type1][i],$data_table_type[@type2][i]]           if nbre[0] == 0           if nbre[1] == 0             nbre[0] = 0           else             nbre[0] = nbre[1] / 10**5           end           elsif nbre[0] < 10**-4 and nbre[0] > 0             if nbre[1] == 0               nbre[0] /= 10**5             else               nbre[0] *= 10**5               nbre[0] *= nbre[1]               nbre[0] /= 10**5             end            else             if nbre[1] == 0               nbre[0] /= 10**5             else             nbre[0] *= nbre[1].to_f            end           end           @table_type[i] = nbre[0]           end           #fin           @hp = max_hp - hp_lost             refresh_skill           end         end                 def evolve_check(mode = "", param = "")          # Pas d'évolution          if evolve_list[1] == [] or evolve_list[1] == nil or evolve_list[1][0] == ""            return false          end

là tu recrées entièrement la table des types du pokémon


>> j'ai trouvé la manip à faire, mais par contre pas le tps de la poster ce soir, donc je détaillerai tt ca dans la journée de demain

Eh bien, cela me va parfaitement pour ce que je fais. Sinon, j'étais en train d'essayer de le faire pour l'Echange, en recréant la table à la fin de l'échange.
Mais j'ai besoin de savoir une chose (je suis complètement nul en ruby) : comment faire fonctionner la fonction set_type sur le POKéMON sélectionné par la variable 4 INDEX POKEMON.
J'ai essayé cela :
pokemon.set_type(Pokemon_Info.type1, Pokemon_Info.type2)
ou :
$pokemon_party.actors[var(4)].set_type(Pokemon_Info.type1, Pokemon_Info.type2)
ou encore :
pokemon_numero(var(4)).set_type(Pokemon_Info.type1, Pokemon_Info.type2)
Mais je ne comprends pas bien le fonctionnement du ruby avec les points . qui séparent les noms de variable ou fonction.

Par là, je veux récupérer les types du POKéMON reçu et utiliser la fonction set_type sur celui-ci à la fin de l'échange, mais je ne suis même pas sûr de bien récupérer le type avec Pokemon_Info.type1 .

Je n'est pas pigé grand chose

Il y a une notice d'utilisation de PSP 4G+ ?

Est-ce que cette méthode est utilise sur PSP DS ?

C'est le "manuel" pour la commande set_type de 4G+ & de ses dérivés :p Parce que 4G+ ne gère pas les faiblesses / résistances comme 0.7, les modifications des types 1 & 2 ne peuvent pas se faire de la même manière

D'où ce script qui corrigeait une ancienne version de PSP4G+, correctif inclus dedans depuis, et explique comment modifier le type 1 ou le type 2, et bien sur que ca fasse effet ^^

Puisque PSP DS a comme base PSP 0.7, cette méthode ne devrait pas être présente.