Script d'utilisation automatisée d'objets

Hello, je voudrais savoir s'il serait possible de programmer ce genre de choses (sans que ce soit trop complexe):

Il faudrait que quand un perso utilise un objet de l'inventaire sur une zone, et qu'il n'y a rien de prévu pour ça, il lance une animation, sur place, d'utilisation de l'objet, genre il sort l'objet de sa poche et le remet.

D'avance merci.

Salut !!
Je ne suis pas hyper hyper calé, mais peut-être peux-tu coder une "fonction d'extension" dans les unhandled_event ???

avec un truc du genre

Code:

function unhandled_event(int what, int type)
{
 if (what == 4 && type == 3)// Utiliser un objet d'inventaire sur rien  
  {  
    //la fonction d'extension
  }
}

Hello, merci pour ta réponse, mais je ne connais pas ces fonctions, c'est beaucoup trop vague pour moi. Bonne année !

ça risque d'être long à expliquer dans le cas général.
J'aurais besoin de savoir plus précisément ce que tu demandes :

Gob a écrit:

(..)
Il faudrait que quand un perso utilise un objet de l'inventaire sur une zone, (..)

Qu'est-ce que tu entends par "zone" ?

Est-ce qu'il s'agit d'un Hotspot ? Comme : en interaction avec un élément du décors, un personnage...
Par exemple : une clé qu'on pourrait essayer sur plusieurs portes (fermées), des coffres, etc. Mais la clé ne fonctionne que sur une seule porte, donc dans tous les autres cas le joueur dirait que la clé ne corresponds pas.
(En gros c

Ou est-ce qu'il s'agit d'une Room ? Comme : L'objet ne produirait un effet que dans une/certaines scènes bien précises.
Par exemple : un détecteur de métal. Dans la plupart des lieux où on l'utilise il ne renvoi aucun signal, mais quand on l'essaie sur les lieux où est enterré un trésor il se mettrait à biper.

C'est pour les cas d'utilisation d'un objet (de l'inventaire) sur les zones possibles: hotspots, persos ou objets (dans la room).
Un joueur m'a reproché qu'il n'y avait pas de réactions si on utilisait un objet sur quelque chose, alors que dans les anciens Gobliiins, le perso sortait au moins l'objet de sa poche. Je fais des anims de Look sur les objets de l'inventaire, en faisant clique droit, je voudrais utiliser ces anims ou d'autres pour qu'il y ait un minimum de réaction dans le cas non prévus dans le code.

J'ai pas creusé à fond, mais il semble bien que le plus simple soit de passer par cette fonction :

Code:

function unhandled_event(int what, int type)

à vérifier selon la doc s'il te faut ajouter d'autres clauses : d'autres combinaisons what / type pour couvrir toutes les sortes d’interactions :

Code:

//|QUOI |TYPE |Description
//|-----+-----+-------------
//| 1   | 3   | Utiliser un objet d'inventaire sur une zone interactive (hotspot)
//| 2   | 3   | Utiliser un objet d'inventaire sur un objet
//| 3   | 3   | Utiliser un objet d'inventaire sur un personnage
//| 4   | 3   | Utiliser un objet d'inventaire sur rien
//| 5   | 3   | Utiliser un objet d'inventaire sur un autre

À première vue, il semblerait qu'on se fiche du "Quoi", on voudrait que ça se produise dans tous les cas d’interaction d'objet d'inventaire avec quoi que ce soit (sauf si c'est une interaction prévue).

Donc pour résumer : (à mettre dans le fichier principal du script global)

Code:

function unhandled_event(int what, int type) {
   if (type == 3) { // Utiliser un objet d'inventaire sur quoi que ce soit
      // ici une fonction qui lance un message ou l'animation
      eEgo.say("Je sais pas le faire...");
   }
}

Là c'est au plus simple, et tu peux déjà essayer tel quel pour voir si ça fonctionne.

Après, j'ai bien compris : tu voudrais (à la place de eEgo.say(...)) déclencher une animation spécifique en fonction de l'objet d'inventaire utilisé.
C'est à partir de là ou ça peut devenir soit compliqué, soit fastidieux (au choix).

Compliqué : ça dépendrait de comment tu organises l'ensemble de ton jeu, s'il y a une organisation bien déterminée entre les objets d'inventaires créés et les animations de sprite... Mais si c'est pas anticipé au départ, j'imagine que ça serait trop compliqué de tout réorganiser. Donc la solution fastidieuse est probablement la plus simple dans ton cas.

Fastidieuse : Tester la propriété ActiveInventory
et au cas par cas, déclencher l'animation correspondante.

Code:

function unhandled_event(int what, int type) {
   
   // Utiliser un objet d'inventaire sur n'importe quoi d'imprévu
   if (type == 3) {
   
      // Test l'objet actif, et définit la séquence d'animation correspondante
      int sequence = 0;
      if (eEgo.ActiveInventory == iPommeItem) {
         sequence = 1;
      }
      else if (eEgo.ActiveInventory == iBananeItem) {
         sequence = 2;
      }
      else if (eEgo.ActiveInventory == iOrangeItem) {
         sequence = 3;
      }
      else { // Au cas où t'aurais pas d'animation spécifique
         eEgo.say("Je sais pas le faire...");
         return; // termine la fonction
      }
      
      // execute l'animation
      cEgo.LockView(5);
      cEgo.Animate(sequence, 1, 0, eBlock);
      cEgo.UnlockView();
   }
}

Dans cet exemple, je présume que chaque animations soient regroupés dans une même vue (5), et donc en fonction de l'objet actif je donne à la variable sequence le numéro de l'animation correspondante. À la fin je déclenche l'animation en passant cette variable (1er paramètre).

Code:

// execute l'animation
cEgo.LockView(5);
cEgo.Animate(sequence, 1, 0, eBlock);
cEgo.UnlockView();

