Pular para o conteúdo
Project ZomboidNotas de sobrevivência Viewpoint

Tradução atualizada: 11 de outubro de 2026

Corrigir mods

Encontre um conflito de mod Project Zomboid sem interromper seu salvamento

Procedimento de teste com reconhecimento de dependência · orientação PZwiki mais antiga e requisitos atuais do autor

A resposta curta

Reproduza em um novo mundo de teste, confirme a linha de base ZombieBuddy/Viewpoint necessária e compare subconjuntos de mods opcionais, mantendo todas as dependências necessárias. Limite o conjunto com falha usando sempre a mesma ação. Se ambos os subconjuntos funcionarem sozinhos, teste sua interação em vez de culpar o último mod da lista.

Nesta página

Defina uma falha curta e repetível

Artigo antigo de solução de problemas do Build 41 do PZwiki descreve a comparação de subconjuntos de mod. Aqui adaptamos essa abordagem à cadeia de dependência de Viewpoint; este é um procedimento de diagnóstico, não uma correção testada para um conflito nomeado do Build 42.

  1. Faça backup do mundo original e grave versões do jogo, carregador e mod. Mantenha o experimento em um novo mundo.
  2. Escreva uma reprodução: por exemplo, abra um contêiner, tente uma transferência e anote o erro visível ou o tempo de registro.
  3. Verifique o jogo base sem mods opcionais onde existe ação. Em seguida, teste a pilha Viewpoint necessária.
  4. Se a pilha mínima de câmeras já falhar, investigue instalação ou Estado Java antes de testar uma dúzia de complementos.

Uma dependência ausente invalida a comparação. Mantenha ZombieBuddy e Viewpoint sempre que um companheiro habilitado os exigir. Mantenha outros requisitos da biblioteca também com seus consumidores.

Divida recursos opcionais, não bibliotecas obrigatórias

  1. Confirme se o seu conjunto opcional completo reproduz a falha em um novo teste.
  2. Divida os recursos opcionais em dois grupos aproximadamente iguais. Adicione as dependências necessárias de cada grupo à sua lista de testes.
  3. Lance o primeiro grupo com o núcleo funcional, use um novo mundo de teste e repita a ação exata. Registre o resultado e a lista habilitada.
  4. Repita com o outro grupo nas mesmas condições.
  5. Se um grupo falhar sozinho, divida esse grupo novamente até ter um pequeno conjunto reproduzível.

Reinicie entre comparações para que um complemento Java já carregado não possa confundir o status da próxima execução. Não altere predefinições, ligações, gráficos e seleção de mods juntos; manter constantes as condições que importam para a reprodução.

Se nenhuma das metades falhar sozinha

A falha pode exigir uma interação entre os grupos. Restaure o conjunto completo com falha conhecida e remova um recurso opcional de cada vez, mantendo as dependências necessárias para o restante. Mantenha cada lista e resultado exatos. Uma metade que passa não prova que todos os seus mods funcionam com todos os mods da outra metade.

Verifique também se o sintoma original dependia de um mundo antigo, de uma sobreposição de entrada específica ou de um servidor. Um teste de novo mundo não pode provar que um salvamento existente é compatível, e um teste local não pode certificar o modo multijogador. Para chaves realocadas, use a comparação da camada de controle; para juntar falhas use a rota de incompatibilidade do arquivo nomeado.

Envie o menor relatório útil

Inclua a combinação com falha, a comparação de aprovação mais próxima, bibliotecas necessárias, números de versão, uma reprodução e a execução com falha console.txt. Diga se é um mundo novo ou um salvamento existente e se a falha é local ou multijogador.

Não rotule o mod de um autor como universalmente quebrado de uma pilha. Mantenha seu salvamento original e nota da lista de mods intactos enquanto espera por uma resposta direcionada; cancelar a assinatura em massa ou excluir todas as configurações descarta a comparação que você acabou de estabelecer.

Fontes e versão

Baseado na documentação do autor e nas instruções da comunidade, não em nosso próprio teste de jogabilidade. Atualizações posteriores podem alterar os padrões.