La Couronne de Cuivre

CRÉATION D'UNE PORTE DANS UNE CARTE EXISTANTE

Cocrane sera content, on arrive enfin à l'objet initial de ce didacticiel !

Pour résumer, voici ce qu'il veut faire : Dans BGT, il souhaite créer un passage secret dans une carte existante, mais qui n'apparaît qu'après la fin de BG. Pourquoi ? Parce que son mod commence après que vous avez occis Sarevok.

Et voici ce que ça donne :

Ce qui conduit invariablement à un CTD dans le jeu.

Avant de continuer, nous allons vérifier quelque chose. Il arrive que dans le jeu original certaines cartes utilisent le même fichier WED et le même fichier TIS.
Pour le vérifier, c'est assez simple avec NearInfinity. Et il se trouve que la carte utilisée est dans ce cas : AR7811.

Lançons donc NearInfinity et chargeons la carte AR7811.ARE :

Nous constatons immédiatement qu'elle utilise le fichier AR7263.WED.

Et je vais vous dire un petit secret. Tendez bien l'oreille : c'est le cas de la plupart des petites cartes des maisons de Baldur's Gate qui partagent le même fichier WED.

Cliquez sur le bouton View/Edit.

Le champ Overlay 0 (traduction : « le fond de carte ») utilisé est AR7263.TIS.

Et ce n'est pas tout : cliquez donc sur le bouton Find > reference to this file pour rechercher tous les fichiers qui comportent des références à ce fichier.

Une nouvelle fenêtre s'ouvre comportant la liste des extensions de fichiers utilisés par le jeu.

Puisque NearInfinity a été programmé de manière intelligente, il a automatiquement coché la case ARE puisque les fichiers WED ne sont recensés que dans les fichiers ARE. Lançons la recherche en cliquant sur le bouton Search :

Le fichier AR7263 est utilisé par 10 cartes !

Lecteur a écrit : La belle affaire ! Ça change quoi ?

Ça change tout !
Si nous modifions le fichier AR7263.WED et le fichier AR7263.TIS qui lui est associé, cela aura des répercussions dans toutes les cartes concernées.
De plus, nous avons vu que pour créer une porte, il faut modifier à la fois les fichiers ARE et les fichiers WED.
Si nous ajoutons une porte dans le fichier AR7811.ARE, nous devons aussi la paramétrer dans le fichier AR7263.WED.
Admettons que nos modifications fonctionnent. Lorsque nous chargerons les 9 autres cartes (AR7263, AR7405, AR7711...), le jeu plantera parce qu'il cherchera dans les fichiers ARE la porte paramétrée dans le fichier AR7263.WED.

Pour que ça marche, il faudrait aussi ajouter la porte secrète dans les 9 autres fichiers ARE.
Vous conviendrez que ça n'a aucun sens !

De plus, il se trouve que les fichiers TIS de certaines cartes de BG1 comportent des scories d'une phase de développement qui n'a pas abouti.

La dernière ligne représente des images qui ont sans doute été créées pour simuler le feu de cheminée. Elles semblent utilisées (je dis semble car le feu est animé in game et le fichier ARE ne contient aucun fichier bam d'animation) et sont référencées dans le fichier WED : bref, tout ceci me semble codé en dur.
Et lorsqu'on charge la carte dans IETME pour la modifier et la sauvegarder, ces 6 dernières tiles ne sont pas sauvegardées. Ce qui conduira invariablement à un CTD lorsqu'on entrera dans une carte qui utilise le fichier WED d'origine.

Bref, l'ami coco n'a pas eu de chance : il est tombé sur le cas où toute modification de la carte devient un enfer !

Mais rassurez-vous, impossible n'est pas moddeur : en termes de modding, il n'y a pas de problème, il n'y a que des solutions. Enfin tant qu'on ne se heurte pas à une limitation du moteur du jeu...

En l'occurrence, il y a deux solutions. Je vous préviens tout de suite, je préfère la seconde, car je la trouve plus élégante, mais c'est aussi la plus chronophage.

Mais commençons par la première.

A. CRÉER UNE « FAUSSE » PORTE SECRÈTE.

La première solution consiste à « simuler » l’existence d'un passage secret avec un travel trigger.
Nous n'utiliserons pas de porte, seulement une (ou plusieurs, selon le degré de complexité du bouzin que l'on souhaite pondre) région(s) dans le fichier .ARE.

