Why cant Squad take some of the mods and make them part of the vanilla?

[nater662]

Some times when you play a mod you just think how is this not in the vanilla version.

Just out of curiosity why can't squad strike a deal with some of the best mods?

[Devo]

Some times when you play a mod you just think how is this not in the vanilla version.

Just out of curiosity why can't squad strike a deal with some of the best mods?

They don't support or use mods, they have stated on many occasions. also, as far as I'm aware if you do work for Squad, you also can't run a modded version (that they know about) it's part of their agreement (says a few ex developers) Which is ironic considering how much mods have extended the life of this 'early access' game. I can't speak for anyone else but if there was no mods to play with I would have stopped playing years ago.

I remember some cool mods, I forget the name but there was one that was rockets made of whiskey barrels, man that was a blast to fly.

This is not to say don't they take some good ideas from people and put it in the game, like the Sub Assemblies manager

Edited June 10, 2014 by Devo

[Guest]

Just out of curiosity why can't squad strike a deal with some of the best mods?

For because.

[asheft]

Didn't they do that with C7? Putting a runway and spaceplane parts into the stock game? I agree that adding some mods that add key missing elements to the stock game (Ferram Aerospace, Deadly Reentry, etc.) would make the stock game a lot better.

Edited June 10, 2014 by asheft
Fixed confusion between two developers

[Red Iron Crown]

They have in the past. They generally don't. They might in the future.

I have read that it's not as simple as just bundling up the mod with KSP and calling it a day.

[wizzlebippi]

Mods are written to access core code from the outside, and consequently have a very different structure. Merging different code is a difficult process.

[Vanamonde]

Remember, you can't just stick something in there once, and it works forever more. Software needs to be maintained, revised, etc. This is much harder to do if you didn't write the code in the first place, and it's not organized the way you would have set things up. Also, what happens when Squad starts making money off of a mod-maker's code? The mod-maker would have to be compensated in some way. How much would they need to pay for that? It's a whole big can of worms.

[allmhuran]

The need or lack thereof for royalties would (could) all be covered by existing agreements. Whether or not that's the case, I'm not sure.

I think the more likely reason is this: modders work against a limited set of functionality that is exposed, they don't have access to the "deeper" layers of the code. For certain kinds of mods (part packs, for instance) this doesn't really make much difference. But for mods that bring additional functionality to the game, Squad has opportunities to make more fundamental changes in layers of code that modders can't access. As a programmer, if I was in Squad's position and saw a mod that I felt should be incorporated, I'd be motivated to see what improvements I could make based on that additional access I have.

[Guest]

I think the more likely reason is this: modders work against a limited set of functionality that is exposed, they don't have access to the "deeper" layers of the code.

This is incorrect. Modding KSP requires an assembly browser to see what is available to use in the stock code because KSP has no exposed modding API like what you speak of. While KSP is mod friendly (and even claiming that is debatable), it's not necessarily modder friendly.

Adding mods to KSP is sketchy for a variety of reasons. For one, the potentially dubious quality of outside code. For two, legal reasons. For three, additional code maintenance. And so on. Of these, legal reasons is probably the most valid, the others can be surmounted through proper vetting and integration of the code. Of course, that's also a lot easier when you have a larger team of coders. SQUAD is actually pretty small in that aspect.

[allmhuran]

What I'm suggesting does not imply nor require that a particular layer has been built specifically with modders in mind. I'm simply saying that there are things modders cannot do that Squad developers can do, and therefore if Squad wanted to implement a type of functionality that is currently provided by a mod, their greater flexibility could easily mean a different implementation.

[Guest]

What I'm suggesting does not imply nor require that a particular layer has been built specifically with modders in mind. I'm simply saying that there are things modders cannot do that Squad developers can do, and therefore if Squad wanted to implement a type of functionality that is currently provided by a mod, their greater flexibility could easily mean a different implementation.

And what I'm saying is that modders often need to do the same things that SQUAD do in order to make things work they want them to.

