6 réponses à ce sujet

[Havelock]

Salut

J'ai quasiment fini mon mod (les sorts constants), et je m'interroge sur le meilleur moyen rendre accessible au joueur certains sorts dans le jeu.

Pour l'essentiel de mes sorts, tout se passe via les dialogues, avec la fonction choice. J'utilise plusieurs conditions : l'id du vendeur de sort et certaines des limitations qui vont avec (même faction... ou pas^^), la quantité d'or détenue par le joueur, et un petit getspell dans la partie result, histoire que le joueur distrait qui possède déjà un sort mais tente de l'acheter à nouveau ne soit pas débité une 2ème fois.

Mais j'ai certains sorts un poil plus élaborés, composés de sorts "simples", pour avoir des armures liées, composées de toutes les pièces d'armure liée et des différentes armes liées (un sort par arme différente). Et il faudrait, pour que le joueur puisse acheter ces sorts, qu'il ait déjà les sorts "simples" les composant, par exemple le sort de casque lié, de cuirasse liée, de gants liés, de bottes liées, et d'arc lié, pour avoir une armure liée complète accompagnée de l'arc.

Et je me questionne sur la meilleure manière d'introduire ces sorts et de vérifier que le joueur connaisse bien les sorts pré-requis. Je sais bien qu'il me faut requérir à des getspell en série, mais à quel niveau ? J'ai fait un essai dans les result des dialogues, sans succès.

Ce que je veux faire est-il possible uniquement via les dialogues, ou pas. Si ça ne l'est pas, j'ai un petit script local qui tourne dès que le joueur utilise mes sorts (basé sur du OnPCEquip), je me dis que je pourrais sans doute y caser ma série de getspell, et faire un addtopic avec le sujet permettant d'acheter ces fameux sorts (à priori pas très lourd ni compliqué) mais... ça me parait moins élégant qu'en passant par les dialogues, moins direct.

Donc : pourrais-je le faire avec les dialogues seulement ? Si non, mon  idée avec le script local vous semble-t-elle correcte ? Et, sait-on jamais, existe-t-il un moyen auquel je n'ai même pas pensé ?

Merci d'avance pour toute suggestion

[Post-it]

Bonjour Havelock, je vais peut-être dire une bêtise ... mais ne peux-tu pas pour ta série de Getspell mettre un Startscript dans le result ...

[elendell]

Hello !

 Havelock, le 17.05.2009 à 23:50, dit :

J'ai fait un essai dans les result des dialogues, sans succès.

Il faudrait savoir ce que tu as écrit exactement dans ton "result" car c'est théoriquement possible (mais je n'ai jamais eu l'occasion d'essayer).

Sinon, tu peux aussi "scripter" les choix d'un dialogue, en cours de dialogue. Regarde <ICI>.

Que les "GetSpell" soient dans la fenêtre "result" ou dans un script démarré comme le dit Post-it, tu donneras un choix (et le dialogue lié au choix) différent suivant si le PJ connait ou non les sorts requis.

[Havelock]

 Post-it, le 18.05.2009 à 00:40, dit :

Bonjour Havelock, je vais peut-être dire une bêtise ... mais ne peux-tu pas pour ta série de Getspell mettre un Startscript dans le result ...

Pas bête ça, je n'avais pas pensé à ce genre de possibilités. On en apprend tous les jours^^

 elendell, le 18.05.2009 à 00:53, dit :

Il faudrait savoir ce que tu as écrit exactement dans ton "result" car c'est théoriquement possible (mais je n'ai jamais eu l'occasion d'essayer).

Sinon, tu peux aussi "scripter" les choix d'un dialogue, en cours de dialogue. Regarde <ICI>.

Que les "GetSpell" soient dans la fenêtre "result" ou dans un script démarré comme le dit Post-it, tu donneras un choix (et le dialogue lié au choix) différent suivant si le PJ connait ou non les sorts requis.

J'avais loupé ce sujet... pourtant bien épinglé
Mais dans le fond ce n'est pas bien grave, puisque c'est déjà plus ou moins ce que je faisais (sans doute un vieux souvenir de msfd^^).

J'avais fait des essais "simples" pour tester ces fonctions jusqu'ici, et après avoir refait ces tests en partant de zéro, je me rends compte que le problème venait de l'emploi malencontreux de else qui semble mal passer. J'espérais naïvement qu'un else me permettrait d'afficher un autre choice quand les conditions ne sont pas toutes remplies (où le vendeur nous explique que "oulah, mais vous connaissez pas tous les sorts requis mon pauvre nérévarine"), mais apparemment faut pas trop y compter. En virant le else, ça marche.

En gros la forme serait:

If ( Player->Getspell sort1 == 1 )
If ( Player->Getspell sort2 == 1 )
If ( Player->Getspell sort3 == 1 )
If ( Player->Getspell sort4 == 1 )
If ( Player->Getspell sort5 == 1 )
choice "armure1" 1
Endif
Endif
Endif
Endif
Endif

