Un module: Késako ?

Bonjour et désolé pour mon interrogation noobesque mais qu'est-ce qu'exactement ce que vous appelez un "module" sous AGS, utilisé à plusieurs reprises dans le forum ?

Je sais comment en installer un grâce au tuto d'Asraroth mais j'hésite à le faire car je ne sais tout simplement pas ce que c'est?...
...Un script avec des commentaires ?

Merci

Oui techniquement c'est juste un fichier script dans AGS, avec ou sans commentaires (mais les commentaires aident à la compréhension)

Plus exactement, c'est une paire de fichiers .asc et .ash, autrement dit le corps du script et son en-tête. Donc techniquement, les fichiers GlobalScript.ash et GlobalScript.asc de n'importe quel projet constituent un module.

Mais on réserve généralement la qualification de "module" aux scripts qui sont autonomes, ton global script il va probablement dépendre de tout un tas d'éléments dans ton projet et si tu essayais de le copier-coller dans un autre projet, ça ferait probablement tout crasher, c'est pour ça qu'on appelle généralement pas le GlobalScript un module

Un bon module, tu te contentes de l'importer dans n'importe quel projet et ça crashera pas, en fait ça ajoutera même des fonctionnalités supplémentaires, généralement sous la forme de nouvelles fonctions

Pour prendre un exemple de module d'@Asraroth justement, imagine que tu aimerais que tous tes personnages parlent dans des bulles, comme dans les bandes dessinéees. Ce serait cool s'il existait une fonction genre Phylactere que tu pourrais utiliser exactement comme Say, mais qui se charge automatiquement de placer une bulle derrière le texte. Eh bien c'est exactement ce que fait le module Phylactere de @Asraroth : c'est une paire de fichier .asc et .ash qui définit une nouvelle fonction nommée Phylactere que tu pourras utiliser dans n'importe quel projet quand tu importes le script.

Si tu jettes un coup d'oeil au script en question, tu verras que y'a plein d'opérations qui sont faites en coulisse, mais toute la valeur d'un module vient du fait qu'on s'en fiche de ça, parce que c'est justement le boulot des gens qui font des modules de coder ces opérations et de livrer un produit fini autonome, plug-and-play pour ainsi dire.

Dernière note : un plugin (ou greffon) accomplit sensiblement la même chose dans AGS, à la différence que ce n'est pas une paire de fichiers .ash et .asc mais un fichier DLL (il me semble) codé dans un langage autre que AGS puis compilé. Une conséquence de cette compilation c'est que ce sera spécifique au système d'exploitation (windows en l'occurrence) et donc pas directement disponible si tu exportes ton jeu pour un autre os comme linux par exemple, ce qui risque de compromettre la portabilité de ton jeu. Moralité : préfère les modules aux plugins si jamais tu dois choisir entre deux qui font la même chose.

Ahah merci Kitai c'est un peu plus clair pour moi maintenant.
Merci aussi pour le conseil de préférer le module au plugin car j'aurais foncé tête baissée dans la solution du plugin justement, et je ne tiens pas spécialement à ce ce que cela apporte des bugs ensuite.

Mais il y a encore un truc qui m'échappe c'est cette histoire de global script, de deux feuilles séparées et tout... j'ai beau avoir relu plusieurs fois (en français et en anglais) le manuel je ne comprends pas grand chose à cette histoire de header ou pas header.

Si tu as une explication simple (du genre comme si tu expliquais à un gros débile) je suis vraiment preneur.

En tout cas merci encore d'avoir consacré du temps pour me répondre.

Ravaillac a écrit:

et je ne tiens pas spécialement à ce ce que cela apporte des bugs ensuite.

Juste pour être clair, ça devrait apporter des bugs seulement pour les gens qui utilisent pas windows (comme moi)

Ravaillac a écrit:

je ne comprends pas grand chose à cette histoire de header ou pas header.

S'il s'agit juste d'importer des modules, c'est pas nécessaire de saisir cette différence, puisque lorsque tu exportes/importes les modules, ces deux fichiers sont rassemblés en un seul fichier .scm

Ravaillac a écrit:

Si tu as une explication simple (du genre comme si tu expliquais à un gros débile) je suis vraiment preneur.

Alors je sais pas si ça va te satisfaire, mais voilà l'idée générale.

Le fichier .ash (le header, ou en-tête) se charge de rendre disponible les fonctions/variables du module à partir des autre endroits dans ton projet : si tu avais seulement le fichier .asc mais pas le fichier .ash (situation impossible) du module Phylactere, tu pourrais pas utiliser la fonction Phylactere dans ton GlobalScript, ou n'importe où ailleurs en fait, ce qui rendrait le module complètement inutile.