Avant ça, il y a une clause else qui ne se déclencherait que si l'objet actif n'a pas été prévu dans ce script. Donc, quand tu test le jeu, par exemple t'essaie d'utiliser une patate sur un parapluie, et que ton personage dit "Je sais pas le faire...", ça signifie que tu doit créer une animation gérant la patate et l'ajouter à cette liste (intercaler juste avant le else final) :

Code:

function unhandled_event(int what, int type) {
   
   // Utiliser un objet d'inventaire sur n'importe quoi d'imprévu
   if (type == 3) {
   
      // Test l'objet actif, et définit la séquence d'animation correspondante
      int sequence = 0;
      if (eEgo.ActiveInventory == iPommeItem) {
         sequence = 1;
      }
      else if (eEgo.ActiveInventory == iBananeItem) {
         sequence = 2;
      }
      else if (eEgo.ActiveInventory == iOrangeItem) {
         sequence = 3;
      }
      else if (eEgo.ActiveInventory == iPatateItem) {
         sequence = 4;
      }
      else { // Au cas où t'aurais pas d'animation spécifique
         eEgo.say("Je sais pas le faire...");
         return; // termine la fonction
      }
      
      // execute l'animation
      cEgo.LockView(5);
      cEgo.Animate(sequence, 1, 0, eBlock);
      cEgo.UnlockView();
   }
}

Pour en revenir à la solution compliquée mais moins fastidieuse (mais je sais pas précisément comment coder ça) :
Il faudrait qu'il y ait une corrélation entre les n°ID des objets d'inventaire et les n°ID des séquences d'animation.
Ainsi on pourrait simplement passer directement la propriété ActiveInventory dans la fonction d'animation.

Ci-dessous la vue sur un projet test :



Panneau Explore project
J'y ai 2 objets : n°1 Cup, n°2 Key

Là c'est le volet avec les animation du perso qui se déplace dans les 4 sens, mais imaginons que je créé une View spécifique pour afficher les objets (Montre l'objet, sais pas quoi faire avec...)
Dans Loop 1 je ferais une animation où il sors une tasse (Cup)
Dans Loop 2 je ferais une animation où il sors une clé (Key)

Ainsi côté script il me suffirait de faire ceci : (une fois pour toutes)

Code:

function unhandled_event(int what, int type) {
   
   // Utiliser un objet d'inventaire sur n'importe quoi d'imprévu
   if (type == 3) {
   
      // execute l'animation
      cEgo.LockView(1);
      cEgo.Animate(eEgo.ActiveInventory, 1, 0, eBlock);
      cEgo.UnlockView();
   }
}

C'est la valeur de eEgo.ActiveInventory qui définit directement le bon n° de l'animation.
Seul souci, c'est si je créé un nouvel objet et oublie de créer une animation qui va avec... Si le script ne trouve pas d'animation à ce numéro ça va planter.

Peut-être qu'il suffit de sécuriser ça en vérifiant le nombre d'animation existant dans cette View avec Game.GetLoopCountForView

Ainsi :

Code:

function unhandled_event(int what, int type) {
   int vue = 1; // < ici le n°ID de la View où sont les animations d'objets
   // Utiliser un objet d'inventaire sur n'importe quoi d'imprévu
   if (type == 3) {
      if(eEgo.ActiveInventory <= Game.GetLoopCountForView(vue)) {
         // execute l'animation
         cEgo.LockView(vue);
         cEgo.Animate(eEgo.ActiveInventory, 1, 0, eBlock);
         cEgo.UnlockView();
      }
      else {
         // En fait l'animation correspondante n'existe pas
         eEgo.say("Je sais pas le faire...");
      }
   }
}

Note que tout ça est purement théorique, j'ai rien testé.

Hello ! Je commence progressivement à explorer ta réponse.
Lancer l'anim par ce biais:

function unhandled_event(int what, int type) {
  if (type == 3)

Effectivement, ça marche, c'est un bon début, mais ça ne marche que sur les objets, pas sur les hotspots et characters. A quoi correspond type==3 ?

Le tableau est détaillé ici :
wiki FR / wiki EN à jour

Je l'ai peut-être mal interprété.
Peut être que le "Quoi" correspond à une action (Regarder, interagir, utiliser...)

Code:

// what
// 1    | hotspot
// 2    | object
// 3    | character
// 4    | nothing (i.e. no hotspot)
// 5    | inventory

et le "Type" le type d'objet (un "objet" dans le sens Programmation Orientée Objet : objets d'inventaire, Hotspot, Curseur, Gui, ..)
Mais en même temps le type n'est pas consistant : "Talk to" vaut 1 dans certains contextes, et 0 dans d'autres...
C'est mal expliqué je trouve...

Donc si cette simplification ne fonctionne pas, ce qu'il te faudrait faire, c'est choisir dans le tableau les lignes correspondant aux situations où tu veux déclencher cette animations.
Puis tester par paire de what/type, et des "ou" entre chaque :

Souvent je l'écris comme ça pour que ce soit lisible et facile à éditer, mais je sais pas si c'est supporté par AGS

Code:

function unhandled_event(int what, int type) {
  if (
     (what == 1 && type == 3)
  || (what == 2 && type == 3)
  || (what == 3 && type == 3)
  || (what == 4 && type == 3)
  || (what == 5 && type == 3)
  ) {
    // ici une fonction qui lance un message ou l'animation
    eEgo.say("Je sais pas le faire...");
  }
}

Normalement/sinon il faudrait l'écrire comme ça :

Code:

function unhandled_event(int what, int type) {
  if ((what == 1 && type == 3) || (what == 2 && type == 3) || (what == 3 && type == 3) || (what == 4 && type == 3) || (what == 5 && type == 3)) {
    // ici une fonction qui lance un message ou l'animation
    eEgo.say("Je sais pas le faire...");
  }
}

En principe, on met entre parenthèse les test des deux variables, joint par && qui signifie "et".
Par exemple : (what == 1 && type == 3)
n'est vrai que si what == 1 et type == 3

Donc l'idée c'est d'énumérer chaque combinaisons, cernées par des parenthèses.
Mettre || entre chaque signifie "ou"
Par exemple : (what == 1 && type == 3) || (what == 1 && type == 3)
n'est vrai que si what == 1 et type == 3 ou si what == 2 et type == 3

