Some tips that would help developing more complex S:AD mods.
Use version control
The version control system allows to track all the changes ever made on your work, allows to revert to earlier stable versions in case of problems and most importantly makes it possible for multiple developers to work on the same project with ease.
A very popular version control solution is GitHub. It provides hosting for projects online, thus allowing several modders to develop a single complex mod.
Another solution is TortoiseSVN, a GUI subversion wrapper, that could be used to host the project on your own computer, or your server. It’s very easy to do so, there is documentation available online.
Both proposed solutions are of course free (or have a free version).
Once you have the version control working, you can track all changes made to your mod. For instance, just before uploading the new version of your mod, after saving the mod, all changes could be verified. This is a must do step, as very often there are things messed up at the last moment. The mod editor itself is reported to have bugs.
After uploading to Steam, the local changes have to be “committed” to the version control repository as well.
The mod folders that need to be under version control are located in:
%appdata%\Stranded - Alien Dawn\Mods
Monitoring run-time errors
The game output log, where the eventual errors can be found, is saved to a file that can be found in:
%appdata%\Stranded - Alien Dawn\logs
The problem is that the game has to end in order to flush the generated game log. This is not practical for debugging as it’s hard to relate the errors in the log with specific in-game events. There is a simple way to monitor the game log in real time outside the modding map. All you need is the Visual Studio IDE. When attached to the game process from menu Debug – Attach To Process (or shortcut Ctrl-Alt-P), all game log, errors included, will be visible in real-time in the “Output” window. The game process to search when attaching should be called “StrandedSteam.exe”.For those of you not familiar with Visual Studio, there is a free version named “Community” that can be downloaded from the visualstudio site.
Writing mode code
Use the in-game console
For instance, when an object is selected, a global var named SelectedObj has the selected object as value. Typing that in the console, would print the contents of the object, which could be a very large text. So it is good to look for specific information inside the object. If a point (.) is typed after SelectedObj (as this is how members are accessed in Lua), pressing the TAB key would show the object’s contents in a list that can be selected from.
Another important global var that could help debugging is UIPlayer. This is a namespace of many important game values. For instance, UIPlayer.labels.Buildings holds a list with all placed buildings, while UIPlayer.labels.Survivors is a list with all spawned survivors. Typing these in the console would log a very large amount of text though, which is not very practical. There is a helper function named ValueToStr, that could be used to show more human readable text. Examples: ValueToStr(SelectedObj), ValueToStr(UIPlayer.labels).
The console supports auto-complete via the TAB key as well. This way there is no need to know the exact name of a given global variable or an object member.
In order to clear the screen from the printed text, use F9 key.
Working with game data
Anyway, it is usefull to have a way to inspect the game data somehow. One way is to use the game console to check the contents of the global var Presets. It contains almost all of the game data, grouped by preset class. As described in the previous section, by typing point (.) after each name in the console, a list with the contents of the current context would be displayed. Doing so, level by level, all of the contents could be analysed.
But using the console has its limitations, as the data contents are too complex to be inspected as a big chunk of text. It is rather required to understand what preset classes are registered in the game, in order to invoke an explicit tool for each of them. There is a console command accepting the preset class that opens an UI data intererface:
where <PresetClass> has to be replaced by the specific class to be inspected. For instance, typing in the console OpenPresetEditor(“FXPreset”) would open the FX editor, which holds one of the most arcane data items – the visual and the sound effects.