Avantages :

Nous ne modifions pas les fichiers WED et TIS, donc nous évitons les problèmes de compatibilité avec les cartes qui utilisent aussi ces fichiers.
C'est très rapide et surtout ça peut se faire directement dans le tp2.

Inconvénients :

Visuellement, ce n'est pas très réaliste : pas de bloc magenta signalant l'existence de la porte, pas de modification du fond de carte quand on ouvre et ferme la porte...
Vous perdez la notion de « difficulté » à détecter la porte. De même, à moins de créer un script assez détaillé, cette fausse porte sera ouvrable par n'importe qui.

Bref, vous comprenez pourquoi je lui préfère l'autre solution. Mais tant pis pour moi, je n'avais qu'à ne pas mentionner cette option. Puisque c'est fait, il faut bien que je m'y colle.

Nous allons :

Simuler l'existence de cette porte dans DLTCEP SANS LA SAUVEGARDER.
La créer avec une procédure WeiDU, afin d'éviter au maximum les risques d'incompatibilité avec d'autres mods.

Alors commençons par créer le travel trigger et le point d'entrée :

Mais ce qui nous intéresse vraiment, ce sont les paramètres que nous allons utiliser dans la procédure WeiDU d'installation de la carte :

Pour se mettre en bouche, on va créer le plus facile, le point d'entrée.
Et pour ça, nous disposons d'une fonction WeiDU magique : fj_are_structure.

Traduction :

Code : Tout sélectionner

COPY_EXISTING ~AR7811.are~ ~override~
…
BUT_ONLY

Je charge le fichier AR7811.are et le sauvegarde dans le répertoire override si les modifications que j'ai faites l'ont modifié. Sinon, je ne le modifie pas.

Code : Tout sélectionner

PATCH_IF (SOURCE_SIZE > 0x11b) THEN BEGIN	// Taille minimum d'un fichier .ARE = Vérification de la validité du fichier .ARE

Je ne modifie mon fichier que s'il n'est pas corrompu : la vérification de la taille du fichier .ARE est un test classique de validation.

Code : Tout sélectionner

LPF fj_are_structure INT_VAR fj_loc_x = 332 fj_loc_y = 164 fj_orientation = 14 STR_VAR fj_structure_type = entrance fj_name = Exit0003 END

Je lance la fonction fj_are_structure pour ajouter le point d'entrée Exit0003 à ma carte en utilisant les paramètres suivants (que j'ai récupérés sur la simulation dans DLTCEP) :

INT_VAR = variables numériques.
- fj_loc_x : coordonnées X du point d'entrée (position horizontale).
- fj_loc_y : coordonnées Y du point d'entrée (position verticale).
- fj_orientation : direction à laquelle feront face les personnages lorsqu'ils arriveront dans cette carte en venant de la carte Co0003 (ici 14 = Southeast).
STR_VAR = variables alphanumériques.
- fj_structure_type : type d'élément à jouter à la carte. Ici c'est « entrance ».
- fj_name : Nom de l'élément que l'on ajoute (Exit0003).

Pour l'installation du travel trigger, nous allons utiliser une autre fonction très pratique : ADD_AREA_TRIGGER

De même, nous utilisons les valeurs que nous avons déterminées avec DLTCEP. Pour vous aider, je les indique entre parenthèses :

