Interface versioning instead of game versioning

[Tomator]

Hi,

The game has bugs, obviously. Then the updates are required ind it's great they are provided from time to time. However, they ruin the game when the user uses mods that are aware of the game version. But...

Mods integrate with the game by some interfaces. What if these interfaces were versions were essential instead? Mods that use interfaces that didn't change would still work. While the game version is changes arbitrarily and the only difference may by texture update or adding new parts, which has no impact on mods, it can disable mods the user has installed. A nightmare is that when a mod defines some parts, no ship containing these parts can even be loaded. They disappear in the game. If the interfaces were versioned, mods would still be loaded, parts displayed ships could be edited and even fly - some part would cease function yet they still could be targets of a rescue missions - in worst case.

[Kerbart]

You overestimate the community. There'd be complaining about updates "that don't do anything."

[HebaruSan]

2 hours ago, Tomator said:

Mods that use interfaces that didn't change would still work.

This is already the case.

[Red Iron Crown]

If you use mods then don't update your game until your mods have caught up. Problem solved, as it has been since modding became possible. 

[Tonka Crash]

You either wait forever for mods that may never update or you play on anyway. I still have about 15% of my mods that haven't updated since I bought the game at 1.4.3. At the jump to 1.5.0 it only took me a couple minutes to find that I needed to wait for some mods to catch up and I recompiled a couple myself, but at 1.6.0 it took over a week to find a problem, but one I can work around.

Edited December 31, 2018 by Tonka Crash

[linuxgurugamer]

1 hour ago, Tonka Crash said:

You either wait forever for mods that may never update or you play on anyway. I still have about 15% of my mods that haven't updated since I bought the game at 1.4.3. At the jump to 1.5.0 it only took me a couple minutes to find that I needed to wait for some mods to catch up and I recompiled a couple myself, but at 1.6.0 it took over a week to find a problem, but one I can work around.

Other than the 1.6 issue of needing to reload 2x after changing parts mods, what other issue have you found on 1.6?

[Tonka Crash]

1 minute ago, linuxgurugamer said:

Other than the 1.6 issue of needing to reload 2x after changing parts mods, what other issue have you found on 1.6?

Needing to start the game twice after a mod change is the problem I was referring to. I only encountered the problem for myself yesterday morning and spent several hours isolating it. I updated to 1.6.0 the same day it came out and hadn't noticed any problems. I also haven't had to use the VAB much in the last week. I finally had a manned mission arrive at Duna the morning I had to leave town for Christmas for 3 days. Since I've been back I've been spending my time exploring that system with existing vessels and wrapping up other contracts, but not building new vessels.

The only other problem and this dates back to 1.5.1 is that the game generally seems less stable than 1.4.5. I get crashes to desktop almost daily where it had been around once or twice a month for 1.4.5. 1.5.1 usually crashed when I would exit the game and 1.6.0 isn't doing that often, but I get frequent crashes during start. It's more rare to see a crash in flight mode.

I usually do a CKAN check before launching, but there haven't been that many updates yet for 1.6.0. It seems that it's taking longer for mod authors to get around to updating. For that I blame the timing of the release being so close to the holidays and people having holiday commitments. The flip side is that it took longer for me to run into the mod change problem just because I'm not updating every time I start.

When a KSP update drops I back up my game tree, run the installers to create a clean install, make a copy of the clean install and then copy over my mods & saves from my current game. I'll start my fully modded game, bounce around all my existing bases & stations and do a few contracts trying to exercise mods looking for problems. If I don't run into problems I keep playing on the update. I saw the problem reports on the new Mk2 Lander can, so I avoided using it. Otherwise I've been able to continue playing as normal.

[linuxgurugamer]

2 minutes ago, Tonka Crash said:

The only other problem and this dates back to 1.5.1 is that the game generally seems less stable than 1.4.5. I get crashes to desktop almost daily where it had been around once or twice a month for 1.4.5. 1.5.1 usually crashed when I would exit the game and 1.6.0 isn't doing that often, but I get frequent crashes during start. It's more rare to see a crash in flight mode

That may be a Unity issue.  What I've found is that it hasn't done a CTD if I'm starting a game which is set to be fullscreen using these startup options:

KSP_x64.exe -single-instance -popupwindow

 

3 minutes ago, Tonka Crash said:

I usually do a CKAN check before launching, but there haven't been that many updates yet for 1.6.0. It seems that it's taking longer for mod authors to get around to updating. For that I blame the timing of the release being so close to the holidays and people having holiday commitments. The flip side is that it took longer for me to run into the mod change problem just because I'm not updating every time I start.

Actually, it may be because very few mods need to be updated for 1.6

 

[Tonka Crash]

5 minutes ago, linuxgurugamer said:

That may be a Unity issue.  What I've found is that it hasn't done a CTD if I'm starting a game which is set to be fullscreen using these startup options:

KSP_x64.exe -single-instance -popupwindow

Thanks for the suggestion I'll try that. I've been using a shortcut to start fullscreen  with -popupwindow, but did not have -single-instance.

7 minutes ago, linuxgurugamer said:

Actually, it may be because very few mods need to be updated for 1.6

