Scripter pour les débutants

[soifran]

Gronichonha à toutes et à tous.
Bon, comme promis, je balance la traduction de cette pépite du wiki de bethesda...
C'est trés long, mais au final trés bien expliqué.
J'y ai rajouté de nombreux commentaires, car des fois, l'auteur semble oublié qu'il s'adresse à des néophytes.
Je vais poster ci-aprés la version pdf, imprimable puis une version site.
Ce poste est trés largement à mettre en rapport avc ma précédente traduction:

Tutoriel de quête et de dialogue

Il faut dans le principe d'abord mieux lire celui ci, histoire de s'impregner de l'esprit du scripting avant de passer à tout autre tuto de script de quête de base.
En effet, si vous attaquez directement sur les tuto ou on vous montre comment faire une quete de abse, vous ne saurez au final que faire des quete de base, et encore, a mon avis sans comprendre pourquoi vous écrivez telles ou telles choses, et pourquoi il faut l'ecrire de la sorte.
Bon courage.
Je précise une dernière chose, aprés avoir traduit et compris ces deux tuto, je sais maintenant faire des quetes, issues de dialogue ou de rentrer dans un lieu, ou bien lors de la saisi d'un objet, etc,etc...
Bonne lecture.

Soifran

[ATTACH]2687[/ATTACH]

[soifran]

