veafSpawn: simplify and rationalize the selection of the air templates

[MacFlorent]

Situation

When an air unit is to be spawned by veafSpawn.findSpawnableAircraftGroupname looks for a group matching an input name in a pre-established list of templates. These templates are all the groups of the mission with a name starting with veafSpawn-.

Among these groups, will be preselected those that regex match either:

• A regex built around the input name ".*" .. (nameUpper or ".*") .. ".*", so all the groups with a name that contain the input name. In this case, it is expected of the caller to give an input name that is a usable regex.
• Exactly the input name, after it has been cleaned of potential regex characters by veaf.escapeRegex.

Problems

veafSpawn- prefix is too limitative

veafSpawn is used:

• With predetermined group templates, which will be hard coded in specific commands (-afac and -cap).
• From a user trigger in a unit of the ME or directly from a marker in-game.

In the first case, since the names as hard coded, no need for a filter. On exception may be when the input name is empty (-cap), in that case the filter could be kept.
In the second one, the filter is actually a bad thing because the end-used, mission maker or player, must be aware of this mechanic to be able to efficiently use veafSpawn. We can also note that the veafSpawnableAircraftsEditor tool will override all veafSpawn- groups when the mission is built (build.cmd), complicated again the usage.

So, there is no need to limit the groups eligible. All groups should be considered.

Name matching is not great

Regex cleanup is not great. The double matching seems sketchy.
There is no need for a full regex matching. A simple "starts with matching" is sufficient and way clearer.

An exact matching would also be better in some cases, but maybe it is too complicated to implement both modes. Unless, maybe with something in the content of the input name, like "name*" would match starting with "name"?

Remediation

What I want to do is rethink veafSpawn.findSpawnableAircraftGroupname.
All regex mechanic will be removed.
The name parameter will be optional.

When name is provided

The method will try to find a group matching name among all groups in the mission.
If the name parameter ends with a "*", all groups with a name that matches or starts with the parameter value will be eligible.
If the name parameter DOES NOT end with a "*", only the groups with a name matching exactly the parameter value will be eligible (so, only one group).

When name is NOT provided

The method will select a group among the groups with a name starting with the veafSpawn- prefix.

Usage

Check all usages of the method.
-cap should not provide name
-afac should give a correct value ending with "*" (this will have to be sync with veafSpawnableAircraftsEditor as well, see below)

Additional remarks

Specifically for the -afac.
veafSpawnableAircraftsEditor needs to have its contents clarified.

• In the current MC settings.lua does not contain ant Reaper group.
• In older settings.lua in the MC it contains Reapers with names like "veafSpawn-mq9-hellfire".
• In the MCT there is some with names like "veafSpawn-MQ-9 - AFAC - JTAC - DRONE".

Which one is used? What should be the correct content?
Another issue should be opened to study these problems.

[davidp57]

Je te renvoie aussi à #240

[davidp57]

Bonne initiative dans l'ensemble, merci.

Mes commentaires suivent:

the veafSpawnableAircraftsEditor tool will override all veafSpawn- groups when the mission is built

Pas tout à fait vrai, il ne fait qu'ajouter les patrons qu'il a, mais ne supprime pas d'éventuels trucs en plus que le mission maker aurait ajouté (ou alors y'a un bug ^^)

A simple "starts with matching" is sufficient and way clearer

Pas trop d'accord, en fait ça permet de faire des trucs du genre -cap hard et ça te chope un truc au pif dont le nom contient "hard"; pratique je trouve.

Which one is used? What should be the correct content?

Alors ça c'est un très bon point; j'essaie petit à petit de rapatrier toutes les config par défaut des différents outils dans le répertoire ("defaults")[https://github.com/VEAF/VEAF-Mission-Creation-Tools/tree/master/src/defaults], mais j'ai pas encore fini.
Idéalement les outils comme le MC devraient avoir les mêmes defaults que ceux présents dans ce folder.

[MacFlorent]

J'ai constaté que ça supprime tout, ce qui était l'origine du problème d'ailleurs.
Impossible d'ajouter un groupe veafSpawn-mq9-unarmed car il est supprimé.
Impossible de faire un -afac avec un group non veafSpawn- car ils sont ignorés par veafSpawn.

Et cela semble délibéré, enfin si je comprends bien le code.

[davidp57]

Ah ben oui t'as raison, au temps pour moi; je confonds avec autre chose (les waypoints sans doute).
Clairement, ça serait bien de faire comme pour les wp, à savoir on ajoute uniquement les avions qui manquent, non ?

[MacFlorent]

Au sujet de l'injecteur

Le smiley signifiait que je suis hésitant. Je le suis toujours. Je trouve que c'est pas mal de réserver les préfixes "veafSpawn-" aux mécaniques standardisées dans les VMCT. Ce que tu proposes donnerait plus de flexibilité, mais finalement quel en serait l’intérêt réel ?

Si on fait les modifications de cette issue pour que veafSpawn prenne tous les groupes, un MM un peu dégourdi comme Sharko pourra faire ses groupes sans préfixe et les mettre dans des commandes en indiquant le nom ou un pattern de nom.
Pour les MM qui voudraient modifier les mécaniques standardisées, on peut supposer qu'il seront assez débrouillards pour modifier le settings.lua. On pourrait d'ailleurs proposer plusieurs settings.lua prédéfinis pour différentes périodes, types de mission, coalitions...

En finissant d'écrire ce commentaire, je pense que je penche plus pour ne pas modifier l'injecteur.

Au sujet du regex

I agree to disagree :)
Je comprends ton point de vue. Mais je reste convaincu que ça n'en vaut pas la peine. En pratique, personne ne va se servir de ce genre de fonctionnalités.
Et ce qui m'embête, c'est que de vouloir gérer un regex implique :

• Une connaissance de cela par les MM, car pour que le paramètre soit un regex propre, il faut que les unités soient toujours nommées en conséquence dans l'éditeur.
• Un code plus compliqué à lire, à maintenir, et des cas à problèmes difficiles à analyser. L'utilisation du double matching avec le regexEscape (qui est approximatif) en est le témoin.
• Impossible de forcer un groupe si son nome est similaire à d'autres groupes. Cas du "MQ-9" tout court, qui doit être renommé en "MQ-9-unarmed", sans quoi impossible de le sélectionner spécifiquement.

Maintenant, comme ton exemple est un simple like '%name%' qui ne nécessite pas un regex, on pourrait aussi simplement étendre ma proposition pour gérer juste cela.