Solar Lander News

[p]After taking far longer than I had intended, I finally have a good plan for ending Early Access. And it involves having 1 or 2 more updates in Early Access. If there's just one more update left within Early Access, then it's going to be the Modding Update (v0.3.x) followed by the Release (v1.0.x). If there will be two more updates within Early Access, then the first of these updates will be the Modding Update (v0.3.x) followed by the Multiplayer Update (v0.4.x) before finally getting to the Release (v1.0.x).[/p][h2]Modding Update (v0.3.x)[/h2][p]Currently, I'm working on the Modding Update. This update will give an official means for users to add their own content and game modes to the game, without changing the vanilla experience. And I am very close to having a solution for Solar Lander to load mods and make them playable. I will leave the details to future devlogs though. But here's what to expect if the Modding Update is the last update before release, and what to expect if the will be one more update after the Modding Update before release.[/p][p]Either way, here's the bare minimum of what to expect from the Modding Update, with the rest of the features I originally planned for the Modding Update being added eventually before release.[/p]

• [p]Create your own spacecraft and possibly non-spacecraft physics bodies.[/p]
• [p]Write your own game modes.[/p]
• [p]Publish your mod to the Steam Workshop or host it elsewhere.[/p]
• [p]Make mods that reference other mods.[/p]
• [p]Create control profiles that can be shared through the Steam Workshop or hosted elsewhere.[/p]
• [p]Add your own music to the game (I currently have no plans on adding any default music ever).[/p]
• [p]Built-in level timers for stuff like speed-running.[/p]

[h3]Last Update Before Release[/h3][p]If the Modding Update is the last update before release, then it'll have multiplayer built-in. It will also have all of the features related to modding that I want to include before release, including:[/p]

• [p]Write your own flight computer programs.[/p]
• [p]Write your own terrain generators.[/p]
• [p]Make complex scene graphs with animations and state switches.[/p]
• [p]Make multiplayer game modes.[/p]
• [p]Add your own planets.[/p]
• [p]Add atmospheres to your planets.[/p]

[h3]Second-to-Last Update Before Release[/h3][p]If the Modding Update is not the last update before release, then there will be a number of features missing from the modding update that will be included in eventually before the release. These include:[/p]

• [p]No ability to make any type of scene graph.[/p]
• [p]No multiplayer game modes.[/p]
• [p]Probably no planets with atmospheres.[/p]

[h3]Modding Tools[/h3][p]The Modding Update will contain at least one tool from the moment the Modding Update hits the Beta branch: A command line utility to convert MSH files to Solar Lander models. Details on that will be in a future devlog. As the modding update progresses, more tools will be added, mainly along the lines of making model files for the game.[/p][p]A second tool that I intend to include from the moment the Modding Update hits the Beta branch is a tool for packaging your mods. Although this will probably later be included within the game itself, especially for publishing to the Steam Workshop. If the mod packaging tool isn't included from the start, it will be included by the time the Modding Update hits the main branch.[/p][h2]Multiplayer Update (v0.4.x)[/h2][p]If including multiplayer functionality in the Modding Update will make it too big, then multiplayer will get its own update. If this happens, then the Multiplayer Update will also get some of the features that the Modding Update didn't get. How many features it gets in relation to modding depends on a few things that I haven't decided on yet. But here's what the Multiplayer Update will focus on specifically:[/p]

• [p]Multiplayer game modes implemented exclusively through mods.[/p]
• [p]A mod will be added to the game featuring a couple of example game modes.[/p]
• [p]Possibility of using peer-to-peer and server-client architectures.[/p]
• [p]For servers, the ability kick and ban players, whitelist players and/or require passwords.[/p]

[h2]Release (v1.0.x)[/h2][p]The 1.0 release will contain all of the features that may have been left out of the previous updates. In addition, there is a master list of features that the community has requested, and I intend to implement most of those. If the community feature requests don't get into any of the other two Early Access updates, they'll also be included in the 1.0 release. In addition, I want to include the following:[/p]

• [p]A built-in tutorial mode, with either a voiceover, popup boxes explaining things, or both.[/p]
• [p]A built-in sandbox mode that has menus for adding and removing objects from the scene, and changing object state.[/p]
• [p]A built-in story mode that's more complex than just landing on barren planets and jumping back into orbit.[/p]
• [p]A system to switch to/from "on-rails" orbits when it time acceleration to improve time acceleration performance.[/p]
• [p]Eliminate all unnecessary elements from the game's player loop, further enhancing performance.[/p]
• [p]A better Command Module AI that will make it much harder to crash the vehicle.[/p]
• [p]More levels in the progression mode.[/p]
• [p]Achievements for the Tutorial and Story game modes.[/p]
• [p]Possibly have achievements for multiplayer.[/p]

[p]To summarize, the Early Access updates will focus mainly on adding functionality to the game. But the release will focus mainly on adding content and whatever features are leftover from the Early Access updates to the game. Some of the items that are listed here for the release may actually be added in the Modding or Multiplayer updates.[/p][h2]Post Release Updates[/h2][p]I currently have no plans for any post-release updates other than bug fixes and security patches. But I am looking at the possibility of releasing Solar Lander on other game stores. Mainly, once the Release comes out, I will consider this game finished and will move on to making other games and projects.[/p]

