What is keeping you from starting your KSP2 Mod?

[Beale]

Waiting for official modding tools.

[cheese3660]

30 minutes ago, Lisias said:

Or, in fewer words, which ones of my list of concerns such tools are going to fix so I can be lured into modding KSP2?

I'll reply to this specifically, on a few of your concerns
 

On 6/13/2023 at 11:05 AM, Lisias said:

Have no published API

The KSP 2 API Docs Project that @munix mentioned is specifically meant to document the API that KSP2 uses.

On 6/13/2023 at 11:05 AM, Lisias said:

And, adding offense to the insult, I need to learn how to build a Unity Game in order to be able do deliver something - no kidding, I need to learn the whole pipeline

And for this one, a few comments,
For DLL only mods: You don't need Unity at all.
For parts mods: You do need unity to build addressables bundles, but that is different than building a whole game, you don't need a full understanding of unity at all for that, and KSP2 Unity Tools is something that I was working on to make it easier yet. And the official tools for part modding, are likely, in my opinion, going to be unity packages that provide similar tools to make parts modding in unity easier.
 

Edited July 8, 2023 by cheese3660
Fixed typo unitry -> unity

[munix]

54 minutes ago, Lisias said:

I said they are reproducing the problems that harmed KSP1's modding in the past. For starters, the cavalier attitude about what we are asking and the praising of tools that are not solving our problems as a solution for our problems because such tools are solving their problems.

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.

54 minutes ago, Lisias said:

Or, in fewer words, which ones of my list of concerns such tools are going to fix so I can be lured into modding KSP2?

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

On 6/13/2023 at 5:05 PM, Lisias said:

So it makes absolutely no sense on modding a Game that:

• Have almost no users online, sometimes literally
  • [edit: the zero points are glitches on the Steam Charts, KSP1 is getting some now (2023-0623)]
  •   Reveal hidden contents

    

• It doesn't runs on any of my machines with a minimally acceptable performance
  • And I'm not willing to commit resources on a new rig right now.
  • TL;DR: I can't even run the thing.

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.

On 6/13/2023 at 5:05 PM, Lisias said:

• Have no published API
  • So I need to Reverse Engineer the thing myself
    • And this is not exactly allowed under some Legislations
    • Not to mention the huge additional time investment on it 
  • There's absolutely no Demo Projects published by the Developes, so Reverse Engineering is really the only way to go

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.

On 6/13/2023 at 5:05 PM, Lisias said:

• And, adding offense to the insult, I need to learn how to build a Unity Game in order to be able do deliver something - no kidding, I need to learn the whole pipeline.
  • On KSP, all I need is Notepad, Paintbrush and sometimes Visual Studio CE to compile a DLL

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.

Edited July 8, 2023 by munix

[Kavaeric]

Hi, so, I figured I'd lend in my two cents on the matter. For background I'm a new modder to KSP1, and I've been learning a LOT about part modding by studying both Nertea's legacy work (and trying to match his style) as well as from prolific folks like Poodmund, Beale, Zorg, etc. I've not formally published any of it yet, but here's the lineup of engines for my first mod, CryoEngines Extensions:

I'll also take the time to point out my background, which is to say that I am a modder of an artist background, not of a programming background. This, I think, will be important for this discussion.

I only learned how to mod about a month ago. At the time, like now, I harbour no ill will towards the developers (and I banter with them even on the official IG server) nor towards any of the active player KSP2 community, despite (or perhaps because of) its admittedly smaller size. Despite this and the eagerness of folks like ShadowDev and Munix, and even contributing to some UI specs for various KSP2 mods, I ended up deciding to commit my efforts to learning KSP1 modding first instead. The word "commit" is important, I feel, because learning how to make an engine is a large undertaking and a big timesink, and I do not want my efforts to go to waste. At the risk of repeating previous points, the reasons I decided to commit to KSP1 modding are as follows:

