Bon après maintes recherches infructueuses je me résigne à poster.
Je n'arrive pas à créer de fichiers include. En gros j'ai deux cas de figure: Soit il m'insulte parce qu'il n'y a pas de main(), soit il m'insulte parce qu'il n'y a pas de StartingConditional()

Si je met un main() dans l'include, forcément, il m'insulte qd j'utilise l'include à un endroit ou il y a déjà un main().

Pour le StartingConditional, je ne vois pas à quoi ca sert ni ce que ça vient faire là
_________________
Now that we've fattened the cow and set out to plow unknown enemies - "Wow!" Shouts the startled crowd "Oh no did you see what I did see?" - The ravaged cabbage drifts on dark red skies - And it looks so nice

Vainqueur BB1, BB3, BB5 et BB6

Saelis a écrit :En gros, tout fichier de script doit comporter un main() ou un StartingConditionnal() (c'est un OU exclusif), sauf les fichiers de script à mettre en include.
Voici un exemple :
Code :
En l'absence de main, ce fichier ne doit pas te refuser la compilation. Le problème est qu'il n'indiquera pas toutes les erreurs qu'il est susceptible de trouver. En gros, il te trouveras les erreurs de syntaxe pure, mais par les erreurs de parcours (genre quand il manque un return à une fonction, ou qu'une imbrication de bloc est mal faite, ou encore qu'une fonction n'a pas le bon nombre de paramètres, etc..).

Moi j'utilise une astuce pour compiler indépendamment mes fichiers "à inclure". Je rajoute la ligne suivante à la fin :
Code :
Il me suffit de compiler avec cette ligne pour repérer toutes les éventuelles erreurs. Puis de la mettre en remarque pour la sauvegarde définitive du fichier.

Ensuite pour utiliser le fichier à inclure :
Code :

Ou

Code :

La présence d'un main ou d'un StartingConditionnal est en somme indispensable au bout d'un moment. StartingConditionnal est une fonction utilisée dans les scripts de dialogue de type Condition. Cette fonction doit renvoyer vrai ou faux pour savoir si un élément de dialogue apparaît ou non. Dans ce cas de figure, on ne met pas de main. Dans tous les autres cas, cette fonction ne doit pas apparaître sinon elle entre en conflit avec le main.

En plus de ça, il faut faire attention aux inclusions multiples, du genre lorsqu'un fichier en inclus un qui en inclus un autre. Tous les fichiers inclus en cascade ne doivent comporter aucun main ni aucun StartingConditionnal.
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

lendraste a écrit :Ben si justement
Et c'est bien là mon pbm

Je peux le sauvegarder simplement mais pas le compiler. Mais peut être est-ce ce qu'il faut faire?
_________________
Now that we've fattened the cow and set out to plow unknown enemies - "Wow!" Shouts the startled crowd "Oh no did you see what I did see?" - The ravaged cabbage drifts on dark red skies - And it looks so nice

Vainqueur BB1, BB3, BB5 et BB6

Saelis a écrit :Tu peux l'afficher ici ?
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

C'était bien ça. Je peux utiliser la commande "sauvegarder le fichier actuel" (ctrl+S) mais pas la commande "Sauvegarder et compiler" (F7) sur un include.

C'est tout ce que je voulais savoir! Pas besoin de compiler l'include pour que ca soit pris en compte.

Donc ça marche donc je peux continuer mon douloureux apprentissage...
_________________
Now that we've fattened the cow and set out to plow unknown enemies - "Wow!" Shouts the startled crowd "Oh no did you see what I did see?" - The ravaged cabbage drifts on dark red skies - And it looks so nice

Vainqueur BB1, BB3, BB5 et BB6

Saelis a écrit :Effectivement, erreur de ma part. Toutefois, chez moi, la compilation à la sauvegarde est activée et il ne me jette nullement d'insulte lorsque je sauvegarde un include file, sauf si ce dernier comporte des erreurs de syntaxe. Il accomplit peut-être un compilation limitée à une passe dans ce cas de figure précis. Je tâcherai de vérifier.
Quoiqu'il en soit, je ne saurai trop de te conseiller d'effectuer une compilation avec un main pour t'assurer que l'include file ne contient pas d'erreur avant de le sauver sans le main car, par la suite, si on y prend pas garde, les messages d'erreur de compilation d'un script utilisant l'include peuvent provenir aussi bien de l'include que du script en question ce qui est assez déroutant, surtout quand il indique une erreur à la ligne 200 alors que notre script n'en comporte que 100 et que l'erreur est issue de la 200ième ligne de l'include.
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

Je me permets de préciser un peu les choses : un script d'include ne compile en général pas (en fait je n'en ai jamais vu compiler sans main) et n'a pas à être compilé.
Il suffit de l'enregistrer, puis de compiler les scripts qui utilisent cet include.

A la moindre modification d'un fichier include, il faut évidemment recompiler tous les autres scripts l'utilisant.

Dernier chose : la taille d'un fichier include n'a aucune incidence sur la taille (après compilation) d'un script utilisant cet include. On m'a déja dit qu'utiliser un include de 2000 lignes dans tout un tas de script ralentissait le jeu, ben moi je dis que non (et Bioware aussi d'ailleurs). Un script qui utilise un include, ne contiendra dans sa version compilée que les fonctions qu'il utilise dans le include, et pas le reste.

En clair, faites des include, ça a que des avanatges

En fait l'include reste dans le jeu en fichier Texte parce que quand vous recompilez tous vos scripts, le jeu pour CHAQUE script où vous avez fait appel à une fonction d'include, rajoute l'intégralité de l'include au début du script, puis compile ensuite.
Cela veut dire que si 100 de vos scripts à 4-5 lignes font appel à une include qui fait 1000 lignes, et celà juste pour une ou deux fonctions, ces 100 scripts seront compilés comme s'il sagissait de scripts à plus de 1000 lignes chacun, donc démultiplication des tailles des scripts, et donc démultiplication de la taille de votre module.
Le but c'est donc de faire plusieurs includes, par type disons, de pas plus de 150 lignes, pour ne pas exagérer la taille de vos scripts. Et surtout de REcompiler tous vos scripts ensuite.
_________________
Atha, Artisan Scripteur.
meet the most beautiful woman in the world

Citation :Oui.


Citation :Je ne suis pas d'accord avec toi .
Prenons un exemple :

Script "inc_malibrairie"
Code :

Script A
Code :

Script B
Code :

Script C
Code :

Pour chacun de mes scripts A, B, C, je vais automatiquement lancer la compilation du script lui-même et de la librairie toute entière (ce que tu mentionnes justement), même si je n'utilise aucune fonction de celle-ci (dans le cas du script A).

En revanche, la taille des scripts compilés, et en conséquence du module, ne dépend uniquement des fonctions réellement utilisées (du moins si on utilise un "bon" compilateur, et celui de Aurora l'est), donc :

taille compilée du script C > taille compilée du script B > taille compilée du script A

Tu peux faire l'essai pour t'en convaincre en extrayant les script (compilés) "*.ncs" de ton module.

Conclusion
Les librairies ("includes") n'ont que des avantages si vous les construisez "proprement", n'hésitez pas en abuser .