Metadata des missions

[ArwynFr]

C'est une demande assez compliquée à mettre en œuvre.

Actuellement les fichiers de mission sont nommés au format side2 ou highwatch1. Le fonctionnement du moteur fait que la liste des missions actives doivent être numérotées de manière continue, donc quand on désactive une mission, il faut renommer toutes les missions numérotées au-dessus. Git a alors l'impression que le fichier de l'ancienne mission est modifié avec le contenu de son successeur, et il recherche les différences dans les fichiers, ce qui n'a pas de sens puisque fondamentalement on travaille sur une mission qui n'a rien à voir.

Idéalement il faudrait trouver un système de metadata pour les missions, permettant de gérer chaque mission dans un fichier qui ne soit pas renommé, et qui gère le type de mission (main vs side), le secteur / fob associé, si la mission est active ou non.

[ImplicitDeny]

Il y a un système : stocker le nom de absolument tous les fichiers de missions devant être considérés comme valides en dur dans l'initialisation du moteur. On pourrait toujours déporter ce genre d'éléments vers un autre script, mais le principe reste le même (et il est un peu sale...).

Il n'y a pas moyen en SQF de parcourir un dossier et d'en trouver le contenu, on est obligé de connaître le nom de la cible à l'avance, pour des raisons de sécurité. Donc soit on stocke tous les fichiers de mission en dur, soit on se repose sur un système de nom "déduit", ce qui est actuellement en place.

J'ai vu en effet sur une des sides mises en ligne récemment que Git était un peu déconcerté. Ca ne m'a pas vraiment satisfait, comme situation, mais pour le moment je n'ai pas d'idée :/

[ArwynFr]

Est-ce que l'utilisation de classes permettrait de gérer cette fonctionnalité ?

[ImplicitDeny]

Développe ta pensée ? L'utilisation d'une classe "mission" abstraite, et de classes filles "main" et "side" pouvant être instanciés ? Dont l'un des attributs serait le chemin vers le script de mission ?

[ArwynFr]

En gros oui.

Je pense à un fichier contenant une liste de classes, chacune correspondant à une mission et contenant ses metadata : type, fob, secteur, activé, script etc ... Avec des classes parent si c'est pertinent pour ne pas tout répéter. Ensuite le moteur n'a plus qu'à charger les classes, choisir une mission qui répond à ses critères, puis la charger avec le chemin vers le script qui est dans la classe.

[ImplicitDeny]

L'ennui c'est qu'il n'y a aucune véritable notion de classe en SQF... Il y a bien des solutions de contournement, mais rien de vraiment plus pratique. A moins que tu aie quelque chose en tête auquel je n'ai pas pensé ?

[ArwynFr]

L'ennui c'est qu'il n'y a aucune véritable notion de classe en SQF...

Pardon ? https://community.bistudio.com/wiki/Class_Inheritance https://community.bistudio.com/wiki/configClasses

Et ça c'est quoi ?

[ImplicitDeny]

C'est comme le port-salut, c'est écrit dessus. "Returns an array of config entries which meet criteria in condition code."

Chez BIS, l'orienté objet existe dans une certaine mesure, mais dans le système de config uniquement. En gros, dans les fichiers .cpp qui définissent les propriétés des objets dans tous les addons.

Côté mission, ou code exécutable, l'orienté objet n'existe plus. On peut seulement instancier des objets déjà existants dans la config, avec createVehicle ou createUnit par exemple. On a également quelques possibilités de getter personnalisés, moyennant une syntaxe moche. On a aussi quelques reliquats sous la forme de getVariable/setVariable qui vont créer, modifier et lire des attributs dans l'espace de noms d'un objet donné.

Il n'est donc pas possible de définir une classe en SQF. Et pas possible non plus d'utiliser le langage de script pour modifier des propriétés d'une classe telle que définie dans la config.

A moins qu'il soit possible de créer des classes personnalisées dans le description.ext (qui est un fichier de config qui ne dit pas son nom), je vois pas. Et à ma connaissance ce n'est pas possible, mais ça vaut le coût de vérifier.

[ArwynFr]

Pour info : https://community.bistudio.com/wiki/Mission_Overview

[ImplicitDeny]

Holy cow, c'est bel et bien possible... J'ai eu une coupure d'internet hier soir donc je n'ai pas pu corriger mon message, mais j'ai fait quelques tests et il est en effet possible d'insérer de la config personnalisée dans le description.ext, config qui n'aura aucun sens pour ArmA mais le jeu se contente de l'ignorer, et non pas de la dropper comme je le pensais initialement. On peut donc ensuite, via script, lire le contenu de cette config sans aucun soucis. On peut l'utiliser pour déterminer les zones disponibles, les missions principales, secondaires, tout...

Enfer et damnation... Que de pouvoir soudainement à disposition...

Ton lien de doc n'ajoute rien de particulier si ce n'est la possibilité de packer notre mission comme un addon, moyennant un rapide bricolage. Les outils pour packer des missions ne semblent pas très externalisés, mais les outils pour packer un addon ça oui. Le plus évident est AddonBuilder de BIS, contenu dans les ArmA Tools, qui fonctionne en mode GUI ou en ligne de commande il me semble. Ca va peut-être résoudre notre problème d'intégration continue.

En bref, bien vu mon cher, tu as eu du pif sur ce coup-là ! :)

[ImplicitDeny]

Du coup je m'interroge, ça vaudrait peut-être le coût de se lancer de suite dans ce chantier. Mais j'ai quelques sides déjà dans les tuyaux, j'ai peut-être intérêt à les boucler et à les merge dans develop avant de créer la nouvelle branch. Il me faudrait donc quelques jours de travail.

[ArwynFr]

Petite découverte, le format addon ne permet pas au jeu de le télécharger la mission ingame comme avec le format mission classique. Il faudrait donc ajouter la mission au modpack LM et le mettre à jour à chaque nouvelle version de la mission. C'est peut-être un peu contraignant !

[ImplicitDeny]

C'était l'une de mes interrogations, effectivement c'est un peu contraignant. Mieux vaut rester au format mission, du coup.