Stranded: Alien Dawn – Conseils de modding avancés

Sans une sorte de système de contrôle de version, il est presque impossible de développer des logiciels complexes. Les mods sont en fait de tels logiciels, malgré le fait que certains outils d'interface utilisateur intégrés aident à les simplifier (presque tout le monde peut créer un survivant personnalisé à l'aide de l'éditeur de mod).
Le système de contrôle de version permet de suivre toutes les modifications apportées à votre travail, permet de revenir à des versions stables antérieures en cas de problème et, surtout, permet à plusieurs développeurs de travailler facilement sur le même projet.
Une solution de contrôle de version très populaire est GitHub. Il fournit l'hébergement de projets en ligne, permettant ainsi à plusieurs moddeurs de développer un seul mod complexe.
Une autre solution est TortoiseSVN, un wrapper de sous-version graphique, qui pourrait être utilisé pour héberger le projet sur votre propre ordinateur ou votre serveur. C'est très simple à faire, il y a de la documentation disponible en ligne.
Les deux solutions proposées sont bien entendu gratuites (ou disposent d'une version gratuite).
Une fois que le contrôle de version fonctionne, vous pouvez suivre toutes les modifications apportées à votre mod. Par exemple, juste avant de télécharger la nouvelle version de votre mod, après avoir enregistré le mod, toutes les modifications pourraient être vérifiées. C'est une étape incontournable, car très souvent il y a des choses foirées au dernier moment. L'éditeur de mod lui-même aurait des bogues.
Après le téléchargement sur Steam, les modifications locales doivent également être «validées» dans le référentiel de contrôle de version.
Les dossiers de mod qui doivent être sous contrôle de version sont situés dans :

%appdata%\Stranded - Alien Dawn\Mods

Lors du test de votre mod, dans la carte spéciale des mods, le jeu affiche toutes les sorties du jeu à l'écran et dans la console du gestionnaire de mods. En cas d'erreurs, le moddeur peut voir les messages exacts générés par l'erreur et aller régler le problème. Mais dans le vrai jeu, en particulier dans les parties sauvegardées où le nouveau mod n'était pas présent, les erreurs ne seront pas visibles. Ainsi, de nombreux mods sont téléchargés sans avoir été suffisamment testés et nous avons actuellement de nombreux rapports de bogues où un mod brise en fait la logique du jeu.
Le journal de sortie du jeu, où les éventuelles erreurs peuvent être trouvées, est enregistré dans un fichier qui se trouve dans :

%appdata%\Stranded - Alien Dawn\logs

Le problème est que le jeu doit se terminer pour vider le journal de jeu généré. Ce n'est pas pratique pour le débogage car il est difficile de relier les erreurs du journal à des événements spécifiques du jeu. Il existe un moyen simple de surveiller le journal du jeu en temps réel en dehors de la carte de modding. Tout ce dont vous avez besoin est l'IDE Visual Studio. Lorsqu'il est attaché au processus de jeu depuis le menu Debug - Attach To Process (ou raccourci Ctrl-Alt-P), tous les journaux de jeu, erreurs incluses, seront visibles en temps réel dans la fenêtre "Sortie". Le processus de jeu à rechercher lors de l'attachement doit s'appeler "StrandedSteam.exe". Pour ceux d'entre vous qui ne connaissent pas Visual Studio, il existe une version gratuite nommée "Community" qui peut être téléchargée sur le site de visualstudio.

Le moteur de jeu S:AD utilise Lua comme langage de logique de jeu, bien qu'il ne s'agisse pas de la version vanille, mais d'une version modifiée - il existe de nombreuses fonctionnalités supplémentaires, modifiées ou supprimées dans les bibliothèques standard. Le code de modding "item" est également en Lua, bien que la version mod n'utilise pas l'original, mais un environnement limité, où certaines fonctions sont mises sur liste noire. Le langage Lua lui-même est très simple, toute personne familiarisée avec JavaScript ou Python pourrait l'utiliser sans problème. Il existe de nombreux IDE qui peuvent être utilisés pour éditer des fichiers Lua. Les plus populaires sont Visual Studio Code et Sublime, les deux sont gratuits. Notez que Steam pourrait considérer que le jeu est toujours en cours d'exécution après sa fermeture, si l'IDE Lua a été démarré à partir de l'environnement de modding. Si tel est le cas, fermez simplement l'IDE.

Sur la carte de l'éditeur de mod, il est possible d'ouvrir une console en jeu via la touche ENTER. Il permet de vérifier la valeur de n'importe quelle variable de jeu, ce qui en fait un bon outil de test. Tout ce qui est saisi dans la console est évalué en tant que code Lua lors de l'exécution et les résultats sont imprimés à l'écran.
Par exemple, lorsqu'un objet est sélectionné, une variable globale nommée SelectedObj a l'objet sélectionné comme valeur. Taper cela dans la console imprimerait le contenu de l'objet, qui pourrait être un texte très volumineux. Il est donc bon de rechercher des informations spécifiques à l'intérieur de l'objet. Si un point (.) est tapé après SelectedObj (car c'est ainsi que l'on accède aux membres dans Lua), appuyer sur la touche TAB affichera le contenu de l'objet dans une liste qui peut être sélectionnée.
UIPlayer est une autre variable globale importante qui pourrait aider au débogage. Il s'agit d'un espace de noms de nombreuses valeurs de jeu importantes. Par exemple, UIPlayer.labels.Buildings contient une liste avec tous les bâtiments placés, tandis que UIPlayer.labels.Survivors est une liste avec tous les survivants engendrés. Les taper dans la console enregistrerait cependant une très grande quantité de texte, ce qui n'est pas très pratique. Il existe une fonction d'assistance nommée ValueToStr, qui pourrait être utilisée pour afficher plus de texte lisible par l'homme. Exemples : ValueToStr(SelectedObj), ValueToStr(UIPlayer.labels).
La console prend également en charge la saisie semi-automatique via la touche TAB. De cette façon, il n'est pas nécessaire de connaître le nom exact d'une variable globale donnée ou d'un membre d'objet.
Pour effacer l'écran du texte imprimé, utilisez la touche F9.

Lors de la création de nouveaux éléments dans le jeu, la façon la plus simple de le faire est de baser le nouvel élément sur un élément existant. Certains éléments de mod ont une option pour "Copier depuis" un préréglage de données vanila. Mais tous ne le font pas, et tous les préréglages de données n'ont pas d'élément de modification. Ou peut-être qu'un mod gâcherait les préréglages existants, au lieu de créer de nouveaux préréglages. Cette intervention a cependant un inconvénient, car le simple fait de désactiver le mod n'annulerait pas ses effets - les données ne sont pas rechargées lorsqu'un mod est désactivé, uniquement le code du jeu.
Quoi qu'il en soit, il est utile d'avoir un moyen d'inspecter les données du jeu d'une manière ou d'une autre. Une façon consiste à utiliser la console de jeu pour vérifier le contenu des préréglages var globaux. Il contient presque toutes les données du jeu, regroupées par classe prédéfinie. Comme décrit dans la section précédente, en tapant le point (.) après chaque nom dans la console, une liste avec le contenu du contexte actuel serait affichée. Ce faisant, niveau par niveau, tous les contenus pourraient être analysés.
Mais l'utilisation de la console a ses limites, car le contenu des données est trop complexe pour être inspecté comme un gros morceau de texte. Il est plutôt nécessaire de comprendre quelles classes prédéfinies sont enregistrées dans le jeu, afin d'invoquer un outil explicite pour chacune d'entre elles. Il existe une commande de console acceptant la classe prédéfinie qui ouvre une interface de données d'interface utilisateur :

OpenPresetEditor("<PresetClass>")

où doit être remplacé par la classe spécifique à inspecter. Par exemple, taper dans la console OpenPresetEditor ("FXPreset") ouvrirait l'éditeur FX, qui contient l'un des éléments de données les plus mystérieux - les effets visuels et sonores.

By injto4ka