munix

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.

All you need is a 3D model, textures, and to configure the part modules in Unity (stuff like setting the mass of the part, what category of part is it, etc.) and then you just click a button to export the mod. No need to code anything.

The easiest way to install mods is using CKAN. You can download the ckan.exe file from the link, put it into your KSP2 folder and open it to install mods.

The C# library should probably work for that, since they're both .NET languages.

Part mods can be made completely without any coding

Not true, we already have ~100 mods for KSP2, and the number keeps growing steadily. The game is perfectly moddable as it is, and the addition of an official mod loader won't really change much, other than some of the boilerplate for the initialization of mods, which is abstracted away by the SpaceWarp modding API anyway (which supports both BepInEx and the WIP official mod loader already). Best thing to do if someone wants to request a mod or learn how to make one is to head to the KSP2 Modding Society Discord server.

you might possibly be on version 2.0 of UITK for KSP2, if so, please update to 2.1, that bug should be (mostly) fixed there Edit: it seems like the issue persists even in 2.1 for multiple mods, so I'll do some more investigation and try to fix it

Don't think there's any documentation for sound modding itself, but SpaceWarp does have an API for the loading of Wwise soundbanks, for more info, it's best to join the KSP2 modding server and ask around

the API documentation itself is not on the wiki, but there's a project for that, too: https://schlosrat.github.io/ however, since we do not have access to the devs' documentation comments, it's really just a list of types and members, meant to allow anyone to contribute their knowledge of the code

Yep, @Safarte has been working on that on the KSP2 modding server.

all engines are surface attachable, so you don't need any nodes to attach them to the plate, that's a feature, not a bug, as far as I know

Is this perhaps just copied over from 0.1.3 patch notes accidentally?

I would just like to reiterate what I said above: As for this point, none of my mods needed any (patch-related) updates since the release of 0.1.0.0, and that's the case for most mods that have come out so far, I believe.

You can search in the game's code for the uses of the "Unity.Jobs" and "Unity.Burst" namespaces and see that there are several uses, such as in the PQS system, and in the maneuver node solver for example.

Saying that the game has "no" multithreading is a bit misleading, since this former KSP 2 developer says that they do use it for some parts of the game:

Just to add on to this: since version 1.4, SpaceWarp supports using either BepInEx or the official mod loader as the backend for mod loading, and we're actively working on making it so that when the official mod loader gets finished, modders can very easily switch from the BepInEx backend to the official one with very little changes.

If you're more comfortable with 3DS Max or Maya, you can definitely just use those, Blender is not a requirement, pretty much anything that exports to .fbx should be usable

Depends on what type of mod you want to make, for parts modding, Lux's tutorials are great, and there's an in-depth written guide as well. For code mods, there's my SpaceWarp.Template which gets you started quickly with a fully working C# mod project. Either way, I definitely recommend joining the KSP 2 Modding Society Discord server! We have a lot of modding resources and everyone is really helpful, most of the modding done so far has been a very collaborative effort.

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

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!

Did you install UITK for KSP 2? SpaceWarp has a dependency on it since version 1.2

That's essentially the solution that we also came up with in some of the discussions, and I think it's pretty reasonable - it will make it clear that it shouldn't be used in a non-dev environment, while remaining unobtrusive enough for the modders testing their mods. Yeah, I see this is a really big issue for most people, not knowing if making a mod with our current tools will make it obsolete in say half a year and they'll have to completely redo it. My hope (and plan) is for us to stick with the development of all of them, and to always try to make them work alongside the game, be it on BepInEx now or later on the official mod loader, but I know that anything could happen between now and then, and that me saying it doesn't really mean much to anyone, so I totally get where you're coming from. And of course, with the game being in the early state that it is, we absolutely can't guarantee things won't change, we can try to mitigate it as much as possible (as an example - version 0.1.3 of the game changed the object hierarchy of the "appbar" where the buttons for all mods are being placed, and no mods had to be updated other than SpaceWarp, because we have an abstraction layer for this system in it, and the goal is to do this with a lot of the crucial game systems that might go through some changes), but of course we can't account for 100% of changes and mods inevitably will break at times, especially this early on, despite our best efforts.

