La Couronne de Cuivre

Introduction


Alors on va passer à la partie la plus fun, on va aller chercher un cre du jeux original, le recopier dans l’override sous un autre nom, puis le « réécrire » à notre sauce.
La technique consiste à récupérer un cre qui ressemble à ce qu’on veut (et qui a surtout la bonne animation, vu que c’est hard-coded) et on va changer ce qui ne nous plait pas pour coller à l’idée qu’on a en tête. Bien sur, ce genre de manipulation est à réserver aux personnages plutôt secondaires ou tout du moins aux personnages qui ne nécessitent pas de grosses modifications pour coller à ce que vous voulez. Sinon effectivement DLTCEP est quand même un peu plus rapide…


Bon trêve de bavardage on s’y met :



UN "PETIT" EXEMPLE



EXPLICATION DÉTAILLÉE


1. Mise en place générale

Avant de passer aux infos en rapport avec la partie files actions où on va allez chercher les informations qu’on veut réécrire, j’ai préféré commencer par quelques commandes élémentaires (en gris) qui vont nous permettre de fabriquer les informations essentielles pour votre cre.
La commande de base qu’on a déjà plus ou moins vue : Je copie un fichier existant « beast.cre » et j’en fais une copie sous mon nom à moi avec préfixe et tout le tremblement. Le truc c’est qu’ici il n’y aura que mon nom de fichier qui va changer. Ma créature a toujours le même fichier dlg, le même script attribué, la même death variable, etc…

Par conséquent je vais changer tout ça avec la commande « WRITE_ASCII » qui comme je l’ai peut-être déjà dit, est la commande que l’on utilise lorsque l’on veut patcher des informations « écrites » (entendez par la non chiffrées). Mais vous allez me dire : la logique ne voudrait-elle pas qu’après mon « WRITE_ASCII » je mette une valeur en hexadécimal de type «0x54 » par exemple ? Et bien on pourrait parfaitement ! D’ailleurs si vous vous amusez à farfouiller dans le file action vous pourrez trouver des valeurs hexadécimales qui correspondent à ces données. Cependant comme vous pouvez le voir j’ai utilisé des mots clefs :

DEATHVAR
DIALOG
SCRIPT_OVERRIDE

Donc qui sont beaucoup plus intuitifs et qui sont des commandes classiques que vous pourrez trouver dans nombre de TP2 (je ne parle évidemment pas des mods old-school tel ceux de kalmachin et consort…). Vous pourrez retrouvez ce genre de mots clefs soit dans les tp2 des autres comme je l’ai dit, dans des extraits du readme de WeiDU, mais surtout (et c’est comme ça que je m’y suis pris) en ouvrant le fichier « ini » lié à vos highlighters : toutes les commandes y sont regroupés et on retrouve entre autre ce genre de chose. Alors mon conseil c’est d’explorer ce fichier et éventuellement d’essayer des combinaisons, par ailleurs c’est un excellent moyen de découvrir de nouvelles commandes et de se familiariser avec la logique d’un tp2. Alors farfouillez mes amis ! FARFOUILLEZ !


2. WRITE_ASCII

Maintenant on va passer à la suite, c’est la où on va commencer à se marrer… On a attribué un nouveau nom de fichier à notre cre, un nom in game et on lui a attribué nos propres fichiers dialogue, script, etc… On va donc commencer à attaquer les offsets en modifiant des données permettant d’afficher le portrait du PNJ :
Si on se réfère à mon tableau tout en haut de ce tutoriel, on s’aperçoit que ces données ont une valeur de 8 cela nécessite donc un WRITE_ASCII. De plus comme vous pouvez vous en apercevoir ce sont des valeurs écrites donc là aucune question à se poser c’est forcément du WRITE_ASCII. Mais ça vous le saviez déjà si vous avez suivi la théorie. Comment ? Mais si vous le saviez !


Comme on le voit dans l’exemple, j’utilise le WRITE correspondant à la taille de l’offset et j’écris la valeur de l’offset (entre ~~ ici car c’est une valeur écrite). A noter également que je ne me suis pas servi des deux premiers 0 après le x (0x34 au lieu de 0x0034 comme on peut le voir dans le tableau du file action). En fait les deux syntaxes sont possibles mais la norme est plutôt de ne pas les utiliser mais si vous préférez avec les zéros après tout…



3. WRITE_SHORT] & WRITE_BYTE

Bon, on continue la manipulation avec un WRITE_SHORT si vous avez compris jusque la ça va aller assez vite maintenant la manip étant toujours la même :
Je suis toujours mon modèle en observant mon code couleur. On s’aperçoit que j’utilise mon WRITE_SHORT car la valeur de mon offset est de 2. Petite subtilité pour modifier ma classe d’armure contre les dégâts « écrasants » (crushing) je mets ma valeur chiffrée entre guillemets pour que WeiDU puisse prendre en compte une valeur négative. Sans transition on passe à la suite :

Je ne m’étendrai pas là-dessus, je vais chercher mes infos dans mon petit tableau et je m’aperçois que la valeur de l’offset est de 1 donc j’utilise WRITE_BYTE car c’est la commande qui correspond à un offset de cette taille. Et après habituel, j’indique le nouveau montant de la valeur.