• As an artist, the development pipeline feels much less intrusive for KSP1. Reading this thread and elsewhere I understand what folks like Lux and ShadowDev say regarding the benefits of packaging assets into bundles, for the sake of performance and load times for players—but if I'm honest, during the actual asset development cycle load times of the game are not actually the biggest time sink. Rather, when I'm making my assets I much prefer having to jump through as hoops as possible when I make changes to textures, models, or config settings.
  
  As an example, a common occurrence is for me to load a WIP engine into the game and finding out the visual appearance of some of the textures feels off. Since I work in KSP1, though, all I need to do is scribble the edit of the texture in Photoshop, re-export as the DDS, and then slap that into the GameData folder and launch the game again. Again I understand folks' criticisms of the inefficiency of the GameData folder, but what it represents to non-technical modders like myself is a very familiar and intuitive workflow that feels very automatic: just drag and drop the new texture, model, or config into the folder and see if it works. There's also the assurance of how it's all exposed to me and very understandable: I know for a fact that if I don't touch the config file in GameData, none of the stats will change because I've thrown in a new texture. Having to first bundle and package a mod using what is ultimately a black box to me adds a fair amount of friction and is much less reassuring, especially if something goes wrong with the new asset.
  
  If you want to get a better sense of the preferences of artist/asset modders like myself, consider how tools like taniwah's Blender exporter are the real game changer, meaning many of us can cut out Unity entirely out of our pipeline: things go straight from the art program we use to model our assets directly into the game with no middleman. The fewer steps between the program I use to make my assets and seeing them in-game, the better. An attempt at an analogy: imagine if every time you wanted to compile your code you wrote in VSCode you had to, for whatever reason, open it in Adobe Dreamweaver first and then export it from there. Sure, it's just "one step", and you're not making a whole thing in DW, but I think you can imagine why it would be so off-putting for asset artists who have a similar relationship with Unity, hence why the new asset creation paradigm in KSP1 is to not use Unity at all.
  
  Perhaps an in-between solution is to have a "dropbox" modding folder akin to GameData specifically for asset modders to quickly drop in new edits when developing. An upgrade over the KSP1 system could possibly be an in-game asset editor that allowed me to just import edited textures and new models on the fly, similar to Cities Skylines' editor, cutting out the need to reload the game repeatedly and allowing me to directly view what the asset will look like with the in-game render engine on the fly. In that regard, I don't think anyone would be opposed to being asked to still bundle their mods for publication at the end of development.
   
• I am turned off by the competing standards of the modding tools of KSP2. A lot of this can be chalked up to the fact that KSP2 is still early in development and so many of the standards or solutions haven't yet crystallised. Nonetheless, if you are asking us what is stopping us from picking up modding now, this is still worth emphasising. I'll go one step further and actually disagree with what ShadowDev said: I don't want to have to choose between three different methods of accomplishing the same thing, because that means I'm making a commitment to that method/tool. As a beginner I inherently do not have the knowledge or background to confidently choose which avenue would work best for me.
  
  Having multiple competing standards itself too becomes a barrier to community as well. Much of the modding effort in KSP1 is still very collaborative, and often spontaneously so: in the last week, Atomic, LinuxGuruGamer, and a few others patched themselves together into a team of like four people to work on a new mod in the span of a few hours and have already produced some concepts and assets. This is only possible because for a given type of asset there is a single unified approach to making it in KSP1, and so everyone merely needs to find which part of the assembly line they need to drop in. It's not the best pipeline, of course, but the fact that it is a single standard and that I can approach anyone and know they can slot into a project gives me a lot of confidence both when making mods and requesting help as a beginner. With many of the biggest mods in KSP1 being highly collaborative efforts (even one-man army Nertea didn't work alone), the fact that KSP2 modding still has not honed in on a singular standard of how to make a basic part config makes me hesitate.
   
• I don't actually know what I'd want to, or should, mod for KSP2. This one I don't think has been mentioned but I think it's what a lot of people feel wrt to the fact that KSP2 is still very early in development. I don't actually do modding for its own sake; I got into modding because I identified a gap in the game that I think should be addressed. I'd argue many of the biggest projects in KSP1 stemmed from this motivation of identifying a gap and then building a mod to address it: Nertea's entire suite is about extending the stockalike experience; ReStock was about refurbishing and standardising the appearance of the stock parts; Beale's new WaterDrinker was made following dissatisfaction with the aging Firespitter framework; my own WIP mod was itself spurred from a desire for more Nertea-like parts. With the current development state of KSP2 being so early, the approach of "identify gap, make mod to address gap" doesn't work because there aren't gaps so much as enormous voids where work hasn't even started. This is not to disparage the efforts of the KSP2 dev team and I have confidence they will follow through on the roadmap, but the reality is is that getting us to mod a game so early in development is akin to asking an interior designer to have a go at re-arranging the dining room furniture for a house that has barely completed building its foundations.
  
  Plus, with the competing standards and ambiguity of the exact features of the roadmap going forward, there is an inherit gamble in spending effort in something that may be folded into the core experience or otherwise rendered irrelevant. None of us want to accidentally recreate a RemoteTech-CommNet or KIS-Stock Inventory situation; the thought of a lot of monumental (unpaid and often thankless) work going into modding a game only for it to be rendered mostly null in six months does not motivate. I think many of us are indeed just waiting to see a clearer picture of what "stock" KSP2 will look like in order to inform the direction of our modding.

 

