DrAzTiK a écrit :Finalement cette commande écrase les fichiers au lieu de les patcher non ? (enfin ça les patch dans un certains sens mais seulement après avoir tout écrasé).
Non, elle n'écrase rien, elle remplace old par new. C'est à toi d'être intelligent pour que le remplacement ne devienne pas un écrasement.
Dans un traitement de texte, quand je fais un remplacement de "mot" par "nom", j'écrase bien "mot". Mais si je dis de remplacer par "mot nom", je me suis contenté d'ajouter "nom" et j'ai utilisé "mot" pour fixer l'endroit après lequel je voulais ajouter "nom".
Avec les scripts et les patchs WeiDU, c'est pareil.
DrAzTiK a écrit :Si j'ai bien compris la commande , elle me sera peut être utile par la suite mais en l'occurence, c'est vraiment pas bien dans ce cas là. Il y a impossibilité de connaitre les blocs exact du script de ces AREA pour chaque joueur. Certains vont avoir un installation original, d'autres vont installé tactics, d'autres SCSII (et le composant de ce mod est encore pire car les blocs doivent beaucoup moduler selon l'installation des autres composants de SCSII).
C'est pour ça que je dis que créer une zone de rencontre entre 2 zones ou le jeux original n'en prévoit pas et ou les composants de tactics et SCS II n'en prévoient pas non plus est beaucoup plus sur non ? (je parle en vu d'une futur hypothétique compatibilité entre mod)
C'est exactement le même problème : comment seras-tu sûr qu'un autre mod ne va pas chercher lui-aussi à modifier une liaison entre zones particulière (qu'il avait vu libre dans une configuration quelconque de mods) pour caser sa rencontre à lui, et comme par hasard la même que toi ?
Tant que tu ne fais pas cette modification sur une liaison vers ou depuis une zone toute nouvelle sur la carte, ajoutée par ton propre mod, tu ne peux pas être certain qu'il ne va pas y avoir un conflit avec un autre mod.
A contrario, avec un script tel que AR0041.BCS, tu pourras
toujours t'en sortir. A moins qu'un mod ne s'amuse à casser toute la séquence de quête des ménestrels, il est obligé de respecter le deuxième combat. Tu peux donc t'appuyer sur la valeur de la variable "RandomEncounters", à 2 après la rencontre.
Les patchs utilisant EXTEND_TOP et EXTEND_BOTTOM sont fiables à 100 %, c'est à dire que ton code sera systématiquement ajouté. Dans le cas de ce script, ajouter à la fin est une impasse : le dernier bloc actuel est toujours actif si aucun autre test ne réussit, donc tout code ajouté après ne sera jamais atteint.
Ajouter au début d'un script est une lourde responsabilité : en cas de défaut dans le ou les blocs ajoutés, tu peux foutre en l'air toute la suite du script ! Par conséquent, sauf dans des cas particuliers comme ce script, où ajouter à la fin n'est pas une option, il vaut mieux éviter d'utiliser EXTEND_TOP.
Ici, ton bloc ajouté au début pourrait être :
Code : Tout sélectionner
IF
OnCreation()
// Mettre 1 pour avant le combat où Renfeld est trouvé, 2 pour juste après, etc
Global("RandomEncounters","GLOBAL",1)
Global("MaVariableAMoi","GLOBAL",0)
GlobalLT("Chapter","GLOBAL",4)
THEN
RESPONSE #100
SetGlobal("MaVariableAMoi","GLOBAL",1)
// Surtout ne pas modifier "RandomEncounters" pour qu'elle reste à 1 ou 2 ou autre, selon ton choix
// Mes méchants à moi
CreateCreature("MONSTRE1",[222.664],8)
CreateCreature("MONSTRE2",[280.664],8)
...
END
Bref, je préserve la séquence existante en utilisant une variable personnelle pour tracer le fait que mon combat ait eu lieu. Et j'utilise la valeur particulière de la séquence existante pour choisir où exactement je veux que mon combat intervienne dans la séquence.
Si tu as des conditions supplémentaires ou en moins par rapport au test que tu reprends, autrement dit si tu ne reprends pas à l'identique un test existant en ajoutant juste ton ou tes tests de variable en plus, tu risques de devoir ajouter plusieurs blocs avec des conditions adaptées. C'est en particulier le cas si tu veux avoir des OU dans ta logique de déclenchement.
Suggestion : faire au plus simple pour éviter d'avoir quelque chose qui ne fonctionne pas dans des cas particuliers.
DrAzTiK a écrit :Pourquoi c'est la promenade de waukine qui est toujours inscrit a name ?
Parce que.
Désolé, mais il n'y a rien à expliquer : le format WMP prévoit qu'il y ait ici une référence au nom de la carte. Dans un jeu mono-carte comme BG ou BG II, il y a un nom d'une zone quelconque, selon ce qu'a décidé le concepteur. Je doute que ce nom apparaisse dans le jeu. C'est sûr que s'il avait pointé sur le texte qui dit "Carte du monde" et qui sert sur l'écran du même nom, ce serait plus simple à comprendre.
Dans Icewind Dale, qui a deux fichiers WM mono-carte, que le jeu peut alterner (le jeu et l'extension), chaque carte a pour cette position un nom pertinent, "Val de Bise" ou "Heart of Winter". Je ne sais même pas si ce nom apparaît quelque part dans le jeu.
Dans Icewind Dale II, qui a un fichier WMP comportant 3 cartes (3 Map Entries), chacune a son nom. J'ignore également si le jeu en fait quelque chose.
DrAzTiK a écrit :Et pour aller droit au but, c'est quoi un entry et c'est quoi un link ?
Une "Entry", c'est une zone qui apparaît sur la carte : c'est pour ça qu'elle pointe sur un xxx.ARE et qu'elle a au moins un flag qui dit si elle est visible ou pas dès le début.
Un "Link", c'est ce qui définit comme on peut se rendre d'une zone à un autre, et en combien de temps. Une liaison part toujours de la zone sélectionnée et permet d'aller à la zone dont l'indice dans la table est indiqué en tant que "Target area entry". Bref la valeur 2 pointe sur l'"Area entry 2", soit la troisième de la table (classique début à 0 de l'indice en informatique). La liaison permet aussi d'indiquer sur quel point de la zone on arrive (via un nom de "Entrance" parmi ceux définis dans le fichier ARE de destination).
DrAzTiK a écrit :Je lis : each exit from the area has an Area Link
Il y a combien d'exit par area ?
C'est toi qui décide (ou plutôt le concepteur de la carte l'a fait). Il y a des sorties possibles aux 4 points cardinaux. Mais cette possibilité était surtout utilisée dans BG pour le passage de zone de proche en proche, alors que dans BG II c'est plutôt une question de logique, sans impact réel. Il peut y avoir plusieurs destinations possibles depuis chaque point cardinal. Par exemple, les portes de la ville d'Athkatla mènent à tous les autres lieux du jeu, à peu de choses près.
Comme la carte du monde est géré comme un logiciel de guidage GPS gère le réseau de routes, il suffit qu'il y ait au moins un point central comme Paris (les portes de la ville) pour qu'on puisse se rendre de Nantes (Franc-Marché) à Gap (Umar), quitte à devoir se taper plusieurs correspondances (dans le jeu, cela revient à ajouter les temps de parcours des différents petits trajets).
DrAzTiK a écrit :Oui mais j'ai pas l'impression que ce site aide beaucoup les profanes... perso pour le moment j'ai du mal a en retirer quelque chose
C'est malheureusement vrai de tout document de référence : sans manuel d'utilisation, c'est inexploitable. A la différence que tu as des outils de visualisation des fichiers du jeu (d'ailleurs basés sur cette référence) pour commencer à se faire une idée de la façon dont c'est utilisé.
C'est exactement comme les "docs" de certains logiciels qui ne sont que la juxtaposition des écrans d'aide pour chaque écran du logiciel. Ou comme la description de la syntaxe des fichiers D et TP2 dans la doc WeiDU. On n'imagine pas pouvoir apprendre à en faire quelque chose, et pourtant on ne peut rien faire qui sorte de l'ordinaire (les tutoriels de la doc WeiDU, par exemple) sans se référer à ces parties référence du document.
C'est de tout même déjà mieux que se contenter du simple affichage de la carte par Near Infinity.
Bonne continuation.