INT_VAR = variables numériques.
- ab_RT_Type : Type de région à ajouter (0 = Trap - 1 = Info - 2 = Travel). (1)
- ab_RT_BbLX : Coordonnée horizontale (X) située le plus à gauche du polygone représentant le travel trigger. (2) (11)
- ab_RT_BbLY : Coordonnée verticale (Y) située le plus en haut du polygone représentant le travel trigger. (2) (11)
- ab_RT_BbHX : Coordonnée horizontale (X) située le plus à droite du polygone représentant le travel trigger. (2) (11)
- ab_RT_BbHY : Coordonnée verticale (Y) située le plus en bas du polygone représentant le travel trigger. (2) (11)
- ab_RT_VxPr : nombre de vertex composant le polygone du travel trigger. (12)
- ab_RT_CuId = numéro d'index du curseur. (3)
- ab_RT_LPoX : Coordonnée X du Point de lancement. (4)
- ab_RT_LPoY : Coordonnée Y du Point de lancement. (4)
- ab_RT_Vx_X_0, ab_RT_Vx_Y_0, ab_RT_Vx_X_1, ab_RT_Vx_Y_1... : coordonnées horizontales (X) et verticales (Y) des différents vertex qui composent le polygone. (12)
  Attention : le premier est 0, le second 1...
STR_VAR = variables alphanumériques.
- ab_RT_Name : Nom du travel trigger. (5)
- ab_RT_Dest : Carte de destination. (6)
- ab_RT_EntN : Nom du point d'entrée dans la carte de destination. (7)

Vous remarquez que vous pouvez trouver les valeurs ab_RT_BbLX, ab_RT_BbLY, ab_RT_BbHX et ab_RT_BbHY à la fois dans l'onglet Regions (Bounding box (2)) et dans la fenêtre de définition du polygone (11).

Et pour finir, on peut résumer la procédure à ceci :

Notre carte est fonctionnelle, il ne nous reste plus qu'à gérer l'apparition de ce passage secret. Cela se fait par script, comme nous le verrons dans la partie suivante.

[/size]

B. CRÉER UNE NOUVELLE CARTE À PARTIR DE L'ORIGINALE ET L'IMPLANTER DANS LE JEU.

Je vous préviens de nouveau : cette technique est longue et pénible à réaliser, mais c'est aussi la plus gratifiante lorsqu'on ouvre la carte créée dans le jeu.

Tout d'abord, nous allons créer un clone de la carte AR7811. Vous pourriez les extraire du jeu ou en faire une copie avec NearInfinity ou DLTCEP.

Mais comme nous allons devoir utiliser WeiDU un peu plus tard, je vais en profiter pour vous donner une procédure WeiDU par tp2 qui fait le travail toute seule :

NO_LOG_RECORD indique que cette procédure ne peut pas être désinstallée. Je l'utilise généralement lorsque je veux tester des blocs de procédures d'installation non intrusives sur des éléments de mon mod sans avoir à me taper l'installation complète.

Si vous souhaitez pouvoir désinstaller, il suffit de commenter cette ligne en ajoutant « // » devant, comme ceci :

Code : Tout sélectionner

//NO_LOG_RECORD

Quant au reste du code, je l'ai traduit dans la procédure, excepté la ligne suivante :

Code : Tout sélectionner

      READ_ASCII ("%offsetoverlays%" + ("%nboverlays%" - 1) * 0x18 + 0x04) ~tileset~

0x18 = taille d'un overlay
0x04 = offset (adresse) du nom de l'overlay (« Name of tileset » dans la structure Overlay du fichier WED).

Note : Je modifierai ce code plus tard pour nous simplifier la vie. S'il vous intéresse, je vous conseille d'attendre la version définitive à la fin de ce didacticiel pour le recopier.

>> J'ai donc cloné la carte AR7811 en carte Co0001 (j'ai utilisé un préfixe imaginaire pour indiquer que c'est une carte du mod de coco).

