Conflits de maps FiveM : MLO qui clignote, props manquants

Vous ajoutez un nouveau MLO, redémarrez le serveur et allez le voir. Le bâtiment est là, mais le commissariat de l’autre côté de la ville clignote désormais, un parking a perdu ses lampadaires et un mur de l’intérieur disparaît quand vous vous en approchez. Rien dans la console n’explique pourquoi. C’est un conflit de maps, l’un des problèmes les plus courants sur tout serveur FiveM qui fait tourner plus de deux ou trois maps. Ce guide explique d’où viennent les conflits, comment reconnaître lequel vous avez, et comment les régler sans passer une soirée dans CodeWalker.

Pourquoi les maps entrent en conflit

La plupart des maps ne construisent pas la ville de zéro. Elles modifient des morceaux de GTA V qui existent déjà : elles déplacent une clôture, suppriment un lampadaire qui gêne, ou percent l’occlusion d’un bloc pour que leur intérieur s’affiche. Pour cela, elles livrent leur propre copie d’un fichier du jeu de base, avec le même nom que l’original.

Les ennuis commencent quand deux resources livrent une copie du même fichier. Le jeu n’en charge qu’une : celle de la resource qui démarre en dernier. Tout ce que l’autre map avait modifié dans ce fichier disparaît tout simplement.

ensure pd_mlo
ensure burgershot_mlo
ensure street_lights

Si les deux MLO streament dt1_05_strm_1.ymap, seule la copie de burgershot_mlo se charge. Les modifications du commissariat n’arrivent jamais dans le jeu, et son intérieur est donc dessiné avec le bloc d’origine autour. Inverser les deux lignes n’y change rien : cela déplace seulement la casse vers l’autre map.

Les types de conflit et ce qu’ils cassent

Le type de fichier en dit long sur ce que vous verrez en jeu. Voici ceux que vous rencontrerez le plus souvent.

Map qui clignote (conflit d’occlusion)

Pour économiser du travail, GTA V ne dessine pas ce qu’il croit caché derrière les murs. Ces bloqueurs invisibles s’appellent des occluders et vivent dans les fichiers .ymap. Un MLO doit retirer les occluders qui masqueraient son intérieur. Quand la copie d’une autre map l’emporte, les anciens occluders reviennent : l’intérieur clignote, disparaît quand vous approchez, ou vous voyez à travers les murs jusque dans le vide.

Conflit de placement des props (.ymap)

Un .ymap dit aussi quels objets se trouvent où : bâtiments, props, LODs, lumières, herbe, et même les endroits où apparaissent les voitures garées. Quand deux maps modifient la même et qu’une seule copie se charge, vous obtenez des props manquants, des bâtiments qui apparaissent et disparaissent, des lampadaires qui ne s’allument pas, ou un arbre qui pousse au milieu d’un nouveau garage.

Conflit d’archetypes (.ytyp)

Un .ytyp définit les objets eux-mêmes : quel modèle utilise un prop, à quelle distance il reste visible et, pour les MLO, les pièces et les portails à l’intérieur. Si deux copies ne sont pas d’accord, des props s’affichent avec le mauvais modèle ou pas du tout, et un intérieur peut perdre une pièce.

Conflits de collision et de modèles 3D (.ybn, .ydr)

Un .ybn est de la collision : ce sur quoi vous marchez et ce qui vous arrête. Un .ydr est un modèle 3D. Un conflit ici se voit quand vous traversez des murs, rencontrez des barrières invisibles, tombez à travers un sol, ou voyez un prop à la mauvaise forme ou aux mauvaises textures. Ces fichiers sont des objets entiers et non des listes de modifications : il n’y a donc rien à combiner. Vous décidez quelle copie doit l’emporter et vous vous assurez que cette resource démarre en dernier.

Le régler à la main

Jusqu’ici, la correction habituelle ressemblait à ceci :

1. Chercher dans toutes les resources les fichiers de même nom.
2. Ouvrir chaque copie dans CodeWalker et les comparer entité par entité.
3. Copier les props, occluders et lumières d’un fichier vers l’autre, et supprimer ce qu’une map a retiré.
4. Enregistrer le résultat dans une nouvelle resource, renommer ou supprimer les originaux, et régler correctement l’ordre de démarrage.
5. Redémarrer, se rendre à chaque endroit modifié et espérer que rien d’autre n’a cassé.

Pour un seul fichier, c’est une heure de travail minutieux. Un gros serveur en a des dizaines, et dès qu’une map est mise à jour, tout est à refaire. C’est aussi facile de se tromper : si vous oubliez un occluder, le clignotement reste.

Les fusionner en quelques clics

Le Map Merger de l’application de bureau FiveDock fait ce travail à votre place. Il lit votre server.cfg, trouve chaque .ymap et .ytyp que plus d’une resource démarrée streame, et replie chaque groupe de copies en un seul fichier qui conserve les modifications de toutes les maps.

