Les doubles sont betes à mourrir....

Répondre
Partager Rechercher
je crée un double d'un pj avec la commande Copy_Object , je le met en faction hostile.
le double est pour l'instant hors du vision du pj, il a été crée dans une autre piece...

bon le pj rejoins son double , et..
1) le double ne se defend pas
2) si le double est un jeteur de sorts , il n'utilisera pas de sorts
3) au bout de plusieurs coup dans la gueule , et si on tourne un peut autour de lui , il pensera a se defendre avec l'arme qu'il a dans la main , mais ne jettera pas de sorts si c'est un lanceur de sort...

Y'a pas moyen de lui activer l'ia ??
le pb, c'est que y a pas d'event utilisable sur les copy
donc je suis presque étonné qu'il se defendent . . .
quoique...
bon sinon, tu peu essayer de voirce qu'a fait RAT sur ses doppelganger, où il utilise un copyobject, et où il controle le double grace au onpercecption du doppel, mais bon . . .
peut être il y aurait moyen de faire un semblant d'ia avec une area of effect, on peut détecter quand un objet entre, sort, et aussi faire un OnHeartBeat assigné a l'effet, qui disparait donc lorsque le clone sera détruit

Ca nous fait déjà le OnPerceptio, le OnHeartBeat, puis d'autres en bricolant un peu. On peut aussi faire des trucs avec le OnHit qui a été bricolé.

Chui sur qu'on peut en faire quelque chose de ces copy ^^
zavais pensé au area of effect (si si, ca fait 2 semaine que je suis plongé ds les effets mdr)
mais bon, c'est quoi l'avantage ?
si faut faire déjà une créature pour le onperception on a déjà un onheartbeat ...
alors y a bien les onenter etc. mais dans une ia, tu t'en sers pourquoi ? (c'est une question, une vraie, pas une question pour souligner mon propos )