Hello, voila ce que j'ai mis:

Code:

   if ((what == 1 && type == 3) || (what == 2 && type == 3) || (what == 3 && type == 3))
{
if (cGob1.ActiveInventory == iLezard)
{  
 cGob1.FaceDirection(eDirectionDown);
cGob1.ChangeView (122);
cGob1.Animate (16, 3,eOnce, eBlock);
cGob1.ChangeView (54);
cGob1.Animate (4, 3, eOnce, eBlock);
cGob1.ChangeView (122);
cGob1.Animate (16, 3,eOnce, eBlock);
cGob1.ChangeView (128);
cGob1.FaceDirection(eDirectionDown);
}}

Je ne voyais pas la raison de mettre les What 4 et 5. En fait, pour la réaction sur les persos, il faut les mettre. Mais la réaction n'est pas claire.

Donc j'utilise l'objet de l'inventaire Lezard sur les objets dans l'écran: Il fonctionne sur certains objets, pas sur d'autres. A priori, il ne le fait pas sur les objets qui auront une utilisation d'objets sur eux.

Sur les persos, pareil, il ne fait l'action que sur ceux sur lesquels aucune utilisation d'objet n'est prévue.

Pareil pour les hotspots.

Gob a écrit:

(..) il ne fait l'action que sur ceux sur lesquels aucune utilisation d'objet n'est prévue.

Pareil pour les hotspots.

Je comprends mieux, du coups c'est précisément (et seulement) le rôle de cette fonction : elle s’exécutera par défaut si aucun event de programmé.

Par exemple ici (fenêtre des propriétés d'un objet du décors)
Tous les cas où je n'ai rien programmé (colonne de droite vide)



Est-ce que tu peux fournir le code d'un event que t'as déjà programmé ? (qui consiste à employer un objet précis de l'inventaire sur quelque chose)
Ou si tu veux, un de chaque cas :
- interaction objet d'inventaire / Hotspot
- interaction objet d'inventaire / Character
- interaction objet d'inventaire / autre objet d'inventaire

J'ai une idée de solution, mais il me faudrait un exemple de code, et j'en ai pas trouvé qui corresponde dans les tutos..

Voila 3 exemples, objet, character, hotspot:

[code=ags]
function o7PorteFrig_UseInv()
{
if (cGob2.ActiveInventory == iLime)
{
 player.Walk(646, 291, eBlock,eWalkableAreas);
player.FaceDirection(eDirectionLeft);
 cGob2.ChangeView (94);
 cGob2.Animate (10, 3,eOnce, eBlock);

cGob2.ChangeView (78);
cGob2.Animate (2, 3, eOnce, eBlock);
aLime.Play(eAudioPriorityHigh, eRepeat);
cGob2.Animate (3, 1, eOnce, eBlock);
cGob2.Animate (3, 2, eOnce, eBlock);
aLime.Stop();
cGob2.Animate (4, 3, eOnce, eBlock);
 cGob2.ChangeView (94);
 cGob2.Animate (10, 3,eOnce, eBlock);
 cGob2.ChangeView (124);
 cGob2.FaceDirection(eDirectionLeft);
Wait(25);
o7PorteFrig.SetView(58);
aChaine.Play(eAudioPriorityHigh, eOnce);
o7PorteFrig.Animate(16, 3, eOnce);
Wait(20);
aGrincementPorte.Play(eAudioPriorityHigh, eOnce);
o7PorteFrig.Animate(5, 5, eOnce);

o7PorteFrig.Clickable=false;
}}

----------------------------------------------------------
function cSommeil_UseInv()
{
 if (cGob2.ActiveInventory == iChopeTisane03)
{  
 player.Walk (1069, 209,eBlock,  eWalkableAreas);
 player.FaceDirection(eDirectionLeft);
aGob2Talk15.Play(eAudioPriorityHigh, eRepeat);
cGob2.Say ("Bois-ça ![C'est pour dormir.");
aGob2Talk15.Stop();
Wait(20);
  player.Walk (1069, 209,eBlock,  eWalkableAreas);
 player.FaceDirection(eDirectionLeft);
cGob2.ChangeView (94);
cGob2.Animate (10, 3,eOnce);
cGob2.Animate (20, 2,eOnce);

cSommeil.ChangeView(9);
cSommeil.Animate(2, 3, eOnce);
aWoosh01.Play(eAudioPriorityHigh, eOnce);
cGob2.Animate (22, 3,eOnce, eBlock);
 cGob2.ChangeView (124);
 player.FaceDirection(eDirectionLeft);
Wait(20);
 player.Walk (1069, 209,eBlock,  eWalkableAreas);
 player.FaceDirection(eDirectionLeft);
Wait(20);
cSommeil.Animate(3, 3, eOnce);
aSluurp01.Play(eAudioPriorityHigh, eOnce);
cSommeil.Animate(4, 3, eOnce);
cSommeil.Animate(3, 3, eOnce);
aSluurp02.Play(eAudioPriorityHigh, eOnce);
cSommeil.Animate(4, 3, eOnce);
Wait(30);
cSommeil.Animate(3, 3, eOnce);
aSluurp03.Play(eAudioPriorityHigh, eOnce);
cSommeil.Animate(4, 3, eOnce);
Wait(30);

player.Walk (1069, 209,eBlock,  eWalkableAreas);
player.FaceDirection(eDirectionLeft);
player.ChangeView(94);
player.Animate(6,3,eOnce);
cSommeil.FaceDirection(eDirectionDown);
aWoosh01.Play(eAudioPriorityHigh, eOnce);
player.Animate(8,3,eOnce);
player.ChangeView(124);
player.FaceDirection(eDirectionLeft);

Wait(40);
cSommeil.Animate(5, 3, eOnce);
Wait(30);
aRonfl01.Play(eAudioPriorityHigh, eOnce);
Wait(30);
player.Walk (972, 224,eBlock,  eWalkableAreas);
player.FaceDirection(eDirectionLeft);
aGob2Talk12.Play(eAudioPriorityHigh, eRepeat);
cGob2.Say ("Je crois qu'il va dormir[comme un loir !");
aGob2Talk12.Stop();

player.LoseInventory(iChopeTisane03);
player.AddInventory(iChopeMetal);
D05ConditionsSortie=D05ConditionsSortie+1;
}}

--------------------------------------------------------
function h4Brasero02_UseInv()
{
 if (cGob2.ActiveInventory == iChopeMetal)
{  
 player.Walk (1043, 490,eBlock,  eWalkableAreas);
 player.FaceDirection(eDirectionRight);
 cGob2.ChangeView (94);
   cGob2.Animate (11, 3,eOnce);
cGob2.Animate (21, 2,eOnce);
o15Brasero.SetView(58);
o15Brasero.Animate(25, 3, eOnce);
aWoosh01.Play(eAudioPriorityHigh, eOnce);
cGob2.Animate (23, 3,eOnce, eBlock);
cGob2.ChangeView (124);
player.FaceDirection(eDirectionRight);
 player.Walk (1017, 490,eBlock,  eWalkableAreas);
 player.FaceDirection(eDirectionRight);

player.LoseInventory(iChopeMetal);  
h5Chope.Enabled=true;
D05ChopeBrasero=1;
}}
[/code]

Merci,
C'est comme je l'imaginais mais j’avais pas trouvé d'exemple.

Avant de solutionner ça, on vas organiser le tout. Je fais l'inventaire de ce qu'il faut / ce qu'on veut :

1. Une animation du personnage, en réaction à chaque objet mal utilisé (utilisation imprévue)
   
2. Que ces animations se produisent sur les zones où il n'y a pas d’interaction de prévue : interactions de type Machin_useInv()
   
3. Que dans toutes autres, où des interactions de ce type sont prévues, que ces animations se produisent lorsque ce n'est pas le bon objet qui est employé
   

1. Les animations

On va recycler le code déjà testé, (ici dans le dernier exemple de mon post)
et comme on veut l'employer dans deux contextes différents : 2. et 3. on va créer une fonction globale spécialement pour ça (ce sera plus pratique).

Le rôle de cette fonction est donc de déclencher l'animation par rapport à un objet de l'inventaire. Je l'appelle JSP (pour Je Sais Pas), donc à placer dans le script global.

Code:

function JSP(int iObjet) {
   int iVue = 1; // < ici le n°ID de la View où sont les animations d'objets
   // Utiliser un objet d'inventaire sur n'importe quoi d'imprévu
   if(iObjet <= Game.GetLoopCountForView(iVue)) {
      // execute l'animation
      cEgo.LockView(iVue);
      cEgo.Animate(eEgo.ActiveInventory, 1, 0, eBlock);
      cEgo.UnlockView();
   }
   else {
      // En fait l'animation correspondante n'existe pas
      eEgo.say("Je sais pas le faire...");
   }
}

Je ne recopie pas l'explication, c'est celle où je suggérais de créer une View de ton perso réagissant avec chacun des objets (réactions où il ne sais pas quoi faire avec).
Et pour chaque, que le n° de Loop corresponde au n° de l'objet dans le panneau Explore project : Inventory items

À noter que la liste d'objet commence par 1, et la liste de Loop commence par zéro, donc la première loop n°0 ne serait pas utilisée. Par conséquent je te suggère de créer une animation de plus, où ton personnage a la même réaction mais sans objet. Comme ça, elle pourrait servir dans les cas doublement imprévus (pas prévue dans le jeu, pas prévue dans le script). ça permet de simplifier cette fonction, mais aussi te simplifier un éventuel travail de traduction (vu que mon exemple comprend une ligne de dialogue).

Code:

function JSP(int iObjet) {
   int iVue = 1; // < ici le n°ID de la View où sont les animations d'objets
   int iLoop = 0; // < ici le n°ID de la loop en réaction sans objet

   if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue)) {
      iLoop = iObjet;
   }

   cEgo.LockView(iVue);
   cEgo.Animate(iLoop, 1, 0, eBlock);
   cEgo.UnlockView();
}

