Guida al server per LAN party: ospita localmente giochi, file e chat vocale

Costruisci un server per LAN party assegnando ruoli separati all'hosting dei giochi, alla distribuzione dei file e alla chat vocale su un'unica rete locale collaudata.

Una buona LAN party dovrebbe continuare a funzionare quando Internet rallenta, un invitato si collega in ritardo o un servizio deve essere riavviato. Perciò il server ha bisogno di più della semplice potenza CPU necessaria per avviare un gioco. Servono indirizzamento locale prevedibile, dati dei servizi isolati, accesso controllato ai file, salvataggi persistenti dei giochi, un canale vocale che non dipenda da una piattaforma pubblica e un piano di ripristino in grado di riportare in funzione l'evento senza ricostruire ogni componente.

Pianifica la LAN party in base ai giocatori, ai giochi e ai flussi di lavoro locali

Inizia dall'evento, non dall'hardware del server. Registra quanti giocatori parteciperanno, quali giochi verranno eseguiti, se ogni titolo supporta un server dedicato o solo il gioco ospitato da un peer, quali sistemi operativi usano i client e se qualcuno parteciperà da remoto. Una serata con sei giocatori nella stessa stanza crea un carico di rete e di calcolo diverso rispetto a un fine settimana con venti giocatori e diversi giochi in esecuzione contemporaneamente.

Trasforma l'elenco degli invitati in una mappa dei client:

• Nome del giocatore e nome del dispositivo
• Connessione Ethernet cablata o Wi-Fi
• Sistema operativo e piattaforma di gioco
• Versione del gioco, mod e contenuti scaricabili richiesti
• Cuffie e client locale per la chat vocale
• Autorizzazione a caricare o scaricare file condivisi
• Necessità di accesso a Internet o partecipazione solo locale

Questa mappa definisce il carico di lavoro prima di discutere le specifiche. Il server deve supportare la combinazione legittima più impegnativa: sessioni di gioco attive, connessioni vocali, download di file, scritture dei salvataggi e amministrazione. Se un flusso di lavoro non è richiesto durante il gioco, pianificalo al di fuori della finestra dell'evento invece di dimensionare il server per ogni possibile attività contemporaneamente.

Assegna ruoli separati all'hosting dei giochi, alla distribuzione dei file e alla chat vocale

Una singola macchina fisica può ospitare tutti e tre i servizi, ma questi devono rimanere ruoli logici separati. Il servizio di gioco gestisce sessioni attive, mappe, mod, configurazione e salvataggi. Il servizio di file gestisce installatori, pacchetti di mod approvati, mappe, schermate e documenti dell'evento. Il servizio vocale gestisce canali, accesso degli utenti e stato temporaneo delle comunicazioni.

Non concedere a ogni servizio accesso illimitato agli altri. Un account per la condivisione dei file non ha bisogno dell'accesso in scrittura ai salvataggi di gioco. Un container di gioco non ha bisogno di controllare il database vocale. Un amministratore del servizio vocale non dovrebbe diventare automaticamente l'amministratore del sistema operativo host. La separazione logica limita i danni causati da una mod difettosa, da una cancellazione accidentale o da credenziali guest esposte.

Scegli prima un solo host e separa i ruoli solo quando i test lo richiedono

Per una LAN party piccola o media, un host x86 collegato tramite Ethernet è solitamente la topologia iniziale più semplice. Esegui il server di gioco, il servizio file e il servizio vocale come container, macchine virtuali o servizi nativi separati, con porte, percorsi di archiviazione e requisiti di risorse definiti esplicitamente. L'obiettivo è la separazione operativa, non il numero massimo di componenti.

Il confronto di ZimaSpace tra un sistema operativo NAS e Linux per i server di gioco aiuta nella scelta della piattaforma. Un sistema orientato ai NAS può semplificare la gestione dell'archiviazione e delle applicazioni, mentre Linux generico può offrire un controllo più diretto sui runtime dei giochi, sugli aggiornamenti dalla riga di comando, sui mod loader e sulle definizioni personalizzate dei servizi.