pis pour le onhit, reste le pb des moines nan ? (je dis ca parce que dans le sujet dessus, y a Skanzo il me semble qui avait parlé d'un OnHitted, mais soulevé cette question )

je serais vraiment très curieux de voir comment tu ferais pour bricoler tt ca *gros clin d'oeil à la Al Bundy*

(non pas que je doute que t'y arriverais , en réalité le smiley c'est pour que tu le fasse , mais je serais vraiment curieux de voir comment )
Citation :
(non pas que je doute que t'y arriverais , en réalité le smiley c'est pour que tu le fasse , mais je serais vraiment curieux de voir comment )
LOOOOOOOOOL !!!!!

bon, ca m'interesse pas du tout de développer ca, mais je vais essayer de pondre quelques trucs quand même ^^

Citation :
mais dans une ia, tu t'en sers pourquoi ?
euh.... tu veux vraiment que je réponde ?
Si je pouvais répondre a ca en trois ligne, ce forum n'aurait pas lieux d'être. Tu veux vraiment le savoir ? Tu prend le premier post du forum en partant de la fin, puis le suivant, puis le suivant, etc... jusqu'a celui la, et tu auras plein d'exemples

Bon, OnBlocker, ca pourrait ce bricoler avec une area of effect, mais la c'est un peu galère ^^

OnCombatEndRound ca ce fait avec un DelayCommand bien placé, mais j'admet que ca peut tendre au bug.

Pour le OnConversation, pas évident du tout par contre :/

OnDamaged, il peut toujours y avoir une fonction récurente qui compte les points de vie toute les demi secondes.

Pour le OnDeath, bien on a notre même fonction récurente

OnDisturbed, je vois pas trop

OnHeartBeat : no comment

Le OnPeception on l'a avec le OnEnter de l'area of effect, et un petit test pour vérifié s'il le voit / l'entend

OnPhysicalAttacked : le je vois pas

OnRested ca peut aussi se vérifier avec notre fonction

OnSpawn : no comment aussi ^^

OnSpellCastAt : bien, on peut toujours modifier la liste de sorts si on en a le courage :bouffon:

Si vous(tu) voulez des éclairsissements sur un/des points, allez y ^^
Sur les trucs que j'ai pas trouvé, je peux peut être y arriver en mega bidouillant.
J'ai réussi à affecter les scripts de henchman a une copie -une copie de copie pour être plus exacte-sans pour autant qu'elle ne soit le henchman de qui que ce soit (ou dominée par qui que ce soit). Je dois préciser qu'un jour Bioware pourrait considérer que tout cela repose sur un bug... Le principe est que quand on fait la copie d'un objet, les effets ne sont pas correctement copiés, leur conséquence le sont parfois (Ability Decrease, Domination) mais pas toujours (lenteur), quant à leur références elles ne le sont jamais: la copie est amnésique, et intègre les modifications comme ses caractéristiques propre. J'utilise cela pour garder les scripts de henchman sur la copie de copie, quand bien même elle n'a plus aucune autre des caractéristiques d'une créature dominée (pour éliminer la gui des henchman, je réaffecte la copie deux comme henchman de la copie un, que je détruis ensuite). Voir aussi la note sur une implémentation possible des henchmen multiples.

Voilà le script, assez affreux car j'ai laissé les lignes de tests (je pense que ça peut être utile), et que je ne suis même pas mes propres conseils (optimisation des AssignCommand) . Il faut que je sorte, si il y a des choses pas clairs, j'essaierais d'affiner plus tard.

PS le script s'utilise tel quel dans un OnUsed.


Code PHP:

object oPlayer GetLastUsedBy();
object oTemp;
location lLoc GetLocation(OBJECT_SELF);
object oCopy CopyObject(oPlayerlLocOBJECT_INVALID"copy1");

void Dominate(object oTarget);

void CountPC();

void AlertEffects(object oTarget);

void CreateCopy2(object oCopylocation lLoc);

void main()
{
    
ChangeToStandardFaction(oCopy,STANDARD_FACTION_HOSTILE); // bon la c'est 
    // vraiment de la perversion d'effectuer le changement de faction sur la première
    // copie plutot que la deuxième, mais c'est juste pour montrer que ca marche.
    
ApplyEffectToObject(DURATION_TYPE_PERMANENTExtraordinaryEffect(EffectSlow()),oCopy) ;
    
ApplyEffectToObject(DURATION_TYPE_PERMANENTExtraordinaryEffect(EffectAbilityDecrease(ABILITY_STRENGTH,5)),oCopy);
    
SendMessageToPC(GetFirstPC(), GetTag(oCopy) + " Strength: " +IntToString(GetAbilityScore(oCopy,ABILITY_STRENGTH)));
    
AssignCommand(oPlayer,Dominate(oCopy)); // une petite explication 
   // s'impose: les dominations de PNJs  imposées par un PJ et par un PNJ  
   // marchent différement, dans le premier cas les scripts de 
   // henchman sont appliqués à la créature dominée, dans
   // l'autre seul un heartbeat est appliqué . C'est pour cela
   // que je fais appliquer l'effet par le PJ.
   // Si je me contentais d'appliquer cela, puis de supprimer
   // la domination par un moyen ou par un autre, les scripts
   // s'envoleraient du même coup, d'où le recours à une
   // copie de copie, qui a le bon goût d'être amnésique. 
    
AssignCommand(oPlayerAlertEffects(oCopy));
    
AssignCommand(oPlayerCreateCopy2(oCopylLoc)) ;
    
AssignCommand(oPlayer,CountPC()); // 1 seul PC , ouf!
    
AssignCommand(oPlayer,DestroyObject(oCopy));
}

void Dominate(object oTarget)
{
     
ApplyEffectToObject(DURATION_TYPE_PERMANENTExtraordinaryEffect(EffectCutsceneDominated()),oTarget);
}
void CreateCopy2(object oCopylocation lLoc)
{
    
object oCopy2 CopyObject(oCopylLocOBJECT_INVALID"copy2");
    
SendMessageToPC(GetFirstPC(), GetTag(oCopy2) + " Strength: " +IntToString(GetAbilityScore(oCopy,ABILITY_STRENGTH)));

    
AlertEffects(oCopy2);// oCopy2 n'a aucun effet d'appliqué, pourtant si la lenteur
    // n'est effectivement pas dupliquée, l'ajustement de force l'est bien ;
    // quant à la domination voir ci dessous. C'est cet oubli qui fait
    // que tout cela marche: les scripts de domination (a savoir ceux des henchman)
    // sont appliqués de facon permanente, quand bien meme on change le maître

    // RemoveHenchman(OBJECT_SELF, oCopy2); //ne marche pas.
    // note: Le maitre doit etre stocke comme un objet local sur la creature
    // dominée et donc etre dupliqué par CopyObject même si le statut de créature
    // dominée ne l'est pas officiellement.
    // On note que la GUI est néanmoins celle d'un henchman quand on clique sur copy2.
    // Tant que l'on a pas change son maître bien sur...
    // Ceci pourrait permettre d'implementer des henchmen multiples, sans besoin
    // de permutation, le seul defaut est que le petit portrait n'apparaît pas.

    // AddHenchman(oCopy2, oCopy2); // fait crasher le programe. Dommage, ca aurait
    // procuré un bon test pour reconnaître ces copies dans les scripts d'henchmen,
    // GetMaster() == OBJECT_SELF, ni dieu ni maitre "les anarchiiiiistes"
    //  (pour les fans de Leo Féré).
    
AddHenchman(oCopyoCopy2);//NB: GetMaster == OBJECT_INVALID n'est PAS un bon
    // test, car tous les henchman désoeuvrés sont dans cette configuration donc pour
    // faire des sections specifiques dans les scripts d'henchman, il faudra utiliser
    // le tag.
    // OBJECT_INVALID, car souvenez vous nous detruisons la premiere copie a la
    // fin du main(), donc des son spawn la copie 2 n'aura plus de maitre, vous
    // pouvez verifier.

    // ChangeToStandardFaction(oCopy2,STANDARD_FACTION_HOSTILE);
}
void AlertEffects(object oTarget)
{
    
effect eTemp GetFirstEffect(oTarget);
    while (
GetIsEffectValid(eTemp))
    {
        if( 
GetEffectType(eTemp) == EFFECT_TYPE_DOMINATED )
        {
            
SendMessageToPC(GetFirstPC(),GetTag(oTarget) + " Dominated");
        }
        else 
SendMessageToPC(GetFirstPC(),GetTag(oTarget) + " effect: " IntToString(GetEffectType(eTemp)));
        
eTemp GetNextEffect(oTarget) ;
    }
}

void CountPC()
{
    
object oTemp GetFirstPC();
    
int i 0;
    while (
GetIsObjectValid(oTemp))
    {
        
i++;
        
oTemp  GetNextPC();
    }
    
SendMessageToPC(GetFirstPC(), IntToString(i));

Bon je ne sais pas si cela intéresse qui que ce soit: mais voilà un tout petit module de démo (zip, 6ko , n'hésitez pas ).

Quand on active le levier copycat, quatre copies du joueur sont crées: deux deviennent des créatures pseudo-dominées (i.e. ont peut leur donner les ordres des henchman mais il n'y a pas de limite de nombre, et leur portrait n'apparait pas en dessous de celui du joueur), deux autres sont hostiles et vont immédiatement attaquer.
Pour une raison inconnue les deux alliés sont passifs au début il faut leur donner un ordre (ex: protégez moi, en se ruant à l'attaque) pour les réveiller.

Voilà, voilà ... Je crois que je suis en compétition avec Skanzo pour le prix du bidouillage le plus infâme maintenant...
moi, grand flemmard et exploiteur devant l'eternel... je me demandais si pom-pom pourrait pas pondre un petit module qui serait une variation du present...

un groupe de joueurs arrive dans une piece.. on tire un levier ou n'inporte quoi comme declancheur , et un groupe hostile identique est spawné dans une piece à coté et ils attendent gentiment que les joueurs ouvre la porte qui est marqué "ne pas ouvrir" .. mouahahah ...

l'ideal etant que si les doubles rencontre les orginaux, ils n'attaquent QUE leur original (le double-joueur1 attaque le joueur 1 , le double du joueur 2 attaque le joueur 2... etc etc) et ignorent les autres joueurs ...
la cerise etant que les doubles soient invulnerables aux attaques de tous les autres joueur sauf de son propre original (double 1 ne peut etre tuer que par joueur 1... etc etc)

prenez ça comme un defi, et je suis sur que ça peut finir dans un .erf sur nwnvault comme "piege tous fait" ... je suis meme pret à faire la doc et le readme en anglais si besoin...

je travaille sur des trucs equivalent , et le but final etant de faire une suite de piece-piege pret à etre incorporer dans un module par import... comme ça les DM peuvent rendre plus amusant un module sans se faire suer... voir preparer des modules types "couloirs de guildes d'assassins pour epreuves d'incorporation" sans se fouler...

qui releve le defi ?
Juste un petit truc. Dans le script tu trouvera cette fonction:
Code PHP:

void CreateCopy2(object oCopylocation lLoc)
{
    
object oCopy2 CopyObject(oCopylLocOBJECT_INVALID"copy2");

    
AddHenchman(oCopyoCopy2);
    
    
RemoveHenchman(oCopyoCopy2);
    
ChangeToStandardFaction(oCopy2,STANDARD_FACTION_HOSTILE);

C'est celle qui crée les copies hostiles. oCopy est la première copie du PJ, détruite à la fin du script. Le RemoveHenchman n'est utile que si tu veux créer plusieurs copies: en effet chaque créature, PJ ou PNJ, ne peut avoir plus d'un henchman, donc si je n'enlevais pas son henchman à oCopy avant d'essayer de lui en filer un autre cela échouerait. Si tu ne veux qu'une copie en revanche, tu n'as pas besoin de RemoveHenchman du tout, le DestroyObject(oCopy) le fera automatiquement.
vi, pas mal du tout, bien que tout cela repose sur un chateau de carte ^_^, enfin tant que ca marche, je ne critique pas, moi aussi je suis un bidouilleur fou

Citation :
Je crois que je suis en compétition avec Skanzo pour le prix du bidouillage le plus infâme maintenant...
Et ben accroche toi mon coco, t'as encore du boulot :bouffon:
Oui c'est tout à fait possible, il y a juste un petit problème: les seuls scripts que je puisse affecter à la copie sont ceux des henchmen (nw_ch_ac*) donc pour faire du scripting spécifique ce sont ces scripts qu'il faut modifier, en rajoutant par exemple (un test sur GetMaster pourrait optimiser les choses si les gars de Bio n'avaient pas écris ces scripts comme des cochons):
Code PHP:

if(GetTag(OBJECT_SELF) == "copie")
{
     
//le code a éxécuter

Donc cela alourdit les scripts modifiés (qui servent aussi aux compagnons/créatures convoquées/dominées), pas terriblement: ce test est rapide étant donné qu'il ne fait référence qu'à OBJECT_SELF. Mais surtout si tu as un système d'henchmen particulier, qui a écrasé ces scripts c'est de ces versions là qu'il faudrait partir (s'ils sont enregistrés sous un autre nom, pas de problème en revanche, les scripts affectés sont les nw_ch_ac*, pas forcément ceux qu'utilisent les henchmen dans un module).

voilà, dis moi ce que tu en penses, modifier le CombatRoundEnd, le onDammaged, et peut-être l'onperception pourrait marcher pour faire ce que tu veux. Néanmoins je ne peux pas te promettre la cible unique, c'est plus compliqué que cela en a l'air (attaque opportuniste, sans parler des sorts à effets de zône...)

EDIT: en y réfléchissant, pour faire ce truc le plus proprement possible le mieux serait de rediriger les scripts de domination via un hakpack (en éditant statescripts.2da).
partons sur l'hypothese qu'il n'y a pas de systeme de henchman particulier ... et pour ce qui est de l'invincibilité aux autres joueurs sauf son original, on oublie... .. on va juste essayer que la copie attaque SON original pour debuter le combat...
Pardon Tonton, j'ai été un peu long:
http://www.sharemation.com/pompom/NWN/copy_trap.rar
Voilà j'ai pas trop le temps d'expliquer là. Sinon que pour une raison qui m'échappe j'ai fait deux zones, dont une totalement inintéressante ou est le StartingPoint, cliquer sur la rive où le ruisseau passe "sous terre" (avec un peu d'imagination) pour aller dans la zone du piège. J'ai posé les trigger comme un sagouin. Je ne gère pas le problème de l'inventaire des copies (i.e. le détruire, lourd à faire sans modifier l'OnDeath des copies, pas impossible, dis moi ce que tu en pense). Voilà sinon je ne sais pas si la façon dont cela fonctionne correspond à ce que tu voulais.
PS: je l'ai très peu testé, "ça a l'air de marcher" est tout ce que je peux dire (notamment pas du tout essayé en multi).
Je sais plus, il est possible que j'ai laissé des lignes de debug (j'ai fait ça hier un peu tard ) . Voilà j'espère que ça te sera utile. N'hésites pas à demander des améliorations/modifications du système.
Citation :
i.e. le détruire, lourd à faire sans modifier l'OnDeath des copies, pas impossible, dis moi ce que tu en pense).
et dans un onaquire item ?
en mettant une variable sur les item lors de la création du double, et test decu dans le onacquireitem . . .
c'est cette solution à laquelle tu fais allusion par "lourd à faire" ?
je remet rien en doute, je demande juste si ce genre de procédé est lourd (pas de malentendu hein )
Citation :
Provient du message de Reyan
et dans un onaquire item ?
en mettant une variable sur les item lors de la création du double, et test decu dans le onacquireitem . . .
c'est cette solution à laquelle tu fais allusion par "lourd à faire" ?
je remet rien en doute, je demande juste si ce genre de procédé est lourd (pas de malentendu hein )
C'est une possibilité, le seul truc c'est que si il n'y a pas d'onacquireitem par ailleurs tu en fais un juste pour une petite zone, et puis tu ne détruit pas les objets au sol.
Je pensais plutôt détruire les objets quand
1) le levier qui crée les doubles est désactivé (les doubles existants sont déjà détruit dans ce cas là, donc ça ferait cohérent)
2) quand les PCs sortent de la zone, mais pour l'instant y a pas de sortie ...

En y réfléchissant c'est moins lourd que je ne pensais: contrairement à ce que j'ai cru on a pas besoin de faire un pseudo-tableau à la création de la copie: une pseudo-liste chainée marche. I.e. tu stockes le premier objet du premier inventaire sur la zone par exemple, tu stockes le deuxième sur le premier... quand tu as fini un inventaire tu stocke un pointeur de fin de liste sur la zone pour pouvoir mettre l'inventaire d'après à la suite rapidement. Quand tu veux détruire les items tu parcours ta liste. Ce qui veux quand même dire que à la désactivation du levier il faut faire cette opération avant de détruire les copies elle-même (sinon il y aurait des "trous" dans la liste correspondants aux inventaires des créatures détruites, et on ne pourrait plus la parcourir), ce qui est assez redondant. Finallement, c'est débile, mieux vaut faire un pseudo tableau, avec un index de dernier élément... mais là outre les opérations de destructions des items à proprement parlé tu dois aussi détruire les objets locaux, faute de quoi tu te retrouves probablement avec une collection de "pointeurs" vers OBJECT_INVALID... grr, sais pas...
Remarque, étant donné la gueule de certains des scripts que j'ai foutu la dedans l'optimisation maximale, je peux déjà oublier...

EDIT: je suis idiot: en faisant une liste chaînée par inventaire, on obtient le meilleur des deux méthodes. Bon je fais ça un peu plus tard.
EDIT2: j'avais oublié les potions et autres parchemins que l'IA de la copie peut lui faire utiliser pendant les combats, ça crée des trous aussi, donc je vais faire un pseudo-tableau, pas joli, lourd, mais au moins ça marchera.
PS: Il y a toujours la possibilité du OnAcquire comme le disait Reyan, mais ça c'est à toi de voir Tonton, étant sonné que ça a un "look" un peu différent. Remarque c'est pas mal les objets fantômes qui disparaissent quand tu les rammasse
Bon, je vais tout de même te tenir au courant: c'est à s'arracher les cheveux. Il y a des bugs partout du côté de Bioware, je crois que j'ai enfin réussi à les démêler:
1) le truc que j'utilise, la bonne nouvelle c'est que ça marche à tous les coups mais:
2) ironiquement un bug de l'effet domination (pas très sûr là) a les même conséquence (à savoir laisser les scripts en place) mais de façon complètement aléatoire autant que je puisse en juger (grosso modo 1 fois sur deux), il m'a fallu un bon moment pour comprendre que certaines de mes premières copies gardaient aussi les scripts d'Henchman. Comme c'est aléatoire c'est inexploitable, mais ça gène pas vraiment non plus si on s'y prend correctement.
3) CopyObject: Là c'est beaucoup plus ******, les copies de PJ sont aléatoirement buggées, environ une sur trois elles se retrouvent complètement en dehors du système de faction:
Code PHP:

    ChangeToStandardFaction(OBJECT_SELF,STANDARD_FACTION_HOSTILE);
    
AdjustReputation(GetFirstPC(), OBJECT_SELF, -100);
    
SetIsTemporaryEnemy(GetFirstPC()); 
n'aura aucun effet sur ces copies buggées!

Malheureusement ça passe aussi aux copies de copies, quoique moins souvent j'ai l'impression (probablement seulement une partie des copies de copies buggées je suppose), donc en faisant des copies de copies de copies de copies de copies de copies de PJs, je peux peut-être diminuer la probabilité mais ça ne me semble pas être une très bonne idée .

Pourquoi est-ce ennuyeux? Parce que DetermineCombatRound, sans oIntruder, cherche une cible parmi les créatures hostiles qui sont présentes. Résultat: quand j'appelle DetermineCombatRound la première fois ça marche car je lui passe l'original en paramètre, mais ça ne marche qu'un round, après quoi la copie buggée n'a plus de cible et reste planté là. Lui taper dessus ne change rien, étant donné qu'elle est en dehors du système de faction, les ajustements automatiques ne lui sont pas appliqués et elle reste neutre.

Comment s'en sortir? Modifier DétermineCombatRound pour forcer la copie à avoir une cible (je ne parle pas de modifier nw_i0_generic , juste de faire une version spéciale pour ces copies). Du coup, je pourrais implémenter ton idée de copie attaquant son original uniquement, aux attaques opportunistes près. Pour ça je préfèrerais tout de même passer par un Hakpack, pour rediriger les scripts de créatures dominées (pas encore testé, mais ça devrait marcher) histoire de ne pas alourdir les scripts de henchman/animal compagnon/familier/créature convoquée, et pour ne pas générer de conflit avec des versions modifier de ces scripts.

Le résultat sera tout de même étrange: les copies attaqueront les PJs sans être hostiles, au cour du combat certaines le deviendront (celle qui ne seront pas buggées) et d'autre non, mais le combat devrait ce dérouler normalement sinon.

Autre problème: la destruction des objets, mon système marche.... presque :bouffon: . J'avais oublié un détail, les objets empilable (stackable): si un PJ ramasse un de ces objets, et que ce dernier se combine avec un équivalent déjà présent dans l'inventaire du joueur, l'objet résultant n'est pas l'objet ramassé, donc il n'est pas détruit par la routine.
Solution?
1) Passer par l'OnAcquire du module comme le suggérais Reyan
2) Utiliser le OnDeath de la copie (tant qu'à faire des scripts spécifiques...)
3) Détruire les objets non équipés de l'inventaire à la création de la copie, ce serait dommage, car dans ce cas la copie n'utilisera pas les propres potion du joueur pour se soigner sous son nez . Par ailleurs ça laisse de côté les munitions... on peut les détruire aussi, mais il ne vaut mieux pas que l'original soit un archer dans ce cas.

