Manager & événements — DM.Manager

Classe définie en sources/DynamicMission.lua:3330-4995 (section complète, entête incluse : 3324-4996).

Événements DCS écoutés

Liste exhaustive du dispatcher onEvent() (:4108-4128) — aucun autre identifiant d'événement n'est testé.

Événement	Handler	Rôle
S_EVENT_BIRTH	_handlePlayerBirth _syncDynamicGroupToDB	Restriction du menu F10 régions au joueur désigné (voir plus bas) ; synchronisation de tout groupe spawné dynamiquement dans groupsByName, sinon invisible à makeUnitTable()
S_EVENT_LAND	_handleLanding	Spawn de défenses pour la coalition du joueur atterrissant (voir Bases aériennes)
S_EVENT_BASE_CAPTURED	_handleBaseCaptured	Mise à jour coalition + re-check statut CLEARED (aucun spawn)
S_EVENT_CRASH	_handleCrash	Journalisation diagnostique + nettoyage comptable
S_EVENT_PILOT_DEAD	_handlePilotDead	Idem
S_EVENT_UNIT_LOST	_handleUnitLost	Idem

Les trois handlers de nettoyage (_handleCrash/_handlePilotDead/_handleUnitLost) convergent vers _cleanupUnitFromActiveGroups(), qui ne détruit rien lui-même : il journalise l'appartenance de l'unité détruite (groupe de région géré par DM, ou groupe de défense de base — dans ce dernier cas, purge immédiate de airbase.defenseGroups). Le retrait effectif de region.activeGroups se fait paresseusement, au prochain runCycle(), pas de façon synchrone sur l'événement.

Restriction du menu F10 régions à un joueur désigné

_handlePlayerBirth() est court-circuité si DM.Config.DEBUG_MODE est actif (le menu régions est alors construit globalement pour tout le monde).

DM.Config.DESIGNATED_PLAYER_NAME (défaut "") contrôle qui a accès au sous-menu F10 → DM → RG (voir Régions). Le droit suit le nom du joueur, pas un slot ou un groupe fixe — il est réévalué à chaque S_EVENT_BIRTH via DM.Manager:_handlePlayerBirth().

• Si DEBUG_MODE est actif, cette restriction est entièrement court-circuitée : le menu régions est construit globalement pour tout le monde.
• Hors debug, à chaque naissance de joueur : sortie immédiate si l'unité n'a pas de nom de joueur (IA) ou n'en est pas une (ex. Jerrycan statique) ; sinon le menu {"DM"} est retiré du groupe puis, seulement si le nom du joueur correspond exactement à DESIGNATED_PLAYER_NAME, reconstruit via _buildRegionsMenuTree() — ce joueur précis obtient le menu.
• Pour tout autre joueur (ou si DESIGNATED_PLAYER_NAME == ""), le menu {"DM"} est simplement retiré du groupe, sans reconstruction — aucun menu régions visible.
• Reconstruit à chaque naissance du joueur désigné quel que soit son slot ou sa coalition, et retiré de tout groupe repris par un autre joueur — évite qu'un joueur héritant d'un ancien slot du désigné garde le menu par accident.

Avec la valeur par défaut (""), personne ne voit ce menu hors DEBUG_MODE.

Séquence de démarrage

DM.Manager:start() s'exécute automatiquement en bas de fichier — sans garde, donc le script s'auto-initialise dès son chargement — en 10 étapes : validation config → scan de mission (reconstruction de zonesByName/groupsByName, instanciation des régions RG_*, scan des bases et des gabarits AD_*) → vérification de cohérence (chevauchements de polygones via SAT, paires MG_/SZ_ par tag) → liaison bidirectionnelle bases↔régions → nettoyage des Jerrycans résiduels → ancrage des bases neutres → resynchronisation des coalitions → activation initiale → démarrage des schedulers, enregistrement du handler d'événements, construction des menus F10.

Point bloquant

Un chevauchement de polygones ou une paire MG_/SZ_ manquante est traité comme critique et arrête toute l'initialisation — rien d'autre ne s'exécute, DM.Manager._initialized reste à false.

Schedulers

• Proximité (30 s) — toujours démarré.
• Auto-activation (AUTO_ACTIVATION_CHECK_INTERVAL, 60 s par défaut) — démarré uniquement si TYPE_CONTROL == "TERRAIN" ; s'auto-termine si la valeur change à l'exécution.