« Ne s’affiche pas » peut désigner plusieurs échecs : ressource qui ne démarre pas, intérieur placé ailleurs, archétype absent ou pièce invisible depuis un seul point de vue. Commencez par distinguer ces observations.
C’est une démarche de diagnostic. Elle ne prétend pas qu’un symptôme n’a qu’une cause possible.
Consignez l’état défaillant
Notez version de ressource, édition cible, coordonnées, direction de caméra et ressources voisines actives. Conservez les erreurs exactes du client et du serveur si disponibles. Enregistrez une capture permettant de retrouver la position.
Conservez l’export défaillant avant de le modifier. Un échec reproductible est un cas de test utile. S’il disparaît après six changements sans rapport, il vous apprend peu.
La ressource entière est-elle absente ?
Vérifiez chemin de ressource, nom du fichier et sortie de démarrage. Inspectez fxmanifest.lua et vérifiez les fichiers attendus, leur casse et leurs extensions. Confirmez que vous testez le bon dossier de ressource, pas une ancienne copie.
Pour les archétypes personnalisés, inspectez l’enregistrement YTYP et ses références. Comparez les fichiers livrés au guide de préparation des ressources.
Une commande acceptée dans la console ne prouve pas la disponibilité de toutes les dépendances. Lisez sa sortie et vérifiez séparément le placement visible.
L’asset s’ouvre-t-il sans apparaître dans le monde ?
Vérifiez la chaîne asset → archétype → placement d’entité. Utilisez le référence des formats de fichiers pour distinguer ces responsabilités. Confirmez le nom exact de l’archétype MLO et la transformation mondiale du placement.
Vérifiez que la carte exportée contient les dernières modifications et les étendues recalculées si nécessaire. Un projet enregistré sur votre poste ne prouve pas que le serveur a reçu un nouveau YMAP.
Si vous avez travaillé en espace local, cherchez une translation ou rotation appliquée deux fois dans l’export et le placement. Ne déplacez pas l’asset jusqu’à ce qu’il apparaisse sans comprendre la transformation appliquée.
Une pièce disparaît-elle à une ouverture ?
Revenez au graphe des pièces. Notez l’ouverture, le côté du seuil et la direction déclenchant le défaut. Inspectez la connexion et les pièces avec la matrice de test des portails.
Une capture grand-angle sans rapport ne prouve pas que la connexion fonctionne. Un échec à une transition précise exige de tester cette transition.
Comparez le même parcours à l’export fonctionnel précédent. Si l’échec est apparu avec une nouvelle pièce, limitez l’expérience à ce changement plutôt que de refaire tous les matériaux.
La pièce est-elle visible mais les déplacements incorrects ?
Passez à l’analyse des collisions. Une entrée peut être bloquée par une collision ne correspondant pas à l’ouverture visible. Réenregistrer le même YTYP ne répare pas une chute à travers le sol.
Inspectez les collisions exportées et répétez le parcours à pied. Vérifiez les ressources superposées au même endroit. Désactivez les suspectes uniquement en environnement de développement contrôlé et documentez chaque comparaison.
Le problème dépend-il de la distance ou d’autres ressources ?
Utilisez des approches fixes pour distinguer effets de distance et transitions de pièces. Le README explique la hiérarchie LOD, pas l’augmentation arbitraire de toutes les distances sans inspecter hiérarchie et limites.
En cas de conflit suspecté, testez la ressource seule, puis ajoutez les voisines dans un ordre connu. Notez la première combinaison reproduisant le défaut. L’ordre est une piste, pas un substitut à l’analyse des assets dupliqués ou superposés.
Terminez le cycle de vérification
Pour chaque tentative, notez hypothèse, changement exact et résultat. Restaurez la version précédente si l’hypothèse échoue. Reproduisez une correction réussie depuis les sources et retestez avec une nouvelle connexion.
Manipuler le cache n’est pas un diagnostic. N’envisagez une livraison périmée que si les preuves l’indiquent et suivez les recommandations actuelles plutôt que de supprimer rituellement des dossiers sans rapport.
YMAP absent dans FiveM : isolez la première couche manquante
Commencez par la découverte des ressources et la console, puis vérifiez le fichier natif exact dans stream/, l’édition cible et les coordonnées. Une ressource reconnue contenant du XML texte au lieu de fichiers natifs n’est pas une carte fonctionnelle. Comparez un nouveau chargement CodeWalker au fichier livré, pas à une autre copie de travail.
Si les objets du jeu apparaissent mais pas les personnalisés, inspectez l’enregistrement YTYP et les dépendances modèles/textures. Si rien n’apparaît, vérifiez d’abord le chargement du YMAP. Le générateur de manifeste aide à comparer les déclarations, mais n’inspecte pas les fichiers et ne prouve pas que les références aboutissent.
MLO qui scintille à une ouverture
Immobilisez la caméra de chaque côté, puis franchissez l’ouverture dans les deux sens. Notez la pièce disparue et le lieu de transition. Comparez géométrie du portail, pièces reliées, limites et affectations. Ne modifiez pas tout ensemble : un changement contrôlé doit expliquer une observation reproductible.
Comparez le même parcours sans ressources de développement superposées. Si seules les vues lointaines échouent, inspectez LOD et streaming au lieu d’augmenter toutes les distances. Utilisez le guide des pièces et portails pour vérifier le graphe et la leçon d’optimisation pour des comparaisons reproductibles.
Intérieur invisible ou collision invisible
Une pièce non dessinée et une pièce bloquant les déplacements sont des symptômes distincts. Testez la limite physique malgré l’invisibilité, puis inspectez rendu et collisions séparément. Retirer une collision ne corrige pas l’enregistrement d’un archétype ; ajouter un portail ne perce pas un collider solide.
Conservez la plus petite ressource reproductible avec édition, versions jeu/serveur, révision source et observation exacte. Si l’application échoue avant l’ouverture d’une carte, utilisez le dépannage du démarrage de CodeWalker à la place.