Là c'est de façon automatique :  une objet / une animation.
Mais si pour X raisons tu as une exception ou une bidouille à y faire je te met quelques solutions dans le spoil ci-dessous :

Spoiler:

2. Pour déclencher sur des zones où il existe une interaction mais avec un autre objet

C'est le cas de figure qui ne fonctionnait pas jusque là : où tu as créé des events de type Machin_useInv()

Comme tu commence par vérifier si le bon objet est utilisé, il nous suffit de lancer la fonction JSP dans les autres cas (else)
Je résume les exemples que tu as fourni :

Code:

function o7PorteFrig_UseInv() {
   if (cGob2.ActiveInventory == iLime) {
      player.Walk(646, 291, eBlock,eWalkableAreas);
      // etc.
      o7PorteFrig.Clickable=false;
   }
   // Si c'est pas avec iLime
   else {
      JSP(cGob2.ActiveInventory);
   }
}

// ----------------------------------------------------------
function cSommeil_UseInv() {
   if (cGob2.ActiveInventory == iChopeTisane03) {  
      player.Walk (1069, 209,eBlock,  eWalkableAreas);
      //....
      D05ConditionsSortie=D05ConditionsSortie+1;
   }
   // Si c'est pas avec iChopeTisane03
   else {
      JSP(cGob2.ActiveInventory);
   }
}

// --------------------------------------------------------
function h4Brasero02_UseInv() {
   if (cGob2.ActiveInventory == iChopeMetal) {  
      player.Walk (1043, 490,eBlock,  eWalkableAreas);
      //...
      D05ChopeBrasero=1;
   }
   // Si c'est pas avec iChopeMetal
   else {
      JSP(cGob2.ActiveInventory);
   }
}

