munix

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.

Also one thing I would like to say here is that there was never any intention on our (KSP 2 modders) side to alienate or attack KSP 1 modders, if anything, (and now I'm really speaking more so for myself personally) we have been users of your mods for years, and they made the game a much more enjoyable experience, I don't think I would have kept playing KSP for 5 years now if there weren't so many amazing mods. And I think that there's a misunderstanding between the two camps here - as much as it pains me to see it, it's definitely pretty clear there's a strong divide between the KSP 1 modding and KSP 2 modding communities, sometimes to the point of needless animosity, when all we want is for KSP 2, a game we see a ton of potential in, to have a modding community as strong as our beloved KSP 1. We simply wanted to have a discussion about what we could do to make KSP 2 modding more accessible to you, and in general, to everyone who wants to take part in it, that's why Lux's original post said: We obviously can't really influence the number of players the game has, or the direction of modding that IG is taking the game in, but what we can do is try to work around any limitations and obstacles to make modding as accessible as possible, which is what we have been trying to do this whole time. That's why all these have been made: SpaceWarp - the general modding API, which abstracts some of the game's and mod loader's APIs so that whenever there's a backend change in either of those, all we need to do is update SpaceWarp, and modders don't need to worry about making changes to their mods. This also means that whenever the official mod loader is actually finished and made public, existing mods built with SpaceWarp should still work just fine, with most changes only happening under the hood in SpaceWarp's internals. SpaceWarp.Template - a collection of various mod .NET project templates to get you set up with a mod project that you can build, deploy and run in the game with literally one keybind. Patch Manager - the KSP 2 Module Manager successor, which is still WIP, but is meant to provide an easy-to-understand syntax for the patching of the game's JSON assets (which are basically the successor of KSP 1's .cfg files). UITK for KSP 2 - a collection of a runtime library, a C# API, and a Unity extension package allowing modders to use the modern Unity UI Toolkit framework and the built-in visual editor for their mod UIs instead of IMGUI, which is a debugging library with really bad performance that was never meant to be used for actual user-facing UIs. KSP 2 Unity Tools - a Unity package which helps with the creation of parts in Unity, giving you visual indicators for things like CoM, CoL and drag cubes, localization tools, automatic generation of JSON part definitions, etc. KSP 2 Community Fixes - a community project with various bug fixes for KSP 2, which make it easier for both players and modders to focus on actually playing the game, or testing their mods, respectively. KSP 2 API Docs Project - a community-driven documentation of the KSP 2 API. Lux's OAB Extensions - a mod that in addition to adding some cool features to the VAB, also has an API for things such as custom part size categories. LFO (Lux's Flames and Ornaments) - a spiritual successor to Waterfall, library for custom engine plumes. ShowKSP2Events - an in-game tool which allows you to see which messages/events the game triggers, when it happens, and how many times/how often, so that you know exactly which ones to hook into from your mods The community is (sometimes literally) working day and night on making both the game and the actual process of modding the game more accessible and more enjoyable. Many of the mods and libraries that I listed are not finished, or perfect, but we're doing our best, and we're open to discussions about all of this. So what we really wanted to hear was: what can we do better to make modding more accessible for you? What are the tools you would like to exist? Please, let's engage in actual fruitful discussion instead of telling people things such as that they're screwing up the modding scene without offering any actual constructive criticism or advice. Thank you all in advance.

Well then maybe instead of just telling us that we're screwing up KSP 2 modding, you could enlighten us with how we should improve it. There already are modders writing code and making assets, and all those people don't seem to mind that they have to spend like 1 more minute on asset bundling, if it means that the game loading times will actually be reasonable. It makes 0 sense to be so defensive about this simple change which seems to only really have positive impact on the game. One more thing I'd like to point out is that I already said earlier that Cheese and I are already working on a successor for Module Manager for KSP 2, exactly for the reason that we want to make KSP 2 modding as accessible and friendly to non-programmers as possible (without sacrificing performance). If you have some feedback on that, you're absolutely free to share it, we welcome all conversations about it, as we have since the start of the project.

What does that even mean? We know that modding is not officially supported yet, so why would it be documented already? And we have been told multiple times that it is coming at some point, we just don't know when, so we simply took matters into our hands and started modding the game without the official support. SpaceWarp is used as an API around many of the game's systems and around the BepInEx mod loader, and right now we're working on abstracting away the last few remaining bits of commonly used BepInEx APIs so that whenever official modding support arrives, most if not all of the work needed to make mods work with the official mod loader will simply be a backend change in SpaceWarp, with minimal changes to existing mods required. That means that people can play with mods right now, which make the game much more enjoyable in many regards, since many of them fill in some of the gaps and missing features or even fix some annoying bugs. At the same time, it will be most likely very easy to update any of the mods we have today to work with the official mod loader as well. This was in my opinion one of the best decisions they could have made - the naive approach in KSP 1 where all the assets for the base game and mods were loaded from individual files on the disk was maybe fine in 2011 and with like 100 parts in the game, but it's obvious now that the performance of it is absolutely dreadful - before I bought a much beefier computer, I had several installs that would take anywhere between 15 and 40 minutes to load. We don't really have any benchmarks yet on how much faster using addressable bundles is, but I can guarantee it will be a significant improvement, at virtually no cost to modders - all we have to do is open Unity, drop the assets into a project, give them a label, and build the bundle, the whole process takes maybe a minute, and the benefits massively outweigh the cost. It's been 12 years since KSP first came out, and KSP 2 shouldn't be stuck with the same outdated technologies and approaches when we can do better. In the end, user experience should always be the most important thing, both for the developers of the game and for us modders, so I 100% welcome this change. Making modding easier at the expense of performance and user comfort is a mistake I really wouldn't want KSP 2 to repeat, especially since the extra "cost" to modders is minimal, as I described. Lux simply gave you an opinion on how MM was designed and its syntax, which doesn't in any way reflect opinions of the game's actual developers, so I don't understand the "we had reasons to avoid modding KSP2 as it appears" thing. You avoid modding KSP 2 because there are modders who disagree with you or criticize the shortcomings of Module Manager?

Just to clear things up, the game's internal mod loader does make use of a GameData folder, if I recall correctly, it will be loading mods from KSP2/GameData/Mods, but those mods will be very different from KSP 1 mods. The internal mod loader already has support for asset loading, even if not publicly documented, and it uses the same addressable bundles that we do with BepInEx+SpaceWarp mods, because that's how the core game is built to work. It greatly improves performance and especially loading times over the "naive" approach of KSP, which was loading all assets from individual files from the disk. This likely won't change, so there's no point in waiting for it.

https://spacedock.info/mod/3277/Space Warp + BepInEx

Yep, it definitely did. One workaround seems to be to take the KSP2_x64.exe file from 0.1.3 and replace the current one with it (credit to @schlosrat). It might not affect the average user too much, but for us modders who might launch the game like 50 times per day when working on a mod and testing it, it's an extremely annoying change, to the point that multiple modders already said they won't continue their work until this is gone.

There isn't really one, KSP 2 data is not stored in folders and individual files, but in Unity addressable bundles. Those are located in KSP2_x64_Data/StreamingAssets/aa/StandaloneWindows64. As for mods, since we're using the BepInEx mod loader, they are (usually) in BepInEx/plugins.

Are you sure you installed UITK for KSP 2 as per the instructions on SpaceDock/GitHub?

Also, I would just like to point out that this is very misleading. If anything, it's the exact opposite. UI made in the earlier versions of the UITK for KSP 2 library only natively supported one fixed resolution and size. If you were to make your window 1000px wide, it would be 1000px wide on an 800x600 screen, same as on a 3840x2160 screen. That's obviously less than ideal, and the only way one could deal with it is by recalculating the size of all UI elements with a multiplier based on the current resolution, resulting in much more unnecessary work for modders. With the automatic scaling introduced in the newer versions of the library, now if you make your window 1000px wide, it will be 1000px wide on a 1920x1080 screen, ~417px wide on a 800x600 screen and ~1812px wide on a 3840x2160. This is the way that KSP 2 itself handles the scaling of all its UI elements, and thus also the correct and intended way for the extra UI library to handle it.