I know that's a lot of text and I appreciate y'alls effort in starting early and getting the modding framework for KSP2 correct. That said, I'll leave off with how, while I think they could word it better, I ultimately agree with Lisias: I feel as though much of the effort and design of modding tools for KSP2 have been engineered by and for programmers and coders, with little input or consideration for those who do not come from that background—and there are a lot of us of that background. To repeat their point, the tools feel like they are being made solely to make programming and optimisation of the game easier at the expense of asset developers. While I understand that programming foundations need to be laid out first, the truth is if you're asking us why, right now, we don't take an interest in KSP2 modding, it's because none of the tools nor any of the communication suggest to me a concerted or directed effort in improving the pipeline, flow, tools, and communication for asset artists.

I am happy to continue to lend help with UX matters, but something like this needs more than just making sure the UI elements are pretty. It will require concerted and active effort to garner feedback and to ensure tools are being designed around all kinds of modders.

(as a disclaimer too: these are all my own thoughts and I do not speak for everyone in the KSP1 modding community, of course)

Edited July 8, 2023 by Kavaeric

[ShadowDev]

would like to add that when official modding support is added it will be virtually the same as the current unofficial system.

only differences will be
SWinfo will become modinfo
\BepInEx\plugins will become \GameData\Mods

you will still need to use unity for part modding since they use addressables bundles

as an example heres a working mod using the current official mod loader

3 minutes ago, Kavaeric said:

disagree with what ShadowDev said: I don't want to have to choose between three different methods of accomplishing the same thing, because that means I'm making a commitment to that method/tool. As a beginner I inherently do not have the knowledge or background to confidently choose which avenue would work best for me.

To clear this up.
Patch Manager is more for modders
Konfig is more for players

[cheese3660]

3 minutes ago, Kavaeric said:

I feel as though much of the effort and design of modding tools for KSP2 have been engineered by and for programmers and coders, with little input or consideration for those who do not come from that background—and there are a lot of us of that background.

This here is why I asked for input from older KSP1 Modders when trying to design a MM-like patching system, the system I had in mind was almost completely meant for programmers, to the point where it was just C# code that had a complex framework around it, and from their input, I realized that that would be very inaccessible, hence why I completely redesigned the format I had in mind to be something akin to SCSS, which was spurred on by your offhand comment on MM patching being similar to CSS selectors. So I shall say, that I want to make modding accessible to those of non-programming backgrounds, and that is what this post is trying to ascertain, how do we make it accessible.
 

13 minutes ago, Kavaeric said:

I am turned off by the competing standards of the modding tools of KSP2. A lot of this can be chalked up to the fact that KSP2 is still early in development and so many of the standards or solutions haven't yet crystallised. Nonetheless, if you are asking us what is stopping us from picking up modding now, this is still worth emphasising. I'll go one step further and actually disagree with what ShadowDev said: I don't want to have to choose between three different methods of accomplishing the same thing, because that means I'm making a commitment to that method/tool. As a beginner I inherently do not have the knowledge or background to confidently choose which avenue would work best for me.

I agree here too,  which may seem odd, given I am working on a competing standard to the one shadow brought up, Konfig. The reason I agree here is that it will be hell on the maintainers of mods and the tools to have to debug incompatibilities between 2 tools doing near the same thing. As for why I am still working on a competitor in that case, is because I feel as if Konfig is inherently less accessible to those non-programmers, and I feel that it is a fundamental flaw of its design and how it works causing that.

But let me reiterate, I want to make modding accessible, to everyone, that is what a lot of my work has been for, like for another example removing any need for any code in parts modding in the last space warp update.

[Kavaeric]

8 minutes ago, cheese3660 said:

This here is why I asked for input from older KSP1 Modders...

I did poke a few of them and they kept directing back to the open letter as the answer to "why aren't you modding for KSP2". Suffice to say I think it might be worth going back to it and reading it with a fine tooth comb.

If you're asking about how to design the tools it might be better to ask questions like, "what do you like about KSP1 modding?" "what do you wish could be better?" to inform the direction you take your tools. I'm a UX design student so of course I'm going to advocate for user testing and research and feedback; I worry that a lot of the decisions being made for KSP2 modding tools are made off assumptions of what KSP1 modders want.

Edited July 8, 2023 by Kavaeric

[munix]

3 minutes ago, Kavaeric said:

I worry that a lot of the decisions being made for KSP2 modding tools are made off assumptions of what KSP1 modders want.

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. 

[LuxStice]

21 minutes ago, munix said:

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. 

to add to this, IG won't provide most of the tools you need to make parts, they will provide the basics, don't expect them to give you a parts switcher, module manager, waterfall nor none of the tools that were made by modders in ksp1, thus the purpouse of this topic, so that we, modders, can make such tools early and in a way to meets your needs

[munix]

2 hours ago, Kavaeric said:

