Jump to content

KSP2 Modding for Mod Authors: What Would You - The Authors - Like to See


Recommended Posts

:::::::::::::::::::::::Moderators please delete this thread if it has already been discussed constructively and in-depth elsewhere::::::::::::::::::

Erm.... Yes. Catchy title eh?

I bring this up here after the concept of 'mod support in KSP II' came up in the Exhaust Plume Dev Diary. The question of how exactly and what exactly could/should be left exposed by the developers for modders to play with. This made me wonder if that conversation has been had and those questions asked about modding in general for KSPII. I've seen plenty of discussion about what game features people would like to see in KSP2 but nothing specific about what mod authors would like to see. 

KSPII devs have made very clear their commitment to the modding community for KSP - which is great! A logical and surely useful question would therefore be: What do the mod authors want? Additionally, one could ask: what lessons can be learned from KSP1 modding? What roadblocks did modders find in KSP1 that could have been avoided if the original devs had done things a little differently? What hooks would mod authors like to see left exposed in KSP2 that were not in KSP1? What would mod authors like to be able to do in KSPII that is not possible - for whatever reason - in KSP1? How could KSP2 modding be more powerful, flexible and manageable for authors and users alike? I hope people will understand the spirit if what I'm asking. Please don't misinterpret this topic as "how did the devs screw up KSP1" or that I'm somehow demanding/expecting infinite modability of KSP2. I just thought it was a pertinent topic that might be beneficial for everyone to discuss.

Some examples of specific things that might be useful to the KSP2 devs to know for example could be:

When developing Scatterer, what things did Blackrack discover that could have made his/hers (????) life easier or Scatterer even better than it already is?

When developing Kopernicus, what did R-T-B learn that might benefit the KSP2 team?

What could Lisius say about developing nightmare mods like Tweakscale that could make it easier?

What could Serbian share that would make indispensable tools like Module Manager better?

Do you see what I'm getting at?

Just to clarify what I mean by 'mod author.' I mean people who create entirely new entities and functionalities for the game - the Lisius', Blackracks, R-T-Bs and Neateas of the world; the tool creators; the hardcore code-writing most bodacious modding mofos from outer space. I do not mean people like me who tinker with Scatterer's parameters (for example) or create Module Manager config files here and there and pat ourselves on the back for a job well done.

 

In summery, what constructive feedback can the KSP1 modding community give the KSP2 dev team that would make KSP2's modding experience more betterer? :)

 

DISCUSS

Edited by rextable
For clarity
Link to comment
Share on other sites

I'm not a KSP modder, but it seems fairly clear that a built in window manager for mods would be great where the mod could be aware of where other mod and KSP windows were on the screen and which window was clicked in was centrally managed.  Every time I open a window or PAW I cringe just knowing that it will likely open underneath the only other window open on the screen.  The same for input management in general.  Many mods seem to read the keyboard raw so even when typing into a very specific textbox in a window, hitting certain keys toggle unrelated mod behavior (Smokescreen, Hullcam...)

Link to comment
Share on other sites

There isn't much they need to do, other than keeping the general code architecture extensible by making the relevant stuff virtual, and providing various code entry points like KSP does.
But from the top of my mind, those are my top items :
- A built-in mod installation/metadata manager like CKAN
- A built-in configuration and dependency manager like ModuleManager (apparently something like that has been confirmed)

- A better serialization framework
- Do not obfuscate the assembly
-
Ship the game with all "optional" .NET packages

9 hours ago, darthgently said:

a built in window manager for mods

A good dynamic code based UI framework would be nice. KSP has one, but it's quite clunky to say the least. Designing and coding a good dynamic UI framework is no small task, so I have some doubts we will get something significantly better.
Unless they decide to integrate a third-party framework, but that wouldn't change the main issue, which is that UI making difficult, time consuming, not much fun, and usually not the part someone working for free want to spend time on.
The issues with UI in KSP 1 mods mostly come from the fact that most of them are using the IMGUI system, which is an old legacy Unity thing for making development tools UIs. The few mods using the UGUI system don't have the issues you mention.
The reason IMGUI is used over UGUI is that it is very easy to work with, but it has many functional and performance issues.
Said otherwise, the main issue with KSP 1 mods UIs is that mod authors are sacrificing UI quality/performance/usability to cut on development time.

