Tout de suite : ouvrez le fichier avec le Bloc-notes, allez aux dernières lignes et cherchez un nom que vous reconnaissez parmi vos mods. Ne supprimez rien — ce rapport nomme souvent un mod, pas toujours le bon, et parfois aucun. Cette page détaille l'étape 5 du guide : où est le fichier, comment le lire, et ce qu'il ne peut pas vous dire.
À la racine de Documents → Electronic Arts → Les Sims 4, à côté du dossier Mods : un fichier texte dont le nom commence par lastException. Le jeu l'écrit au moment où un script se trompe. S'il y en a plusieurs, prenez le plus récent — triez le dossier par date de modification. S'il n'y en a aucun, allez directement à l'étape 5 : l'absence de rapport est déjà une information.
Clic droit sur le fichier → Ouvrir avec → Bloc-notes, ou n'importe quel éditeur de texte. Rien à installer. Le contenu est en anglais et ressemble à du code : c'est normal, et vous n'avez pas besoin de le comprendre. Vous n'y cherchez qu'une seule chose — un nom.
Le jeu écrit deux rapports différents, et on les confond souvent. lastException concerne les scripts : c'est lui qui peut nommer un mod. lastUIException concerne l'interface — les menus, les panneaux — et ne peut pas accuser un mod de script, quoi qu'il contienne. Si vous n'avez que le second, un nom trouvé dedans ne prouverait rien.
Allez aux dernières lignes. Le bloc qui commence par Traceback liste, ligne par ligne, où le jeu passait quand l'erreur est arrivée ; la toute dernière ligne dit quelle erreur. Chaque ligne File porte un chemin :
Traceback (most recent call last): File "T:\InGame\Gameplay\Scripts\Server\...\service_manager.py", line 346, in start_single_service File "C:\Users\...\Mods\mon_mod\carriere.py", line 12, in start KeyError: 3
Les chemins qui commencent par T:\InGame sont le code du jeu lui-même — c'est la machine du studio, pas la vôtre — et ne désignent jamais un mod. Tout autre chemin est un mod. Ne le cherchez pas sur votre disque : c'est le chemin de l'ordinateur de son créateur, au moment où il l'a fabriqué. Ce qui compte, ce sont les derniers mots — ici mon_mod — le nom interne du script, souvent proche du nom du mod, pas toujours identique au nom du fichier dans votre dossier Mods.
Le mod cité n'est pas toujours le coupable. Un mod peut planter à cause d'un autre — une dépendance absente ou pas à jour, un second mod qui touche à la même chose. Et un mod qui surveille le jeu en permanence apparaît dans presque toutes les piles sans y être pour rien. Lisez ce nom comme un suspect, pas comme un verdict.
Trois cas, tous fréquents. Toutes les lignes viennent de T:\InGame : le rapport n'accuse aucun script — l'erreur peut venir du jeu, ou d'un mod sans script (un .package qui change des réglages) qui n'a aucun chemin à écrire dans une pile. Le rapport nomme un mod que vous ne retrouvez pas : le nom interne diffère du nom du fichier — cherchez-le dans les noms de vos .ts4script, ou sur la page de son créateur. Il n'y a pas de rapport du tout : un gel ou une fermeture brutale n'écrit rien — le jeu ne journalise que les erreurs qu'il rattrape. Pas de rapport ne veut donc pas dire pas de coupable : c'est le test par moitiés, étape 6 du guide, qui tranche.
Regardez d'abord si le créateur du mod a publié une version après le dernier patch du jeu : c'est une cause fréquente, et peu coûteuse à régler. Sinon, déplacez son fichier hors de Mods — sur le bureau, dans un dossier « en attente » — sans le supprimer, et relancez le jeu. Si le même rapport revient sans lui, ce n'était pas lui : remettez-le, et passez au suspect suivant ou au test par moitiés.
Cette page est gratuite et le restera. Le reste du triage — les mods décochés après un patch, les fichiers mal rangés, les caches, le test par moitiés — est dans le guide complet, dans l'ordre.
← Revenir au guide