Mantieni un solo host finché il carico combinato rimane reattivo e recuperabile. Sposta la distribuzione dei file su uno spazio di archiviazione separato quando i trasferimenti di grandi dimensioni rallentano le sessioni in corso. Separa il ruolo del gioco quando un titolo richiede librerie incompatibili, un sistema operativo diverso o una finestra di manutenzione in conflitto con gli altri servizi. Separa il servizio vocale solo quando i riavvii del gioco o la pressione sulle risorse interrompono ripetutamente le comunicazioni. Ogni nuovo nodo deve avere uno scopo misurabile e continuativo.

Costruisci il percorso di rete cablato prima di installare i servizi di gioco

Il percorso locale critico è semplice:

PC DEI GIOCATORI
    │
    ├── ETHERNET CABLATA ──> SWITCH CENTRALE ──> SERVER DELLA LAN PARTY
    │                              │
    │                              └──> ROUTER / INTERNET (OPZIONALE)
    │
    └── WI-FI (CLIENT SECONDARI O MOBILI)

Usa lo switch per il traffico locale tra giocatori e server e il router per DHCP, DNS e l'accesso opzionale a Internet. La guida alle LAN party di SUPERJUMP spiega la differenza funzionale tra switch e router e perché uno switch di rete centrale è il punto di connessione locale naturale.

Collega il server e i principali PC da gioco tramite Ethernet ogni volta che è possibile. Il Wi-Fi può rimanere disponibile per telefoni, amministrazione e giocatori che non possono usare un cavo, ma non dovrebbe essere l'unico collegamento per l'host o per i client più sensibili alla latenza. Posiziona lo switch in una posizione centrale, etichetta entrambe le estremità di ogni cavo, proteggi i percorsi di passaggio e tieni a disposizione uno o due cavi e porte di riserva.

Scegli il numero di porte in base alla topologia completa, non solo al numero di giocatori. Includi il server, l'uplink del router, il punto di accesso wireless, il laptop di amministrazione, una postazione giocatore di riserva e qualsiasi nodo di archiviazione secondario. Se lo switch ha sedici porte e il piano le utilizza tutte e sedici, la rete non ha margine di recupero.

Fai funzionare l'indirizzamento locale senza dipendere da Internet

I client devono avere un modo stabile per trovare ogni servizio. Lascia che il router fornisca il DHCP ai dispositivi dei giocatori, poi riserva un indirizzo prevedibile per il server della LAN party. Evita di assegnare manualmente un indirizzo statico a ogni ospite, a meno che la rete dell'evento non disponga di un servizio DHCP; gli indirizzi duplicati sono un guasto evitabile il giorno dell'evento.

Crea una breve scheda di connessione che includa:

• Nome host del server e indirizzo IP locale
• Porte del servizio di gioco e metodo di accesso
• Indirizzo del server vocale
• Indirizzo della condivisione file e credenziali autorizzate
• Nome della rete Wi-Fi e password ospiti, se utilizzata
• Nome dell'amministratore dell'evento

Testa tutti i nomi e gli indirizzi locali dopo aver scollegato la connessione Internet in uplink. Se il gioco, la condivisione file o il servizio vocale possono essere trovati solo tramite un record DNS pubblico, un accesso al cloud o un messaggio in chat memorizzato online, la LAN non è ancora autosufficiente. Conserva una copia stampata o ospitata localmente della scheda di connessione.

Configura il server di gioco come ruolo di produzione in tempo reale

Il servizio di gioco ha la priorità perché la sua reattività influisce contemporaneamente su ogni giocatore attivo. Individua per ogni titolo previsto la build esatta del server, il runtime, le porte, la rotazione delle mappe, la posizione dei salvataggi, il set di mod, il limite di giocatori e il comportamento al riavvio. Non dare per scontato che un avvio riuscito dimostri che il server sia pronto per l'evento.

Mantieni separati i binari del gioco dallo stato persistente:

SERVER_DI_GIOCO/
├── gioco-a/
│   ├── applicazione/
│   ├── configurazione/
│   ├── mod/
│   ├── salvataggi/
│   └── log/
└── gioco-b/
    ├── applicazione/
    ├── configurazione/
    ├── salvataggi/
    └── log/

La directory dell'applicazione può spesso essere ricostruita o aggiornata. La configurazione, le mod approvate, i dati del mondo e i salvataggi richiedono una conservazione intenzionale. I log sono utili per diagnosticare gli eventi, ma possono avere tempi di conservazione più brevi. Documenta il comando o la definizione del servizio che avvia ogni server, così il ripristino non dipende dalla cronologia del terminale.