On a more general note, I somewhat expect KSP 2 to not be as easily moddable. There are some "shortcuts" is KSP 1 that are extremely convenient and noob friendly from a coding perspective, but have very detrimental effects on performance and internal code complexity.
I also expect some subsystems to use "advanced" techniques/tools like Unity Jobs/Burst, which are great for performance but introduce a lot of complexity and are a lot less straightforward to work with. 
And finally, there is the multiplayer aspect, which also introduce extra complexity and restrictions.

Edited by Gotmachine
Link to comment
Share on other sites

8 hours ago, Gotmachine said:

A good dynamic code based UI framework would be nice. KSP has one, but it's quite clunky to say the least. Designing and coding a good dynamic UI framework is no small task, so I have some doubts we will get something significantly better.
Unless they decide to integrate a third-party framework, but that wouldn't change the main issue, which is that UI making difficult, time consuming, not much fun, and usually not the part someone working for free want to spend time on.
The issues with UI in KSP 1 mods mostly come from the fact that most of them are using the IMGUI system, which is an old legacy Unity thing for making development tools UIs. The few mods using the UGUI system don't have the issues you mention.
The reason IMGUI is used over UGUI is that it is very easy to work with, but it has many functional and performance issues.
Said otherwise, the main issue with KSP 1 mods UIs is that mod authors are sacrificing UI quality/performance/usability to cut on development time.

On a more general note, I somewhat expect KSP 2 to not be as easily moddable. There are some "shortcuts" is KSP 1 that are extremely convenient and noob friendly from a coding perspective, but have very detrimental effects on performance and internal code complexity.
I also expect some subsystems to use "advanced" techniques/tools like Unity Jobs/Burst, which are great for performance but introduce a lot of complexity and are a lot less straightforward to work with. 
And finally, there is the multiplayer aspect, which also introduce extra complexity and restrictions.

So if a game is better optimized is it less mod friendly? That brings up a question. Is it better to have a game moddable like ksp or have the performance of F1 2020 as an example. 

Link to comment
Share on other sites

10 hours ago, Gotmachine said:

There isn't much they need to do, other than keeping the general code architecture extensible by making the relevant stuff virtual, and providing various code entry points like KSP does.
But from the top of my mind, those are my top items :
- A built-in mod installation/metadata manager like CKAN
- A built-in configuration and dependency manager like ModuleManager (apparently something like that has been confirmed)

- A better serialization framework
- Do not obfuscate the assembly
-
Ship the game with all "optional" .NET packages

A good dynamic code based UI framework would be nice. KSP has one, but it's quite clunky to say the least. Designing and coding a good dynamic UI framework is no small task, so I have some doubts we will get something significantly better.
Unless they decide to integrate a third-party framework, but that wouldn't change the main issue, which is that UI making difficult, time consuming, not much fun, and usually not the part someone working for free want to spend time on.
The issues with UI in KSP 1 mods mostly come from the fact that most of them are using the IMGUI system, which is an old legacy Unity thing for making development tools UIs. The few mods using the UGUI system don't have the issues you mention.
The reason IMGUI is used over UGUI is that it is very easy to work with, but it has many functional and performance issues.
Said otherwise, the main issue with KSP 1 mods UIs is that mod authors are sacrificing UI quality/performance/usability to cut on development time.

On a more general note, I somewhat expect KSP 2 to not be as easily moddable. There are some "shortcuts" is KSP 1 that are extremely convenient and noob friendly from a coding perspective, but have very detrimental effects on performance and internal code complexity.
I also expect some subsystems to use "advanced" techniques/tools like Unity Jobs/Burst, which are great for performance but introduce a lot of complexity and are a lot less straightforward to work with. 
And finally, there is the multiplayer aspect, which also introduce extra complexity and restrictions.

On the other hand, modders could agree to use a common API to a mod that is a window manager outside KSP2.  But that seems a bit like a goat rodeo trying to get that to work socially

Link to comment
Share on other sites

3 hours ago, dave1904 said:

So if a game is better optimized is it less mod friendly?

Depends what you mean by "mod friendly". KSP 1 "entry level" modding is really easy. The base framework provide a lot of handy shortcuts, and the general "straightforwardness" of the codebase make it accessible to anybody having a minimal coding experience.
I'm speculating quite a bit here, but I expect the KSP 2 codebase to be primarily focused on performance and to use more "serious" coding practices. It doesn't mean the game will be "less moddable" (as long as it's a Unity game that doesn't use IL2CPP,  moddability is near infinite), just that it might be less accessible to people with no coding background.

2 hours ago, darthgently said:

On the other hand, modders could agree to use a common API to a mod that is a window manager outside KSP2.

There is no need for that. KSP1 / Unity has all the UI APIs a modder need. Those issues are actually non-issues if you use the proper UGUI framework. It isn't used for a variety of reason, the main one being that the other framework, IMGUI, is perceived as easier to use, implement and understand.
This is a trap tons of mods tend to fall into. IMGUI quickly become a mess to work with as your UI grow in complexity, but once you've poured hours of UI coding work in the wrong framework, you are kinda stuck with it.

Link to comment
Share on other sites

On 12/31/2021 at 11:19 AM, Gotmachine said:

Depends what you mean by "mod friendly". KSP 1 "entry level" modding is really easy. The base framework provide a lot of handy shortcuts, and the general "straightforwardness" of the codebase make it accessible to anybody having a minimal coding experience.
I'm speculating quite a bit here, but I expect the KSP 2 codebase to be primarily focused on performance and to use more "serious" coding practices. It doesn't mean the game will be "less moddable" (as long as it's a Unity game that doesn't use IL2CPP,  moddability is near infinite), just that it might be less accessible to people with no coding background.

There is no need for that. KSP1 / Unity has all the UI APIs a modder need. Those issues are actually non-issues if you use the proper UGUI framework. It isn't used for a variety of reason, the main one being that the other framework, IMGUI, is perceived as easier to use, implement and understand.
This is a trap tons of mods tend to fall into. IMGUI quickly become a mess to work with as your UI grow in complexity, but once you've poured hours of UI coding work in the wrong framework, you are kinda stuck with it.

Given the Interface seems to have been completely re-done from scratch in the videos so far. Any guess / clues which system they might be using?

Link to comment
Share on other sites

an easy way to make planets, like simple rockets 2's planet maker, but kerbalfied as well as an easier time making barycenter's for said planets

Edited by Meb Kat
Link to comment
Share on other sites

  • 1 month later...

that would lead to the scene being even more flooded by junk mods, what happens when hundreds of thousands of people start making "bobs planet pack-best pack ever"
The pack - Adds some clones of existing worlds

Link to comment
Share on other sites

5 hours ago, kspnerd122 said:

that would lead to the scene being even more flooded by junk mods, what happens when hundreds of thousands of people start making "bobs planet pack-best pack ever"
The pack - Adds some clones of existing worlds

I agree that a flood of additional mods that merely add planets to the Kerbal system would be annoying.  But a mod that allowed the addition of other star systems would be interesting.  Especially if the distance of the star system from Kerbol were to be determined by the download count (or some other rating) of the mod.  I haven't thought this through much, but I think the general idea that the "better" a new star system was, as determined by those playing with it, determining its ranking in proximity to Kerbol could be interesting

Link to comment
Share on other sites

16 hours ago, kspnerd122 said:

that would lead to the scene being even more flooded by junk mods, what happens when hundreds of thousands of people start making "bobs planet pack-best pack ever"
The pack - Adds some clones of existing worlds

Does not matter. You don't think KSP might also have a ton of bad mods that don't get attention because they're being overwashed by the quality stuff? Point being, a planet maker would be good for accessibility - all communities have good and bad content, and it's not hard to find good among bad. A planet maker would let creative individuals tinker with planet creation without having to be good with long config files and coding.

Link to comment
Share on other sites

13 hours ago, kspnerd122 said:

to be fair, the barrier to entry is why we don't get "bobs planet pack 99"

Unity gets a lot of flak for having a low barrier for entry, resulting in a lot of poorly done games. People cherrypick these games when they want to demonstrate that Unity is bad, when it really isn't. KSP and a lot of other good games have been built in Unity, so you really can't use the bad content against it. Just ignore "bobs game 99" if it's getting on your nerves - it shouldn't degrade what Unity has made possible.

All this is to demonstrate that a planet maker isn't bad because people make bad content with it. A toolbox is only as bad as what you use it to make.

Link to comment
Share on other sites

What I'd like to see is easy to describe.

Build the system in such a way that every modder has the same possibilities to build a new part and functions as the developers of KSP themselves.

So... no "hidden" or "undocumented" interfaces.  No special  shenanigans that allow KSP developers to build extensions which would not be possible to build otherwise. Allow modders to build parts and functions that can compete with native functions and parts.

Link to comment
Share on other sites

22 hours ago, Rudolf Meier said:

Build the system in such a way that every modder has the same possibilities to build a new part and functions as the developers of KSP themselves.

No idea how you expect such a system to work, unless it's just an in-game window for code to be written and run.

Link to comment
Share on other sites

1 hour ago, Bej Kerman said:

No idea how you expect such a system to work, unless it's just an in-game window for code to be written and run.

simple... don't export the "interface_for_parts" and hide the "interface_for_internal_parts_of_ksp" ... don't allow parts of ksp to have more functions than modder parts... don't allow them to use the "ksp_core.cool_function12()" if you don't allow modders to use the same function... that's all... (and don't mark important variables as "internal" or "private")

treat modders as if they were developers of the game itself... give them the possibility to completely replace parts with theirs without any disadvantages for the player... :) ... that's how it was in ksp 1... as far as I can say from my experience with modding ksp

Link to comment
Share on other sites

The most important thing that I always miss from KSP is many, many different and new planets and stars. There are some mods that do add these, but they aren't as many and often they are easier than the stock planets. Being able to go to different planets and explore them was the entire reason why I played KSP initially (still my most favorite activity). Figuring out how to land and come back with a manned ship on each one of them was the core reason, so I'd like to see work in that direction: easy to add new planets, easy to add new explorable star systems.

I'd love to visit stuff around a black hole (thinking Interstellar-style kind of thing) even if my spaceship will crash, I loved doing that on Dyson Sphere Program.

Link to comment
Share on other sites

less read-only properties.

let me just edit data of a contract when i access it...^^

simplicity is key, even when they still use c# and you have tons of unity dependencies, i had a really bad time figuring out what contract the player is currently looking at

something like lua might be better though, so modders don't have to recompile their mods for almost every update...

Edited by pwn
Link to comment
Share on other sites

I have an example what you shouldn't do in the future if you don't want to offend modders.

Let's talk about "Vessel.CycleAllAutoStrut" and "Part.CycleAutoStrut" ...

... you know of the existens of KJR. KJR has been around for ever and it helps to make the game more fun. It is not fixing a problem that was programmed into KSP, it is trying to help eliminate "problems" or "difficulties" with Unity and with the fact, that such simulations are always difficult for a physics engine. So,  one should assume that you have an interest in this mod and support it. And still... "Vessel.CycleAllAutoStrut" and "Part.CycleAutoStrut" are no game events and sometimes (e.g. when you rotate docking ports... a very new feature by the way!) they are the only functions that you are calling to inform about this action. ... the result is, that KJR isn't working with those docking ports.

Why is that?

Link to comment
Share on other sites

×
×
  • Create New...