Stranded: Alien Dawn – Suggerimenti avanzati per il modding

Senza una sorta di sistema di controllo della versione, è quasi impossibile sviluppare software complesso. Le mod sono in effetti tali software, nonostante il fatto che alcuni strumenti dell'interfaccia utente incorporati aiutino a semplificarli (quasi tutti possono creare un sopravvissuto personalizzato utilizzando l'editor di mod).
Il sistema di controllo della versione consente di tenere traccia di tutte le modifiche mai apportate al tuo lavoro, consente di ripristinare versioni stabili precedenti in caso di problemi e, soprattutto, consente a più sviluppatori di lavorare con facilità sullo stesso progetto.
Una soluzione di controllo della versione molto popolare è GitHub. Fornisce hosting per progetti online, consentendo così a diversi modder di sviluppare un unico mod complesso.
Un'altra soluzione è TortoiseSVN, un wrapper di sovversione della GUI, che potrebbe essere utilizzato per ospitare il progetto sul tuo computer o sul tuo server. È molto facile farlo, c'è la documentazione disponibile online.
Entrambe le soluzioni proposte sono ovviamente gratuite (o hanno una versione gratuita).
Una volta che il controllo della versione funziona, puoi tenere traccia di tutte le modifiche apportate alla tua mod. Ad esempio, appena prima di caricare la nuova versione della tua mod, dopo aver salvato la mod, tutte le modifiche potrebbero essere verificate. Questo è un passo da fare, poiché molto spesso ci sono cose incasinate all'ultimo momento. Si dice che lo stesso editor di mod abbia dei bug.
Dopo il caricamento su Steam, le modifiche locali devono essere "impegnate" anche nel repository di controllo della versione.
Le cartelle mod che devono essere sotto il controllo della versione si trovano in:

%appdata%\Stranded - Alien Dawn\Mods

Durante il test della tua mod, nella speciale mappa delle mod, il gioco mostra tutto l'output del gioco sullo schermo e nella console del mod manager. In caso di errori, il modder può vedere i messaggi esatti generati dall'errore e andare a risolvere il problema. Ma nel gioco reale, soprattutto nei salvataggi dove non era presente la nuova mod, gli errori non saranno visibili. Pertanto, molte mod vengono caricate senza essere testate a sufficienza e al momento abbiamo molte segnalazioni di bug in cui una mod sta effettivamente infrangendo la logica del gioco.
Il log di output del gioco, dove si possono trovare gli eventuali errori, viene salvato in un file che si trova in:

%appdata%\Stranded - Alien Dawn\logs

Il problema è che il gioco deve finire per svuotare il registro di gioco generato. Questo non è pratico per il debug in quanto è difficile correlare gli errori nel registro con specifici eventi di gioco. C'è un modo semplice per monitorare il log del gioco in tempo reale al di fuori della mappa di modding. Tutto ciò di cui hai bisogno è l'IDE di Visual Studio. Quando collegato al processo di gioco dal menu Debug – Collega al processo (o scorciatoia Ctrl-Alt-P), tutti i registri di gioco, inclusi gli errori, saranno visibili in tempo reale nella finestra "Output". Il processo di gioco da cercare quando si allega dovrebbe essere chiamato "StrandedSteam.exe". Per quelli di voi che non hanno familiarità con Visual Studio, esiste una versione gratuita chiamata "Community" che può essere scaricata dal sito di visualstudio.

Il motore di gioco S:AD utilizza Lua come linguaggio logico di gioco, sebbene non sia la versione standard, ma modificata: ci sono molte funzionalità aggiuntive, alterate o rimosse nelle librerie standard. Anche il codice di modding "item" è in Lua, sebbene la versione mod non utilizzi l'originale, ma un ambiente limitato, in cui alcune funzioni sono nella lista nera. Il linguaggio Lua stesso è molto semplice, chiunque abbia familiarità con JavaScript o Python potrebbe usarlo senza problemi. Ci sono molti IDE che possono essere usati per modificare i file Lua. Quelli molto popolari sono Visual Studio Code e Sublime, entrambi gratuiti. Nota che Steam potrebbe considerare il gioco ancora in esecuzione dopo averlo chiuso, se Lua IDE è stato avviato dall'ambiente di modding. In tal caso, basta chiudere l'IDE.

