When will updates stop breaking mods?

[Overland]

Ive been around since 0.25..

Been driving land trains on kerbin for years. Ive bowed out of KSP for a year or so after 1.30+ broke everything (again)

KSP for me is unrivaled in its engineering possibilities.. Only KSP lets me drive land trains across beautiful landscapes full of challenges.. Each machine being an evolution of a concept born out of the fire and flames of failure and emotional attachment of success..

No other game has got under my skin and into my very soul the way KSP has.. Giving life to self writing stories and legends of thier own making as the deadly yet beautiful diesel electric land trains ply thier way across the lands of kerbin

Yet the biggest challenge of all isnt driving a rolling multiwheeled detriot engined self igniting fuel tank across rough terrain..

Its the updates that break mods everytime.

Coming back to the forum..clicking on the release thread only to find the same mod breaking cycle has repeated like countless times before is absolutely disheartening

I expected it in early access.. Thats over now.. Given that KSP is and has always been lifted to greatness by the mod community, isnt there a good foundation to stop breaking everything with updates?

I speak of this as a self styled landtrain driver, one whos willing to spend good money on getting custom locomotive parts made. Stepping away from the train made of space station parts ideal

Absolutely enthusiastic about finally getting my custom land train controller finally into reality, even going as far as making my own uniform and streaming adventures on my return to ksp

Only to face the grim prospect of having it all not work or be broken somehow in the next update.  A pain I know many mod makers felt.. Some left because of it

So is there a greater plan to stablise ksp versions?

Prevent mods breaking?

Coming back after so long and seeing more of the same is just..very disheartening

 

 

[Tyko]

It's not going to change as long as Squad continues updating the game.

If you had a working version that you enjoyed so much why not just stick with what works and enjoy? There've been a number of times when I've decided to keep playing on a stable game rather than jump into the update cycle.

 

[Kerbart]

No updates: “Squad has abandoned the game.”

API neutral updates that don’t change the way the game works: “Squad is only doing retexturing and not real updates”

Updates that improve the game but require recompilation for some mods: “Squad breaks my mods each update.”

 

It really is a lose/lose proposition for them...

[Lisias]

Just now, Kerbart said:

It really is a lose/lose proposition for them...

KSP is a mod friendly game, not a mod oriented game.

They allow us (and encourage us!) to tinker with the game, but they have their own schedule and agenda - it's what put food on their tables. Hungry developers don't deliver games.

And, speaking very frankly - some of the worst problems I have to solve came from the mods themselves and some.. non exactly standard…. coding practices.