Esegui una partita rappresentativa con il numero di giocatori previsto. Misura l'utilizzo della CPU, la pressione sulla memoria, il traffico di rete, la latenza dei salvataggi e la stabilità dei tick o della simulazione, se il gioco la espone. Ripeti il test mentre il servizio file gestisce un download di grandi dimensioni e il servizio vocale ha utenti attivi. È la sovrapposizione dei carichi massimi, non il pannello inattivo, a definire se l'host è sufficiente.

Distribuisci i file di gioco senza lasciare che i download interrompano le partite

Gli arrivi in ritardo e le versioni non corrispondenti possono trasformare la connessione Internet nel collo di bottiglia dell'evento. Prepara pacchetti di mod approvati, mappe personalizzate, esempi di configurazione del server e altri file dell'evento redistribuibili prima dell'arrivo degli ospiti. Non duplicare i file dei giochi commerciali a meno che la piattaforma e le licenze lo consentano.

Per le piattaforme che supportano il trasferimento locale tra client autorizzati, testa la funzionalità sulla rete effettiva dell'evento. L'esperimento di un operatore con il trasferimento locale di Steam ha utilizzato un vecchio laptop gigabit con unità HDD e SSD e ha rilevato che il computer poteva fungere da utile sorgente locale per il trasferimento dei giochi. La lezione utile è architetturale: il disco sorgente, il collegamento del server, l'uplink dello switch e il client ricevente partecipano tutti al percorso di trasferimento.

Pianifica i trasferimenti più grandi prima dell'inizio delle partite. Se i download devono continuare durante il gioco, limita la velocità o spostali su un percorso di archiviazione e rete separato solo dopo aver verificato che causino latenza ripetibile o contesa per le risorse di archiviazione. Un servizio file più veloce non è un successo se rende instabile il servizio di gioco.

Crea una condivisione di file locale con autorizzazioni specifiche per l'evento

Il servizio file deve essere semplice per gli ospiti e avere un ambito limitato. Fornisci un'area in sola lettura per i download approvati e una cartella separata per gli screenshot, le registrazioni o i file che i giocatori desiderano condividere. Non esporre backup personali, contenuti multimediali domestici, script amministrativi o il file system dell'host.

LAN_PARTY_FILES/
├── READ_ONLY/
│   ├── connection-info/
│   ├── approved-mods/
│   ├── custom-maps/
│   └── utilities/
├── PLAYER_UPLOADS/
└── ADMIN_REVIEW/

Usa un account per l'evento invece di condividere una password permanente di amministratore. Concedi un accesso ospite ampio alla libreria in sola lettura solo se la rete stessa è considerata attendibile. Limita i caricamenti per account, capacità o cartella, quindi esaminali prima di spostarli nella libreria approvata. Rimuovi o disabilita le credenziali dell'evento dopo la festa.

La distribuzione dei file è una funzione di servizio, quindi deve poter fallire senza conseguenze. Se la condivisione si interrompe, le partite in corso e la chat vocale devono continuare. Se un ospite carica abbastanza dati da riempire l'area di caricamento, i volumi dei salvataggi di gioco e del sistema devono comunque mantenere spazio libero riservato.

Ospita la chat vocale localmente come canale di comunicazione indipendente

Le persone nella stessa stanza potrebbero aver bisogno comunque di cuffie, soprattutto quando si trovano in più stanze o durante le partite a squadre. Un server vocale locale mantiene inoltre il coordinamento se una piattaforma di chat esterna o la connessione Internet diventano indisponibili.

Mumble è un esempio pratico perché il suo componente server può essere self-hosted e organizzato con canali e controlli di accesso. Un tutorial Docker indipendente illustra un server Mumble self-hosted con configurazione persistente e gestione delle autorizzazioni. Usalo come una delle possibili implementazioni, invece di fare dipendere la topologia LAN da una particolare applicazione vocale.

Crea i canali del team e una lobby generale prima dell'evento. Usa account normali per i partecipanti e mantieni separate le credenziali amministrative. Verifica i livelli del microfono, il push-to-talk, il cambio di canale e la riconnessione da più di un sistema operativo client.

La voce richiede poco spazio di archiviazione, ma ha bisogno di disponibilità costante. Conserva il database e la configurazione nello spazio di archiviazione persistente dell'applicazione. Non consentire che il riavvio di un server di gioco, un trasferimento di file o un container sperimentale riavvii automaticamente l'intero host se la voce deve rimanere disponibile.