Tu remarqueras que je passe cGob2.ActiveInventory en paramètre de JSP, plutôt que de le faire dans la fonction globale. C'est complètement volontaire.
Peut-être que ça serait revenu au même, mais en vérité ça dépends du contexte, et ainsi t'es libre de l'adapter quand tu scripte tes fonctions Machin_useInv().
Par exemple :
- si dans ton jeu on change de personnage, ou switch entre plusieurs.
- si pour X raison, tu voudrais choisir une animation différente de l'objet indiqué par ActiveInventory
- et tu peux aussi faire appel à la fonction JSP ailleurs dans ton script, si tu veux utiliser ces animations. (dans une scène de dialogue, dans une cutscene...)

Par exemple tu peux aussi l'employer comme ça : (n'importe où)

Code:

JSP(iChopeMetal);

3. Là où il n'y a pas d'interaction de prévue avec aucun objet d'inventaire

On en reviens à unhandled_event qui fera le taf :

Code:

function unhandled_event(int what, int type) {
    if ((what == 1 && type == 3) || (what == 2 && type == 3) || (what == 3 && type == 3)) {
      JSP(cGob2.ActiveInventory);
   }
}

Il te faudra peut-être revoir les conditions de test des paramètres what / type
Et peut-être arranger si tu opère un changement ou switch de personnage (si on change de cGob2)
Je pense pas que ce soit ton cas, mais je le dis pour prévenir si quelqu'un s'appuie sur cette aide pour un autre projet.

Hello, est ce que ça apporte quelque chose que les anims soient toutes dans la même vue ? Ce qui compte, ce sont les conditions de lancement, et ça simplifierait peut être le biniou. A partir du moment où on a un truc comme ça pour chaque objet (plus la condition de l'objet utilisé):
[code=ags]
cEgo.LockView(iVue);
cEgo.Animate(iLoop, 1, 0, eBlock);
cEgo.UnlockView();
[/code]

Dis moi si c'est utile, auquel cas je ferais comme tu dis.

À moi, ça me parait le plus simple, tel que je m'imagine ton projet, et parce que je m'imagine que t'es plus à l'aise avec la création d'animations que la programmation.
Une fois que c'est en place, si tu es régulier entre ta liste d'objets (Inventory Items) et les loop d'une View dédiée, tu n'auras pas besoin d'intervenir dans le code. Seulement quand tu créé une nouvelle interraction (qui produit un event Machin_useInv()) rajouter à la fin un appel à la fonction JSP lorsque l'interraction ne fonctionne pas avec l'objet. (C'est à dire, après le test if (cGob2.ActiveInventory == iLime) de terminer par un else qui appelle JSP dans l'autre cas)

Mais en effet, je vois un soucis...
Avec AGS dans la liste Inventory Items, tu as la possibilité de supprimer n'importe quel objet, et la liste se compacte (les n°ID changent pour ne pas laisser de trous).
Tandis que dans la section View, tu ne peux supprimer que la dernière loop (ce qui est con)... Du coups ça peut créer des décalages, ou il faudrait supprimer plein de loops, et les recréer pour tout remettre dans l'ordre.

Par exemple, t'aurais créé 5 objets, et les 5 animations correspondantes

1. Tasse
   
2. Marteau
   
3. Baguette
   
4. Chapeau
   
5. Peinture
   

Et disons qu'à ce moment là, tu modifie ton scénario après coups, et tu veux supprimer le marteau : ça va décaler Baguette, Chapeau, Peinture.
Dans la View, tu peux pas supprimer directement. Tu dois recopier/recoller une loop sur l'autre, etc. (bref, c'est chiant)