KSP is now a small Operating System (the complexity is near what we had in the 90's). There're some coding practices and standards that need to be taken very seriously nowadays, and it's unavoidable that code that don't follow such practices break on every new release.

Such coding had broke programs in the past on the very same circumstances, it will break now too. Simple like that.

[Chel]

You just gotta wait till a new version of a mod comes out, or simply not update your game.

[pandaman]

Good to see you on here again @Overland, welcome back. I was just thinking a few weeks ago that hadn't seen you around for a while.

As others have said, i don't see the potential for breaking mods going away as long as Squad keep updating the game.

[Pecan]

I hope never.

"Mods" in general would cover the whole of the system so 'no mod-affecting changes' would mean 'no changes'.

[Rocket In My Pocket]

18 hours ago, pandaman said:

Good to see you on here again @Overland, welcome back. I was just thinking a few weeks ago that hadn't seen you around for a while.

Same, good to have you back!

I miss your train related segues in every other thread lol.

19 hours ago, Overland said:

Coming back after so long and seeing more of the same is just..very disheartening

Don't let that stop you, just pick a version that works for you and stick with it, lot's of people do that. (I mean I don't personally, but it seems to work for most of the hard core/heavily modded players around here.)

19 hours ago, Overland said:

Absolutely enthusiastic about finally getting my custom land train controller finally into reality, even going as far as making my own uniform and streaming adventures on my return to ksp

I would totally watch that! Lol.

Edited November 13, 2018 by Rocket In My Pocket

[Snark]

Hi @Overland,

Below is a Massive Wall of Text™, as I am, alas, wont to do.    But if you don't feel like wading through the whole thing, I can boil it down and save you the time thus:

• Speaking as a software engineer:  what you're asking for (continued KSP development, with a rich mod ecosystem in which mods never get broken) cannot be done.
• Most mods actually don't get broken with KSP updates.  And that's because Squad's doing a really good job at making it so.
• The fact that some get broken, sometimes, is an unavoidable fact of life when a platform is, 1. open, and 2. live.
• If you don't like it, then simply don't update KSP.

 

Okay, on with the wall of text.  Don't say I didn't warn you. 

19 hours ago, Overland said:

Its the updates that break mods everytime.

Coming back to the forum..clicking on the release thread only to find the same mod breaking cycle has repeated like countless times before is absolutely disheartening

Depends on the mods.  I use a fair number of mods myself, and I've written (and continue to support) a dozen or so.  My experience?  KSP updates rarely break any of the mods I use or maintain.  Most KSP updates don't require me to update any of my mods at all, not even a simple recompile-- they "just work", and my job as a modder is simply to go 'round my mod threads and update the thread title to make it clear that they still work.

Ditto most of the mods that I use that are written by other folks.

On the other hand, if KSP updates an aspect of the game that's directly relevant to an area that a mod affects, of course the mod's going to be affected.  It's exactly the same as if you're having your bedroom remodeled in your house:  most of the house is just fine, but you're going to have to sleep in another bedroom until it's fixed.  It's not anything at all bad about what Squad's doing-- it's just how software development works.  And, speaking as a professional software engineer who's been shipping commercial code for a living for over 25 years, I can say that I've been impressed with KSP.  I think Squad's been doing an excellent job of not disrupting mods more than they have to.

So, I'd rephrase what you wrote as,

Quote

It's the updates that rarely break mods. Yay!

Sure, on some occasions there's a huge seismic shift in the game, which of necessity breaks practically everything.  The update to KSP 1.1 is probably the best example of this in the 4+ years I've been playing the game.  That one was huge, and it broke practically everything.

But it was there for an excellent reason-- the game was on an obsolete version of Unity, and was riddled with performance-guzzling suboptimal code.  It seriously needed upgrading.  Going back to the home-improvement metaphor, it was like having a grand old house that may have been lovely in its day, but which has unfortunately become riddled with termites and has sky-high heating bills in the winter and a leaky roof and various other problems.  To save the house requires a huge, extensive remodel, which is intrusive to anyone living in the house-- but after it's done, it's so much better for everyone living there.

Or, to pick a different metaphor:  you can't do surgery without some bleeding.

In a situation like that, you just gotta bite the bullet and overhaul it.  The right solution would not have been "just leave it alone and don't bother anyone until eventually the house collapses."  Yes, it was highly disruptive-- but it was also highly necessary.  And huge modding community then stepped up its game and had mods updated for it in reasonably prompt order.  I had my own mods running again within a few days of the release, IIRC.

And that kind of seismic shift is pretty rare.  The large majority of KSP updates are minimally disruptive and don't affect most mods.

19 hours ago, Overland said:

Coming back to the forum..clicking on the release thread only to find the same mod breaking cycle has repeated like countless times before is absolutely disheartening

Do you have a specific example?  Because I keep feeling like you and I must be playing completely different games.  My own experience is that there really isn't much of a "mod breaking cycle", and that KSP updates usually don't affect most mods.  And when they do, the mods are generally updated pretty quick, so the outage is minimal.

And in any case, nobody ever has to update KSP, so if you're worried about having your gameplay interrupted for a few days while waiting for some critical mod to update... why update your KSP in the first place?  Just keep playing your old version until you learn that your favorite mods are compatible with the new version, and then switch over.

Just to be clear:  I don't even slightly mean to belittle or discount your experience.  Obviously this is some form of problem for you, or you wouldn't have posted what you did.  Since what you've described doesn't match my own observations or experience playing KSP, even slightly, it means there's an understanding gap somewhere.  Would love to better understand where you're coming from. 

Maybe you do have a legitimate issue-- and the fact that I don't understand it means that I'm lacking some perspective.  In which case I'd love to learn more so I can understand better!  Or... maybe you're seeing a "problem" where there actually isn't one, e.g. (to pick just one example) if you happen to use CKAN and there are mods that are slow to update their "which versions of KSP do I work on" metadata, so that CKAN thinks they don't work when they actually do-- in which case the problem isn't even slightly with Squad or KSP itself.

Or it could be any one of a number of other things.

So could you please give some specific details about a particular tale of woe you've recently experienced?  i.e. "I updated from KSP <version> to <newer version>, and that broke <specific mods> for <time interval>, which caused me problems because <thing I couldn't do anymore>."

19 hours ago, Overland said:

Given that KSP is and has always been lifted to greatness by the mod community, isnt there a good foundation to stop breaking everything with updates?

No, there isn't.  Because software development doesn't work that way.

19 hours ago, Overland said:

Prevent mods breaking?

Sorry, can't be done.

(At least, not as long as they continue development on the game, which I hope they keep doing for a long long time.)

If you wish they'd just stop developing KSP and let it die, then mods will no longer break, sure.  But that's what it would take.  Do you want that?  I sure don't.  And even if you do want it... you can have it.  Simply stop updating your copy of KSP (and the mods you're using), and then you can happily play that forever.

The reason that KSP mods break, from time to time, isn't because Squad is "doing it wrong".  They're actually doing a pretty good job, as far as backwards compatibility is concerned.  I can state that with confidence, based on, 1. decades of experience as a software engineer, and 2. a few years of modding KSP and observing how they have their code design set up.

Look, much as I love the game, I've had my own share of design gripes about KSP-- including "moddability" areas where I think to myself "gosh, I wish they hadn't designed that code this way, because I want to mod it like that and now I can't because their design in that spot isn't as flexible as it could be."

But not once have I observed them to make an easily avoidable mod-breaking change.  The large majority of their changes either don't affect mods at all, or open up new places that become more mod-friendly than they used to be (not least because they have clearly demonstrated that they make modders a priority-- I've seen plenty of cases of their responding to "moddability" feedback that didn't actually affect the player's experience of an unmodded game, but make things easier to mod.)  And on those few occasions that they do make a seriously disruptive change... it's very necessary.  Happens sometimes.  Can't make an omelette without breaking eggs.

