Vous verrez certaines commandes listées comme “bloquant l'exécution”, où l'exécution du script est
bloquée jusqu'à ce que la commande soit accomplie. Mais qu'est-ce que cela signifie, exactement?
Afin de mieux comprendre cela, nous avons besoin d'explorer un peu plus la façon dont
le moteur de script AGS fonctionne. Dans un jeu AGS, il y a trois fils (threads) de script
qui peuvent être en cours d'exécution à la fois. Pensez à un fil comme un mini-processeur
qui exécute vos scripts.
Au début du jeu, les fils sont tous en attente (ils n'exécutent aucun script) :
Maintenant, au fur et à mesure que vos scripts doivent être exécutés, AGS va essayer
de les exécuter sur le fil approprié (fil de la pièce pour les scripts locaux , et fil global
pour les scripts globaux).
Donc, lors de la première boucle du jeu votre script global repeatedly_execute va etre exécuté.
et une fois l'exécution finie, le fil redevient passif à nouveau.
Mais supposons que dans votre repeatedly_execute, vous appeliez la commande Say.
Say (ou DisplaySpeech dans les anciennes versions) est une commande bloquant l'exécution
et ne se termine que quand le personnage a fini de parler.
Le fil global est maintenant bloqué , attendant que le personnage ait fini de parler.
Cela signifie qu'aucun de vos scripts globaux tels que repeatedly_execute, on_event ou on_key_press
ne va être exécuté tant que le personnage parle. Le fil est bloqué.
AGS empile jusqu'à 5 fonctions pour les exécuter sur ce fil dès qu'il se libère ; mais si vous
avez énormement de choses en cours, il est possible de louper des évènements tels que on_event ou des
appuis sur le clavier si votre script est bloqué longtemps.
Regardons la situation la plus commune dans laquelle se pose un problème.
Supposons que se déclenche l'événement Look at inventory item (Regarder l'objet d'inventaire)
qui exécute un code pour afficher un message.
Supposons aussi que vous ayez du code à la fin de votre fonction on_mouse_click pour
que le personnage reste sur place après avoir exécuté les événements de la fonction on_mouse_click.
Vous allez découvrir que le code à la fin de on_mouse_click est en fait appelé avant l'événement correspondant à
l'inventaire. Regardons pourquoi :
Rappelez vous qu'AGS n'exécute pas les événements automatiquement. Plutôt, la fonction
on_mouse_click gére le clic de la souris et appelle ProcessClick pour exécuter
les événements appropriées. Ce faisant, AGS remarque que l'événement Look At Item (Regarder l'Objet d'Inventaire)
de la clé est associé à une fonction.
Mais, oh non ! les scripts des objets d'inventaire sont dans le script global et le fil global
est bloqué à cause de l'appel de on_mouse_click. Donc, le script appelé lors de l'événement avec
l'objet d'inventaire est ajouté à la pile du fil et on_mouse_click finit de s'exécuter. Le
script d'événement avec l'inventaire suivra après.
Vous pourriez penser que cela signifie que les événements avec les objets et les zones interactives (hotspots)
peuvent s'exécuter à l'intérieur de on_mouse_click, vu qu'ils utilisent le fil de la pièce,
comme ceci :
Cependant, ce n'est pas le cas. C'est toujours le fil global qui apelle ProcessClick,
donc le script de la pièce va en fait être exécuté sur le fil global quand celui-ci
sera libéré.
Finalement, nous arrivons au fil No-Block. Ce fil est uniquement utilisé pour exécuter la fonction
repeatedly_execute_always. Parce que repeatedly_execute_always n'est autorisée à
exécuter aucune fonction bloquante, ceci garantit que ce fil ne sera jamais bloqué et tournera
toujours, même si les autres fils sont bloqués.
J'espère que cela aide à expliquer les blocages de scripts dans AGS. Si ce n'est pas clair, parlez-en sur le forum technique.