In a previous Devlog , I gave a few details about how mods will work in the upcoming Modding Update (v0.3.x). In this Devlog, I\'ll go into a bit more detail, since I now have more details worked-out. Specifically, I\'ve been working out details for mods that add spacecraft to the game.

The mod_info.ini File

The mod_info.ini file will contain a list of spacecraft files used by the mod. This will save on processing power by not requiring the game to have to figure out what each file is used for. There will be a \"CraftCount\" (or similar) field, possibly in a \"Content\" section of the file (not final yet), followed by a \"Craft_X\" field (where \"X\" is a number starting a zero) for each craft file in the mod. Each craft file will be its own .ini file, with Craft_X having the name of the file without the extension.

It will probably be the case that one does not have to list every craft in the \"Craft_X\" field. For example, craft that can\'t be controlled directly probably shouldn\'t be listed. Extra crafts may be referenced elsewhere in a mod package (eg: stack assembly instruction files).

The CraftName.ini File

Each craft will have its own INI file, which will contain the display name for the craft, the craft description, craft properties, and references to other files. These references will be to shared configuration files, mesh files, etc.

Craft INI files will define engines, RCS thrusters, docking ports, and everything else used by the spacecraft that is exclusive to that spacecraft. It will reference other INI files that are shared between multiple spacecraft. Each component can reference its own mesh file.

The craft\'s INI file (or referenced component INI files) are responsible for defining compatibilities between different types of components. For example, in a staging stack, an engine bay may have a width parameter, and an engine must have a width that is less than that of the engine bay to be considered compatible by the game.

The Mesh File

The Modding Update is doing away with the sprite-based graphics that are currently in the game in favor of vector graphics. So each spacecraft will have a mesh file that represents both the visual graphics of the craft as well as the collision geometry. The mesh files will support levels of detail, animations, possibly state switches, but not textures. Each mesh within the file will instead be a solid color. This means that the gradient on the command module is also going away.

There will be one mesh file for the craft body, and one mesh file for each component on the craft separate from the body (eg: the RCS Block). It might possibly also support having all of the components in a single mesh file, with the craft\'s INI file referencing specific items within the mesh, but I haven\'t yet figured out how I\'m going to do that. Mesh files will also be used to define rocket exhaust. This is probably where animations will be most frequently used.

Currently, to make the mesh files, I\'m going to be exporting the mesh I create in a 3D modeling program to a text-based mesh file, and write a program to convert it to Solar Lander\'s mesh format. I\'m basically going to modify the program for the specific needs of each mesh file and later build a utility that can create any type of mesh file that will ever be needed.

Audio Files

Craft INI files can reference audio files, which are used for stuff like alerts, engine sounds, and crash sounds. Of course, these won\'t be the only audio files used in mods.

Stack Assembly Files

A stack assembly file will define how multiple crafts are attached to each other. They\'ll attach spacecraft together through both stage connectors and docking ports. I haven\'t worked-out all the details yet. Craft INI files will probably have a \"DefaultAssembly\" file reference though. I also intend for game mode scripts to be able to reference specific stack assembly files.

Referencing Other Mods

So that one does not have to define absolutely everything, I\'m going to implement a system that allows mods to reference other mods. The references will probably be \"VendorName/ModName/ItemName\", where \"VendorName\" is the name of the mod\'s developer, \"ModName\" is the name of the mod itself, and \"ItemName\" is an item within the mod, such as a mesh file or a spacecraft.

The reference for the vanilla content will probably be \"SolarLander/BuiltIn\". And I will include an unpackaged \"SolarLander/Base\" mod as an example of how to implement a mod. It\'ll be functionally identical to \"SolarLander/BuiltIn\", but lacking Steam achievements, statistics, and leaderboards. Note that mods dependent on the game\'s base content should reference \"SolarLander/BuiltIn\" rather than \"SolarLander/Base\". Since \"SolarLander/Base\" is an example mod made to be played-around with by the player, referencing it rather than \"SolarLander/BuiltIn\" (which is readonly) may result in unintended or undefined behavior.

Using Mods In-Game

The way mods are presented in-game will probably vary quite a bit depending on the mod\'s content. But there will also be a \"Mods\" screen that displays general information about a mod as well as a list of content, categorized by content type.

If the mod contains game modes, then those game modes will be displayed in \"Single Player -> Custom\" or \"Multiplayer\" depending on how the game mode is presented by the mod. Game modes will be able to allow, forbid, or require specific mods or components of mods. The flight computer is getting its own console window, which will allow you to run programs not included in the base game. And there will be some way for game modes to allow you to select which spacecraft to fly among a few other things. I also intend for there to be the option to dynamically add spacecraft in-game. But I haven\'t figured out any of the details yet.