What it boils down to is this:  speaking as a software engineer, it is not physically possible to build software that will never break any client code, if your code base is wide open and most of your classes are accessible to clients.  Can't be done.  I could go on for yet more pages of technical minutiae about why it can't be done, but I've already thrown a massive wall of text at you here, so enough is probably enough (unless you're interested).    Basically, the only ways to avoid "breaking any mod ever" would be a cure worse than the  disease:

• Option 1:  Stop developing the game entirely and let it die of old age.
• Option 2:  Cut down on moddability to the point that the game is very hard to mod and has only a few very narrow interfaces that mods can interact with.  Basically, "eliminate 99% of mods by removing 99% of the hooks they use".  The mods would be gone, but hey, at least they wouldn't keep breaking!

Or we can go with option 3, which is "keep updating the game, and most mods are fine most of the time, and on those rare occasions when a mod breaks, it's just a little while until the mod author fixes it."  Which is what we have now, and personally I'm pretty happy with. 

20 hours ago, Tyko said:

It's not going to change as long as Squad continues updating the game.

If you had a working version that you enjoyed so much why not just stick with what works and enjoy? There've been a number of times when I've decided to keep playing on a stable game rather than jump into the update cycle.

^ Or, instead of inflicting this massive wall of text on everyone, I could have just pointed at this excellent post, where Tyko has tidily summed up pretty much my entire point in just three sentences. 

[Tyko]

1 hour ago, Snark said:

^ Or, instead of inflicting this massive wall of text on everyone, I could have just pointed at this excellent post, where Tyko has tidily summed up pretty much my entire point in just three sentences.  

Thanks @Snark!

@Overland I hope you get this worked out. I've been following your land train posts since I first started playing around v1.0 You've definitely pushed the boundaries of what I thought of as "KSP"

If you do decide to update to 1.5.x you should definitely check out the work @IgorZ has done on the new Kerbal Attachment System. Just watch the train demo video he posted...it's so cool.

- Tyko -

 

[Mr. Peabody]

When will KSP stop breaking mods?

Neva.