Separa lo stato persistente, i file condivisi, le cache e i backup

Non indirizzare ogni servizio verso un'unica directory scrivibile. Separa i dati in base all'impatto della perdita e all'azione di ripristino:

La stessa logica basata sui ruoli si applica quando diversi servizi condividono una macchina. La guida di ZimaSpace per eseguire in sicurezza diverse app self-hosted mostra come mantenere distinti lo stato persistente, i file di grandi dimensioni, i dati di lavoro temporanei e le risorse concorrenti su un host consolidato.

Mantieni separato l'accesso degli ospiti dall'amministrazione del server

Una LAN party collega intenzionalmente dispositivi che il proprietario del server non gestisce. Considera l'accesso dei giocatori, l'amministrazione dei servizi e l'amministrazione dell'host come livelli di attendibilità separati. I giocatori necessitano delle porte del gioco, dell'accesso alla chat vocale e di un percorso limitato per i file. Gli amministratori dei servizi possono riavviare un gioco o cambiare canale. Solo l'amministratore dell'host dovrebbe gestire container, archiviazione, regole del firewall, backup e sistema operativo.

Usa una rete ospiti o una VLAN dedicata all'evento quando il router e lo switch disponibili lo supportano e quando l'isolamento non interrompe il rilevamento locale necessario. Non aggiungere segmentazioni alla cieca: alcune funzioni di trasferimento e rilevamento locali richiedono che i client possano trovarsi a vicenda. Verifica i flussi esatti del servizio dopo aver applicato le regole del firewall.

Il confronto di ZimaSpace tra un router consumer e un firewall dedicato offre il passo decisionale successivo quando l'isolamento degli ospiti, le policy VLAN e gli eventi ricorrenti superano le capacità di un router domestico di base.

Mantieni le interfacce di gestione separate dalla pagina di condivisione dei file e non pubblicare le password di amministratore nel foglio di connessione. Dopo l'evento, rimuovi gli account temporanei, modifica le password condivise, chiudi le porte non necessarie e controlla i file caricati prima di ricollegare il server ai normali servizi domestici.

Pianifica i guasti di Internet e dell'alimentazione senza complicare eccessivamente l'evento

Un server locale riduce la dipendenza da Internet, ma non rende automaticamente ogni gioco utilizzabile offline. Verifica se ciascun titolo richiede l'autenticazione della piattaforma, controlli della licenza, matchmaking, download dal workshop o servizi disponibili solo tramite cloud. Completa gli accessi e gli aggiornamenti necessari prima dell'evento, poi verifica cosa continua a funzionare dopo aver disconnesso il collegamento verso Internet.

Collega router, switch e server a una linea di alimentazione stabile. Un UPS può fornire il tempo necessario per uno spegnimento controllato, ma non deve alimentare ogni PC da gaming. Documenta l'ordine di spegnimento e assicurati che il servizio di gioco salvi il mondo o lo stato della sessione prima di smontare l'unità di archiviazione.

Prepara un piano di riserva proporzionato al rischio. Conserva una copia delle configurazioni del server e dei salvataggi su un'unità separata. Tieni disponibile offline il foglio di connessione. Se il gioco principale non riesce ad autenticarsi, predisponi una o due alternative locali verificate invece di cercare di riprogettare la rete mentre gli ospiti aspettano.

Convalida l'intera LAN durante la sovrapposizione massima prevista

Testa l'evento come un flusso di lavoro, non come l'avvio di tre applicazioni isolate. Collega dispositivi client rappresentativi, avvia la sessione di gioco più impegnativa prevista, inserisci gli utenti nei canali vocali, trasferisci un file approvato di grandi dimensioni, salva una partita e lascia aperta la pagina di amministrazione.

• Conferma che ogni client riceva un indirizzo univoco e possa risolvere il server.
• Misura il tempo di accesso, la reattività del gioco, la perdita di pacchetti e l'utilizzo delle risorse del server.
• Verifica che i trasferimenti di file non causino interruzioni nel gioco o nella voce.
• Riavvia un servizio di gioco senza interrompere i ruoli di file o voce.
• Riempi la quota di caricamento senza riempire il volume di sistema o quello dei salvataggi.
• Disconnetti Internet e ripeti gli accessi locali.
• Ripristina un salvataggio di gioco e la configurazione di un servizio dal backup.