(En cours d'habillage)

Scripter pour les débutants
Depuis le Geck, traduit par Soifran
Avertissement
Ce tutoriel a été hébergé dans de multiples endroits, et les informations contenues dans chaque version peuvent différer.
Pour voir les autres versions, consultez les liens externes en bas de cet article
Introduction
Ce tutoriel s’adresse aux personnes qui veulent apprendre les bases du script dans fallout 3, mais qui n’ont pas une
expérience majeure en programmation. Si cela est votre cas, alors espérons que vous trouverez ce tutoriel utile. Avant
de commencer il y a quelques petites choses que nous devons aborder:

1. Le langage de script utilisé dans fallout 3 n’est pas sensible à la case. Cela signifie que vous pouvez avoir un
script parfaitement bon avec des instructions abrégées, C’est une bonne idée d’essayer de standardiser votre écriture,
ainsi cela permettre de rendre votre script plus facile à lire.

2. Ce tutoriel assume le fait que vous connaissez les base du, ou d’autres outils capable de créer et d’éditer les
fichiers de données de Fallout 3. Si ce n’est pas le cas, alors je vous recommande de jeter un œil au tutoriaux officiel du
pour vous familiariser avec avant de commencer ce tutoriel.

3. Si vous ne comprenez pas certaines terminologies employées dans ce tutoriel, vous pouvez consulter le
glossaire à la fin dette page.

Maintenant commençons si vous le voulez bien? La première que nous avons besoin de savoir à propos du scritpage sur
fallout 3est que chaque script, excepté pour les scripts de résultat (petit fragment de script attaché à une quête et
certains autres objets) doivent démarrer avec une déclaration de ScriptName, qui dénomme l’EditorID du script.

Par exemple:

ScriptName MyFirstScript

Si vous regardez à l’intérieur de certains scripts existant dans fallout3.esm, vous noterez probablement que bon nombre
d’entre eux utilise scn au lieu de ScriptName. Ceci est parfaitement toléré, puisque scn est l’abréviation de ScriptName.
Cela signifie que vous pouvez juste utiliser ceci pour la déclaration de votre nom de script:

Scn MyFirstScript

Félicitations, vous venez d’écrire votre premier script!
Bon d’accord ce n’est pas transcendant –cela ne fait ni ne modifie absolument rien pour le moment.
Pourquoi ne ferions nous pas quelque chose avec ceci?
Editons ce script pour qu’il déclenche l’affichage du texte "Hello World!" lorsque vous prenez une pince à cheveux.
La fonction que nous allons utiliser pour afficher ce message est appelée ShowMessage, mais avant de la mettre dans le
script nous devons lui dire à quel moment l’exécuter, ce qui sera dit par l’utilisation des bornes Begin/End (encore une
fois excepté pour les script de résultat).
Pour chaque frame (image à l’écran) durant laquelle un script tourne, les conditions de chaque borne Begin/End sont
vérifiées séquentiellement du haut vers le bas. Si la condition spécifique est vrai, alors le code contenu à l’intérieur des
bornes Begin/End s’exécutera, autrement le script ne se lancera pas pour cette image.
Comme vous pouvez le constater, il y a essentiellement des conditions d’instruction très spécifique.
Parce que nous souhaitons que notre code se déclenche alors qu’une épingle à cheveux est mise dans l’inventaire du
joueur, nous attacherons le script à la forme de l’épingle à cheveux (EditorID Lockpick), et notre bloc Begin/End utilisera
le bloc de type OnAdd, et utilisera le joueur comme paramètre:


ScriptName MyFirstScript

Begin OnAdd Player

End

Dans un premier temps, pour attacher notre script à la forme « épingle à cheveux », nous devons spécifier de quel type
de script il s’agit. 0 l’exception des scripts de résultat (Result scripts), tous les autres sont divisés en trois catégories
(consultez le glossaire pour les descriptions):

• Object

• Quest

• Effect

Parce que nous souhaitons l’attacher à une épingle à cheveux qui est un élément de type Misc Item (objet divers), il
devrait être spécifié comme étant un script d’objet.
Comme mentionné plus tôt, la fonction que nous allons utiliser dans le script sera ShowMessage. Cependant avant que
nous puissions utiliser cette fonction, nous avons besoin de créer un élément message pour l’utiliser en tant que paramètre.
Cette élément message devrait avoir sa case Message Box désactivée, et devrait avoir d’écrit "Hello World!" dans le champ Message Text. Donnons lui l’ID suivante "MyMessage".
Maintenant que nous avons paramétré un message à utiliser, nous pouvons utiliser la commande ShowMessage dans
notre script dans le but de le faire apparaître:


ScriptName MyFirstScript

Begin OnAdd Player

ShowMessage MyMessage

End


Maintenant, si ce script est attaché à l’entité épingle à cheveux (bobby pin), "Hello World!" sera affiché dans le coin
supérieur gauche de votre écran lorsque l’épingle à cheveux sera ajoutée à l’inventaire.

Les instructions conditionnelles

Pour le moment, le code contenu à l’intérieur de notre script s’exécutera uniquement si une épingle à cheveux est
ajoutée à l’inventaire du joueur. C’est bien joli, mais si nous voulons faire apparaître un autre message s’il est ajouté à
l’inventaire d’un autre personnage (actor) autre que celui que nous avons créé pour le joueur ?

Appelons cet autre message "MyOtherMessage", et il dira "Goodbye World!"
Bien sur, nous pourrions y parvenir en ayant de multiples blocs OnAdd, mais alors, nous finirions par avoir des doublons
dans notre script, ce qui est une chose que nous devrions toujours tacher d’éviter.
A la place nous utiliserons une autre fonction, GetContainer, pour déterminer quel personnage (actor) a le l’item scripté
dans son inventaire.
Appeler simplement la fonction GetContainer ne serait pas suffisant, nous allons devoir vérifier sa valeur de retour, et
d’utiliser cette vérification pour déterminer quel partie du script devra se déclencher.
Pour ce faire, nous allons devoir utiliser la fonction d’instruction « if ».
Et l’instruction if est vraiment similaire au bloc Begin/End.
Il commence par le mot clef "If" se poursuit par la condition qui doit être vérifiée, et se finit par le mot clef "endif".
Les instructions "If" sont différentes des blocs Begin/End en ceci que la condition est entièrement défini par vos soins,
à l’inverse d’être choisi depuis une liste de conditions utilisables.
Voici comment nous allons changer notre script pour que le code contenu dans le bloc OnAdd s’exécute en fonction de
quel personnage (actor) prend et ajoute l’épingle à cheveux dans son inventaire.
Mais le message ne sera seulement visible que si c’est le joueur qui prend l’objet:

ScriptName MyFirstScript

Begin OnAdd

if GetContainer == Player
ShowMessage MyMessage
endif

End

Maintenant, comme un bon nombre de personnage ne comprennent pas comment la fonction d’instruction "if" fonctionne,
alors, détaillons un peu cette dernière.
Premièrement, la fonction GetContainer est appelée. GetContainer renvoie la RefID de la référence qui a l’objet scripté
dans son inventaire.
La RefID est la façon dont s’appelle tel ou tel objet dans le langage script FO3.
ID pour identification. Ici comprenez le joueur ou un autre personnage.
Aussi une fois qu’elle est appelée, vous pouvez la visualiser la valeur de retour.
Par exemple, si l’objet scripté est dans l’inventaire du joueur, alors, la fonction GetContainer retournera l’information
RefID du joueur.
Vous pouvez traduire en langage humain de cette façon:

if Player == Player
; Do something
endif

si joueur == joueur
; Faire quelque chose
endif

La deuxième partie de la condition, "==" est un opérateur. L’opérateur "==" renvoi la valeur 1 si les deux arguments sont
identiques, et 0 s’ils ne le sont pas. Donc, parce que "Player" et "Player" sont égaux, la condition résultante est de 1:

if 1
; Do something
endif

Parce que la condition évaluée est vrai (1), le code contenu a l’intérieur de l’instruction "if" s’exécutera. Si, cependant,
GetContainer renvoi la RefID d’une référence autre que celle du joueur, alors la condition sera évaluée à 0, qui est la
valeur fausse, le code à l’intérieur de l’instruction "if" ne se lancera pas.
Maintenant, comme vous pouvez le voir, notre script a pratiquement la même fonctionnalité qu’avant, bien qu’il soit
sensiblement plus efficace.
Ce que nous allons faire maintenant sera d’ajouter une séquence de code alternative si l’objet scripté est mis dans un
inventaire autre que celui du joueur. La façon la plus évidente de faire ceci sera bien évidemment de créer une deuxième
instruction "if", qui vérifiera une autre condition:


if GetContainer != Player
; Do something else
endif

Comme vous pouvez le voir, cette nouvelle condition est exactement l’inverse de celle que nous avons utilisé plus tôt.
Parce que la valeur de retour de GetContainer sera la même dans les deux conditions, nous ne pouvons pas être sur que
seulement une de ces conditions sera toujours évaluée comme vrai. Cela signifie ceci, au lieu de créer une tout nouvelle
instruction "if", nous pouvons utiliser l’instruction "else" (sinon).
Une instruction "else" ne peut seulement être utilisée que dans une instruction "if" donnée et son instruction "endif"
correspondante.
Cela signifie basiquement "Si toutes les conditions principales sont fausses".
Mettons à jour notre script à nouveau, cette fois si pour afficher "MyOtherMessage" si l’épingle à cheveux scriptée est
ajoutée à l’inventaire d’une référence autre que le joueur:

ScriptName MyFirstScript

Begin OnAdd

if GetContainer == Player
ShowMessage MyMessage
else
ShowMessage MyOtherMessage
endif

End

Maintenant quand le bloc OnAdd tourne, la condition "if GetContainer == Player" est vérifiée en premier. Si elle est
évaluée comme vrai, alors la ligne "ShowMessage MyMessage" s’exécutera, et le script ira directement à l ‘instruction
de fin "endif", ignorant complètement la condition "else".
Cependant, si la première condition n’est pas vraie, alors la seconde "else" sera vérifiée. Comme mentionné
précédemment, l’instruction "else" signifie basiquement "Si toutes les conditions principales sont fausses"
– Si une instruction "else" est toujours vérifiée, son code contenu à l’intérieur s’exécutera et toutes les conditions
suivantes seront ignorées.
Maintenant notre script a deux fins possibles. – Si une épingle à cheveux est ajoutée à l’inventaire du
joueur, "MyMessage" sera affiché, et si celle-ci est ajoutée à l’inventaire autre que celui du joueur, "MyOtherMessage"
sera affiché. C’est cool, mais quand est-il si nous voulons avoir encore plus de possibilité de fin associées à ce script.
Par exemple, que faire si nous voulons lancer un message encore différent (appelons le "MyDadMessage" et lui faire
dire "Hello Dad!") si une épingle à cheveux est ajoutée à l’inventaire du père du joueur (son EditorRefID est MQDadRef)?
Peut être que l’approche la plus judicieuse serait de placer une nouvelle instruction "if" entre l’instruction "else" comme
ceci:

ScriptName MyFirstScript

Begin OnAdd

if GetContainer == Player
ShowMessage MyMessage
else
if GetContainer == MQDadRef
ShowMessage MyDadMessage
else
ShowMessage MyOtherMessage
endif
endif

End
Comme vous pouvez le voir, si l’épingle à cheveux est ajoutée à un inventaire autre que celui du joueur, le script
vérifiera ensuite si l’objet est ajouté à l’inventaire du père (référence MQDadRef).
Bien que cette écriture fonctionne parfaitement, le langage de script utilisé dans FO 3 inclus un outil astucieux nous
permettant d’utiliser un grand nombre de conditions différentes comme celle-ci sans avoir à imbriquer nos instructions
"if" les unes entre les autres. Cet outil est connu sous le nom de l’instruction "elseif", et peut être utilisée de la sorte:

ScriptName MyFirstScript

Begin OnAdd

if GetContainer == Player
ShowMessage MyMessage
elseif GetContainer == MQDadRef
ShowMessage MyDadMessage
else
ShowMessage MyOtherMessage
endif

End

Ce code va marcher exactement de la même manière que le précédent, à la différence près qu’il est plus simple à lire,
comme vous pouvez le voir, et vous n’avez plus qu’à inclure une seule instruction "endif" parce que vous êtes en train
d’utiliser une seule instruction "if".

Parenthèse de Soifran :Lorsque vous scriptez, à chaque fois que vous mettez une instruction "if", vous devez fermer votre vérification par un "endif".
Si vous avez deux "if" doit y avoir deux "endif".

Souvenez-vous toujours de ceci :

- les instructions "elseif" et "else" n’ont pas besoin de leur propre instruction de fin "endif», seul les instructions "if"
ont besoin de leur propre borne fin "endif".
Une des questions les plus fréquentes qu’on me pose à propos du langage de script FO3 est :

Peut-on utiliser "switch/case?".

Si vous n’avez pas fait de programmation avant, alors cette question ne doit pas signifier grand chose pour vous.
Les instructions "Switch/case" peuvent être utilisées dans certaines conditions, au lieu des instructions "if". Bien qu’il
n’apporte pas de fonctionnalité en plus, ils peuvent rendre cependant le code plus facile à lire.
La réponse à cette question est … non. les instructions "switch/case" ne peuvent pas être utilisées dans les scripts
Fallout 3, aussi nous aurons juste à jouer avec les instructions "if" et "elseif".

Variables

Souvent, vous vous rendrez compte que vous aurez besoin de stocker des informations dans un script. Pour cet
objectif, nous avons trois types de variables disponibles à notre disposition. Ces trois types de variables, incluant
leurs abréviations sont :

• int / short / long

• float

• ref / reference

Chacune de ces types de variables peuvent être utilisée pour stocker un type de valeur bien précis.
Basiquement, les variables "int" stockent des valeurs entières (tous les nombres, pouvant être positifs ou négatifs),
les variables "float" stockent des valeurs à virgule (nombres décimaux pouvant être positifs ou négatifs), et les
variable "ref" qui stockent des FormIDs (note de Soifran : Comprenez ici les noms des objets de fallout 3)
(Ils sont plus communément utilisés pour stocker les RefIDs, donc le nom).

Pour commencer, pour créer une variable à utiliser pour nous, nous devons la déclarer. De la même façon que
nous avons utilisé le mot clef "ScriptName" quand nous avons déclaré l’EditorID de
notre script, lorsque nous déclarons une variable, nous devons utiliser le mot clef approprié pour déterminer de
quel type de variable il s’agit.
Nous pouvons choisir le nom de notre variable, mais deux variables dans un même script ne peuvent avoir le même
nom, même si elles sont de types différents, et une variable ne peut pas porter le nom d’une « Form »
(Par exemple, je ne peux pas donner à une variable le nom de "Lockpick", car ce nom est déjà utilisé comme
EditorID de l’épingle à cheveux).


Déclarons une variable "ref», qui pourra stocker le retour d’information de GetContainer pour une utilisation postérieure:

ScriptName MyScript

ref rContainer

Begin OnAdd
...
End

Comme vous pouvez le voir, la déclaration de la nouvelle variable est située au sommet du script, à l’extérieur du
champ de notre bloc Begin/End . Toutes nos déclaration de variable doivent être placées la, comme la déclaration
du nom du script.
Notez comme j’ai écris ma variable – J’ai mis la lettre "r" en préfixe aussi je me souviens que c’est une variable de
référence "ref", et je l’ai dénommé en accord avec sa fonction, qui est de stocké la RefID de l’item scripté conteneur.
La façon dont vous nommé vos variable et quelle convention d’écriture vous utilisez ne regarde que vous, mais il est
important qu’elles soient nommée en accord avec leur fonction, pour que votre script soit plus aisé à suivre. Si vos
variables sont toutes nommées "Variable1", "Variable2" etc. alors votre script sera probablement très difficile à
comprendre.

Une fois que nous avons déclaré nos variables, la valeur 0 lui est automatiquement attribuée. Au départ, pour changer
a valeur de cette variable, nous devons utiliser la commande "set», qui consiste à l’utilisation de deux mots clef - "set"
et "to". Par exemple, si vous voulez relier votre variable "rContainer" à la valeur retournée par GetContainer, nous
devrions le faire de la façon suivante:

set rContainer to GetContainer

Comme vous pouvez le voir, la commande "set" débute par le mot clef "set", qui est suivi par le nom de la variable,
qui est suivi de la commande "to", qui est suivi par une expression (ici getcontainer).
La valeur de la variable sera le résultat de cette expression.

Fonctions de référence

La première fonction que nous avons utilisée dans ce tutoriel, ShowMessage, est ce qui est connu comme une
fonction non-référence, puisqu’elle n’agit pas sur une référence spécifique. La plupart des fonctions, cependant,
sont des fonctions de références, et oriente une action sur une référence (un objet, un personnage, etc.…)
spécifique.
Parce que les fonctions de référence agissent sur des références spécifiques, lorsque nous les appelons, les
références sur lesquelles elle agit doivent être spécifiées. Il y a deux moyens par lesquels une fonction de
référence peut être appelée – avec une syntaxe de référence implicite ou avec une référence de syntaxe explicite.

• Quand des fonctions références sont appelées avec une syntaxe de référence implicite, elles sont appelées
dans la référence scriptée. A cause de ceci, les fonctions de référence peuvent seulement être appelées avec une
syntaxe implicite dans les scripts de référence. Les fonctions de référence appelées avec une syntaxe de référence
implicite utilisent la même syntaxe que les fonctions de non-référence, et peuvent être appelée dans l’inventaire
d’objet en tant que références. (putain balaise, je ne comprends pas ce que j’écris la  va falloir que je creuse )

• Quand une fonction de référence est appelée avec une syntaxe de référence explicite, elles sont appelées
sur une référence spécifique. Cette référence peut être spécifiée de deux façons:

o Via EditorRefID. Seules les références persistantes peuvent être mentionnées ainsi.

o Via une variable locale "ref" stockant la RefID de la référence.

• Les fonctions de référence appelées avec une syntaxe de référence explicite spécifient une référence en
préfixant le nom de la fonction soit avec la référence de EditorRefID, soit par le nom d’une variable "ref", et séparant
celle-ci avec une période – juste comme celle à la fin de cette phrase. (mal à la tête la  )

Il est important de noter que les fonctions ne peuvent pas être utilisées directement pour appeler des fonctions
référence avec une syntaxe explicite, ni ne peuvent être utilisées directement comme paramètres dans d’autres
fonctions. Au lieu de ça, la valeur de retour d’une fonction peut être stockée dans une variable, et cette variable
pourra être utilisée par la suite quand la fonction sera appelée.

Par exemple, le code suivant ne sera pas compilé:

GetContainer.AddItem Caps001 10

Au lieu de ça, la valeur de retour de GetContainer doit être stockée dans une variable locale de type "ref», et cette variable devra être utilisée pour appeler la fonction GetContainer:

ref rContainer

; In the code block
set rContainer to GetContainer
rContainer.AddItem Caps001 10

(Note de Soifran :Traduction du script ci-dessus :ref rContainer Créer la variable de référence que l’on appelle rContainer

; In the code block
set rContainer to GetContainer définir que la variable Rcontainer est getcontainer
rContainer.AddItem Caps001 10 Ajouter l’item capsule, 10 au rContainer (ici le joueur)
Regardez maintenant le premier essai non compilable :GetContainer.AddItem Caps001 10Ici on essaye de donner directement les capsules à la fonction GetContainer, et cela ne fonctionne pas.
Il faut donc créer une variable, ici rContainer , donner la valeur Getvariable à notre variable de référence :
set rContainer to GetContaineret donner l’item souhaité, ici des capsule (ayant la REF ID Caps001) au nombre de 10 à la variable rContainer qui est en fait GetContainer .
Fin de parenthèse)

Dans notre script, nous avons déjà appelé une fonction de référence - GetContainer. Parce GetContainer ne marche
réellement seulement sur les objets d’inventaire, il devrait toujours être appelé avec une syntaxe de référence implicite,
comme celle que nous avons faite.


(Note de Soifran :En fait il faut comprendre par implicite, sous-entendu.
En effet, comme cela ne marche pas de faire appelle directement à GetContainer, c’est pour cela qu’on crée une variable appelé ici rContenair et qu’on dit ensuite que cette variable est en fait GetContainer.
On ne met pas directement (explicitement) GetContainer mais une variable le représentant.
Fin de parenthèse)

Où en étions-nous déjà ? Ha oui, nous venions juste de déclarer une variable de référence "ref», appelé rContainer,
et avions paramétré la valeur de celle-ci comme étant GetContainer. Maintenant que nous avons la RefID de la
référence (objet) qui a l’objet scripté épingle à cheveux stocké dans son inventaire dans une variable de référence,
On peut appeler des fonctions de référence sur elle avec une syntaxe de référence explicite.
Maintenant, comment faire si nous voulons changer notre script afin que si les épingles à cheveux sont ajoutées à
l’inventaire d’une référence (la personne qui prend l’épingle à cheveux) autre que le joueur et le père (MQDadRef),
10 caps soient ajoutés à l’inventaire de cette référence au lieu d’afficher un message?
Nous pourrions utiliser une syntaxe de référence explicite appelée AddItem sur la référence, comme ceci:

ScriptName MyFirstScript

ref rContainer

Begin OnAdd

set rContainer to GetContainer

if rContainer == Player
ShowMessage MyMessage
elseif rContainer == MQDadRef
ShowMessage MyDadMessage
else
rContainer.AddItem Caps001 10
endif
End

Une dernière chose que je devrais aborder ici est que, lorsque l’on compare les RefIDs (à la fois les RefIDs stockées
dans les variables "ref" et celles représentées par les EditorRefIDs), la fonction GetIsReference devrait être utilisé à
la place de l’opérateur "==«, aussi notre script ressemblerait à ça:

ScriptName MyFirstScript

ref rContainer

Begin OnAdd

set rContainer to GetContainer

if rContainer. GetIsReference Player
ShowMessage MyMessage
elseif rContainer.GetIsReference MQDadRef
ShowMessage MyDadMessage
else
rContainer.AddItem Caps001 10
endif

End

Comme vous le voyez, GetIsReference est appelé par la référence qui sa RefID stockée dans notre variable
rContainer, et qui utilise la RefID qui est en train d’être comparée en tant que paramètre. Pour cette fonction,
nous pourrions échanger les deux extrémités, (par exemple "player.GetIsReference rContainer) cela marcherai
tout aussi bien.

(Note de Soifran :
En fait cela veut seulement dire qu’on peut écrire dans les deux sens la condition qui utilise la variable. En effet,
si Pierre == Paul, peut s’écrire aussi bien si Paul == Pierre puisqu’ils sont… ?
Egaux, c’est bien, je n’ai pas perdu tout le monde 
Fin de parenthèse)

Commentaires

A mesure que notre script devient plus long et plus complexe, il peut devenir plus difficile à suivre. Ainsi, pour
rendre ce script plus lisible, il est important de lui annoté des commentaires utiles. Les commentaires sont
basiquement des textes qui font parti du code du script mais qui sont entièrement ignoré par le compilateur – Ils
n’ont aucun effet sur le déroulement du script en lui même.
Les commentaires dans les scripts de Fallout 3 sont spécifié par l’utilisation du point virgule ; - Tout texte écris
après un point virgule est un commentaire et ne sera pas pris en compte par le compilateur. Ce type de
commentaire est connu sous le nom de ligne de commentaire, ce commentaire va du point virgule à la fin de la
ligne.

(en gros jusqu’à ce que vous fassiez ENTER).
Beaucoup d’autre langage machine permette d’allouer un type de commentaire connu sous le nom de bloc de
commentaire, ou un autre caractère spécifique ou une parenthèse marque la fin d’une ligne de commentaire, mais
pas Fallout 3.

(Note de Soifran :
En gros ça veut dire que si votre commentaire est super long et que pour un souci de place, de présentation,
vous souhaitez aller à la ligne, il faudra marquer le début de cette nouvelle ligne par un nouveau point virgule.
Fin de la parenthèse)

Une des fins particulièrement utiles justifiant l’utilisation des commentaires est pour expliquer ce que représentent
certaines valeurs.
Par exemple, la fonction GetOpenState utilise différentes valeurs pour représenter différents états d’une porte
"open states" (ouverte, fermée, serrure cassée, nécessite une clef, etc,etc). En eux-même, ils ne veulent rien dire
de clair, aussi ce peut être une bonne idée de commenter ces états.

Par exemple:

if GetOpenState == 3 ; Closed
...
elseif GetOpenState == 4 ; Closing
...
endif

Comme vous pouvez le voir, les commentaires ici expliquent à quoi correspondent les différentes valeurs dans la
vraie vie. I les commentaires étaient absents, alors, quelqu’un lisant le script devrait d’abord regarder la
documentation liée à la fonction GetOpenState pour comprendre ce que signifient réellement ces conditions.
Le même concept, appliqué à des variables – si vous utilisé des variables avec différents niveaux de valeur
représentant différents états, ce serait une bonne idée d’utiliser un commentaire lorsque vous déclarez une
variable pour expliquer ce qu’elle représente.
Une autre bonne façon d’utiliser des commentaires est pour décrire la fonction d’un script. Par exemple, si vous
avez un script qui utilise des calculs compliqué pour place une référence devant un joueur, alors ce serait bon
d’utiliser un commentaire expliquant ceci au début du script. De cette façon, quiconque lirait le script n’aurait
qu’à lire le commentaire, au lieu d’essayer de comprendre à quoi servent ces calculs, ceci afin de mieux comprendre
en fait comment il fonctionne du coup.
Lorsque vous écrivez des scripts, vous devriez toujours mettre des commentaires où vous pensez que c’est
nécessaire à la compréhension de certaines parties du code.

Style

Le Style est souvent perçu comme l’aspect le moins important de l’écriture d’un script. Les programmeurs expérimentés,
considèrent eux que cette partie est plus importante que n’importe quel autre.
Il y a des chances que lorsque vous lirez des scripts fait par d’autre vous appreniez comment faire des choses.
Et il arrivera un moment ou vous vous direz :"hey, ce script est vraiment bien écrit !"
Bien écris. Pas nécessairement remplis de tonnes de lignes, ni besoin d’une grande connaissance du moteur,
mais plutôt un réel plaisir à lire à travers, et facile à comprendre. C’est ceci un bon style.

Lisibilité

Deux facettes de cette partie ont déjà été abordées: choisir des noms clairs pour les variables, et bien les commenter.
Mais il y en a beaucoup d’autres, tel qu’utiliser les noms complet des commandes plutôt que leurs abréviations, comme
ceci votre lecteur n’aura pas besoin de tenter de se souvenir à quoi correspond ces acronymes; ou utiliser des lignes
d’espacement supplémentaires pour aérer le texte ou montrer les similitudes entre deux lignes. Au stade ultime de la
lisibilité ,vous pourriez donnez votre script à lire à quelqu’un qui n’y connaît rien en script, et il pourrait comprendre ce
qu’il fait.

Cohérence

Etroitement lié à la lisibilité, cela signifie que les choses avec des objectifs similaires ne devraient pas être
nécessairement différentes. Eviter de résoudre un problème de différentes façons à différents endroit si ce problème
est le même, et essayez plutôt de nommer les choses similaires de façons similaires. Par exemple, dans les kits par
défaut , les portes dans les pièces (doorway pièces) peuvent être nommées de différentes façons :

"Doorway", "DoorWay", "DoorFrame", "Door", "Exit", or "Ex".

Est ce que cette variété d’appellations va rendre l’objet que vous cherchez plus facile à trouver?

Agencement

C’est ce à quoi ressemble votre script dans la page: un bon agencement vous fait comprendre la structure du code à
l’intérieur avant même que vous ayez commencé à lire. Séparer chaque section aux concepts différents par une ligne
vierge, et utilisez de préférence un commentaire pour faire un sommaire des sections qui viennent après. Laissez un
espace dans le contenu de chaque bloc par un niveau (écart par rapport à la marge) ; laissez un espace également
pour chaque ligne de commande tel que if, else, ou autre. La plupart des programmes d’éditions de textes , le GECK
inclus, rendent cela plus facile en vous laissant sélectionner un group de ligne que vous souhaitez espacer, en
ppuyant ensuite sur TAB ou Shift-Tab pour « de-espacer »

Cohésion

Les scripts peuvent aisément être répartis entre de multiples scripts d’objet, les conditions dans les quêtes et
conversations, les actions sur les objets, et ainsi de suite. Plus le nombre de choses affectées est élevé, plus le
nombre de choses affectées est grand, plus il devient difficile de garder une trace de tout cela, et de se faire une
image mental de leur interactions, aussi vous pourriez faire un changement aux conséquences inattendues.
Si le nombre de choses affectées est réduit au minimum, regroupés par noms similaires, et leurs interactions éclairées
par des commentaires judicieux, ainsi l’enchevêtrement deviendra de plus en plus tangible.

Simplicité

Ceci est souvent sujet au laconisme. En effet, ci cela rend le script plus simple à comprendre, alors faire quelque
chose en quelques lignes est bon. Mais si vous pouvez choisir entre quelque chose de long, avec des lignes
d’équations à foison, ou simplement trois lignes de commande, alors allez au plus simple, l’option multi ligne.

Compatibilité

Cet aspect est à associer avec la lisibilité et la simplicité. C’est l’art de faire des scripts qui n’interfère pas avec
d’autres mods. Un bon début est de s’efforcer à éviter les conflits de noms de scripts et de ne changer que la partie
du monde ou du jeu dont vous avez vraiment besoin, même si cela doit vous demander un petit effort supplémentaire.

Glossaire

Alias

Beaucoup de fonctions, de mot clef ont des alias. Ce sont des noms alternatifs, ou mot clef, qui peuvent être utilisé à
la place de la fonction principale. Par exemple, la fonction StopCombatAlarmOnActor a comme alias - scaonactor. Cela
signifie que les deux lignes de commande suivantes sont identiques:

StopCombatAlarmOnActor
scaonactor

Block type

Il y a un nombre limité de conditions qui peuvent être utilisées pour un bloc Begin/End , tels que OnAdd et OnDeath.
Chacune de ces conditions est connue sous le nom de block type. Différents types de script ont différent block types
à leur disposition, aussi cela peut aider d’avoir à l’esprit que les blocks type peuvent être séparé en plusieurs catégories:

• Effet

o ScriptEffectFinish
o ScriptEffectStart
o ScriptEffectUpdate

• Reference-specifique

o OnActivate
o OnActorEquip
o OnActorUnequip
o OnAdd
o OnCombatEnd
o OnDeath
o OnDestructionStageChange
o OnDrop
o OnEquip
o OnHit
o OnHitWith
o OnLoad
o OnMagicEffectHit
o OnMurder
o OnPackageChange
o OnPackageDone
o OnPackageStart
o OnRelease
o OnSell
o OnStartCombat
o OnTrigger
o OnTriggerEnter
o OnTriggerLeave
o OnUnequip
o SayToDone

• General

o GameMode
o MenuMode


Note de Soifran :
J’ai ici recréé ici le tableau des différentes commandes utilisables dans les blocs types begin/end ci dessus, en y rajoutant
surtout leur signification, leur rôle à chaque fois.
La syntaxe doit toujours être la suivante :

Begin OnActivate
Ou bien
Begin Ontriggerenter
Etc,etc.
En fait il faut traduire le préfixe On devant chaque mot clef par démarrer.
C’est le On de On/Off.
Fin de la parenthèse

[ATTACH]2688[/ATTACH]

Comme vous pouvez le voir, la majeur partie des blocks types sont de type référence spécifique. La plupart de
ces blocks types ne peuvent être utilisés qu’avec un type précis d’entité. Par exemple, les blocs OnDeath ne
peuvent être utilisés uniquement sur des acteurs (PNJ et créatures), et les blocs OnAdd ne peuvent être utilisés
que sur les entités de type portable, comme les armes.

EditorID

Toutes les entités non référence du jeu, ainsi que certaines entités référence ont un EditorIDs. Ce sont
basiquement des alias pour leur FormIDs, et sont utilisés dans les scripts pour se référer à des entités (forms)
spécifiques.

EditorRefID

L’ EditorID d’une référence.

Effect Script

Les scripts d’effets peuvent être à des formes d’effet de base, qui peuvent être utilisés pour l’effet d’un objet,
acteurs ou formes ingérables. Les variables déclarées dans les scripts d’effet ne peuvent pas être accessible à
distance. Les scripts d’effet sont limités à trois blocks type uniquement:

• ScriptEffectStart

• ScriptEffectUpdate
• ScriptEffectFinish

False (faux)

Toute chose évaluée à zéro.

Form

La plupart des objets stockés dans le fichier data sont de type «form ». Il y a beaucoup de types différents
de «form», chacun stockant des informations sur différents types d’objets. Par exemple, les scripts « forms »
stockent des informations à propos des scripts, de la même façon que les « forms » d’armes stockent des
informations à propos des armes. Différentes « forms » peuvent être identifiées par leur unique EditorID et
FormID.

Note de Soifran :
Moi aussi au début, je n’ai pas trop compris la subtilité de ce qu’ils appellent une forme.
En faite tout connement, ce n’est ni plus ni moins que les différents objets du jeu, que vous pouvez retrouver par catégorie dans l’object windows du GECK.
Les Actors, les Weapons, les objets, les quêtes, etc,etc…
Chaque catégorie d’objet est une « forme ».

FormID

Un nombre hexadécimal à 6 chiffres qui définit une « form ». Les deux premiers chiffres de la FormID correspondent
à la position du fichier de donnée duquel la « form » est originaire durant votre chargement. Cela permet à plus
de 255 fichiers de données d’être chargé simultanément , incluant Fallout3.esm. le préfixe "ff" est réservé aux
« forms » qui stockent des fichiers de sauvegarde (La plupart d’entre eux seront des références.)

Fonction (function)

A coté de la manipulation des variables, chaque chose dans les scripts est accomplie par des fonctions. Certaines
fonctions peuvent être utilisées pour déterminer une information à propos d’une « form » spécifique ou sur l’état
actuel du jeu (lors d’un quête par exemple), et d’autres peuvent être stockées pour effectuer des actions
– affectant des « form » spécifiques ou l’état du jeu d’une certaine façon. Les fonctions qui agissent sur des
références spécifiques sont connues sous le nom de fonctions références (reference functions), alors que les
fonctions qui n’agissent pas sur des « form » spécifiques sont connues sous le nom de « non-reference functions ».

Script d’objet (Object Script)

Les scripts d’objets peuvent être attaché à des formes qui peuvent avoir des références, tels que les acteurs,
ou bien les « forms » d’objets transportables, ou les armes. Ce sont des scripts de référence, et ils peuvent
utiliser des blocs types spécifiques de référence. Les scripts d’objets sont exécutés à chaque image du jeu,
dans lesquelles l’objet scripté (ou son contenant, dans le cas d’un inventaire d’objets) est chargé.

Operateur (operator)

Les opérateurs sont utilisés pour manipuler des valeurs, et sont divisés en trois catégories:

Les opérateurs arithmétiques:

+ Addition
- Soustraction
* Multiplication
/ Division
% Modulo ( le reste d’une division d’un nombre par un autre.)

Opérateurs de comparaison:

== Egal à
!= N’est pas égal à
> Strictement plus grand que
< Strictement plus petit que
>= Supérieur ou égal à
<= Inférieur ou égal à

Les opérateurs logiques:

&& AND (correspond à « et »)
|| OR ( || se fait avec Alt GR 6) correspond à ou

Les opérateurs de comparaisons retourneront la valeur 1 s’ils sont évalués comme vrai, et 0 s’ils sont évalués
comme faux. Par exemple, "3 < 5" retournera la valeur 1 parce que l’état 3 plus petit que 5 est vrai, alors que
l’état "3 == 5" retournera la valeur 0 car 3 égal 5 est faux. Ces opérateurs ne peuvent pas retourner une autre
valeur que 0 ou 1.
Comme les opérateurs de comparaison, les opérateurs logiques retourneront également une valeur 1 s’ils sont
évalués comme vrai, et 0 s’ils sont évalués comme faux.
Voici le tableau qui vous montre les sorties possible des opérateurs logiques:

A B A&&B A||B
false false false false
false true false true
true false false true
true true true true
Bien que les opérateurs logiques NOT et XOR ne soient pas disponible, vous pouvez les simuler en utilisant
les sorties "A == 0" à la place de "NOT A" et "(A||-(A&&B)" à la place de "A XOR B".
Gardez à l’esprit que lorsque vous utilisez des expressions compliquées, il peut être utile d’inclure des parenthèses
ainsi vous, ou quiconque lisant le texte sera certain de l’ordre dans lequel sont évaluée vos opérateurs.

Paramètre (Parameter)

Beaucoup de fonctions, spécialement celles qui génèrent des actions au lieu de rassembler des informations,
requièrent plus d’information afin de fonctionner correctement. Cette information est passée à des fonctions sous
la forme de paramètres, qui sont séparés du nom de la fonction, chacun d’eux était séparé d’un espace, et/ou d’une
virgule. Par exemple, les deux lignes suivantes sont équivalentes:

player.AddItem Caps001 10
player.AddItem,Caps001,10
Quelques fonctions ont des paramètres optionnels, qui peuvent être omis de la fonction appelée. Si elles ne sont
pas incluses dans la fonction appelée, alors il lui sera donné une valeur par défaut. Par exemple, les deux lignes
suivantes sont équivalentes:

player.AddItem Caps001 10
player.AddItem Caps001 10

Joueur (Player)

Plusieurs formes sont codé en hard dans le jeu. La plupart d’entre elles n’ont pas besoin de vous concerner,
mais une très importante, et très utile est la référence "Player". De façon simple, le fait que cette référence
soient codée en hard signifie que vous serez toujours capable de vous référer à la référence "Player" en utilisant
le mot-clef "Player", qui est l’ EditorRefID de la référence"player", peu importe si les fichiers de données sont chargés.

Script de quête (Quest Script)

Les scripts de quête peuvent être attachés aux formes de quête (quest form), et ne sont pas des scripts de
référence. Ils ne peuvent pas utiliser de block type de type reference-specific. Les scripts de quête n’ont pour
unique capacité un script d’écoulement du temps, qui défini combien de fois celui ci sera exécutés. Ceci est
définit dans la forme quête à laquelle le script est attaché, et peuvent être changé via un script avec la fonction
SetQuestDelay. Dans cet esprit, pour un script de quête qui tourne à chaque image, le délai d’exécution de celui-ci
devrait être une valeur très faible, de type 0.001.

Reference

Une référence est un type spécial de forme avec laquelle vous pouvez interagir avec dans le monde et de façon
simple, agir comme un pointeur sur ces formes.
Ainsi, elles contiennent deux sortes d’information :

• Des informations de référence spécifique

• Des informations à propos de l’objet de base (la forme d’après laquelle la référence est basée)

Note de Soifran :
En fait, on ne met jamais dans le jeu les formes qui sont en faites les matrices, mais plutôt des « copies » que
nous appellerons références.
On peut faire ce qu’on veut de la copie, ça n’altèrera jamais l’original qui a servit de plan pour la construire.
Les formes sont en fait des modèles, que l’on copie pour les utiliser dans le jeu.

Script de référence (Reference Script)

Les scripts attachés aux formes qui peuvent avoir des références sont appelés reference scripts. Chacune des références à l’une de ces formes déclenchera ça propre instance du script.

RefID

La FormID de la référence.

True

Toute chose évaluée à une valeur différente de zéro.


Variable

Une variable est quelque chose qui vous permet de stocker une information dans un script à utiliser plus tard. Il y a trois types de variable possible pour les scripts de Fallout 3, chacune d’entre elles stockant des types d’informations différents.

Modifié le 7 septembre 2011 par soifran

[soifran]

Ouais je sais ça fiat peur, mais faut pas c'est trés bien fait, trés pédagogique et instructif. (27 pages quand même ) bise Soifran