Mais il y a peut-être un petit soucis si j'opère comme ça : il y a en tout 11 armures liées différentes à choisir (8 sont des variantes avec/sans bouclier, 3 sont celles sans bouclier (avec l'arc par exemple), donc 7 types d'armures), et 11 sorts simples (5 pièces d'armure dont le bouclier, et 6 armes) à tester en tout. Et avoir tout le panel possible des choice donne un grand nombre de variantes pour pas grand chose, avec des enchainements de getspell trop longs... Il me faut donc ruser ! Au début j'avais bien songé à l'utilisation d'une variable en short, permettant de tester une 1ère fois les 4-5 pièces d'armure, et de ne plus avoir à tester par la suite qu'à tester les armes. Mais ça me laisserait encore 6 variables, donc un nombre de possibilités encore très grand...

Du coup, je crois qu'il va me falloir opter pour une solution alternative : je crée un sujet par type d'armure, et je n'ai plus qu'à faire 1 ou 2 tests avec 5 ou 6 getspells en série dans chaque sujet, et ça devient gérable.

Bon, je me rends compte qu'en m'acharnant un peu plus, j'aurais pu arriver à la même conclusion sans ennuyer personne, mais c'est marrant comme le fait d'expliquer son problème à quelqu'un permet de mieux le comprendre et de mettre le doigt sur ce qui bloque. Je ferais un test dans la journée pour voir si ça fonctionne.

En tout cas merci pour vos réponses

[elendell]

Salut !

J'ai quand même une petite interrogation pour ce que tu envisages. "GetSpell" teste si le PJ possède un sort précis mais si un autre module permet au PJ d'avoir un sort différent qui contient le même effet, tu ne pourras pas le savoir. Suivant le type de sort cela n'est sans doute pas courant mais il y a également un autre cas peut courant mais qui existe, puisque je jouais comme ça : Pour avoir mes sorts bien ordonnés dans l'inventaire et mixés comme je le souhaitais, je créais de nouveaux sorts à partir de ceux que je possédais et supprimais les originaux de ma liste. Dans mon cas, tes "GetSpell" diraient que je ne connaitrais pas ces sorts alors que je les aurais bien mais sous un autre nom. (A moins que les supprimer de la liste de sorts ne les supprime pas vraiment ; je n'ai pas vérifié).

Bref, je me dis qu'il y aurait deux autres possibilités pour savoir si le PJ maitrise des sorts et que le vendeur accepte de lui vendre un autre sort qui les combine.

- Un script global lancé en début de partie qui teste toutes les x secondes les effets de sorts et non pas les "IDs" de sorts. A Chaque fois qu'un effet de sort est positif, il incrémente une variable correspondante. (Soit une variable par effet, soit une variable par sort composé).
Par exemple : Si le PJ est affecté par un sort de bottes liées, une variable locale du script est mise à 1 et l'effet ne sera plus testé. La variable globale du sort de l'armure liée composée est incrémentée de +1. Dans le dialogue du vendeur, il suffirait donc de vérifier l'état de la globale en condition. Quand le PJ a lancé une fois chaque sort requis, on stoppe le script global.

- Un script local sur le vendeur ou dans la cellule (ou ciblé car lancé avec "StartScript" dans un "result" du vendeur). Dans ce cas, pas besoin de script global. Pour que le vendeur accepte de vendre le sort, le PJ doit lui prouver qu'il est capable de lancer les effets séparément. A chaque fois que le PJ a sur lui un des effets, sa variable dans le script est incrémentée.

Ces deux options permettent de savoir si le PJ est capable de bénéficier des effets des sorts (quelque soit l'ID du sort) mais aussi s'assure qu'il a les capacités requises pour le lancer. Car le PJ peut très bien avoir acheté les sorts requis sans avoir pour autant les capacités de le lancer. Là, le vendeur s'assure aussi qu'il en a les capacité avant de lui vendre un sort qui les combine.

[Havelock]

Salut elendell

Dans mon cas ce problème est un peu particulier.
Pour les sorts constants classiques (un sort de casque lié par exemple), le joueur peut les acheter auprès des vendeurs de sorts habituels. Si un PNJ vend dans le jeu de base un sort de casque lié, il vendra également (mais par dialogues avec un prix fixe) un sort constant de casque lié. J'ai fait ce choix pour éviter au joueur de devoir d'abord acheter un sort avant de pouvoir acheter le sort constant correspondant. A priori pas d'interactions avec d'autres mods.
Par contre, avoir des sorts sans durée prédéterminée a une contrepartie : les sorts constants sont tous "prédéterminés". Ils ont chacun leur ID, et le joueur ne peut pas en créer.
Et donc mon idée était que pour pouvoir acheter un sort constant complexe, le joueur devait d'abord connaitre les sorts constants correspondant (et pas les sorts classiques). D'où la détection d'ID et non pas d'effet. Encore que c'est discutable, et la détection d'effet ferait tout aussi bien l'affaire, d'autant plus qu'elle serait moins contraignante pour le joueur.

Surtout, il y a un cas que je n'avais pas envisagé auquel tu me fais penser : si un joueur arrive à s'acheter une armure liée complète, sans armes (casque, cuirasse, gant, bottes), il est normal qu'il supprime les sorts individuels (c'est ce que moi je ferais^^).
Mais s'il se décide ensuite à prendre une "Armure de l'Archer" (casque, cuirasse, gant, botte, arc), pour qu'il ne soit pas bloqué (ce qui serait illogique), il faudrait que je teste, en plus des pièces d'armure liée, toutes les armures complètes, et je me retrouve donc avec 10 tests de plus à faire. Et là la détection d'effet prend un intérêt encore plus important.

J'aurais plutôt tendance à opter pour ta 2ème solution, attachée au PNJ vendeur.
Si j'utilise un script local sur le vendeur, ça signifie que je modifie le PNJ ; ça ne risquerait pas de causer d'éventuelles incompatibilités avec d'autres mods modifiant également ce PNJ, sachant que j'utilise un PNJ déjà existant ? Jusqu'ici je me suis efforcé de ne rien modifier du jeu, j'ai juste ajouté un objet dans une cellule et des dialogues.
Si j'utilise un starscript dans le result du vendeur, comment ça se passe concrètement ? Il faut que le joueur parle d'abord du bon sujet au PNJ pour lancer le script, que le joueur lance les sorts requis testé par le script, puis reparle au PNJ avec le même sujet ? Et ça nécessite également des variables globales ?
Donc ça nous ferait : une des variables globales = 0, via les choice le vendeur nous informe qu'il nous faut invoquer toutes les pièces de l'armure devant lui, pour vérifier qu'on est bien capable de lancer le sort. A chaque sort lancé, les variables globales correspondantes sont ajustées.
Lorsque toutes les variables globales requises = 1, le vendeur accepte de nous vendre le sort.
C'est bien ça ? Et ça ne ferait pas trop abuser des variables globales (je ne sais pas si c'est embêtant ou pas) ?