Dans ce cas là (et c'est un truc qui se faisait "à l'ancienne"), je suggères de ne jamais supprimer d'objet dans Inventory Items (sauf si c'est le dernier de la liste).
Si ça t'arrives de créer un Item, et bien plus tard changer d'avis ou de scénario, bref : que l'objet ne soit plus utile : tu peux supprimer l’interaction (s'il y en a) mais ne pas supprimer l'objet dans la liste. Juste tu le renomme en "iUnused01", tu peux aussi remplacer son sprite par une croix, un carré rouge.
Ainsi quand tu examine ta liste, l'emplacement est conservé (il n'y aura pas de décalage), et tu verras au sprite ou au nom les emplacement inutilisés. Emplacement que tu peux recycler quand tu créera un nouvel objet : il n'y aurait qu'à modifier le nom, le sprite et la loop correspondante. (Et ça éviterait à ta liste de se remplir d'items inutiles, car je crois que la quantité est limitée)

Si cette solution ne te conviens pas, alors il te faudra intervenir dans le script au cas par cas, pour chaque objets, afin de définir quelle loop de quelle view utiliser pour quel objet. Et faudrait le faire pour chaque Event, et pour chaque objet dans unhandled_event. (en fait, tu peux faire sans la solution que je propose, mais alors il faut tout coder dans le script...)
C'est à toi de voir la solution que tu préfères, ou qui t'es la plus facile.

Mon avis, c'est que si t'arrives à maintenir le bon ordre entre une liste de loop (d'une view) et la liste Inventory Item, alors ces exemples de codes fonctionneront une fois pour toutes. T'as plus qu'à te préoccuper de maintenir cette correspondance (et comme j'ai expliqué : recycler les emplacements, si tu fais des changements après coups) et pas oublier d'ajouter un appel à la fonction JSP dans les event d'interraction que tu créé.

En vrai il y aurait mieux et plus simple à faire, si AGS permettait de combiner/superposer des sprites dans des frames d'une loop. Mais il me semble que c'est pas permis.

J'ai l'impression de me redire. Précise moi s'il y a une partie qui te semble pas très claire.

Je ne sais pas, j'ai beaucoup d'objets, déjà plus de soixante dans le premier quart du jeu, ça ferait une view un peu lourde. Enfin, pour le moment il faut que je capte le principe. Je vais m'y mettre.

Ca ne me parait pas bon de lier une view à toutes ces utilisation d'objets, d'autant que les anims utilisent plusieurs views. Par exemple, les animations de sorties et rentrées de poche sont dans des views liées au perso (j'ai plusieurs persos). S'il y a une parlotte, pareil.

Non, je n'arrive pas. Ton principe a l'air de reposer sur 1 objet=1 anim, ce qui ne me convient pas. Mais même, je ne comprend pas ce qu'il se passe, Ags ne prend pas le code.

Si je comprend, on garde ce qu'on avait fait dans la fonction Unhandled_event, qui fonctionne en partie, et on fait du cas par cas dans les zones qui ne fonctionne pas. Est ce ta fonction JSP peut permettre de simplifier le lancement de la bonne anim (suivant l'objet) en laissant tomber les cotés Tout dans la même view et Une seule loop par anim ?

Gob a écrit:

Ton principe a l'air de reposer sur 1 objet=1 anim

Oui mais en fait, c'est dans le cahier des charges, comme tu l'as écris dans le 1er post :

Citation :

(..) quand un perso utilise un objet de l'inventaire sur une zone, et qu'il n'y a rien de prévu pour ça, il lance une animation, sur place, d'utilisation de l'objet, genre il sort l'objet de sa poche et le remet.

Si c'était dans un autre moteur de jeu, je suis bien d'accord qu'on procéderait d'une autre façon. Je pense par ailleurs que dans le moteur des jeux Lucas-Art ils avaient un moyen de faire ça (qui manque cruellement à AGS, à mon avis) : Le moyen par un script de faire un collage d'un sprite dans un autre, et de l'intégrer dans une séquence d'animation. Sinon le moyen (dans le script) de remplacer certaines frames d'une loop.

Si c'était possible de le faire, voici sur quoi je serai parti :
- Créer une seule animation "genre il sort l'objet de sa poche et le remet." mais à vide (sans objet)
- Créer un sprite pour chaque objet (ça c'est bien obligé)
- Lancer l'animation (à vide), et trouver un moyen de coller le sprite de l'objet sur le perso à la frame exacte où il est sensé apparaître
--> ça nécessiterait probablement d’apparaître sur plusieurs frames, à des positions X|Y qui varient un peu... C'est du peaufinage, mais ça se fait.

Bref, ce serait une autre version de la fonction JSP qui ferait ça, en calculant la position du sprite et les moments où l'afficher.
Je crois pas que ce soit complètement impossible à faire dans AGS, mais je sais pas si ça demande d'aller dans le "dur" (Plug-in, API...) ou si c'est du niveau de la bidouille (employer des choses qui sont pas conçues pour ça normalement). Ou même si on pourrait le faire en hackant certains trucs, mais ça peut créer des soucis de compatibilité...

J'ai pas assez d'expérience d'AGS pour voir ça, mais même (si on trouvait) ça me semble déjà très compliqué à passer et faire comprendre dans un topic de forum.

Citation :

ça ferait une view un peu lourde.

À moins que tu me dises que ton PC rame quand t'ouvre la vue dans l'éditeur, en théorie ça ne change rien en définitive (pour le jeu final).
Pour l'économie il s'agit juste d'éviter de démultiplier les sprites. Ces séquences d’animations se composent en 3 parties :
- Sort quelque chose de sa poche
- La chose apparaît dans la main
- Range quelque chose dans sa poche

Faut trouver une astuce graphique pour que la 1ere et la 3e fonctionne pour tous les objets, et pour minimiser le nombre de sprites dans la 2e. (mais il y en aura forcément au moins 1 par objet, sinon tu renonces à l'idée initiale)

Après, tu peux tout à fait ajouter 2 loop dans ta View principale :
- Sort quelque chose de sa poche
- Range quelque chose dans sa poche

Et ne mettre dans la View dédiée à l'affichage des objets que la partie centrale :
- La chose apparaît dans la main

Puis t'adaptes le script d'animation de la fonction JSP.
Disons que la 10e et la 11e loop de ta view principale soient les annimation de sortie/rangement de poche :

Code:

function JSP(int iObjet) {
   int iVue = 1; // < ici le n°ID de la View où sont les animations d'objets
   int iLoop = 0; // < ici le n°ID de la loop en réaction sans objet

   if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue)) {
      iLoop = iObjet;
   }

   cEgo.Animate(10, 1, 0, eBlock); // < n°10 sort de sa poche
   cEgo.LockView(iVue);
   cEgo.Animate(iLoop, 1, 0, eBlock); // < montre l'objet
   cEgo.UnlockView();
   cEgo.Animate(11, 1, 0, eBlock); // < n°11 range dans sa poche
}

Tu pourrais même rajouter (après) une autre séquence où ton perso fait non de la tête, ou prend un air de "j'ai pas compris". (Dit une passant : une animation qui peut te resservir à d'autres chose : dialogues, cutscenes...)

Le principe (pour les objets d'inventaire) de tout mettre dans la même View, est de permettre que ça fonctionne pour la fonction Unhandled_event, pour qu'elle soit en mesure de "deviner" où trouver la bonne séquence en fonction de l'objet actif.

Tu pourrais les ranger différemment, et dans ce cas il faudrait créer dans le script global un tableau (comme un sommaire) qui permettrait de relier pour chaque n°ID d'objet, le n°ID de View et n°ID de loop qui correspond. Et ce tableau, il te faudra l'entretenir.

Mon idée de tout ranger dans une même view est de t'épargner cette tâche. Enfin que ces loop soient rangées en bon ordre dans une seule view, ou dispersées dans n'importe quelle view, ne fait pas de différence dans le poids final, dans la mesure où la quantité est la même. Donc franchement, je m'en inquiéterai pas. Avec la fenêtre View de l'éditeur tu peux avoir la liste de tes loop, et la liste d'objet dans le panneau Explore projet, sur le même écran.

Peut-être que tu t'inquiètes, parce que tu vois la View comme un dossier rempli de plein de fichiers (plus que la moyenne de tes view). Mais ça ne pose pas de problème pour le moteur du jeu s'il sait trouver ce qui lui faut dedans à un moment T. Par contre, l'alternative de compartimenter le tout, et devoir passer par un tableau de données pour que le moteur du jeu les retrouve a un coût. Car quand on joue au jeu, ce tableau devra être stocké en mémoire en permanence.

Oui je pense que tout rassembler en une view, c'est ce qui rationalise au mieux l'ensemble. C'est ce qui fait l'économie en mémoire vive dans l’exécution du jeu (stocker une grosse variable "sommaire/référentiel"), et réduit le nombre de lignes de script à exécuter dans la majorité des situations.

Après, si ça ne fonctionne pas à l'état actuel, j'ai peut être fait quelques erreur dans les codes. J'ai pas de projets AGS assez avancés pour tester et débug ça de mon côté. Si tu peux me retourner d'éventuels messages d'erreur ou console, je pourrais essayer de trouver. Sinon, c'est chaud de deviner.

Est-ce que t'aurais un projet AGS quelconque, du genre un projet qui te sert à faire des test ou un projet abandonné. Où il y aurait déjà une dizaine d'objets, un perso, une Room, que tu pourrais m'envoyer ? (Un wetransfert par MP)

Juste une base un peu plus fournie que les template d'AGS. Comme ça je pourrais essayer d'intégrer ces scripts, vérifier ce qui fonctionne/fonctionne pas, corriger.
Et je pourrais te le renvoyer ensuite pour te servir d'exemple. Ou bien ça m'aiderait à chercher une autre solution si vraiment ça ne fonctionne pas.

Hello, pour préciser, ce n'est pas juste sortir l'objet, le rentrer, le but c'est qu'il y ait une anim rigolote pour certains objets, une plus simple pour d'autres et une générique (non non ou autre) pour les objets les moins intéressants. La loop unique par utilisation d'objet n'est pas trop possible non plus pour la sonorisation, c'est souvent plus simple de séparer l'action en plusieurs loops, surtout que la fonction de lier un son à une frame de la loop marche jusqu'à un certain point, j'ai eu de gros bugs avec ça.
Oui, il faudrait que je te fasse un fichier spécial pour tester, peut être à partir de mon dernier jeu, mais ça va me prendre du temps, je verrais.
Je ne vois toujours pas l'avantage de mettre tout dans la même view.

Que veut dire exactement ce code :

if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue))

Le problème principal est plutôt d'automatiser, sans avoir à rajouter du code au cas par cas pour chaque zone...

Ce code :

Code:

if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue))

