[Dev Blog] SpaceWarp 2.0: Help Us Shape the Future of Modding!

[munix]

SpaceWarp 2.0: Help Us Shape the Future of Modding!

Dear KSP 2 Modding Community,

We're thrilled to have grown alongside you as the SpaceWarp modding API project evolved from its inception in version 0.1 as a simple mod loader, to a community-driven modding API in version 1.0, to where we are now. Your continuous support and feedback have been invaluable in making SpaceWarp better. As we look to the future, we're excited to announce that we are beginning work on SpaceWarp 2.0, a new chapter in our modding journey!

Learning and Growing Together

Our journey through 1.x has been filled with learning experiences. We've listened to many of your suggestions, and have recently introduced some significant updates, such as:

• specification versions - allowing for major changes while still keeping older mods compatible,
• codeless part mods - to empower non-programmers who want to make KSP 2 mods,
• Lua support - for simple scripting without the need to learn C# and .NET,
• experimental support for the official mod loader - to help us prepare for the future.

Those are just a few of the new features that SpaceWarp has seen added during the 1.x development cycle. Your valuable feedback has helped shape SpaceWarp 1, and we're grateful for that.

SpaceWarp 1.5 - A Smooth Transition

Before we dive into the details of SpaceWarp 2.0, let's talk about SpaceWarp 1.5, the next transitional step, and the last update in the 1.x series. We are going to mark all APIs that will be removed or changed as deprecated, and introduce their replacements, giving you a sneak peek of the changes coming in 2.0. That way, while your existing 1.x mods will continue working in 1.5, you will have enough time to prepare them for the major update ahead.

Preparing for the Future

We hear you loud and clear – KSP 2 modding shouldn't have to be tied to an external mod loader when there’s an official one on the way. That's why we're working towards making SpaceWarp fully compatible with both BepInEx and the currently unreleased official mod loader. That way, your mods written for SpaceWarp 1.5 and later should require only minimal changes to support the official mod loader once it arrives.

SpaceWarp 2.0 - Modularization and Flexibility

One of the key architectural differences in SpaceWarp 2.0 is the shift towards modularization. As the library has grown over the past few months, it has gotten to a point where a single project containing all the very diverse APIs and features is simply not sustainable anymore. We want to make SpaceWarp more flexible, so it has enough room to grow in the future without unnecessary complexity, in both the development phase, and in the integration, testing and release phases.

Here are just some examples of the module structure we're considering:

• SpaceWarp.Core – The core mod contract and everything necessary to make a simple mod load in-game.
• SpaceWarp.UI – Including app bar buttons, UI skins, and other UI-related functionalities.
• SpaceWarp.Game – Abstractions of game APIs, enabling seamless interactions with many parts of the game’s code without having to worry about game updates breaking your mods.
• SpaceWarp.Audio – For handling of audio-related features and functionalities.

The Right Approach

We are currently considering two different approaches to the modularization of SpaceWarp:

Approach 1: The Modular Monolith:

• We would split the SpaceWarp modules into individual projects and .DLL files, while keeping them all part of a single mod, single version, and single release zip.
• This approach maintains the current setup for end users and modders, keeping SpaceWarp as a monolithic, but not as tightly coupled library that covers various functionalities.
• The separation of concerns into multiple projects within the SpaceWarp solution will enable easier code management for contributors.

Approach 2: Modular to the Max:

• SpaceWarp would be divided into separate smaller mods, each with its own swinfo.json file, versioning, and independent releases.
• Modders and players can then selectively use only the modules they need, improving customization and reducing unnecessary bloat.
• Community contributions to specific parts of SpaceWarp become more streamlined, as contributors can focus on individual modules without affecting unrelated components, making it easier for multiple people to work on many distinct parts of SpaceWarp at the same time independently.
• *For the sake of transparency – this is the approach that we are currently leaning towards the most, but we want to hear your opinions!

Simplifying Installation for Players

We understand that ease of installation is crucial for players. While approach 2 (Modular to the Max) brings with it more complexity when it comes to user experience when installing SpaceWarp, we're exploring solutions to mitigate this, such as always providing an always updated all-in-one download option for those who prefer simplicity, or the possibility of only installing the core SpaceWarp mod as a lightweight entry point, which will then prompt you to either download the modules your mods depend on manually, or even download and install them for you.