Se il test supera la verifica con un margine utile, smetti di aggiungere complessità. Se lo stesso conflitto di risorse si ripresenta dopo una pianificazione e dei limiti ragionevoli, separa il ruolo che lo causa. Un collo di bottiglia ricorrente della CPU durante il gioco giustifica un calcolo dedicato; trasferimenti di file che saturano lo spazio di archiviazione condiviso giustificano un percorso dati separato; interruzioni della voce durante la manutenzione dell'host giustificano un nodo leggero indipendente.

Quando un host LAN party portatile diventa un server locale riutilizzabile

Un laptop o desktop di riserva è sufficiente per un esperimento una tantum, se riesce a sostenere il carico di lavoro testato e un suo guasto non mette a rischio dati domestici importanti. Un server compatto dedicato diventa più utile quando l'evento si ripete, diversi servizi devono mantenere la propria configurazione tra una sessione e l'altra o l'host deve essere trasportabile senza riconfigurare un PC da gioco.

Per mantenere questo ruolo compatto di calcolo e servizi di rete, un Mini server domestico ZimaBoard 2 offre una piattaforma x86 con doppia LAN da 2,5 GbE, due porte SATA ed espansione PCIe. Queste interfacce offrono opzioni per un percorso server cablato e un'archiviazione locale pianificata, ma l'edizione corretta e la configurazione dello spazio di archiviazione dipendono comunque dai giochi testati, dal numero di giocatori, dalla sovrapposizione dei servizi e dalle esigenze di conservazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Non rendere il prodotto responsabile della correzione di una topologia non definita. Definisci prima i ruoli di gioco, file, voce, identità, backup e ripristino. Se la libreria di file cresce oltre il ruolo compatto a due unità, sposta l'archiviazione di massa su un NAS dedicato, mantenendo i servizi di gioco e voce sul nodo di calcolo. Effettua la separazione solo quando questo ruolo incentrato sull'archiviazione ne dimostra la necessità.

Esegui il backup dello stato difficile da ricostruire

Dai priorità ai salvataggi dei giochi, ai dati dei mondi, alle configurazioni dei servizi, ai manifest delle mod approvate, ai permessi vocali, agli script e alla scheda di connessione. I binari dei giochi e le cache possono essere sostituibili, ma vale comunque la pena conservare la configurazione esatta e sicuramente funzionante usata dal gruppo.

Crea uno snapshot o un backup prima dell’evento dopo l’ultima prova completata con successo. Creane un altro dopo la festa se sono cambiati i progressi, gli screenshot, le registrazioni o le configurazioni. Conserva almeno una copia fuori dal server. Il RAID o i dischi in mirroring possono migliorare la disponibilità dopo il guasto di un’unità, ma non proteggono da eliminazioni, aggiornamenti errati, credenziali compromesse o dalla perdita dell’intero host.

Usa la strategia di backup 3-2-1 di ZimaSpace quando il server inizia a conservare mondi persistenti, file della community o altri dati che non possono essere ricreati. Testa un ripristino in un percorso di servizio pulito invece di presumere che le cartelle copiate si avviino correttamente.

Checklist di configurazione del server per LAN party

Una settimana prima

• Conferma il numero di giocatori, i giochi, le versioni, le mod e i requisiti delle piattaforme.
• Definisci i ruoli dei servizi di gioco, file e voce.
• Mappa le porte dello switch, i cavi Ethernet, l’indirizzo del server e l’eventuale collegamento Internet in uscita.
• Crea gli account dell’evento e separa i percorsi dei dati persistenti.

Un giorno prima

• Esegui la prova completa con carichi sovrapposti.
• Completa gli aggiornamenti e le autenticazioni online necessarie.
• Verifica gli accessi locali con Internet disconnesso.
• Crea un backup sicuramente funzionante e prepara giochi alternativi.

Durante la LAN party

• Usa le credenziali dell’evento e mantieni private le attività di amministrazione dell’host.
• Limita la velocità o rimanda i trasferimenti di grandi dimensioni se le sessioni in corso subiscono rallentamenti.
• Monitora lo spazio libero, le temperature, lo stato dei servizi e l’attività dei salvataggi.
• Invia i caricamenti degli ospiti nell’area di revisione.

Dopo l’evento

