Trouvez un conflit de mod Project Zomboid sans interrompre votre sauvegarde

Définir un échec court et reproductible

Ancien article de dépannage de la Build 41 de PZwiki décrit la comparaison des sous-ensembles de modules. Ici, nous adaptons cette approche à la chaîne de dépendances de Viewpoint ; il s'agit d'une procédure de diagnostic et non d'un correctif testé pour un conflit nommé Build 42.

1. Sauvegardez le monde original et enregistrez les versions du jeu, du chargeur et du mod. Continuez l'expérience sur un nouveau monde.
2. Écrivez une reproduction : par exemple, ouvrez un conteneur, tentez un transfert et notez l'erreur visible ou l'heure d'enregistrement.
3. Vérifiez le jeu de base sans mods optionnels là où l'action existe. Testez ensuite la pile Viewpoint requise.
4. Si la pile minimale de caméras échoue déjà, enquêtez mise en place ou Statut Java avant de tester une douzaine de modules complémentaires.

Une dépendance manquante invalide la comparaison. Conservez ZombieBuddy et Viewpoint chaque fois qu'un compagnon activé en a besoin. Gardez également les autres exigences de la bibliothèque avec leurs consommateurs.

Diviser les fonctionnalités facultatives, les bibliothèques non requises

1. Confirmez que votre ensemble facultatif complet reproduit l’échec lors d’un nouveau test.
2. Divisez les fonctionnalités facultatives en deux groupes à peu près égaux. Ajoutez les dépendances requises de chaque groupe à sa liste de tests.
3. Lancez le premier groupe avec le noyau de travail, utilisez un nouveau monde de test et répétez l'action exacte. Enregistrez le résultat et la liste activée.
4. Répétez avec l’autre groupe dans les mêmes conditions.
5. Si un groupe échoue seul, divisez-le à nouveau jusqu'à obtenir un petit ensemble reproductible.

Redémarrez entre les comparaisons afin qu'un compagnon Java déjà chargé ne puisse pas confondre le statut de la prochaine exécution. Ne modifiez pas simultanément les préréglages, les liaisons, les graphiques et la sélection de mod ; maintenir constantes les conditions importantes pour la reproduction.

Si aucune des deux moitiés n'échoue seule

L'échec peut nécessiter une interaction entre les groupes. Restaurez l’ensemble complet défaillant connu, puis supprimez une fonctionnalité facultative à la fois tout en conservant les dépendances nécessaires au reste. Conservez chaque liste et résultat exacts. Une moitié passagère ne prouve pas que tous ses mods fonctionnent avec tous les mods de l'autre moitié.

Vérifiez également si le symptôme d'origine dépend d'un ancien monde, d'un chevauchement d'entrée particulier ou d'un serveur. Un test du nouveau monde ne peut pas prouver qu’une sauvegarde existante est compatible, et un test local ne peut pas certifier le multijoueur. Pour les clés déplacées, utilisez la comparaison de la couche de contrôle; pour rejoindre les échecs, utilisez la route d'incompatibilité de fichier nommée.

Envoyez le plus petit rapport utile

Incluez la combinaison défaillante, la comparaison réussie la plus proche, les bibliothèques requises, les numéros de version, une reproduction et l'exécution échouée. console.txt. Dites s'il s'agit d'un nouveau monde ou d'une sauvegarde existante et si l'échec est local ou multijoueur.

N'étiquetez pas le mod d'un auteur comme étant universellement séparé d'une seule pile. Conservez intactes votre sauvegarde originale et votre note de liste de mods en attendant une réponse ciblée ; la désinscription massive ou la suppression de tous les paramètres annule la comparaison que vous venez d'établir.