Who/What decides what mods become stock?

[Dortmunder]

I've been wondering lately why Squad doesn't make a lot of mods stock.

Besides the issue of having to update the additions themselves every patch, what is the deciding factor in what would become stock?

There's a few in my opinion that should be stock, like KAS, Precise Node, Engineer, Chatterer, etc.

One big one that hasn't been updated in a while is the Part Welding mod, which would be amazing if it was stock Allowing everyone to massively reduce part counts.

[Clockwork_werewolf]

I think one of the deciding factors is how many people DON'T use a mod, not how many do.

Another factor is, does it change the game-play in a good way (and I don't mean easier).

Third is simplicity to update not just implement.

Forth is personal choice.

KAS can be very buggy and although I can't see many people complaining about it's inclusion it could on it's own add a week or two to EVERY update in the future. Some bugs are fine in mod, people can wait for updates and play a bit buggy or uninstall the mod, neither of these good if it is included in stock.

Precise node may well be a modification they take on board although it would be a case of them changing their code not adapting the mod.

Engineer features things like Delta-V readouts that are specifically against the designers wishes for stock. I understand why people use it and squad is very good about not just allowing but helping modders but that doesn't mean they should change want they want.

I can see no reason not to include chatterer other than the extra work (and that shouldn't be much) and it shouldn't need much if any upkeep.

Part Welding would very much make the game too easy. It removes the need for struts and makes ships almost indestructible and solid like a rock. Even real rockets have problems with bending and compression that can result in problems. Apollo 13 may have even been saved by an early engine shutdown due to compression shock waves.

[BudgetHedgehog]

From The Harv:

This question has popped up in varying degrees of aggressiveness quite a few times... Thanks for asking it straight and simple.

'Merging' mods is one of those things that one the surface would appear simple, but it's actually quite a lot more complicated than it would seem.

Consider that even commercial assets from Unity's asset store, which are packages made specifically to be dropped in and used in existing projects, will, for the most part, require some drastic reworking to fit them into KSP. Granted, the mods are done already over our existing codebase, and that does make the initial integration easier, but there's more to it than that.

If we had a complete game, and someone came up with an awesome new mod that everybody wanted, and we had permission to fold it into the game (another issue in itself), that would probably be the end of the story... Assuming also that we wouldn't have to make any changes to the mod itself (another tall order, since mods are exactly meant to modify the game experience, by definition).

That's obviously not the case here. The game is still growing, and as it grows, it's very common for us to come across bits of old code that now need to be refactored to make it work again. And that's with our own code. Now, consider how frequently mods become incompatible when we release a new update. We are blessed with a modding community here that is so solid, you're likely going to see your broken mods fixed in a short amount of time. That's done by the mod authors themselves, because they care about their projects and they put in a lot of effort to keep it nicely maintained.

Now suppose we were to fold a mod into the game... That author support would now become our own burden, and given that we have our own systems to maintain as we develop already, imagine what it would be like if we started to suddenly plop down chunks containing thousands, or tens of thousands of new, unknown to us, lines of code. We'd end up with an unmaintainable mess of code.

In the end, we're happiest as we are right now. The gist of the problem is that neither the game nor the mods are carven-in-stone, unchanging pieces of code. Both are living, evolving projects, which evolve alongside each other, and it takes the combined efforts of everyone to keep this organism alive.

You can put it like this:

A bird needs a tree to nest in and survive... But try gluing the bird to the tree to see what happens. (actually, don't try that).

Cheers

[Whirligig Girl]

They've never implemented a plugin-type mod, but they have made a feature that a mod had already done. Mission controller gave KSP users career mode way before budgets, but it was well known by the developer of Mission controller and Mission controller Redux that these features were planned for stock, BEFORE they made the mod.

A few stockalike parts have been implemented from ClairaLyrae's Kerbal Stock Parts eXtension mod (now maintained by StupidChris), such as the Cupola, the Remote Guidance unit, and the Skipper.

A few modders have been hired, Chad Jenkins (C7) made the Airplane mod pack back in 0.13 era, and was implemented in the game (and went largely unchanged from how it is now) in 0.15.

Bac9 and Romfarer have both been hired by Squad for content creation unrelated to their own mods.

[cpast]

A few stockalike parts have been implemented from ClairaLyrae's Kerbal Stock Parts eXtension mod (now maintained by StupidChris), such as the Cupola, the Remote Guidance unit, and the Skipper.

ClairaLyrae was also hired by Squad; I don't know of any mods that have been taken into stock essentially as-is (as opposed to Squad re-implementing the idea) that didn't involve the developers being hired by Squad (i.e. C7, Claira).