4. Quelques nouveautés à signaler : commandes WeiDU clef en main

En matière d’édition de fichier cre, les dernières maj de WeiDU nous font profiter de pas mal de nouvelles commandes toutes faites qui nous évitent nombre de manipulations compliquées. Celles ci sont trouvables sous le chapitre macro listing, nous pouvons ici en relever quelques unes assez pertinentes :

ADD_CRE_EFFECT (pour ajouter des effets à des créatures (changements de couleurs, invisibilité, boostage de carac/de CA, protections diverses, immunités...)
DELETE_CRE_EFFECT (pour effacer un ou plusieurs effets sur une créature)
DELETE_CRE_ITEM (pour effacer un ou plusieurs objets de l’inventaire ou de l’équipement de la créature.)[/color]


Voici pour les plus courants et les plus usités. Voir ce tuto pour l'utilisation d'une macro, ça obéit globalement à la même structure peu importe la macro.

Maintenant ça sera à vous de faire un tout cohérent. Bien souvent il suffit de modifier juste quelques éléments pour avoir un cre qui soit utilisable. Personnellement dans la plupart des cas, la création de cre par tp2 est la méthode que je vais utiliser systématiquement car c’est la plus souple la plus rapide, et la plus « propre » j’ai envie de dire.


5. Une option supplémentaire pour éviter certains bugs

La commande WRITE_ASCII comme on l'a déjà vu s’écrit sur 8 octets et si votre valeur "écrite" atteint les 8 lettres vous n'aurez aucun souci mais si ce n'est pas le cas alors vous aurez une partie de l'ancienne valeur qui subsistera. Si on reprend notre exemple de tout à l'heure :
En observant notre fichier sur un éditeur tel que cremaker ou DLTCEP on aura quelque chose du genre :

Death variable = #vBrymul
Dialog file = #vBrymul
Override script = #vBrymul


Nous devons donc préciser sur quel espace, sur quelle zone, nous écrivons pour que la valeur que nous indiquons remplace complètement l'ancienne. En l’occurrence, la zone entière de 8 octet :

Et voilà. En recourant à cette manip, vous vous éviterez bien des problèmes. En précisant le nombre de caractères vous avez également la garantie de ne pas "déborder" sur les autres adresses ; ce qui a de bonnes chances de rendre invalides les scripts suivants par exemple. A savoir que comme vous l'aurez peut être deviné pour toute commande de type WRITE, la valeur "#chiffre" vous permettra d’écrire sur l'espace que vous avez précisez (1 octet, 2 octets, etc...).

Ajout d'une autre partie pour résoudre d'eventuels bug avec la commande WRITE_ ASCII. En espérant que ça vous soit utile...

Armand a écrit :5. Une option supplémentaire pour éviter certains bugs

La commande WRITE_ASCII comme on l'a déjà vu s’écrit sur 8 octet et si votre valeur "ecrite" atteint les 8 lettres vous n'aurez aucun souci mais si ce n'est aps le cas alors vous aurez une partie de l'ancienne valeur qui subsitera.

Il y a une erreur dans ton exemple. En ne précisant pas #8, le seul risque est qu'il reste des caractères parasites à la fin, ce qui donnerait :

Death variable = #vBrymXXXXXXXXXXXXXXX
Dialog file = #vBrymXX
Override script = #vBrymXX
XX étant les caractères demeurant d'avant.

Pour Death variable, le champ fait 32 octets (d'où le plus grand nombre de X dans mon exemple), dont 18 utilisables en raison des variables de mort sous la forme SPRITE_IS_DEAD#vBrym.

Le fait d'ajouter #8 précise le nombre de caractères à écrire. Si le texte indiqué à WRITE_ASCII est trop long, il est tronqué au nombre indiqué. S'il est plus court, WeiDU complète la fin avec des caractères NUL (des 0 binaires) qui marquent la fin d'un texte.

A noter que WRITE_ASCII écrit bêtement ce qu'on lui dit si on ne précise pas le nombre de caractères. En conséquence, si on écrit 9 caractères là où il n'en faudrait que 8, on va allègrement jardiner dans le champ suivant et donc l'endommager.
Par exemple :
WRITE_ASCII SCRIPT_OVERRIDE ~#vBrym789~
va joyeusement écrire un 9 à la place du premier caractère de SCRIPT_CLASS. Bref, non seulement le script Override ne sera pas reconnu (si le fichier BCS s'appelle bien #vBrym789.BCS) mais le script Class sera aussi introuvable dans le jeu à cause du 9 à la place du vrai caractère.

Par conséquent, utiliser systématiquement #N est aussi une sécurité pour s'assurer de ne pas écraser quelque chose en cas d'erreur. A condition de mettre la bonne valeur pour N, bien entendu !

Merci pour ce complément d'information isaya. De mon coté j'ai réajusté légèrement le topic en suivant tes explications pour eviter les confusions et j'en ai profité pour mettre un lien vers mon tuto sur les macros vu qu'il en existe un depuis quelques temps déjà.

Et voilà, le dernier tuto de la série d'Arrmand a retrouvé ses images.

Bonne lecture.