1. Ouvrez Fusion de maps dans l’application de bureau et choisissez le dossier de votre serveur.
2. Cliquez sur Analyser. Vous voyez chaque fichier en conflit, les resources qui le livrent, dans leur ordre de démarrage, et s’il peut être fusionné.
3. Cliquez sur Fusionner. Les fichiers fusionnés vont dans une nouvelle resource fivedock-merged, et une ligne ensure fivedock-merged est ajoutée à la fin de server.cfg, pour qu’elle se charge toujours en dernier.
4. Redémarrez le serveur.

La fusion suit une règle simple, la même que vous suivriez à la main :

• Tout ce qu’une map ajoute est conservé. Chaque prop, lumière, point d’apparition de voiture et occluder qu’une des maps apporte se retrouve dans le fichier fusionné.
• Tout ce qu’une map retire reste retiré. Si un MLO a supprimé un occluder du jeu de base ou un lampadaire gênant, le fichier fusionné l’omet, même si la copie de l’autre map l’avait encore. C’est ce qui fait cesser le clignotement.
• Les modifications du même modèle d’occlusion sont combinées. Quand deux MLO percent chacun leur propre trou dans le même occluder, le fichier fusionné a les deux trous.

Les copies identiques à l’octet près sont signalées comme telles et ignorées, puisqu’elles ne peuvent pas entrer en conflit. Les lumières LOD lointaines sont fusionnées avec le fichier de lumières LOD correspondant, que le jeu veut synchronisé. Vous pouvez faire la même chose en ligne de commande :

> fivedock merge C:\server
41 started resources, 3 map files streamed by more than one
  dt1_05_strm_1.ymap  pd_mlo -> burgershot_mlo
  vw_distlodlights_medium010.ymap  pd_mlo -> street_lights
  shared_props.ytyp (identical)  pd_mlo -> burgershot_mlo

> fivedock merge C:\server --apply
  merged dt1_05_strm_1.ymap  +38 -4, base-game file
  merged vw_distlodlights_medium010.ymap  +112 -0, base-game file

Wrote C:\server\resources\[fivedock]\fivedock-merged. Undo with: fivedock merge undo

+38 -4 signifie que la fusion a apporté 38 éléments que la première copie n’avait pas, et omis 4 éléments du jeu de base qu’une des maps avait supprimés.

Quand une map est mise à jour, relancez l’analyse. Le merger lit aussi sa propre sortie précédente : les nouvelles copies sont donc intégrées à ce que vous avez déjà.

Quand vous n’avez pas besoin de fusionner

Un fichier streamé deux fois n’est pas toujours un problème. Laissez-le tranquille quand :

• les deux maps s’affichent correctement en jeu. Tous les fichiers partagés ne contiennent pas quelque chose dont une des maps dépend.
• les copies sont identiques. Le merger les signale et les ignore pour vous.
• le conflit est dans un .ybn ou un .ydr. Choisissez la copie voulue et ajustez plutôt l’ordre de démarrage.

Questions fréquentes

Pourquoi mon MLO clignote ou disparaît quand je m’en approche ?

En général parce qu’une autre resource streame sa propre copie de le même .ymap, et que cette copie contient encore les occluders que le MLO avait retirés. GTA V ne dessine pas ce qu’un occluder cache : l’intérieur clignote ou disparaît donc quand vous approchez. Le jeu charge la copie de la resource qui démarre en dernier.

Changer l’ordre des ensure règle-t-il les conflits de maps FiveM ?

Seulement pour les fichiers de collision (.ybn) et de modèle (.ydr), où vous choisissez la copie voulue et faites démarrer sa resource en dernier. Pour un .ymap ou un .ytyp que deux maps ont modifiés, le jeu ne charge toujours qu’une copie, et un nouvel ordre déplace la casse vers l’autre map. Ces fichiers doivent être fusionnés en une copie qui garde les modifications des deux maps.

Comment trouver quelles resources streament la même .ymap ?

Cherchez des fichiers de même nom dans les dossiers stream de chaque resource démarrée : deux resources qui livrent toutes deux dt1_05_strm_1.ymap entrent en conflit sur ce fichier. Le Map Merger de l’application de bureau FiveDock lit server.cfg et liste chaque .ymap et .ytyp que plus d’une resource démarrée streame, dans leur ordre de démarrage.

Puis-je fusionner des fichiers .ybn ou .ydr ?

Non. Un .ybn est un mesh de collision entier et un .ydr un modèle 3D entier : ils ne contiennent pas de liste de modifications distinctes à combiner comme un .ymap. Décidez quelle copie doit l’emporter et assurez-vous que sa resource démarre après l’autre.

Dans quelle offre

Le Map Merger fait partie de l’offre Metro. L’analyse et les fichiers restent sur votre machine ; la fusion elle-même tourne sur les serveurs de FiveDock, ce qui garde l’application légère et fait que chaque fusion s’appuie sur les mêmes données à jour du jeu de base. Comparez les offres ou téléchargez l’application de bureau pour analyser votre serveur.