Sulla mappa dell'editor di mod, è possibile aprire una console di gioco tramite il tasto INVIO. Permette di controllare il valore di qualsiasi variabile di gioco, rendendolo così un buon strumento di test. Qualsiasi cosa digitata nella console viene valutata come codice Lua in fase di esecuzione e i risultati vengono stampati sullo schermo.
Ad esempio, quando viene selezionato un oggetto, una variabile globale denominata SelectedObj ha l'oggetto selezionato come valore. Digitandolo nella console, verrà stampato il contenuto dell'oggetto, che potrebbe essere un testo molto grande. Quindi è bene cercare informazioni specifiche all'interno dell'oggetto. Se viene digitato un punto (.) dopo SelectedObj (poiché questo è il modo in cui si accede ai membri in Lua), premendo il tasto TAB verrà visualizzato il contenuto dell'oggetto in un elenco da cui è possibile selezionare.
Un'altra importante variabile globale che potrebbe aiutare il debug è UIPlayer. Questo è uno spazio dei nomi di molti importanti valori di gioco. Ad esempio, UIPlayer.labels.Buildings contiene un elenco con tutti gli edifici posizionati, mentre UIPlayer.labels.Survivors è un elenco con tutti i sopravvissuti generati. Digitarli nella console registrerebbe una quantità molto grande di testo, il che non è molto pratico. Esiste una funzione di supporto denominata ValueToStr, che potrebbe essere utilizzata per mostrare più testo leggibile dall'uomo. Esempi: ValueToStr(SelectedObj), ValueToStr(UIPlayer.labels).
La console supporta anche il completamento automatico tramite il tasto TAB. In questo modo non è necessario conoscere il nome esatto di una determinata variabile globale o di un membro dell'oggetto.
Per cancellare lo schermo dal testo stampato, utilizzare il tasto F9.

Quando si creano nuovi oggetti nel gioco, il modo più semplice per farlo è basare il nuovo oggetto su uno esistente. Alcuni elementi mod hanno un'opzione per "Copiare da" un preset di dati Vanila. Ma non tutti lo fanno e non tutti i preset di dati hanno un elemento mod. O forse una mod farebbe confusione con i preset esistenti, invece di crearne di nuovi. Questo intervento ha tuttavia uno svantaggio, poiché la semplice disabilitazione della mod non ne annullerebbe gli effetti: i dati non vengono ricaricati quando una mod viene disabilitata, solo il codice di gioco.
Ad ogni modo, è utile avere un modo per ispezionare i dati di gioco in qualche modo. Un modo consiste nell'usare la console di gioco per controllare il contenuto dei var Preset globali. Contiene quasi tutti i dati di gioco, raggruppati per classe preimpostata. Come descritto nella sezione precedente, digitando il punto (.) dopo ogni nome nella console, verrebbe visualizzato un elenco con i contenuti del contesto corrente. Così facendo, livello per livello, è stato possibile analizzare tutti i contenuti.
Ma l'uso della console ha i suoi limiti, poiché i contenuti dei dati sono troppo complessi per essere ispezionati come una grossa porzione di testo. Occorre piuttosto capire quali classi preimpostate sono registrate nel gioco, in modo da invocare uno strumento esplicito per ognuna di esse. Esiste un comando della console che accetta la classe preimpostata che apre un'interfaccia dati dell'interfaccia utente:

OpenPresetEditor("<PresetClass>")

Dove deve essere sostituito dalla classe specifica da ispezionare. Ad esempio, digitando nella console OpenPresetEditor ("FXPreset") si aprirà l'editor FX, che contiene uno degli elementi di dati più arcani: gli effetti visivi e sonori.

By injto4ka