It's also worth saying that, in some cases, SQUAD deliberately makes things hard on modders, and I'm not talking about obfuscating intellectual property hard, I'm talking about doing dumb things. For instance, the class that generates asteroids could have been much more open and modder-friendly by exposing a function to simply feed an orbit and a size class into the asteroid generator. BAM, instant Jool trojan. Instead, we get to Mickey Mouse up some crazy scheme whereby you have to add a listener for a new ship being added, ask the class for a completely random asteroid, change the orbit of the newly generated asteroid that was caught by the listener, and then remove the listener. Meanwhile, normal asteroid generation continues. It's silly and it makes the work of modders much harder. So, in a sense, you're right, SQUAD will come up with better implementations but it's not exactly because modders can't see that far into the code or do things inherently worse. I haven't touched the tech tree but I imagine it's the same sort of mess.

E: And don't get me wrong, I think the devs do some pretty decent work here given the demonstrated amount of job stress and the size of their team, but I get the feeling they're in over their heads sometimes and aren't thinking clearly. Alternatively, they don't want modders to show them up any more than they have.

Edited June 10, 2014 by regex

[allmhuran]

Instead, we get to Mickey Mouse up some crazy scheme whereby you have to add a listener for a new ship being added, ask the class for a completely random asteroid, change the orbit of the newly generated asteroid that was caught by the listener, and then remove the listener. Meanwhile, normal asteroid generation continues. It's silly and it makes the work of modders much harder

Yep, that's exactly what I'm saying. To use your example, in order to spawn an asteroid, modders have to use whatever is currently available to spawn asteroids. Squad, on the other hand, can choose to completely rewrite the asteroid spawning functionality.

Squad didn't write the original code with all of the ideas of the modders in mind, they wrote it with their own ideas in mind. If they were to choose to actually build in the functionality of a mod they might experience exactly the kind of frustration you're talking about, and therefore decide to rework some underlying layers to make a more elegant and stable solution.

And hence my conclusion: the integration of the functionality of existing mods is likely to involve a different implementation if it is done by Squad themselves.

[Giggleplex777]

HarvesteR's response:

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

[smart013]

Thanks for the reply. But what about mods that are getting more and more *essential* for keep playing ksp - at least non stock? Mods like advanced texture managing or load textures on demand are more and more needed to keep ksp afloat with a "basic loadout" of mods. Ok, i believe you can say that the mod community solves the problems itself has created, but the alternatives in texture & memory handling that are presented here could very well seen as something that urgently needs to be stock - short of going fullblown stock 64bit. Something we all know can easily be 2 more years away.

(Yes, i know of the unity5 64bit experiments, but i dont think that this will be a stable solution for everyone anytime soon)

Edit: with basic loadout in mods i mean these from where it is very hard to go back stock. EVE comes to mind,KAS, FAR maybe too.

Edited June 10, 2014 by smart013

[LethalDose]

Yep, that's exactly what I'm saying. To use your example, in order to spawn an asteroid, modders have to use whatever is currently available to spawn asteroids. Squad, on the other hand, can choose to completely rewrite the asteroid spawning functionality.

Squad didn't write the original code with all of the ideas of the modders in mind, they wrote it with their own ideas in mind. If they were to choose to actually build in the functionality of a mod they might experience exactly the kind of frustration you're talking about, and therefore decide to rework some underlying layers to make a more elegant and stable solution.

And hence my conclusion: the integration of the functionality of existing mods is likely to involve a different implementation if it is done by Squad themselves.

HarvesteR's response:

Yeah, Harvester's response is valid as far as forcing large chunks of foreign code into the stock game. I know very very little about "real" software development, but I know enough to understand that's an idiotic approach. IMO, using Harvester's statement as evidence that it's not feasible to include mods in stock is a bit of a strawman argument.

I'll probably get reprimanded by the mods for using the term "strawman argument" since it's somehow possible to construe it being insulting or trolling or whatever. IMO, this use fits this definition.

If mods were to be included in the stock game, it's not as easy as just dropping the new code into the game core. Part of development is writing the code to do what you want the software to do, but before that you have to figure out what you want the code to do, and how you want to implement the code (the "structure" of the implementation is the word I use in my head, but may be wrong).

It's in these parts of development (what to do and how to do it) are where mods would be insanely useful, because the modders already went through the process of figuring out what the new mechanic does, and how to implement it.

