Salut tous, juste pour donner des petites idées :

Avez vous essayé d'utiliser un outil de gestion de configuration de code source pour gérer vos fichiers de config de DCS ?
Perso j'utilise Mercurial (c'est gratuit, ça vient avec une GUI très pratique, TortoiseHg) et 3 dépôts pour tout gérer (pour éviter de surcharger le dépôt, les fichiers autres que texte sont filtrés par le .hgignore) :
- fichiers de config dans DCS
- fichiers de config dans Saved Games\DCS
- fichiers de configuration TARGET

Voir ici: http://tortoisehg.bitbucket.org/

Du coup j'ai une branche "Stock" que j'utilise seulement pour les mises à jour DCS, une branche "My" dans laquelle je mets mes modifications perso.
Après si je veux faire des tests je démarre une branche secondaire depuis "My" (par exemple pour tester le DSR).

Ça évite de perdre des choses lors des mises à jour de DCS car au lieu d'écraser les fichiers modifié par ceux d'un mod (ex: MoreVisibility) ou d'un dossier _backup, je fais une fusion et les nouvelles choses ne sont pas écrasées.

Les mods qui installent des textures et des objets 3D je les installe toujours avec JSGME car mes dépôts ne gèrent que les fichiers texte.

Je vous souhaite bien du fun

Cliquez pour voir le fichier-joint

Saved Games\DCS\.hgignore:


DCS World\.hgignore

Alors moi perso j'ai absolument rien compris à ce que tu dis. Ca doit être un truc pour ceux qui parlent en Assembleur couramment.

Haha évidemment il faut avoir déjà utilisé ce genre de soft, mais le pas est vite franchi

Il doit y avoir de bien meilleurs tutoriaux mais je vais essayer de résumer avec mes mots:

Un gestionnaire de configuration est un outil qui va garder une trace des versions successives de fichiers que tu vas mettre dedans, il est capable de restaurer n'importe quel fichier dans une version choisie.
Quand ces fichiers sont des fichiers texte (ça peut aussi fonctionner avec des documents type Word/Excel), L'outil va être capable de fusionner les fichiers, on s'en sert beaucoup pour le code source.

Les fichiers sont gérés en "branches", une branche est une succession de versions de fichiers.

Par exemple dans la branche "Stock" je vais mettre toutes les versions successive à chaque update de DCS.
Et dans la branche "My", je vais mettre mes configurations personnelles.

À chaque nouvelle version de DCS, je vais restaurer les fichiers dans la dernière configuration "Stock", mettre à jour, et créer une nouvelle version (dans la branche "Stock").
Ensuite je fusionne les différences de la nouvelle version "Stock" dans la branch "My".

Exemple pour un fichier donné:
Stock =
A
B
C
Ma modif =
A
B
x

Mise à jour DCS, le fichier devient =
y
B
C
L'outil va savoir que "A" a été changé en "y" dans la branche "Stock" et que dans la branche "My", "C" est changé en "x".

Une fois la mise à jour DCS faite, je souhaite importer les modifications de la nouvelle version dans la branche "My".
Si je fusionne "Stock" vers "My", l'outil va créer une nouvelle version de fichier intégrant les deux modifications =
y
B
x

Je vais ranger cette nouvelle version de fichier dans la branche "My".

Si des modifications sont faites au même endroit (sur la même ligne), il va y avoir un conflit et l'outil me laissera choisir comment je veux le régler.
À tout moment je peux vérifier la différence entre deux ou trois (pour une fusion) versions de fichiers pour voir ce qui a changé et si la fusion c'est bien passée.

Si je prends un exemple tout bête, le MOD MoreVisibility, il va écraser le fichier graphics.lua.
Le problème est que la nouvelle version de DCS a rajouté une ligne plus haut dans le fichier:
"./FUI/Fonts/",
Si j'écrase le fichier avec celui du MOD, je vais perdre cette nouvelle ligne, alors que si je fusionne, non.

Bon, ok j'ai compris maintenant, mais c'est quand même un truc qui doit surtout étre répandu chez les codeurs fous.

Oui, très utiles pour les informaticiens, les SCM (Source Code Management) sont tout simplement incontournables... pour une pratique on va dire avancée. Après avoir utilisé un peu mercurial, c'est surtout git que j'utilise personnellement et professionnellement : mais même avec un public de développeur, force est de constater que savoir utiliser un SCM a peu près correctement n'est pas ce qu'il y a de plus répandu même avec un public sensé être à l'aise.

Le développement de DyMOD est fait pour répondre à ce besoin: JSGME est à la ramasse, il me fallait faire un truc: dans mes premières réflexions, j'avais envisagé d'utiliser git en backend, mais finalement, le front-end est tellement simplifié par rapport à git, que j'ai eu plus vite fait de coder ma propre gestion de SHA1, que de m'adapter à lui.

Yep, j'utilise aussi un dépôt Git pour l'install, et un autre pour le saved games/ depuis des années. C'est devenu une nécessité pour mettre à jour la kilotonne de mods en même temps que DCS, et surtout pour trouver le fauteur de trouble quand on se rend compte du problème X semaines plus tard après avoir effectué 100+ commits. Ca me sert aussi pour produire un *vrai* changelog lors des updates, ils ne nous donnent pas le dixième des infos via le canal officiel.

Je confirme... Il y en chez qui ça ne percute pas, tout simplement...


Gères tu les fichiers binaires aussi ? J'ai hésité à les rajouter de crainte de faire enfler mon dépôt de manière démesurée. Le seul gros pb avec Mercurial est qu'il n'est pas aisé de couper une partie des anciens commits, la seule solution est souvent de recréer un nouveau dépôt, ce n'est pas pratique.

Ça vous embête de parler français...

Seulement ceux qui sont moddés, pour les autres j'utilise BeyondCompare entre les mises à jours ED. Pour limiter la taille du du dépôt, entre chaque update je fais une remise à zéro avec le dernier état du précédent en commit initial, puis je "fige" la version précédente dans un backup. Même procédure pour le "saved games". Ca prend 5 minutes et c'est propre =)