Pendant que j'y étais, j'ai créé un second clone Co0002 car j'ai proposé deux passages secrets à Cocrane. Libre à lui de choisir celui qu'il préfère.

Pour les sceptiques, on vérifie dans NearInfinity ou dans DLTCEP :

Le fichier ARE pointe bien vers les fichiers CO0001.WED et CO0001.BCS.

Et le fichier WED est bien lié au fichier CO0001.TIS.

Il est temps de créer nos portes secrètes.
[/size]

1. Dessiner une porte secrète dans la cheminée et dans le mur.

Avec mon logiciel graphique préféré, j'ai donc créé deux passages secrets : l'un dans la cheminée, l'autre sur le mur Est.

Si j'isole les tiles, ça donne ceci pour la cheminée :

- Et pour le mur :

-

Vous vous souvenez certainement que je vous ai dit qu'en général le fichier TIS affichait les portes ouvertes et que l'on matérialisait les portes fermées par des « alternate tiles » ajoutées à la fin.
C'est effectivement ainsi qu'ils sont constitués. Cependant, ce n'est pas obligatoire. On peut très bien avoir un fond de carte représentant les portes fermées et ajouter les images des portes ouvertes à la fin du fichier. L'essentiel étant de bien définir les paramétrages d'affichage de nos portes.

C'est d'ailleurs ce que j'ai fait ici avec la carte Co0001. D'abord par paresse, mais aussi pour illustrer ce cas particulier dans le tuto.

Mais assez parlé, allons-y.

2. Créer la porte secrète dans la cheminée.

Je crée donc ma porte secrète dans la cheminée :

La cheminée est donc une porte secrète avec 80 % de difficulté à découvrir.
Par commodité, j'ai défini les mêmes polygones d'ouverture et de fermeture de la cheminée :

Je règle aussi le polygone de transparence lorsqu'on baisse la tête pour entrer dans la cheminée :

