Mince si j'avais pu m'en mêler avant !
Bonjour les jeunes !
- baronf a écrit:
- cela aurait été trop beau!
Essaye en remplaçant l'arme par une créature (car après tout le script est fait pour cela...)
Je vais voir si je peux trouver un sort faisant apparaître un objet, pour trouver des différences.
Mets tout de même ici, une copie du script que tu as écrit. (on va peut-être essayer avec un PlaceAtMe)
Voici un petit cours... plutôt une présentation de notions importantes et de méthodologie.
Pour une solution concernant les armes liées au PJ : voir directement la partie D.
PRÉLIMINAIRE : Étendue d'un sort (range)
L'exemple plus loin traite d'un sort "sur soit"...
On verra après, la façon de traiter un acteur désigné par le toucher (pas compliqué... cela va marcher presque comme le "sur soi").
Et ensuite les sorts sur cible dans un rayon donné : le script s’exécute à l'identique sur tous les acteurs dans la zone... sauf que l'on peut y mettre quelques discriminations :
* si appartient à ma faction...
* si appartient a la faction de celui qui est mon getCombatTarget, ou le GetCombatTarget d'un compagnon, ou GetPackageTarget de tel PNJ...
* est une créature, pas une créature, de telle race, de telle faction, un fantome, un vampire...
* possède tel jeton dans son inventaire
* "est la première créature trouvée", ou "est la première non-créature trouvée"... etc.
Les sorts sur cible sont un bon moyen de créer des stratégies de combat par exemple, ou d'affecter l'ensemble d'une population de nouvelles valeurs de propriétés.
Ôtez moi d'un doute : vous voulez faire quoi ?
C'est une étape importante du point de vue méthode. On distingue 3 étapes dans la réalisation d'un petit projet informatique :
- La phase de conception, qui débute par une étude des besoins et la rédaction de scénarios et le choix du ou des scénarios retenus.
- La phase de choix de composants : structures préfabriquées à paramétrer ou de structures sur mesure (scripts) permettant de réaliser ces scénarios.
- La phase de codage et de programmation ou l'on détermine finement le paramétrage et le code des scripts
On progresse dons d'une description assez générale en français, vers une réalisation de plus en plus détaillée et technique.
A) LA PHASE DE CONCEPTION : DÉTERMINER LES BESOINS... sur mesure pour aboutir à des scénarios détaillés1) Les besoins : quelques exemples au travers d'idées de ce que peut être un objet lié... temporairement à un acteur.a) Arme liée : simuler une arme liée qui apparait à la demande directement dans la main ?
Quelques aspects techniques pour faire çà : Une arme placée dans la main est une référence que l'on a pas besoin de placer en x,y,z dans le monde : sa position est celle du noeud du squelette du NIF d'acteur appelé "Main Droite". Son orientation est liée à celle de la main. Dans le monde graphique, le Node (noeud) "Main droite" correspond au connecteur d'équipement (slot) n° 16. Pour attribuer le slot 16 à une arme, il suffit de l'équiper. Cela placera automatiquement le nif sur le bon node du squelette. La notion de slot est utile si on utilise l'extension de script OBSE.
L'arme équipée du point de vue graphique n'est donc qu'un NIF ajouté au squelette de l'acteur.
Comme tout item présent dans un inventaire, C'EST UNE REFERENCE D'OBJET INCOMPLETE ET DEPENDANTE, car elle n'a pas de formID, ni à fortiori d'EditorID. Son objet de base est connu par son formID pour savoir quel NIF charger. Cette référence conserve certaines propriétés fiables comme la persistance, ce qui lui permet de continuer à exécuter son script si sa base en a un. Mais certaines propriétés devient inconsistantes comme la position et l'orientation. LA DEPENDANCE se manifeste par le fait que la reference d'objet présente dans un inventaire est identifiée par son container (acteur ou container), le formID de sa base, et un n° de ligne dans l'inventaire.
Le principe est le même pour chaque pièce d'armure si on veux lier une armure à un acteur. Le container d'un objet d'inventaire peur être connu dans le script de l'objet par la fonction GetContainer qui renvoie son FormID.
b) Acteurs liés : divers scénarios de simulation à explorer :
Un acteur lié apparait à coté du PJ ? Il y a la solution PlaceAtMe ou celle de déplacer un acteur existant et caché dans une cellule technique. Voir plus loin l'explication. lors de la fin du combat, on renvoie l'acteur dans son bocal, ou on le détruit.
Convertir par le toucher un ennemi et le faire se battre contre l'attaquant actuel ? Sort de TOUCHER
Convertir un ennemi de façon aléatoire... Sort de CIBLE Ici acteur ou ennemi converti peuvent être : un pnj non spectre, un pnj spectre , une créature etc...
Les deux derniers ne sont pas vraiment des acteurs.
Les deux derniers scénarios ne sont pas vraiment une application d'acteur liés, mais une modification de valeurs d'acteurs présents sur la scène. cependant la technique est très proche de celle des acteurs liés, malgré un scénario assez différent : pas de déplacement forcé de l'acteur au début, ni renvoi à la fin.
c) Si on veux faire apparaitre un acteur : placeAtMe mais ce n'est pas une bonne idée si le sort est très utilisé !
C'est bugué au niveau des save de jeu, il manque du nettoyage et cela fait gonfler la save de jeu au fur et à mesure qu'un grand nombre de placeatme a été exécuté. On peut utiliser placeAtMe pour des objets que l'on souhaite ajouter dynamiquement, mais qui dans le jeu seront en nombre restreint. On évite de le faire avec des objets qui seront placés de façon très répétitive.
Plus propre donc : on crée une cellule réservoir, avec un stock d'acteurs à lier au PJ ou à ses compagnons. Si ce n'est qu'au PJ, c'est simple : un seul par race liée. Sinon ce sera légèrement plus compliqué parce qu'il faudra choisir qui est affecté à qui et en mettre suffisamment... et se donner une règle d'affectation : le plus simple c'est l'un après l'autre, comme cela se présente.
A chaque lien d'acteur, on modifie éventuellement ses paramètres (règles d'évolution si levelled ou non, sa disposition envers le PJ, sa force, vérifier sa santé... aux petits oignons, quoi) , désigner son adversaire : celui qui te tapes dessus actuellement, ce serait pas mal, non ? Ou le super BOSS chef de faction adverse qu'il faut absolument abattre rapidement... à vous de voir les règles.
d) Si on veux convertir un adversaire présent, il n'y a pas à le chercher, puisque vous l'avez déjà prévu dans votre monde. Il suffit de le toucher avec le sort.
Le script n'a qu'à modifier les caractéristiques voulues. Mettre une bonne disposition (100) de lui vers vous, lui ordonner de stopper le combat, lui ordonner le friendhit, aux cas ou le boulet de PJ lui donne un ou deux coups en trop... et c'est fait ! Un petit coup de santé aussi... donnez lui un fortifiant car vous l'avez cabossé un peu...
Je dis çà, c'est bien sûr fonction du degré de difficulté de jeu que vous voulez. Par ailleurs les sorts sont des pouvoirs, des capacités, des pouvoirs inférieurs, des sorts simples. Cela détermine la fréquence avec laquelle on peut l'utiliser. Donc... facilite plus ou moins le jeu. A vous de trouver les bons réglages du gameplay mis en place.
e) Lier une arme au PJ ou à un PNJ, ou l'un ou l'autre automatiquement selon celui qui a lancé le sort ? (toucher ou sur soit)
f) Lier une arme à un compagnon par exemple, avec un sort par toucher, ou automatiquement parmi ceux présents et appartenant à la faction du PJ ?
(Je dis tout cela pour te donner des idées, car on n'est pas obligé de se limiter à ce qui est déjà existant comme scénarios possible)
2) Exemple de recherche de scénario d'arme liéeUn scénario s'exprime en une ou plusieurs phrases où la grammaire est très importante. Il faut bien préciser toutes les circonstances au travers d'un questionnement : qui, quoi, pour qui, où, combien, quand, comment on doit faire quelque chose.
On écrit un petit scénario dont on essaie de classer les éléments dans cet ordre :
Circonstances préalables, SUJET, VERBE d'action, QUOI (objet), POUR QUI, autres circonstances (lieu, nombre)
LORSQUE (évènement déclencheur) , QUAND (condition de temps, jour, heure, délai, fréquence), QUI (référence acteur sujet) FAIRE (action) ; QUOI (objet), POUR QUI (référence acteur cible), où, vers où, COMBIEN de fois ...
Remarque : Il peut y avoir plusieurs où... un lieu condition par objet ou PNJ intervenant, mais aussi un lieu peut être le lieu d'où on vient, le lieu où on est, le lieu où on va. Par exemple un PNJ appartient à la faction des habitants de Chorrol, mais se trouver actuellement dans la cité impériale.
Donc bien réfléchir à toutes les circonstances possibles qui limiteraient l'accomplissement du sort ou qui influent sur son comportement.
Ici cela va être simple... Je propose :
I) Lorsque le sort est lancé, le PJ LIE une arme déterminée par le nom du sort lancé, à lui même, venant de nulle part quel que soit le lieu de la scène, sans limite à la répétition du sort.
II) Lorsque l'arme est rengainée, elle est supprimée de l'inventaire du PJ.Voilà, les règles conceptuelles (scénario) sont posées correctement. A partie de ces simples phrases, on peut ensuite faire une étude plus détaillée de chacun de ses éléments, afin de préparer l'étude des composants. On se retrouve avec :
Une liste d'objets : PJ (référence qui lance le sort), arme (objet à lier), cible de sort (le PJ)
Des identifiants : player qui est à la fois le lanceur et la cible, ID de l'arme qui dépend de l'Id du sort
un sort : comme le PJ est à la fois le lanceur et la cible on a besoin d'un sort sur soi-même.
Deux procédures : celle de lancement du sort, et celle de destruction finale de l'arme, à priori, avec chacune sa condition de démarrage : le cast et le fait de rengainer l'arme.
a) le cast lance le sort qui démarre le script d'effet. ,
b) rengainer l'arme se détecte dans un script d'objet sur l'arme : bloc condition OnUnequip et la destruction est provoquée par la fonction .
Ce n'est qu'un a priori, cela va se confirmer avec une meilleure connaissance du fonctionnement des composants, en particulier le fait que les sorts ont une durée préfixée, et que la durée d'un combat est indéterminée.
B) LA PHASE DE CHOIX DES COMPOSANTS : PRÉFABRIQUÉ OU SUR MESUREIl s'agit de déterminer les moyens a utiliser parmi ceux qu'offre l'outil, et choisir les règles qui permettent d'atteindre le résultat escompté.
Nous avons besoin d'objets de base armes avec leur NIF, de sorts et de scripts d'effet magique.
1) Le dilemne : simplicité ou complexitéBeaucoup de petits scripts simple, ou on essaie de regrouper en peu de scripts compliqués ?
La question est essentielle pour la souplesse de fonctionnement (le joueur décide de tout lui même avec des quantités de sorts différents), ou au contraire pour la simplicité de jeu : le joueur décide d'appliquer des stratégies, et le gros script prend des options en fonction des règles qu'on lui a donnée. Le joueur peut se consacrer à admirer les effets obtenus. Ce n'est pas le même style de jeu. On peut se retrouver avec une véritable IA supplémentaire s'ajoutant à celle d'origine.
Les scénarios que nous venons de voir conduisent à des structures simples : des sorts et des scripts très simples mais différents selon les conditions désirées.
Là où cela se complique, c'est lorsque l'on veux faire le moins de sorts ou de scripts possibles et regrouper çà en script(s) compliqué(s) avec une multitude de cas particuliers à l'intérieur. Ce n'est pas forcément une bonne idée, parce que au moment de l'exécution, a chaque fois qu'il est appelé, on déroule un gros script, alors qu'on pourrait en dérouler un petit strictement adapté (pour préserver le taux de frame).
Supposons simplement une liste d'armes que l'on souhaite lier au PJ à la demande : on peut faire un sort et un script par arme ; ou un seul sort et un seul script, la meilleure arme étant choisie par le script automatiquement. Et encore plus compliqué si on veux le moins de sorts possibles...
On peut avoir plein de fonctionnements complexes possibles avec des scripts d'effet. Mais souvent il faut les articuler avec des scripts d'objet. Ce sera la cas ici, et parfois même il faut un script de quête (global) pour bien synchroniser les opérations successives et garder la mémoire de certaines informations.
En savoir plus sur les types de scripts : http://wiwiki.wiwiland.net/index.php/TESCS2_:_Types_de_script
2) Déterminer les structures utiles pour un scénario : bien connaitre la logique de fonctionnement du moteur de jeuDe quels types de procédure le moteur dispose t-il, en gros : sorts, scripts d'effet magique, scripts d'objets, quêtes et scripts de résultats et de quête , packages, idle animation.
Certaines procédures sont synchronisées entre elles grâce à des tableaux de conditions qui permettent de détecter des évènements (fonctions ou valeurs modifiées par les scripts, ou par l'AI.
Les types de procédures plus détaillés avec leurs particularités :
- Sorts (référence cast et reference cible) :
* Sort avec effet prédéfinis, sort de durée fixe avec script d'effet (référence) ;
* sort de durée 0 avec script d'effet (référence).
- script d'objet - types d'objets qui peuvent porter un script : acteur sauf PJ, Item sf flèche, potion, activateur, container, porte, furniture, light, flora ;
* script d'objet dans dans le monde (référence) ;
* script d'objet item d'inventaire (référence sans formID) mais un item peut passer alternativement du monde dans un inventaire, d'où certaines pertes d'informations.
- Quête avec tableau de conditions appliquées aux dialogues... car un dialogue peut appartenir à plusieurs quêtes : cela permet de filtrer selon la quête (race, faction...) ;
* script de quête ne s'exécute pas sur une référence par défaut, chaque fonction doit préciser sa référence s'il elle est requise ;
* script de résultat d'étape avec tableau de conditions, pas de référence par défaut, il faut la préciser a chaque fonction ;
* script de résultat de dialogue avec tableau de conditions, référence à celui qui parle ou référence à sa cible.
- Package avec tableau de conditions, cible du package : évènement déclencheurs de packages (un PNJ fait un cast arme liée s'il entre en combat).
- Idle animation avec tableau de conditions : événements déclencheurs d'animations.
2)Application au scénario des armes liées au PJPour aller plus loin, il faut transformer ce scénario et le découper en procédures.
J'ai deux phrases avec un évènement déclencheur et un résultat simple (pas de répétition), donc à priori j'ai bien deux procédures.
I) Que permet de faire un sort avec script d'effet magique : exécuter un script contenant trois blocs de procédure... MAIS avec une durée fixe du sort.
1° La procédure de première frame (ScriptEffectStart) : ma première phase va s'y loger. Parce que c'est le bon évènement "sort lancé" qui démarre cette procédure.
2° La procédure qui se répète à chaque frame pour la durée FIXE du sort (ScriptEffectUpdate)... je n'ai rien à mettre là parce que entre son apparition et sa disparition une arme équipée est gérée par l'AI par défaut d'animation et de combat de l'acteur qui la porte.
3° La procédure terminale, exécutée à la dernière frame(ScriptEffectFinish). C'est là que l'on déséquiperait et supprimerait l'arme si sa durée d'utilisation était fixe. On a donc rien à mettre là, parce que la durée est indéterminée.
Il est donc inutile de mettre une durée de sort autre que 0. Seul le bloc ScriptEffectStart est utile pour notre projet tel qu'il est ici défini. C'est très performant car ce sort n'encombrera qu'à minima le processeur.
II) Pour supprimer l'épée, l'évènement déclencheur est le déséquipement. J'ai un évènement sur un objet item d'inventaire. J'ai donc besoin d'un script d'objet sur l'arme pour détecter cet évènement. L'action est sur l'objet donc elle sera effectuée directement dans le bloc OnUnequip de ce script.
En savoir plus sur les blocs déclenchés par les évènements dans un script : http://wiwiki.wiwiland.net/index.php/TESCS2_:_Begin
C) LA PHASE DE PARAMETRAGE DES OBJETS ET DE PROGRAMMATION1- Création de l'objet à invoquerCréer l'arme de base : copie l'arme que tu veux parmi les armes de base (Beth ou les tiennes), ou ajoute là : supposons qu'il existe MonArmeMachin.
Tu la dupliques en modifiant son ID : MonArmeMachinLiee... tu modifies les caractéristiques comme tu veux. C'est quand même pas une arme ordinaire, c'est une arme divine.
Si tu veux un type d'arme aléatoire, tu te crées une série d'armes liées de type différent MonArmeMachinLiee, MonArmeTrucLiee, etc.
Tu crées un leveledItem, et tu mets dedans ta liste d'arme liées... les paramètres de level permettent de déterminer la difficulté de tirage au sort pour chaque arme.
Tu as maintenant une arme aléatoire utilisable comme si c'était une arme de base. Appelons là : MonArmeAleatoireLiee.
2- Création du sortCréation du sort d'invocation : ID=AMoiDurandal name=A moi Durandal !
Ou si aléatoire : ID=AMoiUnearme name=A moi une arme !
Mets le type à "Sort" si tu veux le lancer quand tu veux, ou "Pouvoir" si tu veux limiter à une fois par jour.
Il faudra aussi renseigner le champ "Spell Level" et "Spell Cost", aux valeurs de ton choix. (ici level "expert" et un coût de 550 ont été indiqués)
Plus de renseignements : http://wiwiki.wiwiland.net/index.php/TESCS2_:_Spell
3- Ajout de l'effetTu lui mets son
script effect... range=Soit (self) durée = 0
Nom du script sera après sa saisie : MonArmeMachinLieeEffectScript ou MonArmeTrucLiéelieeEffectScript ou MonArmeAleatoireLiéeEffectScript
Nom de l'effet (c'est du texte d'affichage je crois) : Une arme apparait ... , Durandal apparait ...
Ecole : Invocation
Effet : il doit être adapté en forme au type d'arme : arc lié, dague liée, épée liée, masse d'arme liée, hache liée. Tu peux aussi laisser à NONE si t'en veux pas...
Décocher ou pas "effect is hostile" dépend de tes idées de scénario : tu veux qu'on te regarde avec des gros yeux dès que tu lances le sort parce que c'est malpoli, alors coche la case. La disposition a ton égard va baisser. Si certains étaient déjà à la limite du combat, il vont t'attaquer. Sinon, il attendrons que tu leur tapes dessus avec Durandal.
Plus de détails : http://wiwiki.wiwiland.net/index.php/TESCS2_:_Effect_Item
4- Création du script d'effet magiqueClique sur le bouton [...] il faut que tu le crées, avec "Magic effect" dans le champ déroulant en haut (il y a Object par défaut).
Bon tu es averti... tu as la page blanche de script : bouton Script / NEW..
ET ... sélectionner Magic Effect
- Code:
-
scn MonArmeMachinLieeEffectScript
ref me
ref myObj
Begin ScriptEffectStart
set me to GetSelf
if me == 0
set me to Player
endif
set myObj to MonArmeMachinLiee
me.additem myObj, 1
me.EquipItem myObj, 1
[color=blue]me.EquipItem MesFlechesLiees, 20[/color]
end
Faire la même chose pour MonArmeTrucLiee, MonArmeAleatoireLiee...
Pour les arcs, il faudrait ne pas oublier les flèches : ajouter
me.EquipItem MesFlechesLiees, 20 par exemple.
- Citation :
- Ancienne question :
Je ne sais pas pourquoi "Ref" a été ajouté à la créature créée "MidasAtronachPotato". Tu devras peut-être l'ajouter aussi!!
Tout à fait... c'est parce que les fonctions utilisées ici avec myObj sont des fonctions qui portent sur la référence de la créature, pas sur la base.
C'est un usage, pas du tout obligatoire pour écrire les ID. Si un objet de base a pour editorID toto, sa reference unique sera totoRef, son script éventuel totoScript. S'il y a plusieurs références, on pourra les nommer totoRef1, totoRef2 etc. Attention, c'est le même script qui tourne sur toutes les références, mais chaque référence possède un jeu de variables bien a elle. Donc si on a une variable myVar dans le script, on pourra tester dans n'importe quel script les valeurs de totoRef1.myVar et totoRef2.myVar !
De même : If totoRef1.getItemCount bonbon > totoRef2.getItemCount bonbon (si ref1 a plus de bonbons que ref2 ...) bonbon est un objet de base.
Autre exemple : If pnj1Ref.isInCombat pnf1Ref.Yield EndIf (si ce pnj est en train de combattre, on l'oblige à faire sa reddition... et cela déclenche un dialogue automatique : il y a une quête Yield... qui lance un dialogue pour tout pnj qui a la condition IsYealding == 1 ).
Pour éviter toute confusion, quand on définit une variable de reference, il vaudrait mieux l'appeler myRef si elle contient une vraie référence, et myObj si elle contient l'ID de la base. On a parfois besoin des deux pour certaines fonctions, et cela est plus logique de les différencier correctement par leur nom.
Par contre ref est un mot réservé du langage pour déclarer ce type de variable... que ce soit une reference ou un objet de base, c'est le même mot.
Donc on écrirait bien "ref myObj" et "ref myRef"
5 - Sauvegarde et fermeture des fenêtres du sortOn clique sur la disquette qui n'a pas de rouge (sinon la rouge c'est la catastrophe : cela recompile tous les scripts...y compris l'esm et donne un ENORME MOD... plus qu'à tout nettoyer ou recommencer... HUM, tu as une copie du mod faite par précaution ? sinon, ne pas sauver le mod, fermer le tescs et recommence le boulot)
Si c'est bon (par d'erreur de compil), fermer le script... mais c'est pas parce que la compil est bonne que le programme fonctionnera bien... on n'a pas d'erreur de syntaxe mais on peut avoir des erreurs de logique !
Dans la fenêtre Effect Item, dans le champ "Script", indique le nom de ton script (celui que tu as mis sur la première ligne de celui-ci après "scn".
Clique sur OK sur la fenêtre "effect item", pour valider.
Puis fait ok sur la fenêtre "Spell".
6 - Script d'objet spécial pour inventaireC'est notre destructeur d'item d'arme liée. Il n'est pas bien compliqué.
- Code:
-
scn MonArmeMachinLieeScript
Begin OnUnequip
; attention, en détruisant l'item, on détruit le script de l'objet... donc il est inutile d'écrire quoi que ce soit après cette ligne
RemoveMe
end
Bien mieux : en l'état actuel des besoins un seul script de destruction générique est nécessaire pour toutes les armes liées parce qu'ils sont identiques.
Si d'autres évènements devaient être gérés, et ceci, pas de façon identique, il faudra faire des scripts différents autant que de besoin.
Remarque : les arcs possèdent des flèches. Il faudrait penser à les ajouter dans le script d'effet, et les détruire ici.
- Code:
-
scn MonDestructArmeLieeScript
Begin OnUnequip
; attention, en détruisant l'item, on détruit le script de l'objet... donc il est inutile d'écrire d'autres fonctions après cette ligne
; si on a des choses à faire, c'est au dessus, par exemple détruire les flèches liées
RemoveMe
end
Modifiez tout vos objets de base armes liée et ajoutez leur le nom du script de destruction.
Pour les arcs :
- Code:
-
scn MonDestructArcFlecheScript
Short Nb
Begin OnUnequip
; ---- on détruit les flèches qui restent s'il y en a encore... ----
If GetItemCount MesFlechesLiees > 0
Set Nb to GetItemCount MesFlechesLiees
removeItem MesFlechesLiees, Nb
EndIf
RemoveMe
end
C'est fini, plus qu'à tester...
Il y a beaucoup de choses d'expliquée ici... digérez bien.
Une dernière remarque : différence de fonctionnement des scripts d'objet item lorsqu'ils sont dans le monde ou dans un inventaire.
Dans le monde, ils fonctionnent comme n'importe quelle autre référence : c'est une vraie réference avec un vrai formID
Alors, getself donne son formId si on en a besoin.
Si on ramasse l'objet, il disparait du monde, la ref est détruite, le formID n'existe plus.
Si vous avez memorisé à l'occasion ce formID dans une variable dans un autre script, la reference correspondante ne répond plus.
Ses variables et valeurs de fonctions sont détruites.
Dans l'inventaire, l'item est identifié par son container (actor ou container) et un numero de slot.
GetSelf donne 0 ... source de gros bugs si vous ne prenez pas garde
GetContainer donne le formID de l'acteur ou du container dans lequel il se trouve... TRES IMPORTANT CA, POUR DE GROSSES RUSES !
Avec l'extension de script OBMM, on peut connaitre ce qu'il y a dans un numero de slot, parcourir l'inventaire, faire une fouille minutieuse.
Conséquence : vous comprenez maintenant pourquoi j'ai fait dupliquer les armes de base en "armeLiee"...
... parce qui si c'était la même base, il y aurait le même script... et que la belle épée ramassée dans la forêt serait détruite quand vous la déséquipez !!! GRRR !
Et en plus, vous ne connaissez peut-être même pas encore le sort qui va bien pour en avoir une efficace, mais sans valeur commerciale.
Autre inconvénients de ces Items qui passent du monde vers l'inventaire et vice-versa :
* Un item ramassé garde la même base... s'il n'a pas de script, il n'y a pas de problème de script... bon (là je me suis fait un noeud au cerveau)...
* Un item ramassé garde la même base... s'il a un script qui fonctionne bien dans le monde, il risque de ne pas fonctionner dans l'inventaire
* Un item dans un inventaire, jeté dans le monde (Drop), au poil dans l'inventaire aura un probleme de getContainer qui marche plus.
* Lors de ces mouvements entrée-sorte d'inventaire, les autres scripts qui ont mémorisé la ref pour en faire des choses perdent la boule...
* Dans les scripts d'objet ITEM, il faut donc gérer finement les événements OnAdd OnDrop OnEquip OnSell OnUnequip.
* Dans les scripts des acteurs il faut prêter attention aux évènements OnactorEquip, OnactorUnequip.
Voualà pour l'instant ! Bon courage !
Sujet: Re: Création d'une arme lié et méthode de conception IA 
Jeu 19 Jan 2012, 20:34