C'est juste une sécurité / précaution.

Explication sur les types de variables:

Bref résumé du spoil ci-dessus, la valeur de l'objet actif comme :

Code:

eEgo.ActiveInventory

est un nombre qui correspond au n°ID de l'objet.

Dans la logique que je propose de correspondance entre les n°ID d'objets, et les n°ID des loop d'une vue, cette précaution vise à éviter un bug ou plantage du jeu si jamais à un moment de test ou dans la version finale de ton jeu, il y aurait plus d'objets que de loop (que t'aies oublié d'en mettre, ou que ce soit pas nécessaires..)
Sans ça, si par exemple tu utilise l'objet n°60 de l'inventaire, et que dans la vue il n'y a que 50 loop, le moteur chercherait la loop n°60 qui n'existe pas, et alors bug sinon plante.

Code:

if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue))

Signifie :  si ne n° de l'objet est un nombre entre 0 et le nombre total de loops dans cette view.
J'aurais préféré tester directement si une loop existe, mais j'ai pas l'impression que ça existe. Enfin ce test là est censé fonctionner pareil.

---

Citation :

La loop unique par utilisation d'objet n'est pas trop possible non plus pour la sonorisation, c'est souvent plus simple de séparer l'action en plusieurs loops,

Oui, et je conseillais pas de faire ça.
Seulement pour la partie de l'animation où l'objet apparaît. Et outre que ça convienne bien au script que je propose, je pense que c'est également plus pratique pour toi, car si tu dois décomposer la partie de l'animation où l’objet apparaît en plusieurs loop, t'es pas sorti de l'auberge. Si t'as déjà 60 objets à 25% de ton jeu, t'aurais déjà dans les 120 ou 180 loops à produire.

Comme l'exemple modifié que je t'ai donné :

Code:

        function JSP(int iObjet) {
           int iVue = 1; // < ici le n°ID de la View où sont les animations d'objets
           int iLoop = 0; // < ici le n°ID de la loop en réaction sans objet
        
           if(iObjet >= 0 && iObjet <= Game.GetLoopCountForView(iVue)) {
              iLoop = iObjet;
           }
        
           cEgo.Animate(10, 1, 0, eBlock); // < n°10 sort de sa poche
           cEgo.LockView(iVue);
           cEgo.Animate(iLoop, 1, 0, eBlock); // < montre l'objet
           cEgo.UnlockView();
           cEgo.Animate(11, 1, 0, eBlock); // < n°11 range dans sa poche
        }

Tu peux ajouter ce que tu veux avant et après, ou intercaler cette partie comme ça te conviens :

Code:

           cEgo.LockView(iVue);
           cEgo.Animate(iLoop, 1, 0, eBlock); // < montre l'objet
           cEgo.UnlockView();

En résumé, l'idée c'est qu'à la fin de cette fonction tu scripte une animation générique, et le rôle de la fonction est de paramétrer le morceau qui doit correspondre à un l'objet concerné. (en profitant de la correspondance entre le n°ID de l'objet, et le n°ID des loop d'une view dédiée à ça).

Après, tu peux avoir/vouloir des cas particulier, et dans ce post : j'avais mis dans un spoiler des manière de faire pour tester et traiter ça.

---

Citation :

Je ne vois toujours pas l'avantage de mettre tout dans la même view.

Citation :

Le problème principal est plutôt d'automatiser, sans avoir à rajouter du code au cas par cas pour chaque zone...

C'est ça l'avantage.
Vois cette View comme une liste de loops. Elle correspondrait à la liste d'objets. Donc il n'y aurait pas besoin de code au cas par cas pour que ça fonctionne.

---

Citation :