I realize that which is the main reason I didn't wait for mods to update, but it would be nice to get an update just to clear AVC warnings. The AVC warning list I get is taller than a 1080p screen can display.

[Snark]

On 12/30/2018 at 10:39 AM, Tomator said:

Mods integrate with the game by some interfaces. What if these interfaces were versions were essential instead? Mods that use interfaces that didn't change would still work.

A few things:

First, that's already the case.  Most mods do, in fact, continue to work from one KSP version to the next.  When we went from KSP 1.5 to KSP 1.6, for example, all of the dozen or so of my own mods just continued to work with nary a hiccup.  Ditto when going from 1.4 to 1.5.

So the game already does what you want.  The large majority of mods handle KSP version transitions just fine with no problems-- don't even need a recompile, they "just work".

And as for the few that don't "just work", and do in fact get broken?  Unavoidable.  Bear in mind that this is not about "interfaces", really.  I get the impression that you're picturing the game's innards as being a big, complex set of "private" implementation that's invisible to mods, and then some fairly sparse, spare, "clean" interface that serves as the boundary between the public outside world (which mods have access to), and the private interior-implementation world.

That's certainly a possible way to organize software.  It's a way that software often is deliberately engineered to do, precisely to make it possible to maintain compatibility-- shared software libraries do that sort of thing all the time, for example.  But KSP is not built that way.  It never has been.  Its innards are mostly exposed-- mods can get at nearly all of the game's code.  There is no interface.  That's why KSP is so incredibly moddable-- precisely because mods have the ability to get at everything.

Also:  If the KSP developers wanted to change the interior design of KSP-- to offer only a very restricted, dumbed-down public API, and hide all the internals-- then that would greatly improve version compatiblity of mods, yes... but it would also make the game much less moddable and it would be a lot harder for mods to be able to do any arbitrary thing they wanted.  Also, note that maintaining that sort of interface is a large, expensive engineering feature-- it requires tons of time, both from the engineers and from API designers, technical documentation writers, etc.  It's a major feature to deliver-- which means providing that would take precious engineer-hours away from other stuff, like implementing shiny new features, fixing bugs, etc.

So, moving to a model like that would require making the game a whole lot less moddable (which means that a large fraction of the mods out there would suddenly shut down, permanently, and be forever gone and impossible to implement), while simultaneously sucking large amounts of engineering resources out of the game so that we'd have a buggier, more feature-poor game experience.  All for the sake of supposedly making the few remaining mods less likely to break on KSP version updates-- which they're already mostly not breaking anyway.

That sounds like a whole bunch of major drawbacks in exchange for very little benefit.  Which I presume is why it hasn't been done.

On 12/30/2018 at 10:39 AM, Tomator said:

If the interfaces were versioned, mods would still be loaded, parts displayed ships could be edited and even fly - some part would cease function yet they still could be targets of a rescue missions - in worst case.

Now, there you're describing a completely different problem-- i.e. "what if I've launched ships that contain parts from a mod, and then the mod goes away".  Right now those ships become unloadable, and you're wanting a solution that would allow them to be loaded to some degree.  That's a perfectly reasonable thing to want-- and there are engineering solutions that could enable such a scenario.  I think that would be a reasonable thread for the "suggestions" forum in its own right.     Right now off the top of my head I can think of some potential solutions to that, and they wouldn't even necessarily be all that complicated to implement.  (I think.  The devil's always in the details, of course.)  But it has nothing to do with your idea about "interfaces" -- it's a separate problem.

[Stoney3K]

6 hours ago, Snark said:

That's certainly a possible way to organize software.  It's a way that software often is deliberately engineered to do, precisely to make it possible to maintain compatibility-- shared software libraries do that sort of thing all the time, for example.  But KSP is not built that way.  It never has been.  Its innards are mostly exposed-- mods can get at nearly all of the game's code.  There is no interface.  That's why KSP is so incredibly moddable-- precisely because mods have the ability to get at everything.

Also:  If the KSP developers wanted to change the interior design of KSP-- to offer only a very restricted, dumbed-down public API, and hide all the internals-- then that would greatly improve version compatiblity of mods, yes... but it would also make the game much less moddable and it would be a lot harder for mods to be able to do any arbitrary thing they wanted.  Also, note that maintaining that sort of interface is a large, expensive engineering feature-- it requires tons of time, both from the engineers and from API designers, technical documentation writers, etc.  It's a major feature to deliver-- which means providing that would take precious engineer-hours away from other stuff, like implementing shiny new features, fixing bugs, etc.

It would be great if KSP offered some kind of consistent API to allow modders to make their stuff work, somewhat independent of KSP updates. But that would only benefit the modders and not the players in the long run, so it would probably not be high on Squad's priority list.

Also, a consistent API means you need to document it (or even, write the API from the documentation and not the other way round) which would be a very time-consuming task, and implementing such a thing now, in an existing version of KSP would be a huge afterthought which would also imply keeping everything backwards compatible with current mods. I really can't see that happen.

Such a thing would be great for a KSP version 2.0 (just as Flight Simulator implemented SimConnect) but probably no earlier.