Le ton est donné, je ne vais pas être forcément très tendre avec cette méthode. Déjà parce qu’elle ne correspond pas au standard de Mugen, ensuite parce qu’à force de manipulations, ça peut devenir un grand n’importe quoi dans votre Mugen.

Le principe de la « méthode officielle » consiste donc à installer séparément les screenpacks, de sorte qu’ils peuvent co-exister sans se « parasiter ». On peut donc les activer et les désactiver très facilement, sans faire de manipulations complexes. Le « petit » défaut, c’est qu’on peut se retrouver avec plusieurs screenpacks installés, mais un seul activé, donc tous les autres prennent de la place pour rien. Mais bon, à l’heure où les disques durs de base comptent plusieurs centaines de Go, c’est assez relatif, comme problème…

La méthode « bourrin », elle, consiste à « écraser » le screenpack existant avec le nouveau.

0. Faire une sauvegarde de secours !

Comme on l’a dit, le principe de la méthode « bourrin » consiste à écraser les anciens fichiers par des nouveaux. Le hic, c’est que comme on le verra plus loin (avec le pourquoi), il arrive que ces manipulations ne donnent pas le résultat escompté (le screenpack ne fonctionne qu’à moitié, voire Mugen refuse de se lancer, ou ne fonctionne plus comme vous l’aviez configuré, etc.).

Comme on aura écrasé les anciens fichiers, le seul moyen de faire marche arrière sera de posséder un backup, un copie de sauvegarde.

Que faut-il sauvegarder ? Pour être sûr, les dossiers data/ et font/. Une fois que votre screenpack est installé et fonctionne convenablement et que vous ne souhaitez pas revenir en arrière, n’oubliez pas de détruire votre copie. Bah oui, le principal intérêt de la méthode étant de consommer moins de place, ce serait paradoxal de conserver votre sauvegarde, dans la mesure où l’effet obtenu serait de consommer en fait plus d’espace disque…

1. L’emplacement des fichiers… c’est de l’aléatoire…

L’idée de base, c’est que les fichiers utilisés (system.def, fight.def, etc.) vont se retrouver non plus dans un sous-dossier de data/, mais directement DANS data/, les nouveaux fichiers venant remplacer les anciens.

Seulement voilà, dans Mugen, on peut avoir différent niveaux de complexité dans les screenpacks. Vous pouvez avoir un screenpack basique (comme c’est un peu le cas de celui fourni par défaut). Mais vous pouvez également avoir plus de polices, une intro, une ending, un logo, des crédits, des musiques, etc. qui feront plus de fichiers. Dans le screenpack Castlevania, j’ai même inclus des stages !

Et là, on a deux écoles : certains vont mettre tous les fichiers dans le même dossier (en l’occurrence, data/), alors que d’autres vont juste garder les fichiers essentiels (system.def, et fight.def) à la racine de data/ et placer les autres dans des sous-dossiers (style SFF/ pour les SFF, Music/ pour les musiques, etc.). Du coup, l’architecture d’un SP « bourrin » varie selon le cas.

Ca commence à devenir chaotique lors de l’extraction des fichiers : si certains vont prendre la peine de vous laisser des instructions (on en revient à l’importance des readme), et d’organiser convenablement les fichiers, d’autres vous laisseront vous débrouiller par vous-mêmes : les fichiers seront extraits pêle-mêle, et à vous de deviner dans quel dossier ils vont ! Si pour certains fichiers, c’est assez évident (le system.def va dans le dossier data/), pour d’autres, c’est un peu au hasard (les polices vont-elles dans le dossier fonts/ ou dans le dossier data/ ?).

Comme on parle de remplacement de fichier, vous allez être confrontés inévitablement aux écrans de ce type :

Avec ce que cela implique implicitement : l’impossibilité de revenir en arrière (à moins de faire un backup préalable, ce dont la plupart des utilisateurs se passent même s’ils en reconnaissent l’utilité, et malgré l’avertissement que j’ai mis au point 0…).

2. Activer le screenpack… avec un peu de chance !

Une fois que vous avez placé correctement les fichiers (ou en tout cas, quand vous supposez que c’est le cas), il n’y a rien d’autre à faire. Le fichier système ayant été remplacé, le chemin spécifié dans le mugen.cfg est correctement paramétré (à moins que le nom du fichier système soit différent, mais je n’ai jamais vu le cas jusqu’ici).

Donc, il ne reste plus qu’à lancer Mugen pour vérifier le résultat… et éventuellement constater l’étendue des dégâts !

Là, avec un peu de chance, tout devrait aller à peu près correctement. Dans le pire des cas, vous aurez des éléments qui ne sont pas complémentaires graphiquement (imaginez une interface Mortal Kombat avec des lifebars Street Fighter Alpha, par exemple…), mais qui n’empêche pas Mugen de fonctionner.