Oui, il faudrait que je te fasse un fichier spécial pour tester, peut être à partir de mon dernier jeu, mais ça va me prendre du temps, je verrais

En fait, ce qui me faudrait, c'est d'avoir le même modèle que tu utilises : pour le menu d'inventaire, pour le système pointer/cliquer (si t'utilise le verbcoin, ou autre... je sais pas). Juste une base qui fonctionne avec le même système.
Pour le contenu, tu peux laisser le personnage par défaut d'AGS. Pas besoin de Room, d'objet, décors... Si tu peux en glisser dedans c'est un plus, mais je peux aussi bricoler ça de mon côté c'est pas un soucis. Je peux créer des objets au pif, faire des décors/perso dessinés sous paint, ou copier/coller des schtroupfs (on s'en fout, t'inquiètes pas)

Par contre, si t'as déjà un prototype d'animation de perso, qui sort un objet de sa poche et le rentre : ça vaut le coups que tu l'y mette.
Si t'as scripté une séquence d'animations qui correspond à ce que tu voudrais obtenir, ça vaut aussi le coups que tu l'y mette, ou me la passe par MP ou dans ce topic. Comme ça je peux me coller à ça.

Si je te demande ça, c'est pour que ce soit plus facile pour toi en retour. Que tu puisse t'y retrouver, et savoir comment l'intégrer et l'adapter dans ton propre projet.
Si je partais de mon côté avec un modèle différent de P&C (comme le 9words) qui est trop différent du système sur lequel tu travailles, t'aurais probablement des soucis.

Faut aussi que j'anticipe que t'es peut-être pas sur la même version que moi d'AGS. Il y a peut-être des incompatibilités. Désolé j'ai pas fait attention à ça. Je suis sur la dernière version stable 3.6.0 et mis à jour le dernier patch.
Si tu peux m'envoyer un truc, je pourrai m'adapter à ta version et ton modèle de jeu. On économisera beaucoup de blabla. (Déjà que j’envoie du pavé facilement...)

En fait le jeu est déjà avancé, j'ai pas mal d'anims d'objets de faites et elles sont toujours composées de plusieurs loops, faisant appel à plusieurs views. Je ne reviens pas là dessus. Je ne comprend toujours pas ni l'utilisation ni l'utilité de ta fonction JSP. Comment est elle utilisée dans le cas des utilisations non prévues d'objets sur les zones où il y a des utilisations d'autres objets prévues ? Est ce que tu dois rajouter une ligne de code ?

Pour l'instant je n'ai pas le courage de t'envoyer un bout du jeu. Quand je supprime les rooms sauf une, le jeu ne part plus.

J'utilise la 3.6.0 aussi, je ne sais plus si j'ai mis le patch.

Désolé si j'arrive pas à faire comprendre.
C'est pas grave pour le modèle. Je demandais si t'avais un prototype sous le coude. Si t'en a pas et que tu peux pas en fagoter un facilement laisse tomber.

Je pourrai me débrouiller avec un template, ça sera plus clair.

Une dernière explication pour la route !

---

La fonction JSP doit être ajoutée dans unhandled_event à la condition des combinaisons de what/type.
Elle doit être ajouté aussi à la fin de chaque script d’interactions d'objets que t'as programmé sur des objets, des zones, des personnages, après le if, à la condition autre (else).
Parce que si t'as programmé une interaction, que ça produise quelque chose à l'écran ou non (parce que c'est pas l'objet attendu), c'est pas considéré comme un unhandled_event par le moteur du jeu. Lui il a exécuté la fonction, mais si ça ne produit rien, de son point de vue le job est fait. unhandled_event ne s'éxécute que si la fonction d'interraction n'existe pas.

Par exemple, t'as programmé qu'on peut donner le lézard à un personnage : après le

Code:

if(eEgo.ActiveInventory == iLezard) {

de ce script il faut que tu ajoutes cette ligne :

Code:

} else { JSP(eEgo.ActiveInventory); }

C'est à dire :
- Soit l'objet est le bon : il se produit ce que tu a prévu.
- Sinon il lance la fonction JSP

Je dis pas de mettre toutes tes animations dans une même view : uniquement la partie spécifique à l'objet.
Sans ça, il te faudra tout le truc pour chaque objets. Par exemple pour 60 objets, ça serait un truc du genre :

Code:

function JSP(int iObjet) {
   if(iObjet == iLezard) {
      cEgo.Animate(10, 1, 0, eBlock);
      cEgo.LockView(2);
      cEgo.Animate(5, 1, 0, eBlock);
      cEgo.UnlockView();
      cEgo.Animate(11, 1, 0, eBlock);
   }
   else if(iObjet == iCup) {
      cEgo.Animate(10, 1, 0, eBlock);
      cEgo.LockView(3);
      cEgo.Animate(8, 1, 0, eBlock);
      cEgo.UnlockView();
      cEgo.Animate(11, 1, 0, eBlock);
   }
   else if(iObjet == iKey) {
      cEgo.Animate(10, 1, 0, eBlock);
      cEgo.LockView(4);
      cEgo.Animate(7, 1, 0, eBlock);
      cEgo.UnlockView();
      cEgo.Animate(11, 1, 0, eBlock);
   }
}

Note que là j'en ai fait que 3, il en faudrait 60 au total.

Si t'as déjà fait d'une autre manière pour un certain nombre d'objets, c'est pas grave. C'est possible de mixer les 2 solutions. 1 pour les objets que t'as déjà animé et dont tu veux pas déplacer les loops, et l'autre façon pour les prochains (si tu changes d'avis).

Après je veux bien réfléchir à un autre moyen. Là dans l’abstrait je peux pas trouver, j'ai juste proposé la solution la plus simple.
Tu me dis que tu as déjà ta façon de trier tes view et les loops. Si c'est une façon méthodique et régulière, alors c'est peut-être possible de le traduire dans le code.

Je t'explique le problème : au moment où ça se déclenche, la seule info dont on dispose c'est ne n° de l'objet utilisé. Il faudrait que ce n° suffise pour deviner le ou les n° de la view et des loop à utiliser.