The devs can't use the code from the code from the mods verbatim, but the purpose, logic, and approximate structure of the mods could be insanely useful to implement the mods by the devs. Yes, the devs have to re-write the code, but using a mod as a roadmap to implement a feature has the potential to save a huge amount of time and effort for the devs.

In my view, adapting mods to the core game is similar to the way tabletop games adapt rules/mechanics/features/whatever from other games. And this happens all the time. You have to change the rules to specifically address the new game, but you don't have to re-develop the new rules/mechanics/features/whatever from scratch. Which is I think more or less what allmhuran is driving at in the quote above.

Again, above is my opinion, based on facts as I perceive them. I could be so painfully ignorant of the realities of software development that what's posted here is complete gibberish.

Edited June 10, 2014 by LethalDose

[LethalDose]

Remember, you can't just stick something in there once, and it works forever more. Software needs to be maintained, revised, etc. This is much harder to do if you didn't write the code in the first place, and it's not organized the way you would have set things up. Also, what happens when Squad starts making money off of a mod-maker's code? The mod-maker would have to be compensated in some way. How much would they need to pay for that? It's a whole big can of worms.

I just re-read this counter-point. I think I addressed the former argument above (code would have to be re-written).

As for the second point (SQUAD making money off of modder's code), a few points:

1. If the mods are re-writing code, it's not the modder's code anymore, even if it was inspired by the modder's work.
   
2. Unless I'm mistaken, modders have to make their mods' source code available to SQUAD.
   
3. I can't imagine SQUAD doesn't have a clause in the ToS/EULA that allows them to do whatever they want with code shared on their forums that modifies their intellectual property.
   
4. Similarly, I can't imagine a modder would refuse to allow their code to be included in stock if they were asked.
   

[allmhuran]

You're not completely off track, but it doesn't usually work out that way.

Let's continue with a nice simple and concrete example brought up by regex: a mod that involves some gameplay involving asteroids, and therefore has the ability to spawn asteroids.

Imagine, then, that the mod therefore has a function to spawn an asteroid called (hopefully) something easy to find like "spawn asteroid". What modders currently have to do looks something like this (pseudocode):

mymod.spawn_asteroid(param1, param2, ...) {
 listener = spawn_listener()
 generate_random_asteroid()
 generated_asteroid = listener.get_latest_object()
 generated_asteroid.orbital_parameters = generate_orbital_parameters(param1, param2, ...)
 listener.delete()
}

Regex suggests that what would be "easier" for the mod would be this:

mymod.spawn_asteroid(param1, param2, ...) {
 squad.spawn_asteroid(param1, param2, ...)
}

A modder can't make this happen directly, though, because it requires that squad encapsulate asteroid spawning in a different way from how it is currently done. On the other hand, if squad wanted to port the mod, they might do this.

However, there are a lot of caveats. First of all, is the mod written nicely like this? What if the spawn_asteroid function in the mod actually has a bunch of side effects? What if it's not named so obviously?

Of course, there's always the question of whether the second model is in fact better. I would suggest in this case that it may not be. The first model may look cumbersome but arguably works for any kind of spawned thing. It is more generic and more flexible. In other cases, however, a mod may be using some rather "nasty" hack to get things to work because the existing code doesn't have a good way to do it. In such a case Squad would almost certainly look at changing the implementation to ensure stability over future updates.

These questions and others like them are the kinds of things that would have to be considered by Squad if they looked at incorporating current mods.

[Guest]

However, there are a lot of caveats. First of all, is the mod written nicely like this? What if the spawn_asteroid function in the mod actually has a bunch of side effects? What if it's not named so obviously?

That's what code reviews are for. You're certainly not going to integrate closed-source code into your own project unless you trust the source.

Of course, there's always the question of whether the second model is in fact better. I would suggest in this case that it may not be.

Oh boy...

The first model may look cumbersome but arguably works for any kind of spawned thing.

Since we've taken it this far, let's examine the code.

mymod.spawn_asteroid(param1, param2, ...) {
 listener = spawn_listener()
 generate_random_asteroid()
 generated_asteroid = listener.get_latest_object()
 generated_asteroid.orbital_parameters = generate_orbital_parameters(param1, param2, ...)
 listener.delete()
}

This is not really generic, it's specific to a single object since you're looking for newly spawned ships that are asteroids. The reason you have to flip-flop the listener is because you don't want to catch player-spawned ships like your next launch; ships and asteroids are the same thing. You could use the process to catch other things you want to spawn but, secondly, you're doing an awful lot of operations in order to catch an asteroid that you just generated. That's stupid.

a mod may be using some rather "nasty" hack to get things to work because the existing code doesn't have a good way to do it. In such a case Squad would almost certainly look at changing the implementation to ensure stability over future updates.

This is exactly what all this listener flip-flopping is, a nasty hack. Now while you claim the first approach is more flexible, were someone to have access to a function that could be called to generate a specific asteroid any class could generate a specific asteroid. Maybe Jool spawns a trojan asteroid, who knows. Maybe you could have an extinction generator spawn huge asteroids to pelt Kerbin is some weird scenario. Under the first chunk of code you've suddenly got a bunch of classes flip-flopping listeners in some kind of crazy dance eating up processing time because accessing generated asteroids isn't easy. Not to mention that the extinction generator has to keep rolling until it gets an "F" class because no one bothered to let it generate an "F" class specifically.

This

squad.spawn_asteroid(asteroidClass, Orbit, etc...)

is portable. It allows multiple classes to get asteroids in a simple, easy manner, whenever they want, with minimal operations, that doesn't involve hacks.

And you are correct, SQUAD will be able to do things better (for the most part) because modders have to create these nasty hacks.

These questions and others like them are the kinds of things that would have to be considered by Squad if they looked at incorporating current mods.

It has less to do with integrating code and more with workflow and workload, IMO. I can only really speak from my own experience (three years professional, five years modding and other open-source shenanigans) but one thing I do know is that pretty much everyone I've met borrows code. They may not specifically lift it line-by-line, but they do borrow; it's part of the learning process and it helps move your projects forward. SQUAD hasn't exactly made it easy on themselves should they decide to borrow code...

E: Anyway, this is all pretty pointless posturing. It's obvious that SQUAD isn't going to integrate modder code.

Edited June 10, 2014 by regex

[allmhuran]

I think you're missing the point regex. I'm using your example just for the sake of having an existing example to use, not because I necessarily think it is the perfect example of the situations we're describing. As such, I won't debate whether one implementation or another is in fact better in this (or any) particular case. I'm talking about the difficulties and potential issues in principle.

[Whirligig Girl]

Didn't they do that with Bac9? Putting a runway and spaceplane parts into the stock game? I agree that adding some mods that add key missing elements to the stock game (Ferram Aerospace, Deadly Reentry, etc.) would make the stock game a lot better.

C7 did that, bac9 did the building remodel.

Many of ClaraLyrae's KSPX parts made it into the game.

Edited June 10, 2014 by Specialist290
Merging sequential posts

[asheft]

Sorry, my bad. I was confusing the addition of spaceplane parts and the B9 pack.

[weezl]

You're not completely off track, but it doesn't usually work out that way.

Let's continue with a nice simple and concrete example brought up by regex: a mod that involves some gameplay involving asteroids, and therefore has the ability to spawn asteroids.

Imagine, then, that the mod therefore has a function to spawn an asteroid called (hopefully) something easy to find like "spawn asteroid". What modders currently have to do looks something like this (pseudocode):

mymod.spawn_asteroid(param1, param2, ...) {
 listener = spawn_listener()
 generate_random_asteroid()
 generated_asteroid = listener.get_latest_object()
 generated_asteroid.orbital_parameters = generate_orbital_parameters(param1, param2, ...)
 listener.delete()
}

Regex suggests that what would be "easier" for the mod would be this:

mymod.spawn_asteroid(param1, param2, ...) {
 squad.spawn_asteroid(param1, param2, ...)
}

A modder can't make this happen directly, though, because it requires that squad encapsulate asteroid spawning in a different way from how it is currently done. On the other hand, if squad wanted to port the mod, they might do this.

However, there are a lot of caveats. First of all, is the mod written nicely like this? What if the spawn_asteroid function in the mod actually has a bunch of side effects? What if it's not named so obviously?

Of course, there's always the question of whether the second model is in fact better. I would suggest in this case that it may not be. The first model may look cumbersome but arguably works for any kind of spawned thing. It is more generic and more flexible. In other cases, however, a mod may be using some rather "nasty" hack to get things to work because the existing code doesn't have a good way to do it. In such a case Squad would almost certainly look at changing the implementation to ensure stability over future updates.

These questions and others like them are the kinds of things that would have to be considered by Squad if they looked at incorporating current mods.

This is correct.. there are also additional considerations which make things even more complex:

All programs involve simplifying assumptions. That is as true of KSP as it would be of a modder's code module. As long as bringing a new feature into the current codebase doesn't change those underlying assumptions, all is well. But if an assumption must be changed.. it can have a frightful affect on a codebase depending on how the original coders managed the complexity of the code in the first place. If the code is nicely designed and all the modules nicely isolated, then changing an underlying assumption may be merely 'large' in its affect. But if it isn't (for any number of reasons), then changing a simplifying assumption could mean something approaching a major rewrite. I've seen this on a code base that was quite small (<40K lines of code). The original authors had written a mess (they were business folks, not computer science folks), and when we had to change some things, it blew up into re-writing 2/3s of the code. Note I'm NOT saying KSP is like this.. I just know what can happen when you make assumptions that are wrong 1 year from now. And.. I expect that KSP is larger as a code base.. which means underlying assumptions changing midstream can have a quite large effect.

When you are writing code, you must try to keep the future in mind.. but the future you decide on might not be the one you actually see.. which is why some programs end up dying nasty deaths after 4-5 years.

The process of designing and writing large programs is a series of line-bets on the future along with a whole lot of rigor to make sure things work correctly as you write each module and integrate it into the whole. I've met LOTS of programmers that don't make good line bets, and many that don't apply a lot of rigor.. as those bad things multiply, things get worse yet.

Again.. I'm not implying anything about KSP, just trying to give real world perspective on the process of writing software.. Looking at the stability of KSP .24 vs. what it could be, I'm betting its a well organized highly unit tested piece of code.. which from any programmer is high praise. I don't know this for a fact, I'm just a customer.. but it seems like it is so.

Edited June 10, 2014 by weezl

[MR4Y]

I thought they were doing this already, but calling them 'new features' instead.

[Ted]

They don't support or use mods, they have stated on many occasions. also, as far as I'm aware if you do work for Squad, you also can't run a modded version (that they know about) it's part of their agreement (says a few ex developers)...

That's far from correct. I have a few modded installs here and even maintain a plugin I developed before joining Squad, as does Romfarer. Most of us at Squad simply don't have time to keep up with the fantastically fast modding scene and try out the new mods and thus don't run modded installs. Furthermore, in testing we tend to use mods to essentially test out areas of the game that are more difficult to test stock, this is usually done with the help of the mod author.

To clarify further on our support of mods. We don't ensure that we'll provide support modded installs simply because it's a practically impossible task to account for all the plugins and add-ons that are out there and assist players in the use of features we're not familiar with. However, that's very different to us supporting the use of mods, which we absolutely do.

Edited June 12, 2014 by Ted

[MR4Y]

To clarify further on our support of mods. We don't ensure that we'll provide support modded installs simply because it's a practically impossible task to account for all the plugins and add-ons that are out there and assist players in the use of features we're not familiar with. However, that's very different to us supporting the use of mods, which we absolutely do.

Really? I'm sorry, but how come a game that has a forum where mods are posted, documentation on how to make them and even has a site dedicated to publish mods so people can use them IS NOT ABLE TO TRACK THE NUMBER OF MODS???

Okay, there might be some other mods out there that are not cointaned within this community, although this is almost impossible at best. KSP is not that big of a game anyways. We're not talking about Fallout 3, Skyrim or even DOOM levels of modding here.

Either you do two things:

-Don't support mods at all and keep with the unlikely scenario that 'because there are too many mods everywhere, we can't possibly support them.' (status quo)

-Assuming the highly unlikely scenarion from above is existant, support only mods posted in the forums or in Curse.