Voilà, si tu veux je peux te mettre à disposition une version reflétant ce que j'ai fais jusque là, bug aléatoire de faction inclus. J'attend tes impressions , Si tu penses que ça vaut le coup de continuer (avec un hak et la bizarrerie des copies neutre qui combattent), n'hésite pas.

PS: Ce truc soulève probablement une question sur le statut des copies de PJs non buggées dans le système de faction... Eh bien, elles ont sûrement une faction mais je ne sais pas laquelle, aucune de celle qui sont censées exister dans le module je pense, peut-être une faction pour chaque (quoique... AdjustReputation n'a l'air de rien faire même sur les copies non buggées, avant changement de faction en tout cas, tirez en votre propre conclusion) .
EDIT : Entre les problèmes des forums, et mes problèmes de connexion, c'est une gageure de poster ici, j'ai donc un peu avancé sur l'option hakpack (fichier de 2ko décompressé), depuis que j’ai rédigé tout ça, ça marche.
Voilà comment je vois la chose chaque double attaquera son original, et s'autodétruira si celui-ci meurt, de plus il auto soignera immédiatement tous les dégâts provoqués par quelqu'un d'autre que son double.
Ca t’irait?
PS: j'espère très sincèrement que je n'aurais pas à aller modifier les sous fonctions de DetermineCombatRound, je crois que non...
Bon, à tête reposée, je me suis dit qu'il y avait tout de même quelque chose d'étrange, étant donné que je n'avais pas vu ce bug la première fois. Il s'avère que le bug est bien là, mais que je l'avais écrasé par inadvertance, je ne vais pas expliquer, je pense que je vous ai déjà assez soûlés comme ça... Je le fais un peu dans les commentaires de pp_i_hostcopy.nss. Passons, le résultat est que j'arrive à déclancher et maintenir le combat sans modif de script (nw_ch_ac1 est juste là pour le débuggage). Cette fois, tout à l'air de marcher (sauf cf plus bas problème des objets empilables, j'attends du retour sur cette version), je me suis même pris une déculottée sorcier de niveau 20 contre copie exacte, mais j'étais pas chaud, j'avais la pression, et arrêt du temps, c'est pas fair-play.
voilà donc la version modifiée: copy_trap.rar