Je n'oublie pas que le but du jeu, c'est de passer dans une autre carte. Mais comme je ne la connais pas (ce cachottier de Coco ne m'a pas donné ce point du scénario...), je l’appellerai Co0003.
Les paramètres relient donc la cheminée au travel trigger Tran0003 que j'ai créé à dessein :

>> Pour que le passage fonctionne, il faudra que Coco crée un point d'entrée Exit0001 dans sa carte secrète Co0003.

Vous avez sans doute remarqué que j'ai considéré que la porte secrète ouverte est représentée par la cheminée allumée alors que la porte fermée est représentée par la cheminée éteinte. Je sais, ce n'est pas très logique, mais comme la carte originale représentait la cheminée allumée, je n'ai pas voulu me compliquer la vie.
D'autant que ça ne change pas grand-chose au fonctionnement de la porte. J'ai simplement coché la case Open pour indiquer que la porte était ouverte en entrant dans la carte (cheminée allumée).

Mais ça ne suffit pas, j'ai aussi modifié le fichier Co0001SR.bmp pour permettre au joueur de pénétrer dans la cheminée pour emprunter le passage Tran0003.

Voici le fichier original :

La cheminée est bloquée par des carrés noirs (0 – Solid obstacle) et gris (8 – Light obstacle) qui définissent des passages interdits.

Je les ai donc remplacés par des carrés bleus (4 – Stone 1) qui permettent le déplacement des personnages.

Mais ce n'est pas encore terminé : pour éviter que les personnages ne puissent entrer dans la cheminée allumée (porte ouverte), j'ai aussi modifié les impeded blocks de la porte ouverte :

Quant à ceux de la porte fermée (cheminée éteinte), je les laisse vides, car ils correspondent aux zones de passage de la carte Co0001SR.bmp et permettront donc de passer dans la cheminée.

Enfin, on crée notre point d'entrée :

Passons maintenant au passage secret dans le mur.

3. Créer la porte secrète dans le mur.

Je vais profiter de ce tuto pour vous montrer comment modifier des tiles d'un fichier TIS existant.

Petit rappel, voici les tiles de la carte originale et celles de ma porte :

–

J'aurais très bien pu utiliser la même technique que pour la cheminée : considérer que les images de la porte secrète ouverte représentent un mur et celles de la porte secrète fermée un passage ouvert dans le mur.

Mis tant qu'à faire, autant en profiter pour vous expliquer comment revenir à une représentation plus « normale ».

Nous allons donc remplacer dans le fichier Co0001.TIS les tiles du mur par ceux de la porte ouverte.

Chargeons donc notre carte Co0002.ARE et examinons la structure du fichier TIS dans l'onglet Wed :

Cliquez sur le bouton Edit tiles pour ouvrir la fenêtre des tiles :

Puis sur le bouton Preview pour visualiser le fond de carte.

Avec la souris, sélectionnons la première tile de la porte dans le mur (matérialisée par un carré magenta) :

Puis la seconde :

Nous obtenons donc les informations suivantes sur nos deux tiles :

La première [4.1] porte le numéro 14.
La seconde [4.2] porte le numéro 24.

Lecteur a écrit : Mais encore ?

C'est très important !

Rappelez-vous : Je vous ai dit que le fichier WED indexe les numéros des tiles par ligne et par colonne.

En l'occurrence, si nous utilisons ce fichier

pour remplacer les tiles du fond de carte, nous n'allons pas remplacer les tiles 14 et 24, mais les tiles 14 et 15 !
Tu ne me crois pas, lecteur incrédule ? Eh bien vas-y, fais-le !

Par respect pour les âmes sensibles, je cacherai le résultat de cette opération désastreuse. Pour les autres, jetez donc un &#339]

[/SPOILER]

Convaincus ?

>> Voici donc la procédure à suivre : Il faut scinder l'image de la porte en carrés de 64 x 64 pixels, les convertir en fichier TIS, et les importer.

Ce qui donne :

–

Pour les convertir en tis, je vous laisse suivre la procédure indiquée dans le premier tuto.

Revenons donc à notre fichier WED et sélectionnons la tile 14 :

Cliquons sur le bouton Replace tiles pour sélectionner le fichier TIS à importer :

Par défaut, le curseur se positionne sur le fond de carte (CO0002.TIS), mais celle qui nous intéresse, c'est CO0001O1. Sélectionnons-la et validons par OK.

La partie supérieure de la porte a été importée et a remplacé la tile originale.

Opérons de même avec la partie inférieure de la porte :

Notre porte redessinée, N'OUBLIONS SURTOUT PAS DE SAUVEGARDER !

Et pour faire bonne mesure, Back, Back et SAUVEGARDEZ de nouveau une fois de retour dans l'onglet ARE !

Nous disposons maintenant du fond de carte adéquat. Il nous reste à créer notre porte.

J'ai conservé les mêmes paramètres que ceux de la cheminée. Exceptés ceux des polygones et des impeded blocks.

Vous constatez en effet que je n'ai défini aucun polygone pour la porte ouverte : une fois ouverte, on ne peut plus la refermer.

En revanche, celui de la porte fermée est défini :

D'ailleurs, le voici :

De même, j'ai créé un travel trigger pour mener à la carte Co0003 :

J'ai aussi modifié le fichier Co0002SR.bmp pour gérer le déplacement des personnages :

Cette fois, j'ai ajouté du bois (9 – Wood 1) pour être raccord avec la carte.

Ce qui donne les impeded blocks suivants :

Sans oublier les polygones de transparence du fichier WED :

Et le point d'entrée :

Nous disposons donc de deux cartes dotées chacune d'un passage secret différent.

Il nous faut maintenant les intégrer dans le jeu en nous assurant qu'elles ne causeront aucun problème de compatibilité avec le jeu vanilla, et bien évidemment avec les autres mods.

4. Intégrer les cartes clones dans le jeu en évitant les incompatibilités.

Récapitulons : Après avoir vaincu Sarevok, CHARNAME continue ses aventures dans Baldur's Gate. A un moment donné, il doit retourner dans la carte AR7811 et y découvrir notre passage secret.
Problème : la carte AR7811 ne contient pas ce passage secret puisque nous l'avons créé dans les cartes Co0001 et Co0002.

Qu'à cela ne tienne ! Nous allons remédier à ce petit désagrément.

Le principe est simple :

>> Nous allons indiquer au jeu que dès que la variable globale Coco_Passage_Secret sera fixée à « 1 », TOUS LES ACCÈS À LA CARTE AR7811 MÈNERONT EN FAIT SOIT À LA CARTE CO0001, SOIT À LA CARTE CO0002.

Je détaillerai toutes les étapes de cette intégration pour la carte Co0001. Il suffira de modifier Co0001 par Co0002 pour effectuer les mêmes opérations pour la carte Co0002.

Première chose à déterminer : Quels autres fichiers du jeu font-ils référence à la carte AR7811 ?

Faisons comme si vous ne connaissiez pas le jeu. Vous avez de la chance, NearInfinity va nous aider.
Nous allons chercher toutes les références du fichier AR7811.ARE présentes dans d'autres cartes du jeu.

Lancez NearInfinity et utilisez le raccourci clavier [Ctrl]+[Alt]+[X]. Ça tombe bien : par défaut, il se positionne sur les cartes !
Cochez la case Custom filters et cliquez sur le bouton Set options... :

Cochez le premier filtre et sélectionnez as string (puisque nous recherchons la chaîne de caractères AR7811.ARE).
Indiquez le nom du champ que nous allons vérifier (Field name) : Destination Area (c'est le nom que donne NearInfinity au champ Destination d'un travel trigger).
Saisissez la valeur de ce champ (Field value) : AR7811.ARE. N'oubliez surtout pas de saisir « .ARE » car NearInfinity ne comprendrait pas AR7811 seul.
Lancez la recherche en cliquant sur le bouton Search.

Eh bien on s'en doutait un peu : On accède à la carte AR7811 par le quartier AR7800 de Baldur's Gate. Une fois entré, on peut se rendre à l'étage (AR7812).
Mais maintenant, vous saurez comment rechercher des informations dans NearInfinity.

Il serait extrêmement facile de charger les cartes AR7800 et AR7812 et de copier leur travel trigger qui permet d'entrer dans la carte AR7811, puis d'en modifier les champs pour qu'il nous envoie dans Co0001. Idem avec le point d'entrée : on copierait le point d'entrée de AR7811 et on le renommerait Exit0001 pour qu'il corresponde à celui de la carte Co0001.

Sauf que... ATTENTION aux problèmes de compatibilité si un autre mod utilise et modifie aussi les cartes AR7800 et AR7812.

Bref, comme toujours en modding, mieux vaut faire les choses bien. Et dans ce cas, faire les choses bien, c'est patcher (modifier) les cartes AR7800 et AR7812, et surtout ne pas en créer de nouvelles versions qui écraseraient celles du jeu.

Heureusement, nous avons un outil qui nous permet de le faire sans trop de difficultés : WeiDU.

Nous allons donc cloner leurs travel triggers et leurs Entrance points relatifs à la carte AR7811.
Comment ? Comme ceci :

Traduction :

Code : Tout sélectionner

LPF ~GW_CLONE_TRAVEL_TRIGGER~ STR_VAR GW_Dest_old = AR7811 GW_Dest_new = CO0001 GW_Name_new = Trancoco0001 RET GW_add_trigger END

On lance la fonction ~GW_CLONE_TRAVEL_TRIGGER~ qui va rechercher l'existence d'un travel trigger relatif à la carte AR7811 (variable GW_Dest_old).
S'il existe, elle stocke ses paramètres dans une chaîne de caractères (variable GW_add_trigger) pour qu'on puisse les cloner.
La variable GW_Dest_new (CO0001) intégrera automatiquement la référence de notre carte dans le travel trigger.
La variable GW_Name_new (Trancoco0001) est le nom du nouveau travel trigger.

Code : Tout sélectionner

PATCH_IF ("%GW_add_trigger%" STRING_COMPARE_CASE "") THEN BEGIN

Si la variable GW_add_trigger) n'est pas vide, c'est qu'on a trouvé un travel trigger de transfert dans la carte AR7811, donc on le clone.

