Comprendre l'organisation des scripts dans Arma Reforger

Dans l'atelier Enfusion, les scripts sont présentés de deux façons différentes selon l'outil utilisé.

• Dans le Resource Browser, les scripts sont organisés par mod (chaque mod possède sa propre arborescence de fichiers).
• Dans le Script Editor, ils sont regroupés par module logique, indépendamment de leur mod d'origine.

Chaque mod doit respecter la structure type (scripts/Game/, scripts/GameLib/, etc.) pour plusieurs raisons :

1. Découverte automatique : Le moteur Enfusion scanne automatiquement les dossiers scripts/ de chaque mod pour enregistrer les classes. Sans cette structure, les scripts ne seraient pas détectés.
2. Ordre de chargement et dépendances : L'arborescence définit implicitement l'ordre de chargement :
   • Engine → Entities → GameLib → Game → WorkbenchGame (ce dernier uniquement si le jeu est lancé en mode éditeur)
   • Cela garantit que les classes de base sont chargées avant celles qui en héritent
   • Un module ne peut référencer que les modules chargés avant lui dans cet ordre
3. Exposition dans le Script Editor : La structure standardisée permet au Workbench d'afficher correctement tous les scripts disponibles dans la vue Projects de l'éditeur de scripts, en les organisant par module logique plutôt que par origine physique.
4. Système de surcharge/extension :
   • Un mod peut étendre ou surcharger une classe du jeu de base
   • Le moteur sait où chercher les classes parentes grâce à l'arborescence
   • Exemple : Un mod ACE peut étendre SCR_BaseGameMode en respectant la même organisation
5. Résolution des conflits : L'organisation modulaire permet au moteur de gérer les conflits de noms entre mods (priorité, ordre de chargement configuré).
6. Compilation et optimisation : Le moteur peut optimiser le chargement en chargeant les modules dans l'ordre correct et en résolvant les dépendances efficacement.

En résumé : l'organisation des scripts n'est pas une simple convention, c'est une exigence technique du moteur Enfusion pour que les scripts soient découverts, compilés et chargés correctement. C'est similaire à la structure de packages dans Java ou de modules dans Python.

Dans le Resource Browser, Arma Reforger présente les scripts en deux racines principales, auxquelles s'ajoutent celles des mods chargés.

1: les deux racines de tout projet de mod Arma Reforger : ArmaReforger et core
2: la racine du projet du mod appelé ES_Sandbox
3: les racines de plusieurs mods chargés avec le projet du mod ES_Sandbox

Chacune de ces racine contient un répertoire scripts (si tant est que le mod en question ait des scripts). Dans les racines par défaut de l'atelier Enfusion (ArmaReforger et core), vous trouverez :

• Core/ - Noyau du moteur Enfusion (classes de base)
• GameLib/ - Bibliothèque de gameplay de base (composants, entités, réplication)
• WorkbenchCommon/ - Scripts des plugins et outils de l'éditeur Workbench (UI, panneaux, actions d'édition)
• WorkbenchGameCommon/ - Scripts exécutés lorsque le jeu tourne depuis le World Editor (preview, debug en éditeur)

• Game/ - Logique de jeu Arma Reforger
• GameCode/ - Code du jeu
• GameLib/ - Extensions de GameLib spécifiques au jeu
• Workbench/ - Scripts des plugins et outils Workbench spécifiques au jeu
• WorkbenchGame/ - Scripts exécutés lorsque le jeu Arma Reforger tourne depuis le World Editor

Si des mods sont chargés, leurs scripts sont présentés dans l'arborescence du mod, suivant la même structure standardisée.

La vue Projects de l'éditeur de scripts montre l'organisation logique des modules de code. Elle regroupe tous les scripts des mods dans la même arborescence logique unifiée.

Projects
├── Engine('scripts/Core')          → core/scripts/Core/
├── Entities                        → reflète l'API C++, mais pas de scripts ES (sauf si scripts d'un mod), donc vide
├── GameLib('scripts/GameLib')      → core/scripts/GameLib/ + tous les GameLib de Arma Reforger et des mods
├── Game('scripts/Game')            → ArmaReforger/scripts/Game/ + tous les Game des mods
├── Workbench('scripts/WorkbenchCommon')         → core/scripts/Workbench/ + tous les scripts Workbench de Arma Reforger et des mods
└── WorkbenchGame('scripts/WorkbenchGameCommon') → core/scripts/WorkbenchGame/ + tous les scripts WorkbenchGame de Arma Reforger et des mods

On trouve bien dans la racine Game des scripts d'un mod chargé (TILWMissionFramework, en l'occurrence)

Les classes accessibles en Enforce Script sont en réalité définies en C++ dans le moteur. Ces classes C++ sont organisées en namespaces — des espaces de noms qui évitent les conflits entre classes de même nom.

Chaque module du Script Editor correspond à un namespace C++ :

Enforce Script masque ces préfixes pour simplifier l'écriture : quand vous utilisez EntityManager, vous utilisez en réalité enf::EntityManager. Les règles de visibilité entre modules sont directement dérivées de ces namespaces C++.

La réponse dépend de ce que fait la classe :

Règle pratique : la grande majorité des scripts de mod vont dans scripts/Game/. C'est le seul module qui a accès à toute la logique du jeu (GameLib, Engine).

• Vous créez un nouveau game mode → scripts/Game/GameMode/MonGameMode.c
• Vous créez un composant de soins réutilisable → scripts/GameLib/Components/MonHealComponent.c
• Vous ajoutez un panneau dans le Workbench → scripts/Workbench/MonPlugin.c