Pokémon Script Project Forum Index

Manuel | Search
 Information des admins 
Si vous désirez parler de PSP ou obtenir du soutient là dessus, merci d'aller faire un tour sur https://pokemonworkshop.com/forum/index.php Imbécile heureux

Méthode set_types

 
Post new topic   Reply to topic    Pokémon Script Project Forum Index -> Game Making -> Ressources techniques -> Scripts
Previous topic :: Next topic   
Author Message
Sphinx
Scribe
Scribe


Joined: 07 Jan 2008
Posts: 9,736
Localisation: Quelque part, dans le monde... Ou peut être sur une autre planète...
ID Steam: FaQuinator

PostPosted: Sat 6 Jun - 23:49 (2009)    Post subject: Méthode set_types

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






LA METHODE set_types !


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:
    #------------------------------------------------------------
    # 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 Clin d'œil foireux)
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 :
Quote:
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 ?Mollasse enragé ) 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 ! Clin d'œil foireux 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 :
Quote:
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 Clin d'œil foireux

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. Clin d'œil foireux

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 Clin d'œil foireux 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 !


Last edited by Sphinx on Fri 31 Jul - 17:06 (2009); edited 2 times in total
Back to top
Publicité






PostPosted: Sat 6 Jun - 23:49 (2009)    Post subject: Publicité

PublicitéSupprimer les publicités ?
Back to top
PiVa
Guest





PostPosted: Sun 7 Jun - 00:00 (2009)    Post subject: Méthode set_types

Oulà, je lirait plus tard xP


Sphinx : Pichu, arrête de flooder en dehors de Libre, stp
Coupable 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


Last edited by PiVa on Sun 7 Jun - 11:17 (2009); edited 1 time in total
Back to top
Newtiteuf
Membre


Joined: 22 May 2008
Posts: 5,090
Localisation: Sur PC (enfin devant ...)

PostPosted: Sun 7 Jun - 11:14 (2009)    Post subject: Méthode set_types

:shock: Sphinx, c'est super ! Tu es un dieu ! Félicitation !
Back to top
Visit poster’s website
SiriusXIV
Guest





PostPosted: Fri 14 Aug - 21:32 (2009)    Post subject: Méthode set_types

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.
Back to top
Sphinx
Scribe
Scribe


Joined: 07 Jan 2008
Posts: 9,736
Localisation: Quelque part, dans le monde... Ou peut être sur une autre planète...
ID Steam: FaQuinator

PostPosted: Fri 14 Aug - 22:05 (2009)    Post subject: Méthode set_types

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

>> 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 Imbécile heureux



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...
Back to top
SiriusXIV
Guest





PostPosted: Sat 15 Aug - 08:54 (2009)    Post subject: Méthode set_types

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


Joined: 07 Jan 2008
Posts: 9,736
Localisation: Quelque part, dans le monde... Ou peut être sur une autre planète...
ID Steam: FaQuinator

PostPosted: Sat 15 Aug - 09:12 (2009)    Post subject: Méthode set_types

ah... :!


>> je vais tester alrs, pour comprendre pk ca ne marche pas Mollasse enragé
Back to top
SiriusXIV
Guest





PostPosted: Sat 15 Aug - 18:32 (2009)    Post subject: Méthode set_types

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  


Back to top
Sphinx
Scribe
Scribe


Joined: 07 Jan 2008
Posts: 9,736
Localisation: Quelque part, dans le monde... Ou peut être sur une autre planète...
ID Steam: FaQuinator

PostPosted: Sat 15 Aug - 20:10 (2009)    Post subject: Méthode set_types

Clin d'œil foireux 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 Imbécile heureux
Back to top
SiriusXIV
Guest





PostPosted: Sat 15 Aug - 21:31 (2009)    Post subject: Méthode set_types

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 .
Back to top
Mercury
Membre


Joined: 26 Jun 2013
Posts: 258
Se débrouille comme il peut
Localisation: pas de calais
Masculin
Nintendo Network: Lareinerouge62

PostPosted: Sun 19 Jan - 07:48 (2014)    Post subject: Méthode set_types

Je n'est pas pigé grand chose Bouche extensible
Back to top
Skype Facebook
Ku'rei
Membre


Joined: 10 Aug 2010
Posts: 546
Adepte du NoMoreExcuses
Localisation: Chambéry
Masculin

PostPosted: Mon 20 Jan - 16:26 (2014)    Post subject: Méthode set_types

Il y a une notice d'utilisation de PSP 4G+ ?
Back to top
og_loc-TATOO
Membre


Joined: 11 Oct 2009
Posts: 3,383
Sailor Maniac
Localisation: noitasilacol

PostPosted: Thu 23 Jan - 13:37 (2014)    Post subject: Méthode set_types

Est-ce que cette méthode est utilise sur PSP DS ?
Back to top
Sphinx
Scribe
Scribe


Joined: 07 Jan 2008
Posts: 9,736
Localisation: Quelque part, dans le monde... Ou peut être sur une autre planète...
ID Steam: FaQuinator

PostPosted: Thu 23 Jan - 18:47 (2014)    Post subject: Méthode set_types

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 ^^
Back to top
Pαlвσlѕку
Team SDK


Joined: 17 Aug 2008
Posts: 5,983
Masculin

PostPosted: Thu 23 Jan - 19:30 (2014)    Post subject: Méthode set_types

Puisque PSP DS a comme base PSP 0.7, cette méthode ne devrait pas être présente.
Back to top
Skype
Display posts from previous:   
Post new topic   Reply to topic    Pokémon Script Project Forum Index -> Game Making -> Ressources techniques -> Scripts All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  

Index | Free forum | Free support forum | Free forums directory | Report a violation | Cookies | Charte | Conditions générales d'utilisation
Powered by phpBB © 2001, 2005 phpBB Group
Thème par Thomas et l'équipe de la refonte PSP 2012 (version 1.0)