[Snark]

27 minutes ago, The Dunatian said:

When will KSP stop breaking mods?

Neva.

Well, nothing's forever.  Eventually it will, same as any other software development project:  when Squad ceases development on it.

But until then?  Yeah, gonna keep happening.  It's unavoidable.  It's not physically possible for them to guarantee not to break anything ever, so about all they can do is to try to work in a way that minimizes the disruption.

And it's clear to me that they do try to minimize the disruption, and frankly (speaking both as a KSP modder and as a professional software engineer) they do a pretty good job of it, in my opinion.

[wumpus]

2 hours ago, Snark said:

What it boils down to is this:  speaking as a software engineer, it is not physically possible to build software that will never break any client code, if your code base is wide open and most of your classes are accessible to clients.  Can't be done.  I could go on for yet more pages of technical minutiae about why it can't be done, but I've already thrown a massive wall of text at you here, so enough is probably enough (unless you're interested).    Basically, the only ways to avoid "breaking any mod ever" would be a cure worse than the  disease:

• Option 1:  Stop developing the game entirely and let it die of old age.
• Option 2:  Cut down on moddability to the point that the game is very hard to mod and has only a few very narrow interfaces that mods can interact with.  Basically, "eliminate 99% of mods by removing 99% of the hooks they use".  The mods would be gone, but hey, at least they wouldn't keep breaking!

 

Classes are wide open?  I had a whole long reply how it should have been possible (within *strong* boundaries, and extremely expensive), but that assumed some sort of API between KSP and mods.  If the modders can meddle with the classes directly that is clearly impossible.  And of course trying to change this would fundamentally break *every* mod in a way that would require a near-total re-write.

Linux has a specific API and most of Linus's famous salty responses were from those who dared break the existing [external] API.  Change an internal hook, or expected binary interface?  No problem.  The catch is that what the KSP modders are doing is essentially the "internal API" and worse.  And of course, even if you wrote your Linux program to the unchanging API, you still have to check regularly to see if KDE/Gnome or (gods help you) SystemD didn't break your program.

You might as well ask them to not have bugs.  The only way that appear possible is to have limited features, *NEVER ADD FEATURES*, and spend years (after deployment) fixing those bugs.  I've heard that Knuth thinks he's fixed his last TeX bug, but that may be the only program sufficiently well written (and long lived) to become "bug free".  Don't hold your breath for another one to come along (although things like jet-engine control software might also qualify.  Don't ask how picky the FAA is in how software is written).  For something that organically grew (and lives on top of Unity), that type of thing is strictly impossible.

[Snark]

29 minutes ago, wumpus said:

Classes are wide open?

Pretty much, yeah.

They do have some private classes and private methods and such, which are out-of-bounds for modders.  But all public classes and methods are fair game... and a huge swath of the game falls into that bucket.  It's what makes KSP so extraordinarily moddable.  They've made a point of pretty much "letting it all hang out" so people can get in there and futz with all kinds of things.

29 minutes ago, wumpus said:

I had a whole long reply how it should have been possible (within *strong* boundaries, and extremely expensive), but that assumed some sort of API between KSP and mods.

Yes.  Which there isn't.  Even slightly.

Mods can talk to literally hundreds of classes in KSP (might even be thousands, for all I know)-- it's all sitting right there out in the open.  And the code that mods talk to is the same code that the Squad devs themselves talk to.  There isn't any "modding API" in KSP.  There never has been, and probably never will be.  Rather... in essence, the whole freaking game is the API.

The lack of a formal modding API in KSP isn't at all a surprise to me.  Building and designing that sort of thing is a huge time investment-- believe me, I've done that sort of thing as part of my job, and it's a major feature to implement.  It would sideline a hefty chunk of their engineering team to provide just that one thing... and then they'd have the problem that either it would be very narrow and constrained (which would drastically limit the creative freedom of mods), or else would be very big and complex (in which case it would become an engineering job probably bigger than the whole rest of the game put together).

Not to mention all the investment they'd need to make for formal documentation, and regression testing, and yadda yadda.  APIs are hugely expensive features to ship and maintain, even for a big team.  My impression is that Squad's fairly small, and that their developers have got their hands completely full simply staying on top of the game itself, implementing features and bug fixes.  No way would I expect them to have the kind of time in their budget for implementing and maintaining a formal modding API.