In light of recent news of a security exploit in Unity, I have rebuilt the latest version of the Physics Update (v0.2.14) with an updated version of the Unity Editor that I'm using for this project. The demo version has also been updated.

Note that I am not able to apply updates to the "physics-update-playerprefs" or "pre-physics-update" branches. If you want to play on those historical branches of Solar Lander, then you should apply the patch that Unity has provided. But "physics-update" (non-playerprefs version), "beta-build", and "default" branches have been updated with a clean build of the game.

[p]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.[/p][h2]The mod_info.ini File[/h2][p]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.[/p][p]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).[/p][h2]The CraftName.ini File[/h2][p]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.[/p][p]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.[/p][p]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.[/p][h2]The Mesh File[/h2][p]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.[/p][p]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.[/p][p]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.[/p][h2]Audio Files[/h2][p]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.[/p][h2]Stack Assembly Files[/h2][p]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.[/p][h2]Referencing Other Mods[/h2][p]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.[/p][p]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.[/p][h2]Using Mods In-Game[/h2][p]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.[/p][p]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.[/p]

[p]One of the goals I've always had for the Modding Update was for players to be able to load a controller profile without affecting their other settings. And I'm finally working on making that goal a reality. Before the Physics Update, you had to assign axis controls in a dialog box that popped-up before the game started. This was before I discovered a way to do this from scripts. For the Physics Update, I decided to just get rid of the dialog box and find some way to integrate axis assignments into the in-game settings screen. Originally, I was going to continue using Unity's legacy Input Manager for this. But I didn't like the way I would have to implement that with the legacy Input Manager. So I went with the new Input System instead. Later, I decided I wanted to implement a control profile system, like what rFactor 1 has. But I also decided not to try implementing it in the Physics Update, since that would take a lot of time to get working, and the game would probably not be in a state where I could patch bugs in the meantime.[/p][p][/p][p]Now that I'm focusing almost exclusively on the Modding Update (as far as Solar Lander development goes), I can implement most of my goals without destroying the updateability of the Physics Update. Plus, I kind of need the Physics Update to work because I'm using that as a reference for the Modding Update, to make sure I don't accidentally miss any features or gameplay mechanics. Also, the move to developing the Modding Update is the first time I've made an update its own project, separate from the project files of the current game version. I probably could have done this in a better way, but it is what it is. And the fact that I did this from the beginning is the whole reason I am able to continue making updates for v0.2.x while also working on v0.3.x.[/p][p][/p][p]Now I almost did something that would have caused a massive delay: I almost replaced the control system I had (which works perfectly) with a new one that would have made the control profile system similar to Zeepkist. Fortunately, I realized that I would not be able to quickly replace the system I had with a new system and scrapped the idea completely. Nonetheless, the attempt to implement this profile system did result in a delay by a few days.[/p][p][/p][p]So here's how the system is going to work: If there is no Settings.ini inside "Users//AppData/LocalLow/TChapman500/Solar Lander", then the game will load all of the settings from the legacy PlayerPrefs settings, saving axis and button assignments in "Profiles/PlayerPrefs.ini". If it finds a Settings.ini file from the Physics Update, it'll load from that instead and save the axis and button assignments to "Profiles/Legacy Settings.ini" instead. And when you click "Reset Defaults" in the lower-left corner of the screen, it'll create a practically empty "Profiles/Default.ini" file (overriding it if it already exists). If you modify the controls, but do not explicitly save the profile settings, then it'll create a "Profiles/Untitled.ini" file, which essentially behaves the same as the current system.[/p][p][/p][p]When you want to load a profile, this dialog box will pop-up with a list of profiles that are in your local Profiles folder. All you need to do is click on the profile you want to load, then click "Load".[/p][p]If you click "Save Profile", then no dialog box will appear unless the current profile name is "Default" or "Untitled". If you click "Save Profile As..." or the current profile name is "Default" or "Untitled", you'll get this dialog box. Entire the profile name (without an extension) and then click "Save". If you click on an existing profile, then the profile name field will be auto-filled with the name of the existing profile that you clicked. You will get a confirmation prompt if you try to override an existing profile.[/p][p]Now there is one thing you must keep in mind if you decide to create a bunch of profiles. You must have only the devices you intend to use for the profile plugged in before you start the game. Extra joysticks plugged in will be recorded in the profile's ini file even if they are not used by any controls.[/p][p][/p][p]There are two more things to note before I end this post:[/p]

1. [p]I intend to provide some default profiles for various types of controllers, but only for controllers that I have access to. These profiles will be included in the game's installation files (Probably in "/Profiles"). The game will copy these profiles into your local Profiles folder if they aren't already there. And if you're not happy with the defaults provided, you can modify them without fear of them being overridden.[/p]
2. [p]I plan to make control profiles sharable through the Workshop. I haven't worked-out the details for that yet. It is likely that this specific feature won't be available when the Modding Update hits the beta branch. But it is one of the goals for the Modding Update.[/p]