Why do updates break mods?

[blorgon]

It strikes me as rather odd that updates to the base game are so major that they break existing mods. What is it that they're changing so drastically that mods need to be updated as well?

[Gargamel]

3 hours ago, blorgon said:

major

It's not just the major things that break mods, it can be tiny little things.

If they slightly change how a function call is handle by KSP, then the mod will behave differently than intended.    So the mod makers need a chance to update or recompile the mod for the update, and then test it out to make sure it still work as intended. 

Think of it like this.   If a car, built last year, used 16" tires, but this year's model used 16.25" tires, if you put last years tires on this years car, the car will still work, but the speedometer and odometer will be off. 

[blorgon]

7 hours ago, Gargamel said:

If they slightly change how a function call is handle by KSP, then the mod will behave differently than intended.

Right, that's kinda what I'm asking about. Why is it that the devs make changes like this in the first place?

I'm just curious about the workflow and why the framework on which the mods are based is so volatile. You'd think by now we'd have a really stable system to work with.

Is this par for the course for games with big modding communities?

[HebaruSan]

9 minutes ago, blorgon said:

Why is it that the devs make changes like this in the first place?

Sometimes a particular fix may require that sort of change, or it may just be easier to do it that way. If a bug is happening because a function needs more information to do its job correctly, adding a parameter makes sense, but it also means any mod using the old version of that function will break. Often there's a trade-off between compatibility and a clean API going forward; an old version of a function can be preserved with some default behavior, but anyone writing new code from scratch ought to use the new version, so you'd really rather get rid of the old one.

Another challenge is that "the API" is made up of essentially every public function anywhere in SQUAD's code. Modders can and will use just about any of them, given the breadth of different kinds of mods we have. If a smaller set of functions was provided specifically as a "modding API" then special effort could be applied to them (but that might also limit what could be accomplished by mods).

9 minutes ago, blorgon said:

You'd think by now we'd have a really stable system to work with.

... if that was one of their high priorities for development. If SQUADdies had a list of rules printed out on their walls and one of the rules was, "Never break backwards compatibility", and next to it was a list of ways to work around common compatibility pitfalls, with commit checks to catch accidental violations, then yes, stability would be expected.

Even so, the system has been pretty stable lately. Many mods that worked on 1.3.1 still work on 1.4.3.

9 minutes ago, blorgon said:

Is this par for the course for games with big modding communities?

I think it's par for the course for games that allow modding, period. Any game under active development is going to risk breaking mods unless the dev team follows rules as draconian as "never change any public function" and "never change file formats".

[blorgon]

5 hours ago, HebaruSan said:

Sometimes a particular fix may require that sort of change, or it may just be easier to do it that way. If a bug is happening because a function needs more information to do its job correctly, adding a parameter makes sense, but it also means any mod using the old version of that function will break. Often there's a trade-off between compatibility and a clean API going forward; an old version of a function can be preserved with some default behavior, but anyone writing new code from scratch ought to use the new version, so you'd really rather get rid of the old one.

Another challenge is that "the API" is made up of essentially every public function anywhere in SQUAD's code. Modders can and will use just about any of them, given the breadth of different kinds of mods we have. If a smaller set of functions was provided specifically as a "modding API" then special effort could be applied to them (but that might also limit what could be accomplished by mods).

... if that was one of their high priorities for development. If SQUADdies had a list of rules printed out on their walls and one of the rules was, "Never break backwards compatibility", and next to it was a list of ways to work around common compatibility pitfalls, with commit checks to catch accidental violations, then yes, stability would be expected.

Even so, the system has been pretty stable lately. Many mods that worked on 1.3.1 still work on 1.4.3.

I think it's par for the course for games that allow modding, period. Any game under active development is going to risk breaking mods unless the dev team follows rules as draconian as "never change any public function" and "never change file formats".

Fair enough. I hope I don't sound like "why doesn't SQUAD stop messing with modders?"

I'm honestly just curious about the limitations with the game, and what makes a game conducive to modding. I honestly believe that mods keep this game alive, so it is frustrating having to wait for mods to get updated, and I can't imagine the frustration of the modders constantly having to recompile and edit their mods. I just wish there was a more symbiotic relationship between SQUAD and the community.

Edited May 5, 2018 by blorgon

[sarbian]

