De l'usage des mods assets additionnels - proposition

Cf. les débats suscités par le big asset pack, la demande d’Olivier de voir le HMS Hermes utilisé par chez nous, et l’intérêt que cela a renouvelé sur ce sujet .

Inspiré de la friction positive de nos idées avec @Zip , je vous soumet la proposition suivante sur une manière d’appréhender, par le plan organisationnel la possibilité d’intégrer de tels mods dans nos missions.

Les lignes directrices de la proposition

pas de changement brutal et d’imposition généralisée d’un quelconque big asset pack
éviter les errements et déplaisirs connus liés à l’imposition généralisée d’un pack de mods énorme en taille et trop souvent mis à jour
ouvrir le plus largement possible la possibilité aux missions makers d’intégrer des mods qui les intéressent dans leurs missions
imposer une progressivité à l’intégration de cette possibilité afin d’en maîtriser et objectiver (par la pratique) les effets

Côté serveur

conserver un serveur publique DCS sans mods, afin d’assurer une ouverture et un accès le plus large possible à celui-ci (objectif de communication dans l’ouverture publique H24), ainsi qu’une stabilité garantie
le serveur publique sans mods constitue ainsi au passage une référence sur laquelle nous pouvons toujours nous appuyer pour la continuité de nos activités en cas de difficulté rencontrée sur le serveur privé
le serveur privé doit être le seul sur lequel des mods assets additionnels peuvent être installés
tout mission maker doit pouvoir demander l’ajout d’un mod asset additionnel au serveur privé

S’agissant de l’installation des mods assets additionnels je vois deux options :

soit les admins serveur prennent cette charge et le suivi qui va avec,
soit on ajoute un accès ftp sur les répertoires mods et Liveries des users files du serveur privé dont on accorde l’accès aux missions makers, charge aux missions makers de communiquer sur les mods mis en place

Dans les deux cas, le sujet Big Asset Pack pourra être renommé en sujet de suivi des mods assets installés sur le serveur privé.

Utilisation de ces mods additionnels dans les missions

Au sein de la 735th, des créneaux d’activités “officielles” sont assez bien identifiés :

lundi soir
mardi soir
vendredi après-midi

Il convient de distinguer l’usage sur ces créneaux de l’usage en dehors de ces créneaux.

Sur les créneaux de vols officiels

Afin d’assurer progressivité et d’éviter des déconvenues trop régulières, je propose de limiter le recours à de tels mods uniquement sur la dernière semaine du mois et à condition que les mods utilisés sur le créneau concerné soient annoncés dans un sujet d’organisation sur le forum au moins une semaine avant.

Charge aux participants de suivre l’organisation de l’activité et préparer leur DCS en conséquence.

En dehors des créneaux de vols officiels

Je propose de ne mettre aucune restriction sur l’usage des mods, avec le serveur privé, en dehors des créneaux identifiés comme officiels.
Charge à l’organisateur d’une activité de communiquer et s’entendre avec les participants à son activité pour que tout le monde ait bien ce qu’il faut.

Installation des mods côté client

La modeste expérience du Big Asset Pack montre que celui-ci devient très vite, très volumineux, et sa taille peut augmenter encore très rapidement…

Ce n’est manifestement pas la bonne approche.

Je pense qu’il vaut mieux passer par une gestion plus unitaire de ces mods additionnels.
OvGME permet de très souplement et efficacement réaliser cette gestion unitaire.

Je propose donc de passer plutôt tous ces mods en format individuel OvGME.

Charge aux organisateurs d’activités de bien communiquer sur les mods utilisés.
Charge aux participants de bien gérer leur installation (beaucoup d’efforts en tutos et accompagnements sont réalisés pour y aider, un juste retour est que chacun se prenne en main).

Feedbacks sur les mods utilisés

Il serait bien de systématiser du feedback sur les mods utilisés à chaque fois que c’est le cas, au niveau du sujet forum qui leur est dédié.
Le but est d’objectiver l’usage de chaque mod installé au niveau du serveur sur les points suivants :

le mod est-il concrètement utilisé
l’utilisation du mod a-t-il effectivement apporté quelque chose à la mission jouée

Le but, en se donnant du temps et la progressivité évoquée en tête de sujet, c’est de pouvoir faire du tri si c’est requis, et c’est aussi de savoir dire à tout nouveau venu quels sont les mods les plus couramment utilisés selon son ou ses créneaux de vol de prédilection.

Voilà la proposition.
Désolé c’est beaucoup de blabla.
Cela me semble être néanmoins une bonne façon de pouvoir contenter tout le monde, en douceur .

Zip

Merci d’avoir synthétisé tout ça, merci pour les propositions.
Globalement, bonnes idées (une partie viennent de moi, donc c’est normal ) et je rebondis juste sur quelques points :

soit les admins serveur prennent cette charge et le suivi qui va avec,

C’est à mon sens la seule option valable, techniquement.
Il sera impossible de garantir la stabilité des serveurs si on ne maitrise pas complètement leur configuration.
Donc, veto pour moi quant à la possibilité de laisser des membres ajouter/supprimer des mods.