Code : Tout sélectionner

LPF ~GW_REINCLUDE~ STR_VAR GW_input = EVAL "%GW_add_trigger%" END

C'est cette fonction qui clone le travel trigger dans la carte.

Vous trouverez en pièces jointes le fichier GW_Tuto_Cartes.tp2 qui détaille toutes ces opérations.
Pour l'utiliser, intégrez-le dans votre propre tp2 en modifiant les variables GW_Dest_old, GW_Dest_new et GW_Name_new pour les adapter à vos besoins.

Pour les curieux, vous trouverez ci-dessous le détail de ces fonctions :

► Afficher le texte

N'oublions pas les points d'entrée :

Pour eux, j'ai utilisé la fonction de WeiDU fj_are_structure qui ajoute un élément à une carte.

Et on peut vérifier dans les fichiers AR7800.ARE et AR7812.ARE :

Voilà : notre carte est opérationnelle et intégrée dans le jeu.

Malheureusement ce n'est pas terminé : les cartes AR7800 et 7812 comportent désormais deux travel triggers au même emplacement – l'original conduisant à la carte AR7811 et le cloné à la carte Co0001.

>> Il faut donc indiquer au jeu quand prendre en compte le passage vers la carte AR7811 ou vers la carte Co0001.

Nous allons le faire avec le script des cartes AR7800 et AR7812 en utilisant la variable Coco_Passage_Secret.