So they've done the simple, pragmatic thing:  don't even try.  Just make the game wide open, and leave hundreds (or maybe thousands) of classes just hangin' out there flapping in the breeze where anyone can do anything they want to them.

It's simple, it's easy, it gives maximum creative flexibility to mods, and it doesn't require the dev team's time.  It has the advantage that mods can do practically anything they want.  However, it also comes with the disadvantage that mods can do practically anything they want.    It means that Squad has zero control over (or knowledge of) what mods might be doing, and it would become basically impossible to change anything, ever, without the risk of breaking some mod somewhere.

29 minutes ago, wumpus said:

The catch is that what the KSP modders are doing is essentially the "internal API" and worse.

Pretty much, yeah.  Note that, as I mention above, there are private classes and methods inside KSP, which are off-limits to modders.  But the bulk of it is public and available to everyone, so this statement of yours does pertain, for the most part.

29 minutes ago, wumpus said:

You might as well ask them to not have bugs.  The only way that appear possible is to have limited features, *NEVER ADD FEATURES*, and spend years (after deployment) fixing those bugs.

Ding ding ding. 

29 minutes ago, wumpus said:

For something that organically grew (and lives on top of Unity), that type of thing is strictly impossible.

Exactly.

[DerekL1963]

11 minutes ago, wumpus said:

I've heard that Knuth thinks he's fixed his last TeX bug, but that may be the only program sufficiently well written (and long lived) to become "bug free".

The Shuttle's software was essentially bug free...  And the software that drove the missile fire control system I worked on in the Navy absolutely was bug free.  But, in both cases, huge heaps o' cash and man-hours were invested to accomplish that.

 

13 minutes ago, wumpus said:

Don't hold your breath for another one to come along (although things like jet-engine control software might also qualify.  Don't ask how picky the FAA is in how software is written).

Absolutely, there's plenty of code that's bug free.  There's just very little commercial or open-source/free software that's bug free because the cost doesn't merit the returns.

[Snark]

23 minutes ago, DerekL1963 said:

The Shuttle's software was essentially bug free...  And the software that drove the missile fire control system I worked on in the Navy absolutely was bug free.  But, in both cases, huge heaps o' cash and man-hours were invested to accomplish that.

Yep, very much a matter of "you get what you pay for."

For super-critical, "somebody dies if there's a problem" code-- such as military systems, spacecraft, avionics, etc.-- you can get remarkably stable and low-bug code, if you are willing to spend literally thousands of dollars on each individual line of code.  And even then, it only works because the use case is narrowly defined (unlike a wide-open flexible system like KSP).

(And even there, it's not "bug free"-- there's no such thing for anything with more than a few lines of code, any more than it's physically possible to machine a part to zero tolerance.  It's just that the bug count can be driven very, very, very low.)

(And even spacecraft with very heavily vetted software can have problems, since they're used by... well... human beings, who will never be bug free.  Here's a particularly comical incident with the space shuttle-- fortunately not a situation where anybody got hurt.  "... failed because ground controllers sent instructions to the shuttle in nautical miles instead of feet ...")

23 minutes ago, DerekL1963 said:

There's just very little commercial or open-source/free software that's bug free because the cost doesn't merit the returns.

^ This, exactly!

If we were willing to pay a few thousand bucks per copy for KSP, then we could have much lower bug counts and mod breakage than we do.    But we don't, and for a fun little cartoon spaceship game turned out by a relative handful of developers on a rapid release cycle for a target market of maybe a million or so people tops, who only pay the equivalent of dinner-and-a-movie for it... well, we're not gonna get perfection.  The economics simply don't work out.

[Geonovast]

1 minute ago, Snark said:

who only pay the equivalent of dinner-and-a-movie for it.

And only once at that.

[Pecan]

14 hours ago, Snark said:

pay the equivalent of dinner-and-a-movie for it...

Dinner out costs more than I paid for KSP!

[Dafni]

At this point I have nothing to add to the discussion, just WELCOME BACK Mr. OVERLAND!

I was missing you and your creations on here.

[magnemoe]

