La Couronne de Cuivre

D'après ce que j'ai lu, il semble bien en effet que les scripts soient parcourus dans un ordre précis. Je crois que le parcours successifs des scripts s'interrompt dès qu'une condition IF est vérifiée. Les actions correspondantes sont lancées et le parcours des scripts est alors censé reprendre au début du premier script. Il me semble que le jeu cycle au rythme indiqué dans le programme BGConfig dans le paramètre Taux de rafraîchissement des options AI.
C'est d'ailleurs ce qui faisait dire à certains concepteurs de script que certains écrivaient des scripts qui trichent vis à vis des règles du jeu, notamment vis à vis des sorts (normalement, un seul sort par round, donc toutes les 6 secondes), en n'introduisant pas de pause (par un timer) entre deux sorts.

La logique des scripts est à priori d'avoir les cas les plus importants dans le premier script, de façon à ce que la réaction soit la plus rapide et qu'il y ait peu de chances qu'une condition plus prioritaire ait empêché d'atteindre ce point.

Du coup, la présence du soin en début de script lui donne une priorité importante par rapport aux attaques. Comme le script tourne en permanence, ce n'est pas une question de début de combat, mais plutôt de début de round voire encore plus souvent.

Le tutorial de SimDingo a plutôt bonne réputation. Peut-être est-il clair sur ce point ? Par ailleurs tu trouveras aussi peut-être des infos dans d'autres tutorials sur le même site, voire même dans la doc du compilateur Bioware.

D'ailleurs, voici un petit extrait qui pourrait expliquer des choses :

There are a several 'default' scripts which run all the time in the various games.
In all games, the DPLAYER scripts are present. Of these, the important ones are DPLAYER2.BCS, which is assigned to all party members on joining, and DPLAYER3.BCS, which runs on the protragonist. However, these scripts are deactivated when the party AI is turned off.
In the Baldur's Gate games, BALDUR.BCS (and BALDUR25.BCS in ToB) are also present. They have no specific object (and as such, local variables do not work in them), but run all the time.
Finally, PLAYER1D.BCS runs whenever the party rests, in a similar way to the NPC entries in PDIALOG.2DA.

Ma suggestion d'utiliser DPLAYER2 a peut-être été la cause de certains de tes problèmes si l'IA n'était pas active.

Si une action prend du temps (attaquer, lancer un sort, se déplacer), l'exécution du script ne reprend apparemment qu'après la fin de la ou des actions.

Dans le tutorial, peut-être l'auteur faisait-il référence au fait que le script ne repartait pas de lui-même, mais qu'il était soumis à la période de rafraîchissement et au fait que le personnage n'était pas déjà lancé dans une action.

L'intérêt du continue(), c'est aussi d'éviter de boucler toujours sur les mêmes actions si les conditions d'un des premiers blocs sont vérifiées. D'après le tutorial de SimDingo, c'est surtout utile pour scripter les combats.

Si, les scripts se terminent fréquemment. Un script de personnage de l'équipe contient notamment les tests spécifiques aux interactions, aux quêtes, ... basés sur des conditions qui ne sont pas toujours vérifiés (souvent, ils n'ont rien à faire). C'est surtout lors d'un combat que des conditions se trouvent facilement vérifiées. Tu trouveras dans certains scripts un test sur True(), justement lorsque le personnage n'a rien d'autre à faire, pour lui faire faire les cents pas par exemple.