• As an artist, the development pipeline feels much less intrusive for KSP1. Reading this thread and elsewhere I understand what folks like Lux and ShadowDev say regarding the benefits of packaging assets into bundles, for the sake of performance and load times for players—but if I'm honest, during the actual asset development cycle load times of the game are not actually the biggest time sink. Rather, when I'm making my assets I much prefer having to jump through as hoops as possible when I make changes to textures, models, or config settings.
  [...]
  Perhaps an in-between solution is to have a "dropbox" modding folder akin to GameData specifically for asset modders to quickly drop in new edits when developing. An upgrade over the KSP1 system could possibly be an in-game asset editor that allowed me to just import edited textures and new models on the fly, similar to Cities Skylines' editor, cutting out the need to reload the game repeatedly and allowing me to directly view what the asset will look like with the in-game render engine on the fly. In that regard, I don't think anyone would be opposed to being asked to still bundle their mods for publication at the end of development.

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.

2 hours ago, Kavaeric said:

• I am turned off by the competing standards of the modding tools of KSP2. A lot of this can be chalked up to the fact that KSP2 is still early in development and so many of the standards or solutions haven't yet crystallised. Nonetheless, if you are asking us what is stopping us from picking up modding now, this is still worth emphasising. I'll go one step further and actually disagree with what ShadowDev said: I don't want to have to choose between three different methods of accomplishing the same thing, because that means I'm making a commitment to that method/tool. As a beginner I inherently do not have the knowledge or background to confidently choose which avenue would work best for me.
  
  Having multiple competing standards itself too becomes a barrier to community as well. Much of the modding effort in KSP1 is still very collaborative, and often spontaneously so: in the last week, Atomic, LinuxGuruGamer, and a few others patched themselves together into a team of like four people to work on a new mod in the span of a few hours and have already produced some concepts and assets. This is only possible because for a given type of asset there is a single unified approach to making it in KSP1, and so everyone merely needs to find which part of the assembly line they need to drop in. It's not the best pipeline, of course, but the fact that it is a single standard and that I can approach anyone and know they can slot into a project gives me a lot of confidence both when making mods and requesting help as a beginner. With many of the biggest mods in KSP1 being highly collaborative efforts (even one-man army Nertea didn't work alone), the fact that KSP2 modding still has not honed in on a singular standard of how to make a basic part config makes me hesitate.

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.

2 hours ago, Kavaeric said:

• I don't actually know what I'd want to, or should, mod for KSP2. This one I don't think has been mentioned but I think it's what a lot of people feel wrt to the fact that KSP2 is still very early in development. I don't actually do modding for its own sake; I got into modding because I identified a gap in the game that I think should be addressed. I'd argue many of the biggest projects in KSP1 stemmed from this motivation of identifying a gap and then building a mod to address it: Nertea's entire suite is about extending the stockalike experience; ReStock was about refurbishing and standardising the appearance of the stock parts; Beale's new WaterDrinker was made following dissatisfaction with the aging Firespitter framework; my own WIP mod was itself spurred from a desire for more Nertea-like parts. With the current development state of KSP2 being so early, the approach of "identify gap, make mod to address gap" doesn't work because there aren't gaps so much as enormous voids where work hasn't even started. This is not to disparage the efforts of the KSP2 dev team and I have confidence they will follow through on the roadmap, but the reality is is that getting us to mod a game so early in development is akin to asking an interior designer to have a go at re-arranging the dining room furniture for a house that has barely completed building its foundations.
  
  Plus, with the competing standards and ambiguity of the exact features of the roadmap going forward, there is an inherit gamble in spending effort in something that may be folded into the core experience or otherwise rendered irrelevant. None of us want to accidentally recreate a RemoteTech-CommNet or KIS-Stock Inventory situation; the thought of a lot of monumental (unpaid and often thankless) work going into modding a game only for it to be rendered mostly null in six months does not motivate. I think many of us are indeed just waiting to see a clearer picture of what "stock" KSP2 will look like in order to inform the direction of our modding.

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!

Edited July 8, 2023 by munix

[GGG-GoodGuyGreg]

Sorry but I think this is the best place to ask this with so many Moders here.

Can someone ELI5 for normies like me how much easier would official mod support make it when modding the game and what would official mod support look like?

Also, is there any type of mod that can’t be done or is much harder to do because of this?

Thanks in advance! 

 

Edited July 8, 2023 by GGG-GoodGuyGreg

[LuxStice]

13 minutes ago, GGG-GoodGuyGreg said:

Can someone ELI5 for normies like me how much easier would official mod support make it when modding the game and what would official mod support look like?

Also, is there any type of mod that can’t be done or is much harder to do because of this?

Sure!
What most devs mean by "Official mod support" is mostly just a publicized API for modders to work with, along with some tools inside the engine (or even inside the game) for modders to play with.
The API would be something like a set of classes that players can extend from to create their own mods, modules and more. As for the methods, it can be a vast amount of things, but would mostly just help programmers.
As for tools, we expect them to be all inside Unity, since thats what they work with, they'll probably make available some of the tools that they already use, such as ie. a tool to create the part's icon, or a tool to test engine plumes, or a tool to create new planets. Modding support rarely means that they'll develop actual mods or helpers or even frameworks for the community, because that would mean that, other than supporting the game with new content and bug fixes, they'd have to support something (often) very complex.
As for doccumentation, i also dont expect them to give us a detailed documentation, just the basics of each class and method, which is more than enough for most programmer modder.

