Patcher les fichiers cre avec le TP2

Récemment j'ai eu à m'intéresser à la modification de cre via le TP2 et j'aurais donc quelques questions. Comme les esemples sont toujours plus parlant, je commence par ça :

Citation :

COPY_EXISTING ~vampif01.cre~ ~override/#vVamp1.cre~
SAY NAME1 @64
SAY NAME2 @64
WRITE_ASCII DEATHVAR ~#vVamp1~
WRITE_ASCII DIALOG ~#vVamp1~
WRITE_ASCII SCRIPT_OVERRIDE ~#vVamp1~
WRITE_SHORT 0x24 82 // Change current HP to 82
WRITE_SHORT 0x26 82 // Change max HP to 82
WRITE_SHORT 0x46 "-1" // Change natural AC to -1
WRITE_SHORT 0x48 "-1" // Change effective AC to -1
WRITE_BYTE 0x270 0x80 // Change to be NEUTRAL
WRITE_BYTE 0x0052 7 // Change THACO to 7

Voila donc ici j'ai utilisé une manip que j'ai plus ou moins méchamment pompé sur le tout jeune mod tyris flare dont le tp2 est trés intéréssant. Dans le sens où on peut y voir plusieurs manip d'édition de fichier assez basique (comprenez pas trop compliqué et surtout aps trop exhaustive.).

Dans la premiére ligne je copie le fichier existant vampif01 en #vvamp1 dans l'override. Puis je remplis des champs équivalent à l'onglet other attributes de cre maker via la commande "WRITE_ASCII".
La commande "WRITE_SHORT" elle me permet en reprenant les offset associé dans ietme (0x24,0x26,0x46...) de modifier les valeurs existantes. Jusque la je n'ai pas vraiment de probléme puis vint cette commande "WRITE_BYTE" où je ne donne pas de valeur réel mais une valeur hexa décimal equivalente trouvable dans le fichier EA.IDS qui correspond au champ ennemy ally.
Donc ici se pose la question : pourquoi utiliser ici une valeur hexa décimal et aps ailleurs ? En refléchissant à tout ça j'ai été amené à me pencher sur trois commandes :

Citation :

* or WRITE_BYTE offset value The first argument is the offset at which the second argument (an 8-bit byte value) is written.
* or WRITE_SHORT offset value The first argument is the offset at which the second argument (a 16-bit short value) is written.
* or WRITE_LONG offset value The first argument is the offset at which the second argument (a 32-bit long word value) is written.