We Value Your Feedback!

Your opinions matter to us! We're building SpaceWarp together, and your insights are integral to shaping its future. We'd love to hear what you think about the two approaches we've shared:

• Are you more inclined towards Approach 1 (The Modular Monolith) or Approach 2 (Modular to the Max), and why?
• How do you think we can enhance the installation experience for players?
• Do you have any other suggestions for what you’d like to see in SpaceWarp 1.5 and 2.0?

Please share your feedback here, or in the KSP 2 Modding Society Discord server, where the development of SpaceWarp and most KSP 2 mods takes place, for a more real-time discussion!

Join Us on This Exciting Journey!

SpaceWarp 2.0 promises a more flexible and future-proof modding experience. Thank you for being a part of this journey with us. Your contributions and feedback help us make SpaceWarp better every day, and we hope that we can all help the KSP 2 modding community one day reach the inspiring heights of its predecessor.

Let's shape the future of KSP 2 modding, together!

[Falki]

I prefer approach 1, though without strong opinions towards it.

Reasoning: Space Warp isn't that big (yet!) to warrant splitting it into multiple mods. App 1. would reduce dependency issues. I'd even merge UITK for KSP2 with SW as that seemed to be no. 1 reason players were having issues with. Also, I have a personal preference for singular mods with separation of concerns split between projects. But either way you choose, we'll adapt.

[munix]

1 hour ago, Falki said:

I prefer approach 1, though without strong opinions towards it.

Reasoning: Space Warp isn't that big (yet!) to warrant splitting it into multiple mods. App 1. would reduce dependency issues. I'd even merge UITK for KSP2 with SW as that seemed to be no. 1 reason players were having issues with. Also, I have a personal preference for singular mods with separation of concerns split between projects. But either way you choose, we'll adapt.

Thank you for your feedback!

Just to explain our reasoning for these changes a bit more - you're right that SpaceWarp is not that large right now, but with the 2.0 update we want to change the architecture to facilitate better future growth, which I don't doubt we'll see happening.

As for UITK for KSP 2, the reason why I made it a separate mod, and not even a SpaceWarp mod (it's even now just a BepInEx mod with a swinfo.json file for the SW mod list support), is that there are modders out there who don't want to use SpaceWarp, and I don't like the idea of gatekeeping such an essential type of a library only for SpaceWarp mods. For the same reason I'm planning on making the AppBar library that I'm working on a separate non-SpaceWarp mod, because I want everyone to be able to use it for their mods' buttons, not just SpaceWarp modders.

And actually, with approach 2 we could probably integrate those libraries much easier into "SpaceWarp" than with approach 1, because if all the modules of SW are separate mods, there's nothing stopping us from allowing people to use only one or two modules as separate mods without actually having to use the core of SpaceWarp, though there's still an argument to be made about whether they should be a part of SpaceWarp if they can work without it.

Dependency issues are a good point, but I think we can deal with those in a way that makes the user experience much better than what it is currently - one of the ideas was that on startup SpaceWarp could read the list of mods to be loaded and check their dependencies, and if there's any SpaceWarp.* dependency that isn't installed or up-to-date, we could ask the user if they agree with us downloading and updating their SW for them - if not, we'd simply point users to the URLs with the dependencies. If they il agree, we could launch some external executable that would take care of the download and installation process automatically

[RUD Everyday]

When will Spacewarp 2.0 be released? (Im guessing after For Science?)

[munix]

1 hour ago, gfdgfherytrey said:

When will Spacewarp 2.0 be released? (Im guessing after For Science?)

Yes, that is currently the plan, 1.6 was just released, but it just included a relatively small feature that is necessary for some specific mods, and 2.0 should most likely be next.

[RUD Everyday]

would be cool if spacewarp had Utik preinstalled.

[munix]

2 hours ago, gfdgfherytrey said:

would be cool if spacewarp had Utik preinstalled.

Dependency management can become ugly very quickly when mods bundle their dependencies with them, the best thing to do is just use CKAN which solves all dependency issues and mod updates for you.