On one side it can be annoying to update your mod. But on the other one I would rather not see the game dev slowed down by the need to keep mods compatibles.

[blorgon]

13 minutes ago, sarbian said:

On one side it can be annoying to update your mod. But on the other one I would rather not see the game dev slowed down by the need to keep mods compatibles.

That's a fair point, but if you think about it, if they kept mod compatibility in mind while developing new updates, the community would get to play the new update sooner, because mods would most likely be ready to go at release or at least would take a lot less time to fix anything that breaks. Right now, the community has to wait for however long because the modders are unpaid volunteers that have their own lives. Some mods don't even get updated anymore.

I'd much rather wait longer for a release with a guarantee that mods will be compatible than risk my favorite mods being broken for months, or even abandoned. We already wait a long time for KSP updates anyway.

Just my opinion, of course. I'm also of the (probably unpopular) opinion that SQUAD (or Take Two, or whoever is in charge these days) should integrate the more ubiquitous/popular mods like scatterer and SVT, and convert all the tank/structural/utility/engine parts to procedural generation. 

Edited May 5, 2018 by blorgon

[sarbian]

You can not have a game that allows mods as complex and intricate as KSP's and have a fixed stable modding API. 

9 minutes ago, blorgon said:

'm also of the (probably unpopular) opinion that SQUAD (or Take Two, or whoever is in charge these days) should integrate the more ubiquitous/popular mods like scatterer and SVT, and convert all the tank/structural/utility/engine parts to procedural generation.

And after being integrated that content would not evolve anymore. Which is a net loss for players.

[HebaruSan]

3 hours ago, blorgon said:

I'm honestly just curious about the limitations with the game, and what makes a game conducive to modding.

A few samples:

• https://kerbalspaceprogram.com/api/class_vessel.html
• https://kerbalspaceprogram.com/api/class_celestial_body.html
• https://kerbalspaceprogram.com/api/class_orbit.html
• https://kerbalspaceprogram.com/api/class_part.html
• https://kerbalspaceprogram.com/api/class_ship_construct.html
• https://kerbalspaceprogram.com/api/struct_vector3d.html

Scroll through those pages to get a sense of how long they are. Every single line that isn't under a "private" heading represents something that SQUAD has to leave as it is in order to avoid breaking mods. And this is just a tiny fraction of all the classes that are out there. In effect the structure of the game and most of the behavior is set in stone, unless mods are allowed to break.

[blorgon]

4 hours ago, sarbian said:

And after being integrated that content would not evolve anymore. Which is a net loss for players.

That's a fair point to make for many mods, but things like scatterer, skybox and sunflare replacements, Stock Visual Terrain, and RemoteTech (of course, SQUAD already added their own comms, which blows in comparison to RT, but that's another discussion) don't need to evolve that often, if ever. I'm only talking about mods like that.

Quote

You can not have a game that allows mods as complex and intricate as KSP's and have a fixed stable modding API. 

I honestly don't see why not. I really don't think the two are mutually exclusive. I'm talking in general, of course. A game like that would need to built from the ground up with modding in mind. 

2 hours ago, HebaruSan said:

Scroll through those pages to get a sense of how long they are. Every single line that isn't under a "private" heading represents something that SQUAD has to leave as it is in order to avoid breaking mods. And this is just a tiny fraction of all the classes that are out there. In effect the structure of the game and most of the behavior is set in stone, unless mods are allowed to break.

That's a fair point, but how many of those methods are changed in any given update to a different return type, or changed to require different arguments, or have their names themselves changed? And how many of those are actually things mods commonly require access to?

This is all for the sake of discussion, by the way. I know SQUAD will never make a modder's paradise.

[HebaruSan]

3 minutes ago, blorgon said:

That's a fair point, but how many of those methods are changed in any given update to a different return type, or changed to require different arguments, or have their names themselves changed? And how many of those are actually things mods commonly require access to?

Very few. That's why so many 1.3.1 mods continue to work on 1.4.3.

There was more breakage between 1.2 and 1.3, since the localization invalidated certain functions that assume English (such as CelestialBody.theName, which was removed and then came back recently because they apparently decided that an issue I filed about it had to be fixed ). For whatever reason, 1.3 also had instances of types being renamed and function parameters being changed (I kind of suspect that a newer dev worked on those changes and didn't realize the impact they would have).