Stranded: Alien Dawn – Advanced Modding Tips

Without some sort of version control system, it’s close to impossible to develop complex software. The mods are in fact such software, despite the fact that some built-in UI tools help to simplify them (almost everybody can create a custom survivor using the mod editor).
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

When testing your mod, in the special mod map, the game displays all game output on the screen and in the mod manager console. In case of errors, the modder can see the exact messages generated by the error and go to fix the problem. But in the real game, especially in saved games where the new mod was not present, the errors will not be visible. Thus, many mods are uploaded without being tested enough and we currently have a lot of bug reports where a mod is actually breaking the game logic.
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.

The S:AD game engine uses Lua as a game logic language, although it’s not the vanilla version, but a modified one – there are a lot of additional, altered or removed functionalities in the standard libs. The modding code “item” is in Lua as well, although the mod version does not use the original, but a limited environment, where certain functions are blacklisted.The Lua language itself is very easy, anyone familiar with JavaScript or Python could use it without problem.There are many IDE that can be used to edit Lua files. Very popular ones are Visual Studio Code and Sublime, both are free. Note that Steam could consider the game still running after closing it, if the Lua IDE has been started from the modding environment. If that is the case, just close the IDE.

On the mod editor map, it is possible to open an in-game console via the ENTER key. It allows to check the value of any game variable, thus making it a good testing tool. Anything typed in the console is evaluated as Lua code in run-time, and the results are printed on the screen.
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.

When creating new stuff in the game, the easiest way to do it is to base the new item on an existing one. Certain mod items have an option to “Copy From” a vanila data preset. But not all do, and not all data presets have a mod item. Or maybe a mod would mess with the existing presets, instead of creating new presets. This intervention however has a drawback, as just disabling the mod would not revert its effects – the data isn’t reloaded when a mod is disabled, only the game code.
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:

OpenPresetEditor("<PresetClass>")

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.

By injto4ka