Pourquoi ces différences ? On l’a dit avant : les screenpacks sont plus ou moins complexes et comprennent plus ou moins de fichiers. La forme de screenpack la plus basique est la simple interface (les menus, les différents écrans), sans lifebars. Et donc, imaginons que vous ayez installé un screenpack complet « Street Fighter Alpha » (interface & lifebars), et que par-dessus, vous installiez un screenpack Mortal Kombat avec juste l’interface : vos fichiers de lifebars ne sont pas remplacées, et sont donc utilisées avec la nouvelle interface. Maintenant, imaginez ce que ça peut donner après des dizaines d’installations successives : avec tous ces screenpacks « empilés », on se retrouve avec l’interface d’un screenpack, les sons d’un autre, les lifebars d’un troisième, les « FX » (effets lumineux) d’un quatrième, les polices d’un cinquième… Bref, ça devient du beau n’importe quoi.

Mais ce n’est pas le pire qui puisse vous arriver. J’ai vu il y a quelques années un screenpack livré avec un fichier common1.cns. A la base, ce n’est pas très gênant puisque c’est un fichier qu’on modifie rarement. Sauf dans des cas très particuliers. Le premier, c’est quand vous installez un jeu complet. Dans ce cas, le common1.cns peut être modifié (en gros, ce fichier contient le code des actions « courantes » des personnages : marcher, reculer, sauter, etc. : comme ces actions seraient codées de la même façon pour pratiquement tous les personnages, Elecbyte les a codées dans ce fichier, ce qui évite au créateur de personnage de le faire). Pour un Mugen « classique », pas de souci, mais pour un jeu complet, le(s) créateur(s) vont plutôt adapter le common1.cns à leurs besoins plutôt que de réécrire pour chaque personnage toutes les parties de ce fichier qu’ils veulent adapter pour leur jeu. Un autre cas, assez similaire, est celui où l’utilisateur est assez expérimenté et souhaite modifier les actions de base pour tous ses personnages, afin de les adapter à ses désirs. Dans ce cas, il modifiera directement le common1.cns. Et donc, si on installe notre « screenpack de bourrin » sur ces configurations, on perd le common1.cns, avec des conséquences plus ou moins grandes selon les modifications qui avaient été effectuées…

Terminons quand même par le top du top, sur lequel je suis tombé une fois : un inconscient a cru bon d’inclure dans son screenpack le fichier mugen.cfg ! Avec évidemment la ligne « motif » modifiée pour que l’utilisateur puisse « profiter » de son screenpack déjà installé… Seulement, vous devez vous rappeler qu’on a déjà évoqué ici toute l’utilité de ce fichier : il vous permet de configurer Mugen (niveau de vie, vitesse de jeu, résolution, sons…), et notamment les boutons de jeu ! Donc avec un tel fichier, vous perdez tous vos réglages !

Pas bien méchant, me direz-vous, il suffit de tout reconfigurer ! Oui, mais ça, c’est le scénario idéal, ma bonne dame ! Parce que dans les faits, il y a aujourd’hui 90% de chances que vous utilisiez le nouveau Mugen 1.0, et 90% de chances que notre screenpack soit prévu pour une autre version. Et d’une version de Mugen à l’autre, le fichier mugen.cfg a connu de subtiles modifications, si bien qu’au final, vous avez perdu votre fichier avec vos réglages, vous n’avez plus le fichier d’origine, et vous n’avez qu’un fichier mugen.cfg prévu pour une autre version, et qui fera donc planter Mugen lorsque que vous le lancerez !

4. Conclusion

Au départ, ce système d’installation se veut plus simple (on remplace juste les anciens fichiers par les nouveaux), mais à l’arrivée, les failles de cette méthode sont nombreuses, et même dangereuses pour certaines !

Récapitulons la comparaison entre les deux méthodes :

Avantages de la méthode « bourrin » :

  • Mugen prend moins de place (à condition de ne pas faire de sauvegarde de secours)

Avantages de la méthode « classique » :

  • Plusieurs screenpacks peuvent co-exister de façon indépendante,
  • Les fichiers de chaque screenpack sont dans des dossiers séparés ce qui évite les mélanges hasardeux,
  • Ce système de sous-dossiers facilite l’extraction des fichiers,
  • Avec ce système, on sait où trouver tous les fichiers d’un même screenpack (pratique pour la suppression),
  • Si un screenpack pose problème, il est possible (et très simple) de revenir en arrière,
  • On peut désactiver un screenpack sans le désinstaller,
  • La méthode d’installation est toujours la même,
  • On ne touche pas aux fichiers « système » de Mugen comme le common1.cns ou le mugen.cfg, et on ne risque donc pas de perdre ses réglages.

Si vous avez le choix entre un screenpack « bourrin » et un screenpack classique, vous savez désormais lequel choisir, et si vous décidez de créer des screenpacks, vous savez également quelle méthode d’installation choisir…

Laisser un commentaire

Vous devez être connecté pour laisser un commentaire. Connexion »