Pour mieux comprendre cela, nous devons tout d'abord nous pencher sur le fonctionnement du moteur de script AGS. Lorsqu'un jeu AGS est lancé, il y a trois files de script qui peuvent être exécutées. Figurez-vous une file comme un mini-CPU (processeur) qui exécute vos scripts.
Au début du jeu, toutes les files sont inactives (aucun script n'est lancé) :
Ensuite, puisqu'il faut bien que les scripts soient exéctués, AGS tentera de les lancer chacun dans la file appropriée (la file Room pour les scripts locaux, et la file Global pour les scripts globaux).
Ainsi, au premier cycle de jeu, les repeatedly_execute de vos scripts globaux seront lancés :
Voilà qui est fait, et lorsque l'exécution est terminée, la file redevient inactive.
Mais supposez que dans repeatedly_execute, vous appeliez une commande Character.Say. Say (ou DisplaySpeech dans l'ancien style de script) est une commande bloquant l'exécution et ne retourne qu'une fois que le personnage a fini de parler :
La file globale est désormais bloquée, attendant que le personnage ait fini de parler. Cela signifie qu'aucune de vos fonctions de script global comme repeatedly_execute, on_event et on_key_press ne pourront être lancées tant que le personnage parlera, puisque la file est occupée.
AGS place jusqu'à 5 fonctions en attente à la fin de la file, qui seront lancées dès que la file ne sera plus occupée ; mais si votre script occupe la file un certain temps, il est possible que vous passiez à côté de certains événements comme on_event et on_key_press.
Voyons la situation qui pose généralement le plus problème. Supposez que vous ayez une interaction Player looks at inventory sur un objet d'inventaire Key, qui appelle un script afin d'afficher un message.
Supposez aussi que vous ayez du code à la fin de votre fonction on_mouse_click pour que le personnage reste où il est suite à tout clic interactif.
Vous remarquerez alors que le code qui se trouve à la fin de on_mouse_click est appelé avant l'interaction sur l'objet d'inventaire. Regardons pourquoi :
Rappelez-vous qu'AGS ne lance pas les interaction automatiquement ; en fait, la fonction on_mouse_click gère les clics de souris et appelle la fonction ProcessClick pour lancer l'interaction appropriée. Le moteur trouve alors que l'interaction associée à l'objet Key est une commande Run Script.
Mais, oh non ! Le script concernant l'objet d'inventaire se trouve dans le script global, et la file globale est déjà bloquée à cause du clic de la souris. C'est pourquoi le script correspondant à l'interaction sur l'inventaire est ajouté à la fin de la file, et que la fonction on_mouse_click finit alors son exécution. Le script d'interaction sur l'inventaire suivra ensuite normalement.
Vous pensez alors peut-être que les interactions d'objets et de hotspots peuvent être lancés à l'intérieur de on_mouse_click, puisqu'elles se trouvent dans la file de la pièce, de cette façon :
Cependant, ce n'est pas le cas. C'est là encore la file globale qui appelle ProcessClick, de façon à ce que le script de la pièce soit en fait exécuté dans la file globale, dès que celle-ci sera libre.
Pour finir, nous arrivons à la file No-Block. Cette file n'est utilisée que pour lancer la fonction repeatedly_execute_always. Vu que repeatedly_execute_always n'est pas autorisée à lancer de fonction bloquant l'exécution, on est assuré que la file ne sera jamais bloquée et s'exécutera donc toujours correctement, même si les autres files sont occupées :
J'espère que cette aide explique le blocage de façon à correspondre au scripting AGS. Si vous trouvez que quelque chose n'est pas clair, vous pouvez proposer de l'améliorer sur le forum Technique.