J’en profite pour rappeler qu’il existe deux types de mods, que nous avions nommés user files et game files.
Dans le DCS moderne, la plupart des mods assets sont user files, mais pas tous.
Or les deux serveurs partagent une base d’installation (en gros, c’est le même jeu installé une seule fois).
Donc, il n’est pas possible d’utiliser des mods game files.

Je pense qu’il vaut mieux passer par une gestion plus unitaire de ces mods additionnels.
OvGME permet de très souplement et efficacement réaliser cette gestion unitaire.
Je propose donc de passer plutôt tous ces mods en format individuel OvGME.
Charge aux participants de bien gérer leur installation (beaucoup d’efforts en tutos et accompagnements sont réalisés pour y aider, un juste retour est que chacun se prenne en main).

Tout à fait d’accord sur l’approche unitaire, et tout à fait d’accord aussi sur l’utilisation d’OvGME.
Les tutos sont faits, les membres sont formés (tiens, ça sonnait moins graveleux dans ma tête ça) et sont tout à fait capables de maintenir à jour une collection de mods VEAF - voir ce qu’on a fait pour les skins.
Je propose de créer dans notre repository VEAF user files des mods dont le nom indiquera explicitement qu’ils font partie des mods obligatoires pour nos missions.

Charge aux organisateurs d’activités de bien communiquer sur les mods utilisés.

Ça sera bien plus simple d’avoir un pack de mods obligatoires (qui bien sur peut évoluer), qui sera maintenu par un admin avec l’aide et les propositions des mission makers, et dont les modifications seront clairement documentées dans le forum (par exemple, on pourrait ajouter une pastille dans l’encart version des clients ou des messages d’alerte comme je fais quand je mets à jour le serveur).
De cette manière, pas de surprise au moment des missions : les mission makers savent ce qu’ils peuvent utiliser (c’est ce qu’ils ont d’installé, puisqu’ils sont membres également et doivent suivre la règle eux aussi), les participants ont les mods en arrivant, et le serveur est en permanence à jour.

Feedbacks sur les mods utilisés

Très bon point !
Comme c’est très subjectif de déterminer si, oui ou non, un mod est “utile” avant coup, on l’accepte systématiquement (sauf contrainte technique - décision laissée à la discrétion des admins serveur) et on évalue après.
Je suis fana !

Jed

Même si je suis intéressé sur le principe par les mods pour les possibilités offertes (par exemple j’aime beaucoup le A-4C) :

Il faut garder un set de mods qui ne casse pas l’IC
Les mods ne permettent pas en pratique d’avoir des missions publiques
Maintenir ces mods à jour sur tous les clients me semble compliqué (cf. discussions passées et situation actuelle avec DCS open beta/stable, SRS, tacview etc…)

Je trouve que :

avoir des mods serveur qui ne demandent rien au client c’est OK (mais maintenir une liste claire, eg. le mod pour réduire la précision des unités est-il toujours installé/nécessaire?)
Avoir un pack limité de mods clients optionnels (eg. skins, docs) pourquoi pas, mais c’est pas mal d’efforts pour peu de résultats
Avoir un pack de mods nécessaires pour rejoindre la mission, ça devient compliqué à gérer, et il faut qu’il soit le plus restreint possible pour limiter les impacts de gestion et sur les clients (eg. pas de “nice to have”), du coup je suis moins motivé…

EDIT : Pour le contexte, dans les mods de la troisième catégorie j’utilise le A-4 et le civil air traffic. J’ai utilisé le pack d’unités FR aussi. Même si je m’en sers en solo, je suis peu convaincu que leur inclusion vaille l’effort nécessaire…

Je ne parle que de mods en user files, aucun mod sur le core DCS. Donc sans impact sur l’IC.

Je reste contre l’idée d’un pack obligatoire, c’est trop contraignant et source de désaccords.

C’est très largement gérable à partir du moment où :

on limite la situation où les mods peuvent être nécessaires - d’où l’idée de limiter à la dernière semaine du mois,
les organisateurs d’activités communiquent bien sur le contenu de ce qu’ils organisent
les participants s’intéressent un minimum aux activités organisées
on s’appuie tous sur OvGME pour une gestion simple et efficace

@Jed :

des mods assets additionnels qui ne demandent rien au client, ça n’existe pas …
les mods clients optionnels ça existe déjà, c’est déjà utilisé et en place (cf. les liveries VEAF), c’est tout dans ce topic : https://community.veaf.org/topic/303/ovgme-veaf-dcs-user-file-mods . Mais ce n’est pas le sujet désolé .
utilises-tu les repositories OvGME que nous avons mis en place pour la VEAF ? Tu confirmes que tu trouves que c’est compliqué à gérer côté client ?

Le point d’achoppement, ce sont les activités sur les créneaux officiels.
Si on ne converge pas sur ce sujet, alors on interdit l’utilisation de mods sur les missions dans ces créneaux, et on ne les autorise que pour en dehors de ces créneaux.