• Arresta correttamente i servizi di gioco e conferma i salvataggi finali.
• Esegui il backup delle modifiche approvate e dei contributi dei giocatori.
• Disabilita gli account temporanei e cambia le credenziali condivise.
• Registra i colli di bottiglia prima di modificare la topologia per il prossimo evento.

La configurazione è completa quando i giocatori possono accedere alle partite, scaricare i file approvati e usare la chat vocale locale seguendo percorsi documentati, mentre ogni servizio può essere riavviato o ripristinato senza prendere il controllo degli altri.

FAQ sul server per LAN party

Posso organizzare una LAN party senza accesso a Internet?

Sì, se i giochi selezionati supportano il gioco in rete locale o tramite server dedicato e se tutte le autenticazioni, gli aggiornamenti, le licenze, le mappe e le mod necessarie sono state preparate in anticipo. Testa l’intero processo di accesso con Internet disconnesso, perché alcuni giochi dipendono ancora dai servizi delle piattaforme online.

Mi serve un router o basta uno switch per una LAN party?

Uno switch può collegare i dispositivi locali, ma un router semplifica l'assegnazione degli indirizzi fornendo il DHCP e può offrire l'accesso opzionale a Internet. Per la maggior parte degli eventi domestici, collega il server e i giocatori a uno switch centrale, quindi collega lo switch al router.

Ogni PC da gioco dovrebbe usare Ethernet?

Quando possibile, usa Ethernet cablata per il server e per i PC da gioco sensibili alla latenza. Il Wi-Fi può supportare dispositivi mobili, amministrazione e client aggiuntivi, ma provalo nelle condizioni reali della stanza prima di affidargli il percorso di gioco principale.

Una sola macchina può ospitare più server di gioco contemporaneamente?

Sì, quando la richiesta combinata di CPU, memoria, spazio di archiviazione e rete rimane entro la capacità testata dell'host. Assegna a ogni gioco porte, stato persistente e una procedura di riavvio propri, quindi prova il carico simultaneo previsto per i giocatori.

Quali file dovrebbe condividere un server per una LAN party?

Condividi solo contenuti approvati e legalmente ridistribuibili, come mappe personalizzate, pacchetti di mod, guide alla configurazione, utilità e informazioni sull'evento. Mantieni i download in sola lettura e colloca i caricamenti dei giocatori in una cartella separata e limitata, per poterli esaminare.

Steam può trasferire i giochi sulla rete locale?

Steam supporta il trasferimento di giochi sulla rete locale tra client idonei, ma i permessi dell'account, le impostazioni del client, lo stato del gioco, la velocità dello spazio di archiviazione e la struttura della rete influenzano il risultato. Prova l'esatta configurazione di client e switch prima dell'evento, invece di farci affidamento senza un'alternativa.

Perché ospitare localmente la chat vocale se tutti si trovano nello stesso edificio?

La chat vocale locale aiuta le squadre distribuite tra più stanze, mantiene coerenti le comunicazioni tramite cuffie e offre un'alternativa che non dipende da una piattaforma di chat pubblica. È più utile quando viene configurata come servizio indipendente, capace di sopravvivere ai riavvii dei server di gioco.

Devo usare container o macchine virtuali per i server di gioco?

I container sono efficienti quando i giochi condividono un sistema operativo host e un runtime compatibili. Le macchine virtuali offrono una separazione più netta tra i sistemi operativi quando un titolo richiede librerie, strumenti di gestione o confini di manutenzione diversi. Scegli in base alla compatibilità e al ripristino, non alla moda.

Come si uniscono gli amici remoti a un server locale per una LAN party?

I giocatori remoti hanno bisogno di un percorso protetto appositamente, come una rete privata autenticata o un'esposizione configurata con attenzione e specifica per il gioco. Tratta l'accesso remoto come una topologia separata, con requisiti propri di larghezza di banda Internet, identità, firewall e sicurezza, invece di rendere pubblici tutti i servizi locali.

Cosa devo salvare prima dell'evento?

Esegui il backup dei salvataggi dei giochi, dei dati dei mondi, delle configurazioni, degli elenchi di mod approvate, delle impostazioni vocali, delle definizioni dei servizi, degli script e delle informazioni di connessione. Verifica che almeno una copia sia archiviata al di fuori del server della LAN party e prova un ripristino pulito.