Il y a plein de fonctions et de variables dans le fichier .asc (ce que j'appelle le corps du script, ou body) mais la plupart ne seront pas disponibles ailleurs dans ton projet car absentes de l'en-tête, et c'est très bien comme ça : ces fonctions et variables là sont uniquement utiles au module pour effectuer ses opérations en coulisse, mais toi quand tu utilises le module tu as pas du tout besoin d'aller mettre tes mains sous le capot, autrement dit tu as pas besoin d'accéder aux fonctions et variables internes au module.

Ok merci je comprends mieux, merci encore !

Mais admettons que j'ai envie néanmoins de faire mes fonctions moi-même, avec des conditions et tout le toutim...

Dans quel(s) cas je vais dans le header, dans quel(s) cas je vais dans le body ?
D'ailleurs dans le même ordre d'idées je ne comprends pas non plus pourquoi (et surtout quand) mettre mes fonctions en dessus ou en dessous de "function repeatedly_execute() " ?

Désolé pour ces questions qui doivent vous sembler idiotes

Tu vas très rarement utiliser l'en-tête en vrai, la plupart du temps tu vas scripter des choses directement dans le corps de ton global script ou bien dans les scripts des pièces.

Mais c'est vrai que parfois, peut-être, tu voudras créer une fonction assez générale que tu voudras pouvoir utiliser à la fois depuis le global script et depuis les scripts de tes pièces. Dans ces cas-là, tu vas coder ta fonction avec des conditions et tout le tintouin dans le corps d'un nouveau module que tu auras créé rien que pour ça, et ensuite tu vas ajouter une ligne simple qui suit le format import function(...); dans l'en-tête de ton module, histoire de rendre la fonction codée dans le corps de ton module disponible depuis tes autres scripts (en particulier, global script et scripts de pièce). Sans l'en-tête, tu pourrais jamais appeler la fonction codée dans le corps de ton module depuis tes autres scripts.

Tu me diras : bah pourquoi pas tout coder directement dans l'en-tête alors et se débarasser complètement du corps ? Ce serait une option dans certains cas en effet, mais il y a quelques bonnes raisons d'avoir ce système d'en-tête versus corps.

En ce qui concerne tes fonctions en dessus ou en dessous de repeatedly_execute, ça importe vraiment pas tant que ça. En fait le programme lit le script de gauche à droite et de bas en haut (comme nous quoi) donc la seule chose dont tu veux t'assurer c'est que chaque fois que tu utilises une fonction ou une variable (pour changer ou consulter sa valeur) cette fonction ou cette variable a bien été déclarée plus haut dans ton script.
Si tu t'assures pas de ça et que tu utilises avant de déclarer, ce serait un peu comme si je disais : "L'autre jour Buffy dormait à côté de Pondo, et j'ai un chat qui s'appelle Buffy et une peluche qui s'appelle Pondo". Bizarre non ? C'est mieux de faire les choses dans l'ordre*, déclarer d'abord, faire référence ensuite : "J'ai un chat qui s'appelle Buffy et une peluche qui s'appelle Pondo, et l'autre jour Buffy dormait à côté de Pondo".

* Ceci n'est pas une indice comme quoi Pondo serait un animal préhistorique partouzeur de droite, et franchement je suis offusqué qu'on puisse envisager cette possibilité

Kitai a écrit:

Tu vas très rarement utiliser l'en-tête en vrai, la plupart du temps tu vas scripter des choses directement dans le corps de ton global script ou bien dans les scripts des pièces.

Mais c'est vrai que parfois, peut-être, tu voudras créer une fonction assez générale que tu voudras pouvoir utiliser à la fois depuis le global script et depuis les scripts de tes pièces. Dans ces cas-là, tu vas coder ta fonction avec des conditions et tout le tintouin dans le corps d'un nouveau module que tu auras créé rien que pour ça

Je n'ai pas suivi toute la conversation donc pardon d'avance si j'ai raté quelque chose mais dans un cas comme celui-là je ne comprends pas bien l'intérêt de créer un module "rien que pour ça". On peut parfaitement créer une fonction dans le global script (.asc), l'importer dans l'en-tête et l'utiliser dans les scripts des pièces !

valoulef a écrit:

dans un cas comme celui-là je ne comprends pas bien l'intérêt de créer un module "rien que pour ça". On peut parfaitement créer une fonction dans le global script (.asc), l'importer dans l'en-tête et l'utiliser dans les scripts des pièces !

Tout à fait, c'était surtout pour donner un exemple où on crée une nouvelle paire en-tête/corps, afin d'illustrer que lorsqu'on fait ça, c'est l'en-tête qui va permettre de rendre disponibles aux autres scripts (y compris le global script, qui se trouve tout en bas de la liste) la fonction codée dans le corps.