Ir para o conteúdo
Tanven, início

lastException: o que o relatório do jogo lhe diz (e o que não diz)

Para já: abra o ficheiro com o Bloco de notas, vá às últimas linhas e procure um nome que reconheça entre os seus mods. Não apague nada — este relatório nomeia muitas vezes um mod, nem sempre o certo, e às vezes nenhum. Esta página desenvolve o passo 5 do guia: onde está o ficheiro, como o ler, e o que ele não lhe pode dizer.

← O guia inteiro · Tanven

1.Onde está o ficheiro

Na raiz de Documentos → Electronic Arts → The Sims 4, ao lado da pasta Mods: um ficheiro de texto cujo nome começa por lastException. O jogo escreve-o no momento em que um script falha. Se houver vários, pegue no mais recente — ordene a pasta por data de modificação. Se não houver nenhum, salte diretamente para o passo 5: não haver relatório já é uma informação.

2.Abra-o com o Bloco de notas

Clique direito no ficheiro → Abrir com → Bloco de notas, ou qualquer editor de texto. Nada para instalar. O conteúdo está em inglês e parece código: é normal, e não precisa de o perceber. Só procura uma coisa — um nome.

3.lastException ou lastUIException?

O jogo escreve dois relatórios diferentes, e confundem-se a toda a hora. lastException diz respeito aos scripts: é ele que pode nomear um mod. lastUIException diz respeito à interface — menus, painéis — e não pode acusar um mod de script, seja o que for que contenha. Se só tem o segundo, um nome encontrado lá não provaria nada.

4.Encontre o nome de um mod no texto

Vá às últimas linhas. O bloco que começa por Traceback lista, linha a linha, por onde o jogo passava quando o erro chegou; a última linha de todas diz qual foi o erro. Cada linha File traz um caminho:

Traceback (most recent call last):
  File "T:\InGame\Gameplay\Scripts\Server\...\service_manager.py", line 346, in start_single_service
  File "C:\Users\...\Mods\meu_mod\carreira.py", line 12, in start
KeyError: 3

Os caminhos que começam por T:\InGame são o código do próprio jogo — é a máquina do estúdio, não a sua — e nunca apontam para um mod. Qualquer outro caminho é um mod. Não o procure no seu disco: é o caminho do computador do criador, no momento em que o construiu. O que conta são as últimas palavras — aqui meu_mod — o nome interno do script, quase sempre parecido com o nome do mod, nem sempre igual ao nome do ficheiro na sua pasta Mods.

O mod citado nem sempre é o culpado. Um mod pode falhar por causa de outro — uma dependência em falta ou desatualizada, um segundo mod que mexe na mesma coisa. E um mod que vigia o jogo a toda a hora aparece em quase todos os relatórios sem ter nada a ver com o assunto. Leia esse nome como um suspeito, não como um veredicto.

5.Quando o relatório não nomeia nada

Três casos, todos frequentes. Todas as linhas vêm de T:\InGame: o relatório não acusa nenhum script — o erro pode vir do jogo, ou de um mod sem script (um .package que muda definições), que não tem nenhum caminho para escrever num relatório. O relatório nomeia um mod que não encontra: o nome interno é diferente do nome do ficheiro — procure-o nos nomes dos seus .ts4script, ou na página do criador. Não há relatório nenhum: um congelamento ou um crash duro não escreve nada — o jogo só regista os erros que apanha. Por isso, não haver relatório não quer dizer não haver culpado: quem decide é o teste por metades, o passo 6 do guia.

6.O que fazer com o nome

Veja primeiro se o criador do mod publicou uma versão depois do último patch do jogo: é uma causa frequente, e barata de resolver. Senão, mova o ficheiro para fora de Mods — para o ambiente de trabalho, para uma pasta «em espera» — sem o apagar, e volte a arrancar o jogo. Se o mesmo relatório voltar sem ele, não era ele: reponha-o e passe ao suspeito seguinte ou ao teste por metades.

Esta página é gratuita e vai continuar a sê-lo. O resto da triagem — os mods desmarcados depois de um patch, os ficheiros mal arrumados, as caches, o teste por metades — está no guia completo, por ordem.

← Voltar ao guia