Voici l'explication d'iesdp concernant ces commandes. Ca m'a donc amener à me poser deux autres questions : Pourquoi la commande "WRITE_BYTE" fonctionne aussi bien en valeur réelle qu'en valeur hexa décimal (y'a t-il une restriction suivant les offset) ? Si la valeur (data type) est exprimé en byte dans la case equivalente dans iesdp doit on forcément utiliser la commande "WRITE_BYTE" ou c'est unquement la taille de la valeur de l'offset qui compte ?

Enfin j'ai cherché à appliquer des effects sur mon tout nouveau fichier cre, il y a bien ces deux trucs :

Citation :

0x02c4 4 (dword) Offset to effects
0x02c8 4 (dword) Count of effects.

J'imagine que la premiére ligne est le numéro de l'effect et la deuxiéme la quantité d'effect utilisé ? Je sais qu'il y a aprés des offset particulier pour parametrer l'effect mais au niveau de la syntaxe comment ça se presente ? On le place également dans le patchage du cre ?

Salut, Armand!
Ca bosse dur, on dirait ^^
Alors, commençons,
tous ces WRITE fonctionnent de la même manière, tu les utilises selon la taille de ce que tu as envie d'écrire dans le fichier cre. Soit:

WRITE_BYTE pour une information d'un octet (8bits)
WRITE_SHORT pour un word (16bits)
WRITE_LONG pour un dword (64bits)
WRITE_ASCII pour ce qui est plus long et composé de lettres (128bits si on ne précise pas la taille de la donnée soit 8 caractères (d'où la règle d'or de Cool dans les noms de d, baf et j'en passe...))

Leur fonctionnement général est le suivant:
WRITE_MACHIN adresse donnée

Dans un fichier, chaque information possède une adresse. Cette adresse peut s'écrire en hexadécimal, en décimal ou même en binaire du moment qu'on précise quelle "unité" on utilise.
0x0010 = 0d0016 = 0b00010000
hexadécimal décimal binaire

Ensuite la donnée que tu écris par-dessus ne doit pas être plus volumineuse que ce que tu peux en caser et doit être cohérente avec ce qu'attend le fichier à l'adresse où tu écris. (Donc pas de lettres pour l'adresse des PV par exemple)

Ensuite, passons aux effects. Tu souhaites certainement savoir comment on utilise les deux offsets que tu as cité 0x2c4 et 0x2c8. OK, tu l'auras voulu, planquez-vous, le code arrive!



Surtout, pas de panique. Je ne sais pas si tu as l'habitude de flirter avec un code pareil mais en sortant de ce topic, tu l'auras compris (si je suis pas trop flou ou à moins que tu ne saches déjà de quoi il s'agit).
Il faut savoir qu'ajouter des effects à une créature n'est pas sans conséquences sur le fichier. En effet, les offsets sont tout bouleversés lorsqu'on rajoute des données en plein milieu des autres.
Donc lorsque l'on rajoute un effect à une créature, certaines autres adresses doivent être mises à jour. Tu remarqueras que j'ai séparé le code en trois parties.

1ere partie: Récolte des données

On doit savoir ce qu'on modifie et pour cela, on doit aller chercher ces infos dans le fichier en lui-même. La commande READ est exactement l'inverse de WRITE:
On stocke une info trouvé à l'adresse indiquée dans une variable.

Ici, on a besoin de modifier les données correspondant à l'offset des items, des slots des items, des sorts connus, des sorts mémorisés, des sorts qu'on peut mémoriser et... de l'offset des effets ainsi que du nombre d'effets que possède déjà la créature.

2e partie: Ajout de l'effet

Alors comment l'ajouter?
Un effect de créature fait une taille de 0x108 hexadécimal bits donc on doit insérer un espace de cette taille dans l'offset des effects car l'offset des effects a pour rôle d'informer au jeu que toutes les données après lui sont des effects. INSERT_BYTES est parfait pour ça.
Ensuite on remplit cet espace vide par les paramètres de l'effect: en commentaire sur l'image.

De cette manière, si on veut modifier le THAC0 de la créature on commence par:
WRITE_LONG ("%offset_effet%" + 0x08) 54

Explications: 0x08 est l'adresse du type d'effect voulu dans l'effect lui-même qui possède l'adresse indiquée par %offset_effet%, l'opcode comme on l'appelle. 54 correspond à l'opcode du même numéro à savoir "THAC0 Modifier".

Les autres paramètres sont écris avec le même principe. L'effect a une adresse et le paramètre 1 de cet effect a une adresse dans l'effect. On va donc écrire dans le trou qu'on a fait tout ce qu'il faut pour obtenir un vrai effect.


3e partie: Mise à jour de la créature

Bien, on a notre effect. On doit maintenant rendre cohérent notre fichier en l'actualisant.
L'action première constituant cette étape est de réécrire le nombre d'effect que possède la créature car maintenant, elle en possède un de plus.
WRITE_LONG 0x2c8 ("%nombre_effet%" + 1)

Chose faite. Et maintenant, on doit décaler toutes les adresses étant après ce changement du nombre de bits qu'on a ajouté car toutes les données après l'ajout de l'effect se sont vues décalées de 0x108. Donc la condition est: si l'adresse à changer est après l'offset des effects, alors augmenter ces adresses de la taille de l'effect.
Ce qui donne le PATCH_IF NOT ("%offset_effet%" > "%offset_divers%")
C'est la condition. Puis augmenter l'adresse de la taille de l'effect soit 0x108.


Je sens que j'ai étalé un brouillard. Si tu le traverses, tant mieux mais si toi ou quiconque a des questions sur mon baratin, n'hésitez pas, ce n'est pas évident.

Je pense avoir saisi pas mal de choses. Peut être est ce du au fait que je me bouffe dut p2 depuis quelques temps déjà...
J'ai néanmoins quelques question sinon je ne serais pas la :

Citation :

READ_LONG 0x2a0 "offset_sorts"
READ_LONG 0x2a8 "offset_sorts_info"
READ_LONG 0x2b0 "offset_sorts_memorises"
READ_LONG 0x2b8 "offset_slot_item"
READ_LONG 0x2bc "offset_item"
READ_LONG 0x2c4 "offset_effet"
READ_LONG 0x2c8 "nombre_effet"

La partie entre guillemet ce sont des variable de ton invention non ? Peut on mettre n'importe quoi ou est ce prédéfini ?

Citation :

INSERT_BYTES "offset_effet" 0x108 // Insert cre value
WRITE_LONG ("offset_effet" + 0x08) 51 // Add effect n°51 (Strongdark by rgb)
WRITE_LONG ("offset_effet" + 0x14) "-16768752" // Parameter 1
WRITE_LONG ("offset_effet" + 0x18) 3 // Parameter 2
WRITE_LONG ("offset_effet" + 0x24) 100 //Probability 1

J'ai bien aimé ton explication ici ça m'a pas mal aidé à avancer. Mais d'une comment arrive tu à determiner la valeur en byte d'un fichier cre ? Pourquoi les offset de write_long ne corresponde t-il pas à ceux que l'on peut trouver dans la partie fileformat/effects d'iesdp ? Doit-on obligatoirement passer par near infinity ?

Citation :

WRITE_LONG 0x2c8 ("nombre_effet" + 1)
PATCH_IF NOT ("%offset_effet%" > "%offset_sorts%") BEGIN
WRITE_LONG 0x2a0 ("%offset_sorts%" + 0x108)
END
PATCH_IF NOT ("%offset_effet%" > "%offset_sorts_info%") BEGIN
WRITE_LONG 0x2a8 ("%offset_sorts_info%" + 0x108)
END
PATCH_IF NOT ("%offset_effet%" > "%offset_sorts_memorises%") BEGIN
WRITE_LONG 0x2b0 ("%offset_sorts_memorises%" + 0x108)
END
PATCH_IF NOT ("%offset_effet%" > "%offset_slot_item%") BEGIN
WRITE_LONG 0x2b8 ("%offset_slot_item%" + 0x108)
END
PATCH_IF NOT ("%offset_effet%" > "%offset_item%") BEGIN
WRITE_LONG 0x2bc ("%offset_item%" + 0x108)
END

Une dernière question sur la commande PATCH_IF NOT. C'est une commande adapté n'est ce pas ? Tel quel je ne l'ai pas trouvé dans le read me de weidu.

Citation :

READ_LONG 0x2a0 "offset_sorts"
READ_LONG 0x2a8 "offset_sorts_info"
READ_LONG 0x2b0 "offset_sorts_memorises"
READ_LONG 0x2b8 "offset_slot_item"
READ_LONG 0x2bc "offset_item"
READ_LONG 0x2c4 "offset_effet"
READ_LONG 0x2c8 "nombre_effet"

Tu as raison, les parties entre guillemets sont des variables de mon invention. J'ai pris des noms très explicites mais encombrants pour l'explication, d'autres auraient surement pris des noms de variables de 5 caractères tout au plus. Donc le nom, c'est comme le moddeur le souhaite, c'est son organisation.

Ensuite pour la taille en byte d'un fichier cre, on a des constantes à connaître ou à se noter dans un coin. L'IESDP en contient pas mal, mais pas toutes. Le fait que l'effect d'une créature fasse 0x108 hexadécimal bytes est une constante. Ensuite comment fait-on pour obtenir les offsets? L'IESDP n'a pas tort mais a oublié de préciser une chose (à moins que j'ai sauté une ligne): pour les offsets d'effects de creatures, on enlève 8 bytes par rapport aux effects externes (j'avoue mon incompréhension encore sur ce point...).
Donc si tu vas sur l'IESDP, ICI (et attention BG2 utilise la version 2 des effects)
Et que tu enlèves 8 aux offsets qu'il te propose, tu obtiens les offsets que j'ai utilisé dans mon exemple.

Par exemple, pour le numéro d'opcode, j'avais dit WRITE_LONG (%offset_effet% + 0x08) 233
Tu as %offset_effet% qui te permet de pécher ton poisson dans le bon lac (on va pas chercher dans les items, hein )
Et dans l'IESDP on te dit:
Offset: 0x0010
Size (data type): 4 (dword)
Description: Opcode number
10 en hexadécimal, ça donne 16, on retranche 8, ce qui donne 8 ou encore 0x08 en hexadécimal.
Donc on pêche le bon poisson dans le bon lac: %offset_effet%+0x08 est l'adresse où il faut envoyer l'hameçon. L'offset de l'opcode est un dword, donc 4 bytes, donc on utilise WRITE_LONG.

Finalement, on obtient: WRITE_LONG (%offset_effet%+0x08) 233
Le raisonnement est le même pour les autres paramètres de l'effect.

Enfin, PATCH_IF s'utilise comme suit:

PATCH_IF condition BEGIN
code
END

Dans la condition, tu as le droit d'utiliser NOT, AND, OR et bien plus encore dans la condition, ne t'en prives pas!
Pour en savoir plus, je t'amène directement au bon passage de Readme-WeiDu:
http://www.weidu.org/~thebigg/README-WeiDU.html#value

Si tu as peur de te tromper pour savoir où commence et où s'arrête la condition, mets-la entre parenthèses.

Et vive le fichier tp2!