17 hours ago, wumpus said:

Classes are wide open?  I had a whole long reply how it should have been possible (within *strong* boundaries, and extremely expensive), but that assumed some sort of API between KSP and mods.  If the modders can meddle with the classes directly that is clearly impossible.  And of course trying to change this would fundamentally break *every* mod in a way that would require a near-total re-write.

Linux has a specific API and most of Linus's famous salty responses were from those who dared break the existing [external] API.  Change an internal hook, or expected binary interface?  No problem.  The catch is that what the KSP modders are doing is essentially the "internal API" and worse.  And of course, even if you wrote your Linux program to the unchanging API, you still have to check regularly to see if KDE/Gnome or (gods help you) SystemD didn't break your program.

 You might as well ask them to not have bugs.  The only way that appear possible is to have limited features, *NEVER ADD FEATURES*, and spend years (after deployment) fixing those bugs.  I've heard that Knuth thinks he's fixed his last TeX bug, but that may be the only program sufficiently well written (and long lived) to become "bug free".  Don't hold your breath for another one to come along (although things like jet-engine control software might also qualify.  Don't ask how picky the FAA is in how software is written).  For something that organically grew (and lives on top of Unity), that type of thing is strictly impossible.

Yes, this make KSP mods more vulnerable than say Skyrim mods there they makes fewer engine changes on updates and most important you don't link classes directly, you use an internal scripting engine for stuff like effect. 

[Overland]

Thankyou everyone that replied :) still going through said wall of text(s) :)

I did read something about wheel suspension being fixed a little more in the recent update. 

Ill just have to learn how to maintain mods

its good to be back :)

ill start looking around for ways of getting an Alco World and RS3 modeled to KSP standards. Its going to be a big change, biggest concern was going the fengist route. Get a nice parts pack released with much pride and happiness, only for it all to not play nice with the next update

still, that said.. Most land train mods of mods were wonderfully low tech

as long as they keep alternators and resource consumption the way it is, diesel electrics should always work

Ill reply when I got time. Thats a formidable wall of text to nargle :)

[FleshJeb]

Hey @Overland, I just wanted to add to the chorus of people that miss you and your unique take on KSP.

I sympathize with your frustrations, because I experience them myself, but I hope you find a way to come back, because what you do is cool and fun.

[sturmhauke]

On 11/13/2018 at 11:29 AM, Snark said:

The lack of a formal modding API in KSP isn't at all a surprise to me... It would sideline a hefty chunk of their engineering team to provide just that one thing... and then they'd have the problem that either it would be very narrow and constrained (which would drastically limit the creative freedom of mods), or else would be very big and complex (in which case it would become an engineering job probably bigger than the whole rest of the game put together).

This is the approach taken by stuff like Second Life, Neverwinter Nights, Roblox, etc. They come with a default world to play in, but they're really more creation platforms with robust interfaces and APIs. Second Life has its Linden Scripting Language and Neverwinter Nights had its own language, which were both C-derived and had function calls to hook into the core engine. Roblox is similar but uses Lua.

[Lisias]

On 11/14/2018 at 9:27 PM, sturmhauke said:

Second Life has its Linden Scripting Language and Neverwinter Nights had its own language, which were both C-derived and had function calls to hook into the core engine. Roblox is similar but uses Lua.

On the other side, you can only do what they allow you to do. For every single thing you is able to do, someone had to think, decide if they want you to do so, and then implement.

It's the exact opposite from KSP, where they allow us (and even encourage us) to tinker in whatever we want. We can change absolutely anything on the game, from the Aerodynamics' engine (see FAR) to the Orbital Mechanics' (se Principia).

You can't have the cake and eat it too. Or we have KSP as we have and love, or we don't.

[Fraktal]

Hey, I'd be happy if the modders would just stop putting MiniAVC into the CKAN releases of their stuff. Putting it in the standalone release is fine and makes sense, but CKAN already does the version checking and won't even let you install an incompatible release in the first place unless you go out of your way to allow it, so not only is MiniAVC redundant in the CKAN release, but 99% of the time a pointless annoyance as well due to the mod working just fine despite the constant demands to downgrade my KSP version.

Edited November 19, 2018 by Fraktal