Trovare il mod che fa crashare il gioco: il metodo della bisezione, con i numeri

Hai cento mod installati, il gioco si chiude sempre nello stesso punto, e nessun messaggio indica chiaramente il colpevole. La tentazione è disattivarli uno alla volta, ma con cento mod servirebbero fino a cento avvii. Esiste un metodo molto più rapido: dividere a metà il gruppo dei sospetti a ogni prova.

La wiki di modding di Cyberpunk 2077 lo indica come soluzione standard per i crash riproducibili: disattivare i mod a metà e controllare se il crash si ripete con ciascun gruppo. In questa guida lo spieghiamo con i numeri e lo adattiamo ai gestori di mod più comuni.

Passo zero: è davvero colpa dei mod?

Prima di cercare un colpevole tra i mod, verifica che ci sia. Anche la procedura della wiki di Cyberpunk prevede questo controllo: disattiva tutti i mod e avvia il gioco. Se il problema si ripete anche senza mod, la causa sta nel gioco, nei driver o nel sistema, e la bisezione non serve.

• Con Mod Organizer 2, crea un profilo copia e disattiva tutto lì: il profilo principale resta intatto.
• Con Stardew Valley, avvia il gioco senza SMAPI, oppure sposta temporaneamente le cartelle fuori da Mods.
• Con Minecraft, avvia il profilo Fabric con la cartella mods vuota, oppure il profilo senza loader.

Come funziona la bisezione

Supponiamo che il colpevole sia uno solo. Si procede così:

1. Dividi i mod sospetti in due metà. Disattiva la seconda metà e avvia il gioco.
2. Se il crash si ripete, il colpevole è nella metà ancora attiva. Se non si ripete, è in quella disattivata.
3. Tieni solo la metà colpevole come nuovo gruppo sospetto e ripeti dal primo passo.
4. Quando il gruppo sospetto contiene un solo mod, l’hai trovato.

Ogni prova dimezza i sospetti. Il numero massimo di avvii è quindi il numero di volte che si può dividere n per 2 prima di arrivare a 1, cioè il logaritmo in base 2 di n, arrotondato per eccesso. Con 100 mod: 100 → 50 → 25 → 13 → 7 → 4 → 2 → 1, sette avvii.

Avvii necessari per isolare un mod difettoso dimezzando

Caso di un solo colpevole: log₂(n) arrotondato per eccesso. Disattivarli uno alla volta ne richiede fino a n.

10 mod4

25 mod5

50 mod6

100 mod7

200 mod8

400 mod9

Mostra i valori in tabella

Avvii necessari per isolare un mod difettoso dimezzando

Mod installati	Avvii al massimo
10 mod	4
25 mod	5
50 mod	6
100 mod	7
200 mod	8
400 mod	9

La differenza con il metodo uno alla volta cresce rapidamente: con 400 mod si passa da un massimo di 400 avvii a 9. Anche contando qualche avvio in più per gestire le dipendenze, il guadagno resta enorme.

Le dipendenze: la trappola principale

Il metodo funziona solo se ogni prova è “pulita”, cioè se l’unica cosa che cambia è la presenza dei mod sospetti. Le dipendenze rompono questa condizione. Se disattivi un framework ma lasci attivo un mod che ne ha bisogno, il gioco produrrà un errore diverso da quello che stai cercando, e potresti concludere che il colpevole è nella metà sbagliata.

Alcune regole pratiche:

• Tieni sempre attivi i framework e le librerie durante la ricerca: Fabric API per Minecraft, SKSE e le sue librerie per Skyrim, RED4ext, CET, ArchiveXL e TweakXL per Cyberpunk, i framework come Content Patcher per Stardew. Se il sospetto ricade proprio su un framework, verificalo alla fine in una prova separata.
• Dividi per gruppi coerenti, non per posizione nell’elenco: un mod e le sue patch di compatibilità devono stare nella stessa metà.
• In Skyrim e Fallout, controlla i master mancanti: se un plugin attivo richiede un master disattivato, il gioco non si avvia. LOOT e MO2 lo segnalano con un avviso.
• Annota ogni prova: quali mod erano attivi e cosa è successo. Dopo cinque o sei avvii è facile confondersi.

In questo esempio sono bastate cinque prove. Il caso peggiore per 40 mod è di sei, perché log₂(40) ≈ 5,3 si arrotonda per eccesso: quando un gruppo dispari si divide in parti disuguali (qui 5 mod in 3 e 2), finire nella parte più piccola fa risparmiare un avvio.

Applicarla nei diversi gestori

Quando la bisezione non basta

Il metodo presuppone un solo colpevole e un crash riproducibile. Ci sono tre situazioni in cui va adattato.

Il problema nasce da due mod insieme

Se il crash compare solo quando due mod sono attivi contemporaneamente, a un certo punto entrambe le metà funzioneranno, perché i due responsabili sono stati separati. È un indizio prezioso: significa che c’è un conflitto. Ripeti la ricerca tenendo sempre attiva una delle due metà e dividendo l’altra: troverai il primo mod. Poi tieni attivo quello e cerca il secondo nell’altra metà.

Il crash è casuale

Se il gioco si chiude dopo un tempo variabile e non in un punto preciso, ogni prova richiede molto più tempo e un esito “nessun crash” è meno affidabile. La wiki di Cyberpunk lo riconosce: i crash casuali sono molto più difficili da diagnosticare. In questi casi conviene prima leggere il log (SMAPI, i rapporti di crash di Minecraft, il stacktrace.txt di Cyberpunk) per restringere i sospetti, e solo dopo dividere.

Il problema è nel salvataggio

Alcuni mod lasciano dati nel salvataggio. Se il crash avviene solo caricando una partita specifica, prova anche una partita nuova: se lì non succede, il problema potrebbe essere nel file di salvataggio e non nell’elenco attuale dei mod.

Dopo aver trovato il colpevole

• Controlla la versione: spesso il mod non è difettoso ma non aggiornato all’ultima versione del gioco o del framework.
• Leggi i commenti e i bug segnalati sulla pagina del mod: è probabile che altri abbiano già incontrato lo stesso problema.
• Cerca patch di compatibilità se il conflitto è tra due mod.
• Segnala il problema all’autore con il log e l’elenco dei mod: è il modo più efficace perché venga corretto.

Per evitare che un aggiornamento del gioco rompa tutto in una volta, vedi la nostra guida a backup e aggiornamenti.