[WeiDU] Comment Patcher plusieurs adresses simultanément sur un même intervalle ?

[Armand]

Je tente de patcher le composant d'un effet à l'intérieur d'un sort. Ce sort comprend en lui même 35 effets (1 effet pour chaque niveau) et par conséquent on observe certaines occurrences dans les adresses. Si je prend les 3 premières adresses à patcher :

En hexadécimal

0x5f7
0x687
0x717

En décimal

1527
1671
1815

Par une simple soustraction on peut observer qu'il y a un écart de 144 en valeur décimal et de 0x90 en valeur hexadécimal (cet écart étant fixe). Par conséquent je me demandais si il y avait une manière d'appliquer cette modif en une ligne au lieu d'avoir à écrire 35 WRITE_BYTE ?

[deratiseur]

Le tp2 du dukp est farci de ce genre de choses, et voici l'extrait d'un fichier txt que je m’étais mis de coté pour pouvoir répéter la manœuvre sans prise de tête.

Code : Tout sélectionner

COPY    ~Derats_kits/Essaim/Spells/pxb4infe.spl~        ~override~
  READ_LONG 0x64 abilities_off
  READ_SHORT 0x68 num_abilities
  FOR (i = 0; i < num_abilities; i += 1) BEGIN        // pour chaque habileté
    WRITE_BYTE (abilities_off + 0x570*i + 0x6ee) 60    // indiquer la mort par ver putride après 60 secondes
  END

Ou 570 = différence entre offset dernière place de l'habilité 2 et offset dernière place de l'habilité 1
OU 6ee = offset désiré sur habilité 1 - nombre de l'abilities off (au 0x64) (j'ai impression que c'est toujours 72)



Deuxième possibilité :
Crée un sort avec une seul hability et multiplie le avec le code de notre ami Zranoff. Voir encore le patchage de ce sort pxb4infe dans le dukp, c'est le plus compliqué de tous.

[Isaya]

WeiDU possède une fonction très puissante pour faire la même chose : le couple GET_OFFSET_ARRAY et PHP_EACH. Il y a un exemple concret pour les objets dans le tutoriel 9.24 de la doc WeiDU.
En gros, pour pouvoir l'utiliser, il faut connaître la structure SPL (ou ITM dans le cas du tutorial) et le principe du code proposé par dératiseur. Mais ces fonctions sont tout de même la façon la plus propre de faire.

Exemple perso, pour décoder les caractéristiques d'une arme (extrait pour la partie mêlée) :
[HTML] GET_OFFSET_ARRAY ab_array 0x64 4 0x68 2 0 0 0x38
PHP_EACH ab_array AS int => ab_off BEGIN
// Type d'attaque (mêlée, projectile, lanceur, magique ...)
READ_BYTE (ab_off + 0x00) attacktype // à analyser : 1=mêlée, 2=projectile, 4=launcher, 3=magical ignoré
PATCH_IF attacktype = 1
BEGIN
// mêlée
SET nbAttaques += 1
SPRINT ~typeattaque~ ~Melee~
READ_SHORT (ab_off + 0x0e) attackrangeMelee
SPRINT strallonge ~Allonge : %attackrangeMelee%~
READ_BYTE (ab_off + 0x12) attackspeedMelee
READ_SHORT (ab_off + 0x14) thac0bonusMelee
READ_BYTE (ab_off + 0x16) dicesidesMelee
READ_BYTE (ab_off + 0x18) dicenumberMelee
READ_SHORT (ab_off + 0x1a) damagebonusMelee
END
END // PHP_EACH
[/HTML]
Tu pourrais faire des WRITE à la place des READ, bien entendu, dans ton cas. Et n'en faire qu'un, puisque tu veux juste modifier un paramètre de chaque extended header.
Le gros du travail est de savoir quoi mettre dans les paramètres de GET_OFFSET_ARRAY et pour ça il suffit de la définition de la structure SPL, dans ton cas. On retrouve d'ailleurs dans mon exemple les valeurs 0x64 et 0x68 du sien.
Ensuite l'intérieur du PHP_EACH travaille avec un offset local à l'élément, pas besoin d'un calcul de type "abilities_off + 0x570*i + 0x6ee" comme dans l'exemple de dératiseur.

[Armand]

Merci derat pour ton code en suivant ton modèle je suis arrivé à un code satisfaisant. Je n'ai pas utilisé le code de zranoff vu que les paramètres à modifié obéissent à un système un peu chaotique...

Oui isaya effectivement cette commande a l'air très intéressante. Je pense avoir compris le concept je testerais à l'occaz sur un autre code. Juste un petit eclaircissement sur la ligne du debut il y a unt ruc qui m'echappe :

Code : Tout sélectionner

GET_OFFSET_ARRAY ab_array 0x64 4 0x68 2 0 0 0x38

La valeur 4 ici si j'ai bien compris prend en compte les valeurs d'une certaine taille et la valeur 2 qui la suit de même. Mais que signifie les deux autres valeurs 0, à priori elle indique de ne pas lire quelque chose mais quoi ? Tu saurais m'aiguiller à ce sujet ?

[Isaya]

Comme je l'écrivais, il faut vraiment se prendre la tête avec l'exemple du tutoriel, avec le format ITM sous les yeux, pour avoir une chance de comprendre.

Concernant les deux premiers (position 2 et 4), 4 et 2 définissent le nombre d'octets des champs Offset (position 1) et Iterations (position 3). Les valeurs 5 et 6 correspondent à Index et sa taille en octets. Comme indiqué dans le tutoriel

The value read from "Index" is the number of iterations into the file the current read should be made. This is not always relevant for GET_OFFSET_ARRAY, but for reading general effects (on-equip effects), this is 0x6e.

Je crois que c'est clair, non ? Euh, passons...

Tu ne veux vraiment pas te contenter de 0 0 ?

Bon, pour le fichier ITM, il semblerait que l'offset 0x6e corresponde aux effets obtenus quand on prend l'objet en main. Ces effets figurent dans la liste des "features blocks", dont l'offset est 0x68 (cf format ITM). Pour accéder aux "feature blocks", si je comprends bien le tutorial, il faudrait utiliser GET_OFFSET_ARRAY2.
Un "Extended header" peut faire référence à un ensemble de "feature blocks". Hors les "features blocks" sont gérés globalement pour l'objet (et non à l'intérieur d'un extended header) à partir de l'offset en 0x6e. Par exemple, le premier extended header va faire référence aux 3 premiers features blocks, donc à partir du rang 0, 3 feature blocks. L'extended header suivant va utiliser 2 features blocks, à partir du rang 3, donc count = 2, offset = 3. Et ainsi de suite.
Je ne sais pas si ça t'éclaire. Concrètement, sans faire un dessin, je ne sais pas si c'est possible de rendre les choses compréhensibles pour une telle structure.

Reste que dans le cas que tu exposes, tu te fiches des feature blocks, donc inutile de se prendre la tête...

[Armand]

Merci pour ces précisions isaya. Je reviendrais exhumer ce topic après tests pour faire partager mes expériences sur le sujet.