[SCRIPT] Quelques questions sur l'ordre d'exécution des scripts

[ferrumach]

Un script est lu de haut en bas , le END final clot le script etau début (d'après qq tutoriaux), tant qu'une condition (IF) est vérifiée le script reste sur le même bloc (pour simplifier).

QUESTIONS :

1) Que se passe t-il ensuite, par exemple lors d'un combat lorsque le script affecté à une créature ennemie arrive à la fin ?
J'ai lu qu'il y a 7 scripts, pour par exemple une créature : d'abord celui d'override, puis area, specific,race ,classe, puis défaut (je crois que c'est l'ordre) donc rapport avec ma question les scripts (lorsqu'ils existent) sont lus l'un à la suite des autres ?
Et ensuite (il y a un schéma très explicite avec des flèches dans un tutorial fait par un certain simdingo sur TeamBG) que se passe t-il, la créature reste "bloquée" sur le dernier script (DEFAULT) ?

Un exemple (en français) est donné dans un tutorial : celui du script d'un dragon rouge, le 2eme bloc (le 1er il se met une peau de pierre) (il y 14 blocs) raconte:

"Si je ne vois pas de Personnages Joueurs et que mes points de vie sont en dessous de 50 alors je me lance un sort de guérison de prêtre"

On est au début du combat, cela m'étonnerait qu'il ait moins de 50 HP, donc (dans la plupart des cas) le script passe au 3eme bloc, à noter c'est le seul bloc qui lui permet de se soigner... et comme le script n'est pas relu il ne pourra plus se soigner..

a) quel intérêt de mettre un "bloc soin" dés le 2eme bloc ? Et dans la pratique j'ai déjà vu Firkkrag se lancer des guérisons après un certain temps de combat, si qq peut m'expliquer.
Merci

Édit : comment fait on pour jouer en mode fenêtré (utile pour faire des tests), j'ai du mal avec la commande -w ?

[Walar]

Je ne pourrais pas t'expliquer techniquement. Mais le script "tourne" en permanence quand la créature est présente. Il y a aussi l'exemple des potions, si le script ne se lisait qu'une fois les créatures ne les utiliseraient qu'une fois ou même pas du tout (selon les conditons).

J'ai lu qu'il y a 7 scripts, pour par exemple une créature : d'abord celui d'override, puis area, specific,race ,classe, puis défaut (je crois que c'est l'ordre) donc rapport avec ma question les scripts (lorsqu'ils existent) sont lus l'un à la suite des autres ?

Je me sers toujours du script d'override moi (c'est rare tout de même d'avoir besoin de plusieurs scripts pour une créature, c'est plutôt dans le jeu original qu'il y a ça). Quand aux ordres d'exécution il y en a mais je ne saurais le dire par coeur... Mais les scripts tournent en permanence quand la créature est là... Mais dans un script lui-même, les trucs du haut se déclencheront d'abord (si les conditions sont réunies).

On est au début du combat , cela m'étonnerait quil ait moins de 50 HP, donc (dans la plupart des cas) le script passe au 3 eme bloc, a noter c'est le seul bloc qui lui permets de se soigner...et comme le script n'est pas relu il ne pourra plus se soigner..
a) quel intéret de mettre un "bloc soin " dés le 2eme bloc?, et dans la pratique j'ai déja vu frikrag se lancer des guérisons après un certain temps de combat , si qq peut m'expliquer

Je viens d'y répondre. Je sais cependant qu'il y a un ordre préférentiel pour mettre les commandes dans un script, Isaya l'avait dit récemment. En tout cas moi au début j'ai tendance à poser les variables.

Enfin je dois dire clairement que je ne me suis pas trop embarrassé de tutoriels sur les scripts et j'ai un peu fait par moi-même surtout en regardant comment faisaient les autres.

[ferrumach]

Les scripts tournent en permanence : le taux de rafraîchissement de l'IA définie dans le programme de config détermine le rythme de répétition (typiquement 30 fois par seconde).
Une itération du script s'arrête dès qu'elle trouve une condition de remplie. La fois suivante, l'évaluation des conditions reprendra normalement depuis le début. Je crois que la commande Continue() permet de continuer depuis le point atteint.

citation d'ISAYA

Le tutorial ne dis pas vraiment cela....
je cite le tutorial fait par un certain ( misdrha'al ), section 3)

Le script est lu par le moteur de haut en bas..une fois la dernière condition finie il ne repart pas pour un tour.... il est dit exécuté

Bon il y a peut etre une nuance....
(mais laquelle ?), enfin la pratique du jeu me conforte vers l'explication de walar et d'isaya...

merci d'avance

[Isaya]

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.

[ferrumach]

Très intéressant+++

Pour etre clair, je vais prendre un exemple:

1)Prenons un script avec 14 blocs: le 1,2,et 3éme aucune des conditions ne sont vérifiées ( donc le moteur passe à la suivante) , le 4 ème IF marche donc response (actions) ET le moteur repart au 1 er bloc
Tout ceci fait avec une itération de 30 par seconde, si le paramètre choisi est 30 c'est juste ?
(je comprends mieux alors l'interet du continue())

Donc en théorie un script n'est jamais terminé (tant que le perso est vivant )puisqu'il faudrait que tous les blocs soient faux.

Quant au tutorial de simdingo il est très bien fait ( le seul problème c'est l'anglais)
le schéma est très explicatif ( je le conseille vraiment pour comprendre comment un script est lu par le moteur). C'est plutot la phrase que je cite de l'auteur du tutorial en francais que je ne comprends pas (cf)

Merci en tout cas isaya pour les explications, je préfère avoir une vue d'ensemble que betement modifier des scripts sans savoir les mécanismes globaux.

[Isaya]

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.