La Couronne de Cuivre

j'essaie de créer un DEFINE_PATCH_FUNCTION pour simplifier une instruction répétée 120 fois :
Pour l'appeler comme ça : LPF PX_INTERPLAN_SORTS INT_VAR parchemin = pxf2ex2a END



Sauf que weidu bloque systématiquement sur le DEFINE_PATCH_FUNCTION :

[DERATS_MAGASIN_2/SETUP-DERATS_MAGASIN_2.TP2] PARSE ERROR at line 1941 column 8-20
Near Text: COPY_EXISTING
GLR parse error

Pourquoi ? Une fonction ne peut pas être une COPY ?

COPY est une instruction de type ACTION, et tu tentes de la lancer dans un contexte de PATCH.

Je connais 2 solutions :

Englober ton COPY_EXISTING dans une instruction INNER_ACTION
Créer une méthode DIMORPHIC

OK, avec ça se compile.

Mais l'instruction Refuse de fonctionner, bloque sur "ERROR: cannot convert pxf2ex2a or %pxf2ex2a% to an integer"

j'ai essayé en ajoutant/enlevant des % et des ~ mais je n'y arrive pas. Comment ai-je pu programmer des mods en étant autant bidon avec Weidu, ça me dépasse....

C'est normal, dans la définition de la fonction tu utilises STR_VAR tandis qu'à l'appel tu utilises INT_VAR, remplace le par STR_VAR et ça devrait aller.

Ok, ça marche. Je te remercie. Que ferais sans toi ? (et sans JohnBob, FreddyGwendo, Zranoff et d'autres.... je suis dépendant des autres )

Heu non, en fait ça s'installe mais c'est complètement foiré. Tous les entrées dans le magasin ont comme nom d'objet PARCHEMI et le paramètre "timer" calé à 78 (ça doit être le patchage pour le N manquant^^). Où est-ce que ça foire ?
Testé, ça ne marche pas mieux en remplaçant
LPF PX_INTERPLAN_SORTS INT_VAR parchemin = pxf2ex2a END
par
LPF PX_INTERPLAN_SORTS INT_VAR parchemin = %pxf2ex2a% END

Bon, oubliez ça, j'ai fais autrement (comme d'habitude). Sujet clot. merci encore Selphira.

De retour. Je ne comprend pas. Mon fichier "final" (pxl2rpt0.2da) incluant 9 autres fichiers est fini, ça ça marche. Mais pourquoi avec 10 instructions "COPY" il n'y a que deux fichiers qui sont copiés ?

En l'occcurance les deux fichiers copiés sont le pxl2rpt0.2da, le fichier final construit à partir des 9 autres (et ça ça marche, merci encore Selhira) et celui du dernier bloc, le pxl2rpt9.2da. Où sont passé les 8 premiers fichiers ?

Voilà le code final : Rien de plus simple, c'est le même bloc répété 9 fois avec chaque fois un fichier différent. Alors WTF ?

-----------------------------------------------

Et autre truc bizarre : si j'inverse les blocs pour qu'ils commencent par les sorts de niveau 9 pour finir par les sorts de niveau 1 ça ne s'installe plus.....

ERROR: [Derats_Magasin_2/Sorts/Special/pxl2rpt9.2da] -> [override/pxl2rpt9.2da] Patching Failed (COPY) (Failure("ERROR: READ_2DA_ENTRY_FORMER failed on variable %rows_43_2%"))

Ça refuse de s'installer dans l’ordre décroissant mais ça s'installe dans l'ordre croissant. WTFFFFFF ?

on, comme je sens que ça va être nécessaire voilà les 9 fichiers :

Si tu veux que les fichiers .2da originaux soient aussi copié, et pas seulement utilisé pour construire le fichier pxl2rpt0.2da, il faut enlever les instructions BUT_ONLY, qui signifient "copie le fichier, uniquement si des modifications ont été apportées à son contenu". Comme dans ce cas tu ne fais que lire, aucune modification n'est faite, la copie n'est pas réalisée.

Pour pxl2rpt9.2da, BUT_ONLY n'est pas présent, il l'a donc copié

OK, merci. J’apprends petit à petit sur weidu, mais pfff, la galère. Et pour l'ordre décroissant, tu as une explication logique ?

Dans ton fichier pxl2rpt9.2da, il y a une ligne qui n'a que 2 colonnes Comme tu lis ce fichier avec l'instruction suivante, Weidu décide qu'une ligne est valide si elle a au moins 2 colonnes Sauf que plus loin, tu tentes de lire 3 colonnes ! Pour corriger ce problème, déjà indiquer qu'une ligne n'est valide que si elle possède au moins 3 colonnes L'erreur n'apparaitra plus, mais ta ligne ne sera pas ajoutée, il faut donc aussi corriger la ligne de ton fichier pxl2rpt9.2da afin de lui ajouter la 3ème colonnes

Je te remercie, encore une fois tu me sauve. j'ai donc maintenant un sort qui peut potentiellement donner le choix entre 658 sorts (et encore, il faut que j'indexe B_spells)

Mais pourquoi ça ne buguait pas quand je demandait l'ordre de 1 à 9 ? Pourtant la ligne à deux colonne n'est pas à la toute fin du fichier, elle est au milieu. Ça aurait du rendre une erreur, non ?

C'est du à la façon dont Weidu stocke les tableaux, j'ai eu pas mal de prises de tête avec eux lors du développement d'AutoDescription.

En fait, l'un de tes fichiers .2da lus précédemment avait l'entrée %rows_43_2%" valide, Weidu a gardé cette information et ne l'a pas supprimée lors de la lecture des fichiers suivants.
Tu aurais pu avoir l'erreur si avant l'instruction READ_2DA_ENTRIES_NOW ~rows~ 2 , tu aurais vidé le tableau avec CLEAR_ARRAY rows

DavidW l'explique plus en détail ici : https://gibberlings3.github.io/Document ... rse_2.html (recherche "Because of how WEIDU stores arrays")

Ok, merci. Weidu ça reste vraiment du charabia pour moi. Je me demande comment vous avez tous cette capacité de comprendre comment manipuler si intensément cet outil exotique. (Freddy Gwendo c'est pointé un jour et s'est mis à pondre des codes monstrueux qui ont aidé toute la communauté. Zranoff, bien avant ça, c'est pointé un jour sur le forum Légende et a distribué à la demande des scripts weidus complexes quelques jours plus tard...)
Peut être que quelques notions de programmation en c où je ne sais quel autres truc aiderait. Je suis trop "ancien" pour ça, moi j'ai appris pendant mes années lycée le Visual basic