Usually they also provide guides and tutorials on how to do various things modding related and some sort of channel to communicate with the devs on methods that you need or questions that you might have.

You gotta remind that, anything they do provide us, has to be maintained and public ready, so they can't be creating new things, since that would mean that, on top of the complex and massive game that they already have, they'd have to maintain and update also those newly created things.

TL;DR
Basic API with public methods and classes, documentation of the game's code, Unity tools that they already use will be available


The most probable outcome to creating a new part mod would look something like

1. Download Unity
2. Download IG's provided Unity addons
3. Open Unity and setup addressables (guided by some tutorial made by them)
4. import model into unity, add every module u need to the part
5. press "Export" on IG's provided addon
6. copy to KSP2 folder

which is already pretty close to what we do currently when creating part mods

As for config only mods, i can't see them making such tools/framework for something like that, its not as simple as "load all configs", specially now that the game is based on .json configs and prefabs and not just a simple text file. remember, what they create they'll have to maintain.

As for .DLL mods, the work will be easier with the API's, but dont expect it to be THAT easy.


I dont think that Officialy, all types of mods can be done, Ie. @munix's UITK for KSP2, it loads DLLs before the game even starts, which you can't possible do from whitin the game, such mods would be an almost impossible task to make officially (w/o the right code, which they don't have currently). Other than that, everything is possible officially.

Edited July 8, 2023 by LuxStice

[Lisias]

8 hours ago, LuxStice said:

What most devs mean by "Official mod support" is mostly just a publicized API for modders to work with, along with some tools inside the engine (or even inside the game) for modders to play with.

No.

It's a set of documentation provided by people that wrote the code, knew the requirements the code aimed to fulfil and understand why things were coded that way.

In a moment of conflict or confusion, these guys are the ones that are in a position to take a decision that is going to stick on the long run.

Downplaying the reason the KSP1 modders are pledging for an sanctioned documentation is not exactly the best way to conquer their hearts… 

Edited July 9, 2023 by Lisias
Tyop! Surprised?

[LuxStice]

8 minutes ago, Lisias said:

No.

It's a set of documentation provided by people that wrote the code, knew the requirements the code aimed to fulfil and understand why things were coded that way.

In a moment of conflict or confusion, these guys are the ones that are in a position to take a decision that is going to stick on the long run.

Downplaying the reason the KSP1 modders are pledging form an sanctioned documentation is not exactly the best way to conquer their hearts… 

Sure ok. if you think so, but most, if not all, recent games that have modding support follow that pattern

Edited July 8, 2023 by LuxStice

[Lisias]

3 hours ago, LuxStice said:

Sure ok. if you think so, but most, if not all, recent games that have modding support follow that pattern

None of them have NASA, ESA and SpaceX engineers using and probably modding the game - even at work. KSP¹ is not an ordinary game.

You are not modding just for kids, still unable to tell good from evil - not to mention nuances on the different copyrights laws around the World.

You are also modding for full grown adults, professionals on many different areas, including aerospace engineers - and these guys have a very low tolerance to push overs and unethical practices in general.

You want their help? You need to cope with their needs.

However, I'm assuming KSP2 is taking the same route KSP¹ took, but perhaps I'm wrong? If KSP2 is going to be just another one of these recent games "following that pattern" focused on kids and mainstream gaming, then definitively KSP2 is not for me neither for such people.

And, then, you are right and don't need to hear our pledges, as we are not going to play KSP2 anyway.

Edited July 9, 2023 by Lisias
Some entertaining grammars made less entertaining.

[Angelo Kerman]

The biggest thing keeping me from modding KSP 2 is a lack of official modding support. Someday they might include it, then someday I might mod the game. That's one big difference between KSP 1 and KSP 2: in KSP 1, the designers provided modding support early on. I wasn't around before KSP 1's 0.23.5, but by then they had modding.

[Kavaeric]

9 hours ago, munix said:

 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.

Could be as straightforward as burying an "enable developer mode" option somewhere in the settings or config file of SpaceWarp that evokes a text warning on what it entails; enabling it would allow for loading unbundled assets from a development folder a la KSP1 GameData. Having it require a restart wouldn't be out of the question—I imagine most modders, like with KSP1, will likely have a secondary "workshop" or "test" instance of KSP2 that's separate from their main game to test compatibility and to improve load times. Slapping a watermark in the corner of the screen reading "SpaceWarp developer mode" would mean it'd be very easy to tell anyone who might have it on when they shouldn't (i.e. when seeking support). I imagine there may be other developer features in future that may be opt-in like a dropbox asset feature.

re: competing standards and official modding support: I imagine the big reason is that any modding tools and API that IG publishes will be backed with some kind of promise (implied or explicit) that both the modding API will not be altered and that the game is in a somewhat stable situation where randos on the internet like myself can start smashing meshes together and putting them in the game. This isn't to disparage any of the efforts of any of you—it's just a confidence thing, and for a lot of folks I imagine nothing short than the rubber stamp of the game's own developers is sufficient to ease anxiety that efforts put in now will not be wasted in the foreseeable future. Perhaps this can be mitigated if the community modding tools for KSP2 being developed right now were endorsed in some way by the devs, but I imagine they have other more pressing matters to tend to right now.

Edited July 9, 2023 by Kavaeric

[Lisias]

28 minutes ago, Angelo Kerman said:

That's one big difference between KSP 1 and KSP 2: in KSP 1, the designers provided modding support early on. I wasn't around before KSP 1's 0.23.5, but by then they had modding.

And not only that, they made the thing extremely friendly to newbies. Notepad and PaintBrush, is all what you really needed to toy around in your first custom part set (reusing current meshes, of course). With a bit of 3d modelling using practically any format ever published under the Sun (they supported Collada!!) and you are in the selected group of innovative part sets.

They really gone the extra mile to lure people of all ages and backgrounds into modding KSP¹.

Addionaly, for each new modder that published something, you have about 20 (rhetorical number, I pulled it from my… hat..) that did the same for themselves at home but didn't bored to publish their changes. The ones that published things are just the tip of the iceberg, they wouldn't be afloat without the rest of the iceberg under the water.

 

20 minutes ago, Kavaeric said:

re: competing standards and official modding support: I imagine the big reason is that any modding tools and API that IG publishes will be backed with some kind of promise (implied or explicit) that both the modding API will not be altered and that the game is in a somewhat stable situation where randos on the internet like myself can start smashing meshes together and putting them in the game.

A bad standard is better than no standard at all. We didn't did what we did because of the MM's many flaws, we did besides them. We did that because MM made it very easy to anyone to do that.

We had problems with it? A lot, newbies can really screw up things sometimes. But every single one of us was a newbie screwing things once, it's part of the growing pains. We get rid of the growing pains, we lose growing itself.

[munix]

4 hours ago, Kavaeric said:

Slapping a watermark in the corner of the screen reading "SpaceWarp developer mode" would mean it'd be very easy to tell anyone who might have it on when they shouldn't (i.e. when seeking support)

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.

4 hours ago, Kavaeric said:

re: competing standards and official modding support: I imagine the big reason is that any modding tools and API that IG publishes will be backed with some kind of promise (implied or explicit) that both the modding API will not be altered and that the game is in a somewhat stable situation where randos on the internet like myself can start smashing meshes together and putting them in the game. This isn't to disparage any of the efforts of any of you—it's just a confidence thing, and for a lot of folks I imagine nothing short than the rubber stamp of the game's own developers is sufficient to ease anxiety that efforts put in now will not be wasted in the foreseeable future. Perhaps this can be mitigated if the community modding tools for KSP2 being developed right now were endorsed in some way by the devs, but I imagine they have other more pressing matters to tend to right now.

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.

[schlosrat]

6 hours ago, Lisias said:

Addionaly, for each new modder that published something, you have about 20 (rhetorical number, I pulled it from my… hat..) that did the same for themselves at home but didn't bored to publish their changes. The ones that published things are just the tip of the iceberg, they wouldn't be afloat without the rest of the iceberg under the water.

I was one of those! I had a bunch of custom MM patches I used in my KSP¹ game to mess around with stock parts. I never really felt like my personal dabbling rose to the same level as the real KSP¹ modders, so I've never (previously) self-identified as such, but I definitely get your points about the entry bar being very low in that sense. Anyone who wanted to could jump in and copy existing parts to make new modified versions suiting their purpose.

6 hours ago, Lisias said:

A bad standard is better than no standard at all. We didn't did what we did because of the MM's many flaws, we did besides them. We did that because MM made it very easy to anyone to do that.

We had problems with it? A lot, newbies can really screw up things sometimes. But every single one of us was a newbie screwing things once, it's part of the growing pains. We get rid of the growing pains, we lose growing itself.

I agree with this point too, We need to settle on some standards that both make the barrier to entry low to better engage future KSP2 modders and which give all the confidence that we've got a clear path and we're not confused about which way we're going. 

7 hours ago, Lisias said:

None of them have NASA, ESA and SpaceX engineers using and probably modding the game - even at work. KSP¹ is not an ordinary game.

I 100% agree that the KSP player base is significantly different from other kinds of games, and I've no doubt that you'll find NASA, ESA, and SpaceX engineers among them. This is a very valid point about who we're modding for, but I can honestly say that I don't see KSP (either version) being used at work in the aerospace industry.

To be clear here, I'm not saying I can't imagine how it could be, but rather that I literally don't see it, and have never heard of it. As a professional aerospace engineer with 27 years in the business, I think I can safely say this isn't likely to ever be the case. We have other tools (e.g., AFSIM, STK, HIL simulations, etc.). If we showed up to any kind of meeting with work in hand where we wanted to show colleges, customers, our boss, or anyone something and we used KSP as the means to do it we'd be laughed out of the room. Maybe there are some isolated incidents of this happening, but I've never seen it and never heard of it. That said, I'm equally certain there are professional aerospace engineers who are both players and modders. Me for example, though I'm sure there are others.

That said, I also share your hope that KPS2 doesn't take off in some silly direction to be just another ordinary game. I don't think that's likely, but I agree it would be a terrible outcome and like you, I'd probably give up on it if it did.

11 hours ago, Lisias said:

It's a set of documentation provided by people that wrote the code, knew the requirements the code aimed to fulfil and understand why things were coded that way.

In a moment of conflict or confusion, these guys are the ones that are in a position to take a decision that is going to stick on the long run.

Downplaying the reason the KSP1 modders are pledging for an sanctioned documentation is not exactly the best way to conquer their hearts… 

Regarding documentation, I'm curious how much there was on hand when KSP¹ modding began. Certainly, we can see what's available for KSP¹ now, but have you taken a look at what we've got for KSP2 so far? My concern here is that we could be waiting a very long time before IG releases the XML docs. I'd personally love to see them release those today, but I doubt we'll see them until v 1.0 at the earliest. In the meantime, I think we've got a pretty good set of documentation that is in fact easily extensible by our community. Perhaps the state of KSP2 documentation is not so bad relative to what was on hand when KSP¹ modding began? So, clearly, having the dev's own XML files would be ideal, but is that really the point at which KSP2 modding should begin? It seems to me there's quite a lot we can fruitfully do with the documentation we do have.

BTW, the bulk of the documentation for KSP2 that we have today is in some sense official - it was stripped directly from an official DLL. There is zero ambiguity about 99% of what's on the page @munix linked (https://schlosrat.github.io/)

[Poodmund]

There was some sentiment early on in the thread that 'things' such as Module Manager should be handled first party. I couldn't disagree more. Having a first party mod loader available is great as it gives all modders a keyhole for interoperability but tools like Module Manager, these absolutely should remain 3rd party as it allows for the modding community to be completely agile in the way these tools are developed and evolved to cater for, potentially, the fast paced needs of the modding community.

Intercept Games should not take on the responsibility, for example, for being in control of the niche needs of the modding community that they do not require for their 1st party title because they are not the ones with the interest. The modding community is. They provide the platform, we provide the agile, customisable tools.

I can't be bothered to engage in a back and forth on the matter so I won't be.  

[schlosrat]

FYI: The latest version of the official KSP¹ documentation was "Generated on Tue Nov 1 2022 18:36:51 for Kerbal Space Program by    1.8.7", so 1 day prior to the published release date of 1.12.4 itself. But the better question I think is when was the first official release, and when can we expect something like this for KSP2? My hunch is we're not likely to see that during EA. The devs have more important things to focus on than this, plus they may view their own code as being too volatile - which would make a task like this something that's just not worth doing at this stage. I think the absolute earliest we might even hope for something like this is 0.2.0 (Science), but that's the optimist in me and I would not at all be surprised if it's much later.

Also, if official documentation is a must for some KSP¹ modders to consider modding KSP2, then I hope that in the meantime we can nevertheless see continued engagement (like what's happening right here, right now) between the two groups. Even if you're not ready to jump into KSP2 modding, there are a lot of really valuable things that can take place with dialog!

Incidentally, we have asked in the past for the XML docs to KSP2. We weren't told "no", only that our request would be relayed and so far we've not gotten any. I'm sure we'll renew that request from time to time, but we all understand that IG isn't likely to hand that over until they see it as being a ready product and at the right time. Perhaps we could explore the question of when they feel like it might be the right time, but again I wouldn't expect a detailed or precise answer as they would likely feel like it would turn into an obligation.

[Lisias]

3 hours ago, schlosrat said:

BTW, the bulk of the documentation for KSP2 that we have today is in some sense official - it was stripped directly from an official DLL. There is zero ambiguity about 99% of what's on the page @munix linked (https://schlosrat.github.io/)

And that's the problem, please check the Forum's Publishing Guidelines. And no, the KSP¹ Documentation is lacking, and it's not a model to be followed.

What we are asking for is the fulfilment of a promise made by the Game Designer 3 years ago: proper documentation, and not more relying on shady practices considered Piracy by this Forum.

 

3 hours ago, Poodmund said:

There was some sentiment early on in the thread that 'things' such as Module Manager should be handled first party. I couldn't disagree more. Having a first party mod loader available is great as it gives all modders a keyhole for interoperability but tools like Module Manager, these absolutely should remain 3rd party as it allows for the modding community to be completely agile in the way these tools are developed and evolved to cater for, potentially, the fast paced needs of the modding community.

And I could not disagree more with you.  

Whoever is maintaining this pivotal piece of Software, should be someone committed to the Franchise and willing to accept criticism and act accordingly.

MM had many flaws, but it wasn't any of them that played havoc around here - it was the cavalier attitude from the maintainers on handling not only the constructive criticism, but on badly diagnosing key issues on the environment that ended up promoting spreading of false information that at best, made people wasting time and at worse, wrongly pinpointed innocent Add'Ons from causing trouble.

This kind of abuse should not be allowed to happen again, and having it handled First Party is the best way of accomplishing that.

 

 

[LuxStice]

3 hours ago, Poodmund said:

Intercept Games should not take on the responsibility, for example, for being in control of the niche needs of the modding community that they do not require for their 1st party title because they are not the ones with the interest. The modding community is. They provide the platform, we provide the agile, customisable tools.

amazingly said, MM is not of IG's interest. Their interest is to make KSP2, not the modding community tools, thus reinforcing my point of the Official modding support being only a generated documentation, some tools and a handful of tutorials, that's what we've seen from most mod heavy games, and thats how it will most probably be, i cant see the devs diverting from that too much.

 

12 hours ago, Kavaeric said:

enabling it would allow for loading unbundled assets from a development folder a la KSP1 GameData

We're working on that! but it will be only for development purpouses since enabling it for production builds would mean a BIG hit on KSP2's loading times. I mean just look at SORRY's early builds, the game almost doubled its loading time because of the 2k-4k textures, SORRY it self was taking about 5-8 seconds with only 6 parts, Its not feasible to allow for the KSP1's loading style for production, else we'll have the same problem as KSP1's loading times. We gotta remember that the game now runs in a 3 textures per part(minimum), and each texture being at least 2k.

 

12 hours ago, Kavaeric said:

community modding tools for KSP2 being developed right now were endorsed in some way by the devs

even tho i would love for this to happen, i can't see the devs doing this, mostly because as you said, they have more important things, and also, i don't think its good for them to endorse something that they didnt work in.

[schlosrat]

36 minutes ago, Lisias said:

And that's the problem, please check the Forum's Publishing Guidelines. And no, the KSP¹ Documentation is lacking, and it's not a model to be followed.

What we are asking for is the fulfilment of a promise made by the Game Designer 3 years ago: proper documentation, and not more relying on shady practices considered Piracy by this Forum.

In the video you linked we see Nate Simpson talking about modding (and representing Star Theory, not yet IG). I played it multiple times and listened carefully, but did not hear where he promised documentation specifically. Scott Manley says things like "make it easy, not have to decompile, un obfuscate large parts of the code", and Nate is clearly nodding his head emphatically through that part. Nate answered by saying "That's one of the nice things about knowing exactly what you're gonna make when you start making it, so we can really make some core architectural decisions to make sure that it's highly moddable, highly stable, highly expandable, ... we wanna see a platform that has a life... I mean the original game's continued to evolve over nearly a decade..."

That said, I've yet to hear anything from IG other than that they want to support modding. I'd be quite surprised if they don't deliver some sort of documentation at some point, but what I see and hear in this video is a clear articulation of support in general, not a specific promise of documentation. For that matter, I'd say based on what I've seen that they have, in fact, delivered much of what they said they want to do in this video. We do have a highly moddable game with a core architecture that reflects their design choices to make it so. In the three patches (4 counting the hot fix) that have come out so far there have been only very minimal impact to mods  - though a good portion of the credit for that belongs to people like @munix and @cheese3660 wisely making design decisions at our end to ensure there's minimal impact.

Let's talk about the other point you made where you seemed to be implying that we're practicing some form of piracy and may in fact be in violation of this forum's rules. Did you visit the site we linked? If so, did you happen to notice the long and detailed article I wrote there meticulously describing the process we followed? If not, then I'd like to encourage you to please read it. https://schlosrat.github.io/articles/HowMade.html

The site we've got is made without decompiling the game's code. The information presented is the same as what you'd get from Visual Studio if you dropped an untouched copy of the Assembly-CSharp.dll in as a dependency and then wrote your own code to use it. All we've got is the publically available API interface that the code itself presents. There's not a single line of source code from the game. You might want to give that a gander before suggesting that piracy is a foot, my friend.

Edited July 9, 2023 by schlosrat
Fixed typo