Archives des forums MMO/MMORPG > Neverwinter Nights > NWN - Maskado > Autre zone ?
Autre zone ?
Par Majca le 6/6/2002 à 10:03:53 (#1601369)
Est-il possible d'exécuter un évenement dans une zone Z1 suite à l'action d'un pj situé en zone Z2 ?
De même, est-il possible d'exécuter un évenement dans une zone Z1, déclenché par autre chose qu'un pj ? (par exemple, déclenché par le fait qu'une variable globale v = 1)
Par Jey le 6/6/2002 à 14:30:48 (#1602799)
En effet, si un script doit se déclencher à un endroit vide, je vois pas trop à quoi ça servirait, surtout si c carrêment ds une autre zone, car j'imagine que le jeu ne chargera en mémoire que la zone actuelle pr économiser les ressources et surtout la mémoire vive!
Cependant, je vois ce que tu veux dire dans le cas où il y aurait un joueur qui ferait une action ds une zone, et l'autre qui en subit les conséquences ds l'autre... Peut-être possible, mais pr les raisons précités, je ne sais pas vraiment... Et surtout ds le cas où ds la zone où est sensé se passer l'action, ben y a pas de joueur, l'événement se lance ds le vide?.. De toutes façons, ce genre de choses sont assez rares je pense... Par contre, ce qui ferait l'affaire serait l'utilisation d'une variable locale associée au joueur (Tutorial 10, étape 9, 10, 11, etc...). Ainsi le joueur effectue une action ds la zone Z1, celle-ci déclenche un script qui crée la variable locale assignée au pj. Plus tard, celui-ci se rend en zone Z2, là un trigger déclenche un script qui ne va jusqu'au bout après test que si le pj qui l'a déclenché possède la variable en question, et cela crée alors l'évènement en zone Z2. Disons que ce système n'est pas instantané et implique d'attendre que le joueur pénètre ds la zone, mais c surtout pour une question d'efficacité que je trouve cela préférable parce que je doute qu'un évènement qui se déclenche ds une zone où il n'y a personne, et dc même pas chargée en plus sûrement, soit des plus utiles! :D Autant attendre qu'il arrive au niveau de l'évènement afin qu'il en voit l'effet, double avantage: c plus intéressant pr le joueur de voir l'effet de ses actions, et en plus, on économise les ressources... :D
Edit: Sinon en y réfléchissant, certains évènement peuvent effectivement se déclencher sans intervention de pj. Par exemple, si tu crées un script assigné à un quelconque objet ds le cas "OnHeartBeat", le script se déclenchera alors toutes les 6 secondes. Mais il ne faut pas oublier (et ça rejoint ce que je disais encore) que c alors un évènement très gourmand comme il lancera en boucle le script alors même que les joueurs st absents (enfin, comme je le disais, ils seront ds la zone je pense qd même, puisque je doute qu'une zone soit chargée s'il n'y a aucun joueur. Mais ils ne seront pas forcément à proximité pr voir l'effet du script).
Par Caepolla le 6/6/2002 à 14:36:47 (#1602841)
:merci:
Par Majca le 6/6/2002 à 15:48:09 (#1603219)
L'intérêt que j'y vois est le suivant:
Banzaiii!, un groupe d'aventuriers (les pj) viennent de libérer une jeune fille prise en otage par le méchant orc d'à côté. Manque de bol, ce méchant orc était le fils du chef d'une tribu située quelques zones plus loin. VENGEANCE ! Le chef envoie une partie de ses guerriers faire la fête dans le village de la dite demoiselle.
Cependant, un groupe de guerriers orcs, c'est méchant.
=> ils rasent tout sur leur passage (en bref, les zones entre le village et la tribu).
Bref, ce que je veux, c'est que si les orcs font des rencontres pendant leur "voyage", ils devront se défendre/attaquer (vu qu'ils sont méchants) au même titre que les pjs auraient dû le faire.
=> des brigants, un paysan vennant vendre ses légûmes au village, etc, etc... tout y passe!
Je ne tiens surtout pas à ce que, paff!, un groupe d'orcs apparaisse en bordure de zone alors que dans la zone d'à côté, d'où ils auraient logiquement dû venir, tout le monde est en bonne santé.
Si des pj se trouvent dans les zones "intermédiaires", ils voient les orcs passer en courant, hurlant de rage et qui sait, peut-être vont-ils se battre, etc...
S'il n'y a pas de pj dans les dites zones, tout dépend de comment le jeu gère les zones où aucun pj ne se trouve.
Si elles "existent" et sont gérée au même titre que les autres, et à partir du moment où, comme je le pense, les pnj/créatures se battent entre eux suivant leur faction, mon idée est facilement réalisable.
Si par contre elles "n'existent pas", je ne vois pas trop comment faire étant donné qu'on ne peut modifier une zone qui n'existe pas...
La seule solution serait alors de charger la zone comme elle à été créée dans l'éditeur lorsqu'un pj y pénètre, puis, une fois chargée, PAF!, tout le monde est mort :D
Seul hic, ça n'a absoluement rien à voir avec le but initial étant donné qu'en agissant de la cette manière (charger la zone puis appliquer les modifs), se ne serait pas dynamique. C'est-à-dire que suivant ce qui a été programmé, tel ou tel pnj a survécu, tels autres sont morts, etc... alors qu'avec la première méthode, suivant les jets de dés au combat, leur "chance", leurs compétences, etc... certains orcs seront morts, certains pj auront survécu, etc...
=> Je suis complètement à côté de mes pompes :rasta: ou vous voyez où je veux en venir :eureka: ?? :)
Par Jey le 6/6/2002 à 19:53:57 (#1604664)
vous voyez où je veux en venir ??
Euh... franchement? J'ai un peu de mal... :rolleyes:
Enfin, si je comprends un peu, mais justement, je ne vois tjrs pas l'intérêt de la chose, à savoir créer des évènements que personne ne peut voir!
Reprenons ton exemple! Tu délivres la fille. Penses-tu vraiment qu'immédiatement, le clan orque part à l'attaque? D'abord, comment seraient-ils au courant? Tu le dis toi-même, ils st qques zones plus loin! Alors soit l'orc kidnappeur a pu s'enfuir, ms il lui faut le tps de rejoindre ses potes, soit comme je le pense, ça a conduit à sa mort, et là il faut encore plus de tps pr que le clan soit au courant (ils envoient un éclaireur au bout de qque jour comme le gars revient pas, etc...). Puis une fois au courant, même des barbares ne partent pas en guerre comme ça sur un coup de tête! Je ne dis pas qu'ils vt tenir un gros conseil de guerre, mais ils vont rassembler les guerriers, peut-être même aller quérir des orcs de tribus voisines, se préparer, prendre les armes, faire éventuellement des rituels nécessaires avt le cbt (ce st des tribus primitives, ne l'oublions pas), et pquoi pas, s'ils prévoient de camper là bas, prépareront-ils aussi les affaires, le campement, etc... pr déménager! Donc je trouverais ça absurde qu'au moment même où tu délivres la fille et tues peut-être le fils orc, ben la tribu soudainement part en guerre! Au contraire, ça prend du tps!
En outre, il est évident que l'intérêt est bon aussi pr le joueur s'il participe au combat, alors s'il se passe sans lui... ce serait un peu idiot (surtout que tu sembles vouloir un combat qui se passe seul, et un combat, ça prend des ressources. Alors faire ramer tt le module pr un combat où seuls des pnjs participent, et où les pj ne st même pas des témoins- ce n'est dc même pas pr la beauté de la bataille- ben c pas très intéressant, je trouve).
Maintenant, mes idées à moi. Au moment où tu tues l'orc, ça crée une variable locale sur le joueur. Et ainsi, au moment où il rentre ds la zone, le script repère s'il a ou non la variable. Si non, c que ça ne se sera pas passé, le village est normal. Si oui, le joueur verrait au moment où il arriverait de l'autre côté de la carte (ainsi ça enlève de l'absurdité dt tu parles au cas où ils viendraient du même endroit que le joueur) la tribu entière orc. Il pourrait alors participer au combat, qui se fait en live devant lui.
Si au contraire, tu préfères que le joueur arrive trop tard, qu'il se sente éventuellement responsable même et veuille laver l'affront (de ttes façons, avec juste qques paysans pr l'aider, un groupe seul contre une tribu orc aurait eu peu de chances). Ds ce cas, un script très simple à faire pourrait être qu'au changement de zone, cela repère la variable, et si elle n'est pas là, la carte se charge normalement, sinon, une autre carte se charge, qui serait la même mais version ravagée. En fait tu devrais faire 2 cartes identiques, l'une avec le village en état, les oiseaux qui chantent, l'herbe verte et les papillons, l'autre avec les maisons brûlées, l'herbe jaunie par le feu de la bataille et piétinée par les orcs, des cadavres carbonisés d'humains et d'animaux, et un campement orc installé à côté du village carbonisé après le combat. En fait, une version "avant bataille", et une "après bataille". Cela peut amener des suptibilités d'arriver trop tard, car les orcs croient avoir gagné et ne s'attendent pas à votre arrivée. C plus subtil, le but sera d'investir en cachette le village, etc... Enfin, c pr dire que ce système de variable local est très pratique selon ce à quoi tu veux arriver.
En plus l'avantage de tt ça est que justement tt se passe exactement comme tu veux! Car si tu veux créer un combat aléatoire, bah des pnj majeur de ton module pourraient périr, et ça pose encore bcp de problèmes! Outre un ralentissement inutile alors qu'il est bien plus beau de créer une zone à part spécial design "après combat" où tt est fait d'avance!
Enfin, je pense à une dernière possibilité! Tu peux mélanger un peu pr ts les goûts! Puisqu'on parle d'inclure la notion de temps, j'ai vu qu'il y a certaines fonctions en rapport avec le temps. Alors il doit être possible d'inclure une vraiable locale incluant le temps de jeu. Le script au changement pourrait alors être un peu plus complexe (mais pas trop dur à réaliser tt de même je pense) puisqu'il proposerait non plus 2 mais 3 choix! Pr cela, il faudrait que la mort de l'orc, qui est ce qui déclenche tt, crée non plus une mais 2 variables locale au pj. La première serait donc juste là pr dire si oui on non on l'a tué! Un premier test emmènerait le pj ds la version "village tranquille" si la variable est absente. Si elle est présente, un autre test se ferait avec la seconde variable. Cette variable devrait contenir le temps de jeu (qui doit pvr, je pense et le répète, être accessible par une fonction aisément) et selon ton estimation, le script emmènera ds le village au moment où les orcs attaquent pr pvr défendre les villageois si le pj arrive à temps; ou il emmène ds le village version "destroy" s'il a mis trop de tps pr arriver!!! Voilà! Que de nuances!
Par Majca le 6/6/2002 à 20:20:08 (#1604809)
Le fait est que je ne savais pas que la zone de destination pouvait dépendre d'une variable. Si c'est le cas, effectivement, ma question n'a plus aucun sens. La méthode que tu proposes est alors biensûr celle à utiliser.
Par Jey le 6/6/2002 à 20:39:44 (#1604883)
A ce propos, Caepolla, tu dis que les variables ne sont pas conservées d'un module à l'autre. A la limite, ce n'est pas étonnant, car si elles st locales, c déjà certes parce qu'elles ne concernent qu'un objet, mais aussi que cet objet est dans un module unique, qui est en qque sorte le programme général. Mais supposons un pj qui stocke qques variables de ce genre suite à certaines aventures. Puis entretemps, il passe sur un autre module pr ensuite revenir sur le module actuel. Les variables lui st elles réaffectées à son retour ou définitivement perdues?
Par Caepolla le 6/6/2002 à 22:15:03 (#1605276)
:aide:
Par Myvain le 7/6/2002 à 13:54:58 (#1608371)
Cet objet accompagnant le joueur lors de son changement de module, la variable devrait théoriquement rester enregistrée et attachée à cet objet jusqu'à la prochaine modification. Non?
Par Caepolla le 7/6/2002 à 17:14:02 (#1609589)
Par Jey le 7/6/2002 à 20:53:30 (#1610861)
Pr en revenir au sujet principal, je pense qu'effectivement, si on attache un script à un objet au lieu d'une simple variable locale qui risque elle de disparaître, mais faisant exactement la même chose que la variable, à savoir le script n'exécute aucune action mais ne fait que donner une information dans certaines circonstances (permettant par ex ds notre exemple à "prouver" qu'on a fait une certaine quête afin d'avoir accès à une autre). Dans ce cas, comme l'appel au script ne disparaît pas en changeant de module, ben ça pourrait faire l'affaire (même si l'absence du script ds un autre module fait qu'il ne sert à rien ailleurs).
Surtout que j'ai réfléchi à qqch que tu as dit Caepolla, qd tu dis que le lieu où le personnage a quitté le module était gardé en mémoire. Ben justement ça m'a rappelé une news où il me semble, il était dit que si on faisait jouer son perso sur un autre module entretemps alors qu'on est sur une quête ailleurs, qd on revient, on réatterit au début du module au lieu de revenir là d'où on est parti!!! (ce qui n'est pas trop grave en cas d'aventure avec DM certes puisqu'il peut ns replacer "à la main", mais implique qu'on ne peut faire 2 aventures sans DM au risque de devoir recommencer la première à zéro!!!)
Et dc à mon avis, le lieu d'où on est parti doit être gardé en mémoire aussi ds une sorte de variable qui est sans doute réinitialisée dès chaque rentrée ds un module... Et peut-être dc que ttes les variables locales aussi alors!
Par Myvain le 7/6/2002 à 20:53:47 (#1610863)
Sinon, j'ai pensé qu'il serait peut-être possible d'utiliser le journal des quêtes mais après recherche sur le forum officiel, il semblerait que celui-ci reste sauvegardé sur le module où il a été créé.
Par Myvain le 7/6/2002 à 21:16:51 (#1611042)
Provient du message de Jey
Effectivement, concrètement le script lui n'est pas attaché à l'objet, mais au module. Par contre, l'appel au script lui est bel et bien attaché à l'objet!
Je ne crois pas, un script peut faire référence au "Tag" d'un objet et en fonction de ça accomplir une action, un test...etc (le script est alors sur le module et ne peut pas en sortir comme l'indique Caepolla). Par contre un objet ne peut pas appeler un script de lui-même. Essaye avec Aurora, tu verras que rien n'est prévu pour que l'objet fasse référence à un script de lui même. A moins qu'on se soit mal compris ce qui est tout à fait possible ;)
Par Majca le 7/6/2002 à 21:20:07 (#1611064)
Provient du message de Myvain
Merci pour la réponse :)
Sinon, j'ai pensé qu'il serait peut-être possible d'utiliser le journal des quêtes mais après recherche sur le forum officiel, il semblerait que celui-ci reste sauvegardé sur le module où il a été créé.
eh bien, c'est pas plus mal non ?
Ca permettrait déviter le cas extrême où un gros joueur (gros = qui joue beaucoup hein...;)) se retrouve avec 50 objets invisibles dans son inventaire...
Je me dis qu'il ne serait pas plus mal que le serveur stocke des informations relatives aux joueurs afin de les "reconnaître" et de savoir où est ce qu'ils en étaient lors de leur départ du module.Provient du message de Myvain
Je ne crois pas, un script peut faire référence au "Tag" d'un objet et en fonction de ça accomplir une action, un test...etc (le script est alors sur le module et ne peut pas en sortir comme l'indique Caepolla). Par contre un objet ne peut pas appeler un script de lui-même. Essaye avec Aurora, tu verras que rien n'est prévu pour que l'objet fasse référence à un script de lui même. A moins qu'on se soit mal compris ce qui est tout à fait possible ;)
Bien vu ;)
Par Myvain le 7/6/2002 à 21:29:03 (#1611134)
Provient du message de Majca
Je me dis qu'il ne serait pas plus mal que le serveur stocke des informations relatives aux joueurs afin de les "reconnaître" et de savoir où est ce qu'ils en étaient lors de leur départ du module.
Le problème qui se pose ensuite est le suivant:
1) le PJ est enregistré sur le module avant de le quitter
2) il va faire un tour ailleurs en empruntant un portail
3)quand il revient, son vécu est différent (materiel, XP...)
Le module pourra-t-il prendre en compte ces changements étant donné que le personnage est différent. En effet les variables locales qui sont enregistrées sur le module pour ce perso ne correspondront peut-être plus... :aide:
raaaaaah vivement qu'on puisse tester tout ce qu'on a en tête!
Par Majca le 7/6/2002 à 21:56:03 (#1611322)
Ce serait équivalent à : "le personnage est parti dans une autre contrée et le voilà revenu au bout de x mois."
=> ??
Par Myvain le 7/6/2002 à 23:26:36 (#1611869)
Je ne sais pas comment seront gérés les transferts de perso de module à module, si quelqu'un a plus d'infos là-dessus: je prend
JOL Archives 1.0.1
@ JOL / JeuxOnLine