[elendell]

Salut !

C'est difficile de dire ce qui conviendrait le mieux dans ton cas sans avoir le "mod" en main d'une part mais surtout parce qu'il y a plein de possibilités pour gérer tout ça.

Dans la mesure où les sorts demandés pour l'achat d'un sort composé sont des sorts uniques, il n'est effectivement pas nécessaire de tester l'effet. Mais cela peut être un choix de "RolePlay". Soit parce qu'on veut que le PJ maitrise un sort avant de passer à un plus complexe (il doit donc avoir déjà utilisé chaque sort simple qui entrent dans la composition du complexe au moins x fois en cours de partie), soit parce que cela affine le dialogue entre vendeur et PJ ("Je ne vends pas ce sort à un débutant" "Mais monsieur, je maitrise parfaitement ces sorts" "Ah oui ? Prouvez-le moi !").

Ensuite, il y a des éléments que je ne connais pas. Par exemple : Celui qui vend une armure invoquée composée est-il le seul qui vend les sorts individuels qui entrent dans cette composition ?

Techniquement, le plus simple est sans doute d'avoir une variable globale pour chaque sort individuel. Mais tout peut également être stocké au fur et à mesure dans un script global. De plus, dans un dialogue, il n'est possible que de tester 6 conditions de globales à la fois et au moins une risque d'être utilisée par la vérification du "choice".

Je crains qu'il ne te faille faire différents essais pour trouver la solution qui te convient le mieux, en tenant compte de différents éléments :

- j'avais lu dans un autre sujet que toutes les variables étaient toujours chargées, qu'elles soient globales, locales dans un global ou même dans un local qui ne ne tourne pas car dans une autre cellule que le PC. (Mais je ne retrouve pas le sujet en question).

- Une info peut être stockée dans une variable locale d'un script global et on peut la récupérer, même si ce script global n'est pas actif mais il n'est pas possible de tester directement une de ses locales en condition de dialogue.

- Un script global unique peut être utilisé en script ciblé par plusieurs PNJs. Mais, si le fait qu'il soit ciblé permet que les actions concernent celui qui le lance, il n'est pas possible non plus de tester directement une de ses locales en condition de dialogue. Et il ne faut pas oublier de le stopper après chaque utilisation (Sinon, il conserve sa première cible).

- On peut aussi avec Tribunal utiliser "SetJournalIndex" (en plaçant un journal à un index qui n'existe pas). Cet index est testable en condition de dialogue. Mais cela ne doit être fait que de façon temporaire car quand on recharge la partie, le journal se place à l'index le plus haut qui existe vraiment.

- Il faut éviter autant que possible d'attacher un script directement à un PNJ du jeu pour les compatibilités.

- Relis les pages 25 et 26, 141 et 91 du MSfD


Désolé, je ne vois pas quoi te dire d'autre pour l'instant (A part : "amuse-toi bien !"   )