We have already had some discussions on this topic at one point, but nothing really became of it, maybe exactly because we didn't really have any constructive KSP 1 modder feedback and the people modding KSP 2 were at this point already used to the Unity bundling process, so it seemed unnecessary to go through the strenuous effort of making this possible, since the game was simply not built in a way to support anything like this. So thank you for bringing it back up, because I think it's a very important discussion to have, and we should definitely reopen it, especially with a new perspective being brought into the mix. Most of us KSP 2 modders never did work on KSP 1 modding, so that's exactly why we want to hear what the community considers important, what we should be focusing on, and how we can make the transition as smooth as possible! One thing I'll say now about this specific point is that it's very important it be discussed very thoroughly, because it's very much a double-edged sword. While I can see how much value it could add by making the process of iterative development and testing of for example part mods, I can also imagine it could be abused in mods releases to the point where the situation would devolve into a KSP 1 no-optimization-whatsover 30-minute-loading-times situation. For that reason my proposal would be to *somehow* only make this tool/system available in "developer installs" of SpaceWarp, and still enforce the actual mod releases to use the Unity bundling pipeline for the best of both worlds. As for competing standards, that's actually a very rare situation so far in the KSP 2 modding community - the absolute majority of people modding KSP 2 are all in one Discord server, where they all discuss their mods and libraries, and we've had many discussions about how to best go about certain decisions that affect the community as a whole - for example deciding to strictly use BepInEx as a mod loader and make SpaceWarp only an API which uses BepInEx as a backend, and many other similar situations. Actually the singular case I can think of where there were two sort of "competing" mods/libraries is exactly what Shadow mentioned, that being Patch Manager and his Konfig. However, even though you can achieve similar results using Patch Manager as you can with Konfig, the target audiences and even the scope and purpose of the two mods is very different. While Konfig is a simplified C# syntax tool for the runtime patching of some select game objects such as parts or celestial bodies, Patch Manager is trying to be a spiritual successor to Module Manager - it is a comprehensive tool which allows you to patch any and all JSON files in the game (the equivalent of KSP 1's .cfg files), it has a full custom syntax based on SCSS, a superset of CSS, which many people are already familiar with - even non-programmers, which we chose exactly for the reason that it's familiar, easy to understand and the language it's based on already has a lot of learning materials available. The goal is also for modders to be able to create their own Patch Manager "modules", through which they can provide a patching system for their own mods, similarly to how you can for example configure Waterfall plumes with Module Manager in KSP 1. And when it comes to collaborative efforts, I also think that the KSP 2 modding community is also very much full of team players - we have modders working together every day to help each other create and improve our mods, or joining forces to make mods together, such as me and @cheese3660 working on the aforementioned Patch Manager (which I'm very grateful for, because my knowledge of language parsing is nothing next to hers). There's barely ever any animosity or even sense of competition between the members of the community, really, most of the currently existing mods have been a mostly collaborative community effort. If anything, KSP 1 modding has always seemed much more much more divided, segregated, and scattered, until very recently when @AtomicTech took our advice and made a unified KSP 1 modding server similarly to our KSP 2 one, which was also the reason why I personally found it so much more difficult to get into KSP 1 modding in the past. Would you also please mind elaborating on the "KSP 2 still has not honed in on a singular standard of how to make a basic part config" part? Because as far as I'm aware, there's only one way to do it, same as the game's developers: filling in the part module data using Unity and then exporting it into JSON - which Cheese has very helpfully provided a tool for to make even easier. This is obviously a very valid point - the game is in very early stages, and a lot of people will probably just say to themselves that there is no point in trying to mod a game that's going to be changing so much in the future. And I don't even really disagree, I'm well aware that a lot of our mods will either get broken sooner or later, or won't be needed at all with future updates. I cannot really speak for anyone else here, but what I will say for myself is that the reason I got into KSP 2 modding in the first place was because despite how much I love KSP 1, I never managed to really get into developing mods for the game myself, it always seemed like pretty much anything I could imagine myself wanting in the game was already made by someone else. KSP 2 is a new frontier, a place where we can learn from the mistakes made in KSP 1 modding, and improve on it, and even if some of our current mods will be deprecated at some point, to me it's still worth the effort knowing that there will be some people who otherwise might not have even kept playing the game, but did because we helped improve the experience for them. It probably won't be worth the time investment to a large number of people, and that's totally ok We just want to know if there are perhaps some people who *do* want to get into KSP 2 modding but are hesitating, and we want to make the experience as nice as possible for them. Once again, thank you for all your feedback and I hope we can continue this discussion to make KSP 2 modding better for everyone!

To be fair we tried a couple of times to have a dialog in a couple of places, and most of the time all we are told essentially just comes down to "just wait for official tools". And while that is a valid position to hold, it doesn't really help inform us what they would actually like to see or even how they imagine those official tools will work, or how they'd want them to work.

And I would like to reiterate that we want to know exactly what it is you think we're doing wrong - saying this doesn't really help us understand why exactly you're unhappy with the current tools we have that I listed, and we'd appreciate some concrete, specific constructive criticism and suggestions. As for your list of concerns, like I already said in my previous post, we can't really change how the game is built, but we try to work with it and not against it as best as we can We as modders obviously can't wave a magic wand and make the game run smoothly on your machine or multiply the number of players by 10. If those are your main issues, it's understandable, but we can't do anything about that, so there's no point in continuing the discussion. Having attempted to get started with KSP 1 modding a couple of years ago, I can tell you that the resources about KSP 1 modding seemed to me even more obscure, sparse and outdated compared to what we have going on with KSP 2 now. The publicly available API is laughable, there's barely any useful information or documentation in it (I'm talking about https://www.kerbalspaceprogram.com/ksp/api/index.html), and we have pretty much the same thing available anyway: https://schlosrat.github.io/. As for "demo projects", yes, there are none published by the developers, since their official mod loader is not yet released, but like I already mentioned in my previous post, we're mitigating that by having a community-made modding API which can work with either BepInEx as it is now, or it can switch to the official solution when that is made public. Moreover, we even have a custom collection of mod project templates to automatically generate the type of mod project you want to build, including some example code etc, and I have more project templates coming soon - for example a full part mod template including the Unity project with all the necessary setup for you to basically just drop in your own assets and press "build", or a template with a full setup for a mod using Unity UI Toolkit, for much easier creation of UIs. I don't think we could do much better in this regard, but if you have any suggestions, like I already said, we'll definitely welcome any discussion about this. We want to keep improving our tools, and a big part of that is the feedback we get from modders about them. This is far from being true, you don't need to know anything about Unity or use it to build a code mod. If you want to make a part mod, you still definitely don't need to know how to build a full Unity game, you only need to learn to use like 1% of Unity's functionality, which is building asset bundles/addressables. That won't change with the official modding tools because the game at its core is built using this system, and we even got some tips from the game developers on how we should go about modding the game using the system. That said, we have people in our modding server who have had 0 programming, modeling, or Unity experience, and who are now successfully writing C# mods and making their own parts with Unity. The process is really easy, and I already mentioned some of the extra tools made by the community, which make it even easier. We also have several tutorial videos about it, which are very helpful even for total beginners. I hope this addressed at least some of your concerns, basically we're making the best of what we've got, and if you think we can improve it, we'd definitely like to hear your suggestions and criticism.