détail:
Ca marche pareil, quand le levier est activé ça déverrouille la porte et produit les copies, qui sont invulnérables et passives tant que leur original ne s'aie pas approché (trigger), suite à quoi elles l'attaquent.
Par contre ne plus tester comme DM car plus rien ne se produira.
Je ne fait de copies que des joueurs, pas de leurs familiers, henchman, etc... Peut être modifié.
Ah oui, le deuxième effet kisscool, que j'avais oublié de mentionner, si un joueur de la zone a une créature dominée quand le levier est activée, il la perd immédiatement. Etant donné le temps que dure domination je ne pense pas que cela arrivera très souvent ceci dit.
Je n'ai pas corrigé l'histoire des objets empilables non détruits si ils sont ramassés, j'attend des échos, en effet si je met un hak pour rediriger les scripts de domination (à mon avis la version la plus propre et la plus versatile, à la fois par rapport à celle ci et à l'édition directe des nw_ch_ac*) le OnDeath rend cela trivial.
J'ai tout de même fait un effort de présentation: conversations avec texte en jolies couleurs (enfin, pour ceux qui aiment le violet), le trigger pour "plonger" dans le ruisseau est correctement posé (et oui, la zone qui ne sert à rien est toujours là)...
Ne pas faire attention à tout ce qui traîne, bâton de sorcier, trois petit garçons... C'est des outils de débuggage.
Dommage que j'ai qu'une bécane qui puisse rouler sur nwn sinon j'aurais pu tester avec deux PJ
En tout cas, ça m'a l'air de bien tourner

Citation :
Pom-pom: Je crois que je suis en compétition avec Skanzo pour le prix du bidouillage le plus infâme maintenant...

Azra: Et ben accroche toi mon coco, t'as encore du boulot
"Infâme" ils disent :bouffon:
Pourtant j'ai jamais vraiment poussé le vice
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés