KSP 2 Mod Potluck

[0111narwhalz]

With KSP2 on the horizon, it's time to start thinking about how to make modding excellent from the beginning. Star Theory won't be able to get everything right from day one—that's just programming—so it falls on us, the community. Duplication of effort is silly and causes problems later down the line. For this reason I propose we coordinate the development of core dependency mods (coredeps). Below are some of my suggestions for coredeps which can establish long-term standards from the get-go:
• A general resource library similar to the Community Resource Pack. Never again should we face the anarchy which preceded the CRP. LiquidHydrogen competing with LH2, FSCoolant versus B9CompressedAir versus IntakeAtmosphere versus IntakeAtm… It's a mess so easily avoided, but we need to take the initiative. The earlier the burn the less the ΔV, yes?
• A part category base similar to the Community Category Kit. Standardized ideas of where parts belong improve the user experience massively.
• ModuleManager. MM forms the foundation of essentially every part-affecting plugin. The health of the future KSP2 modding community is contingent upon the ability of mods to, well, modify—both the game and one another. Masterpieces like Tweakscale could not practically exist without MM.
• A part switcher. Today we have the Firespitter one, the B9 one, Configurable Containers from Allista, and the stock one. There's a high probability that KSP2 will implement this feature, given that KSP1 already has, but we still need to account for the possibility. A standardized part switcher will streamline a lot of model, config, and compatibility work.

Furthermore, a consortium of coredep maintainers and potential KSP2 modders would be useful in coordinating the development path taken by such dependencies, especially concerning the CRP- and CCK-like coredeps. If sufficient interest is demonstrated, a Discord server could be set up to facilitate such coordination. The Ailevérse team—led by myself, @TotallyNotHuman, and @Benjamin Kerman—has agreed to spearhead the development of the resource and category libraries, since our planned suite of science-fiction mods would make heavy use of such libraries. If you would like to propose any coredeps for inclusion into the above category, or would like to commit to the effort itself (which would be greatly appreciated!), feel free to reply below.

The potluck so far:
 • Resource pack — the Ailevérse Team
 • Categories — the Ailevérse Team

[Guest]

I think it's too early for this, some of those things will be addressed directly by the Devs, like MM for instance, if I'm not wrong Nate confirmed somewhere that we're getting a vanilla analogue from the start.

Edited February 1, 2020 by Guest
"they Nate"

[linuxgurugamer]

What @Master39 said. Without knowing what’s in the game, it is presumptuous to start talking about what’s needed.  For example will the equivilent of the ClickThrough Blocker be included?  How about the Blizzy toolbar and the Toolbar Controller?  Then there are a number of libraries which are dependencies for other mods; who gets to decide what’s  “core” and not?

Regarding part switchers, you left out a few, including IFS among others.

How is this done for other games?  It might be a good idea to see what works and doesn’t work before this.

[0111narwhalz]

35 minutes ago, linuxgurugamer said:

who gets to decide what’s  “core” and not?

The definition the Ailevérse team has been working on is basically "functionality which a lot of mods need, and which would otherwise be developed and redeveloped." This project is primarily about setting standards early on to avoid problems I observed over the course of my KSP experience.

41 minutes ago, linuxgurugamer said:

ClickThrough Blocker […] Blizzy toolbar and the Toolbar Controller

Clickthrough blocking is a huge quality of life feature, and I would say that it does indeed belong on this list.
Toolbar Controller is, as I understand it, a utility to use either the stock or Blizzy's toolbar, and so its necessity is contingent upon the existence of both a stock and modded toolbar. This early on I expect one or the other.
Blizzy's toolbar would belong here as well, since mods with GUIs will want to make themselves accessible to the screen without the old hardcoded keyboard shortcuts, and it'd be best if they agreed upon one way of doing this.

1 hour ago, Master39 said:

I think it's too early for this, some of those things will be addressed directly by the Devs, like MM for instance, if I'm not wrong Nate confirmed somewhere that we're getting a vanilla analogue from the start.

I'm a bit behind and sideways on the news. If that is indeed true, and its features are robust and extensive, then so be it—less work for the one who would have signed up. It should be clarified that all of these suggestions assume that stock KSP2 won't have the relevant features we've enjoyed in the mature KSP1 modding community.

It should also be clarified that signing up in no way binds an author to a commitment. It is more like calling the ball before half your team rushes for it. If you sign up, and then discover that you do not want to or cannot contribute, there should be no shame in pulling out and allowing another author to take the lead.

[Guest]

@0111narwhalz the point was not debating single examples, was that we don't know.

We don't know which core mods we'll need.

We don't know if we'll need them at all.

We don't know if it make sense to start developing core mods instead of asking for those features directly to Star.Theory, since "increased moddability" is an active goal the developers are trying to reach.

 

Im the first that understands how fun and engaging is to speculate on the new game, arguing is (almost) always fun and it helps us to cope with the hype and the wait, but it's dangerous to start organising or worse, working, on said speculation.

Until the game is out and we put our hands on it we really don't know what kind of mod is needed or not.

 

 

 

 

Edited February 1, 2020 by Guest
Late night here, my dumb errors meter is sky high. V2

[0111narwhalz]

24 minutes ago, Master39 said:

I'm the first that understands how fun and engaging is to speculate on the new game, arguing is (almost) always fun and it helps us to cope with the hype and the wait, but it's dangerous to start organising or worse, working, on said speculation.

Oh, for sure—I'm not suggesting that we immediately start creating these mods. There's a large chance that we won't need all of these features, or maybe even any of them—but it'd be best to not trip over one another while implementing the ones it turns out we will need.

[mcwaffles2003]

Out of curiosity, if all these types of mods are so core to the other mods to come and you possibly have such a level of communication, why not bring them all into one to help communication between them instead of having like 5-10 separate mods? Not a modder myself and I pose this as a simple question.

[Incarnation of Chaos]

9 minutes ago, mcwaffles2003 said:

Out of curiosity, if all these types of mods are so core to the other mods to come and you possibly have such a level of communication, why not bring them all into one to help communication between them instead of having like 5-10 separate mods? Not a modder myself and I pose this as a simple question.

Because many mods make changes to core deps for their own gameplay/realism reasons, so having them all intergrated into a single mega-mod would cause massive conflicts and actually increase the number of patches needed.

[DStaal]

9 hours ago, mcwaffles2003 said:

Out of curiosity, if all these types of mods are so core to the other mods to come and you possibly have such a level of communication, why not bring them all into one to help communication between them instead of having like 5-10 separate mods? Not a modder myself and I pose this as a simple question.

Part of it is historical reasons - CRP was started at one point by one group who saw the need, ClickThroughBlocker was started by someone else who saw that need, etc.  Who's interested in what problem depends on personal interests and what you need.  People interested in resource definitions and distribution may not be interested in UI coding, and vice-versa.

Also note that there are a couple of groups who've started their own resource packs since CRP was invented.  Some haven't gained much traction, some have.  And sometimes you'll have a special case that needs something different.  And maybe you don't need all of them in every case, or the case you have isn't covered by the mods available.  (One of the reasons for all the different part switchers is that the functionality of them doesn't completely overlap - they all do slightly different things, sometimes incompatible things.)

I'm hoping Star Theory is taking a good look at what's out there, and seeing which dependency tools are getting wide use, and building their own versions of them into the base game.  Module Manager, ClickThroughBlocker, and a part switcher are obvious things that likely should be included as core in KSP2, allowing easy use by any and every modder.  Something like CRP they may want to define a few more resources in stock, and give them better definitions, but the real need is for modders to work together.  Others are in widespread use - but aren't everywhere.

Regardless, starting now on any of it for modders is jumping the gun.  We don't know what'll be in the game, or what will be possible to change.  I could see Star Theory having built-in resource definitions of every major rocket fuel, as well as having a mining system with resources for that.  If that's there, there may be no need for a CRP - even if the game itself doesn't use all the resources.  Or they could add one or two resources, and we'll need to organize something.  Who knows?  It's to early to guess, and to early to start.  Anything people do now would just be in theory until we can see what is actually needed and possible.

[0111narwhalz]

Eh, fair enough. If it's too early it's too early.

Well, if a resource pack or a category pack are needed, the Ailevérse team will be ready to go.

[Guest]

Since those are considered essentials and people, generally, know that, it's not implausible that they'll be implemented into base game. In particular, click-through blocking should have been a part of KSP1. It's a bugfix for something Squad failed to address.

Standards, both visual and plugin, only have to be established by the community if the devs fail to do so. For the former, not enough "finished" parts have been shown to be sure, but enough to hope for the finished KSP2 stock to be at least up to ReStock's levels. For the latter, the list of promised features gives a similar hope, although whether ST delivers on them is up in the air. If they botch it, then the community will have to step in. 

[linuxgurugamer]

19 hours ago, Dragon01 said:

In particular, click-through blocking should have been a part of KSP1. It's a bugfix for something Squad failed to address.

Actually, Squad did address it, but only for the stock game. Only one or two mods actually implemented click-through blocking, which is why I wrote the mod

[Guest]

I meant that this should have been the default behavior for everything, not fixed on a case-by-case basis. Hopefully, it'll be done right in KSP2.

[linuxgurugamer]

2 minutes ago, Dragon01 said:

I meant that this should have been the default behavior for everything, not fixed on a case-by-case basis. Hopefully, it'll be done right in KSP2.

The problem is that people coded using the Unity calls, and those knew nothing about the current game windows.

Ideally they would have a framework for people to use which would do that automatically.  Would have been nice in the original, but when they started coding, they didn't know what they were doing.

[Guest]

Yeah, that's the kind of problem that you only realize when you have a functional alpha ready, at best. Unless you've done a game on the engine in the past, of course. This is why I hope Star Theory will do a better job than Squad did.