Le principe est simple : on ajoute les actions suivantes aux scripts de ces cartes :

AR7800_add.baf

AR7812_add.baf

Bien entendu, ne vous gênez pas pour adapter le nom et les valeurs de ces variables selon votre bon vouloir.

Note : J'ai commenté la commande OnCreation() car il se peut que le script original contienne déjà cette condition. Par expérience, je me suis aperçu que le moteur du jeu traite de manière assez aléatoire deux blocs de script la comportant : quelque fois les deux blocs sont traités, d'autres fois, seul le premier est pris en compte. Pour éviter cette loterie, je vais donc ajouter mon bloc au tout début du script sans référence à OnCreation(). Comme ça, si un bloc suivant contient cette condition, il sera traité automatiquement.

Lecteur a écrit : Et si la carte d'origine n'a pas de script ?

Toujours aussi impatient !
Eh bien nous allons le gérer dans le tp2 :

Traduction : Si le script AR7800.bcs existe dans le jeu, je lui ajoute au début le bloc AR7800_add.baf, sinon, je compile le script AR7800. Idem pour le script AR7812. Ici encore, je vous laisse modifier le nom du répertoire de votre mod (« monmod »).

► Afficher le texte

[/size]

C'est terminé !

Modification du 21.04.2016 : ajout des pièces jointes.

Le chapitre 5 du tuto concerne les portes spéciales (invisibles, animées...) : il est en cours de rédaction.

Au début de l'été, je compte rédiger le cinquième chapitre de ce tuto concernant les "portes spéciales".
Quels sont les points qui vous paraissent prioritaires : les portes invisibles, les portes animées, d'autres points... ?

La Couronne de Cuivre

[TUTORIEL] [CARTES] Créer une porte dans une carte existante : Chapitre 4

[TUTORIEL] [CARTES] Créer une porte dans une carte existante : Chapitre 4