Jump to content

Craft checking between KSP versions


Azimech

Recommended Posts

Right now I'm running 1.2.2 and 1.2.1 alongside each other. What I've noticed is that craft built or modified in 1.2.2 won't load in 1.2.1 because it says they're not compatible. A simple edit in the top of the craft file -changing the version to 1.2.1-  makes it work, at least with my rover.

Now I wonder if the version checker should be so rigid, especially between minor updates like this one.

I can imagine a lot of people might encounter such things on KerbalX, @katateochi. It happened to me at least once that a user came to me with a question.

Link to comment
Share on other sites

Well, obviously I can't speak for Squad, since I don't work there.  But speaking as a software engineer, I can totally understand the motivation.

A computer program is like a machine with many thousands of moving parts.  Each part needs to interact with many others, and it all needs to work flawlessly.  A subtle change in one part can cause completely unexpected changes in other parts.

3 hours ago, Azimech said:

especially between minor updates like this one

...this.  The implication here-- that "minor updates don't break things"-- isn't necessarily the case.  In software development, when you have a shipping product that lots of people are already using and you're proposing changing it in some fashion-- any fashion-- then you pretty much have to take the attitude that all software changes are guilty until proven innocent.

It's nightmarishly hard to change anything while guaranteeing that you don't break something else.  In fact, a lot of the time, it seems like it's practically guaranteed to break something.

That's why software producers have to spend time testing their software.  A lot.  QA takes incredible amounts of time and effort, and still can't catch all the bugs.  That's not because the QA folks are lazy or incompetent-- it's because they have an impossibly hard job.  I'm not employing hyperbole, here-- it's literally, mathematically impossible.  There are simply too many potential combinations and permutations of interactions to be able to test everything exhaustively.  Cannot be done.

Therefore, since it's impossible to test everything, you have to focus your resources on testing the most important things first.  Any simplifying assumptions you can make, to establish large areas that you don't have to test, is a huge win, because that frees up more resources to test the really important things.

So... say you're a software developer.  What's a really, really big time saver, that can be achieved simply and easily?

How about this one:  Data produced by a new version of the product does not need to be backwards-compatible with old versions of the product.

That's a hugely valuable assumption to be able to make.  Squad's making that assumption, here-- that stuff saved in 1.2.2 doesn't need to be openable in 1.2.1.  Why is that valuable?  Because it means they don't have to test that.  They have their hands completely full just testing the following:

"Does stuff that the player does in version N work in version N?  And does stuff produced in older versions continue to work in N?"

Not having to test the reverse-- "does stuff produced in version N work in older versions?"-- is a giant win, from a QA perspective.  (It's also a giant win from a development perspective:  the devs don't have to worry about "will the thing I'm doing here cause breakage in older versions of KSP?", which is tremendously liberating and makes things much easier to develop.)

Note that not all software developers can get away with this assumption.  Consider a product like Microsoft Word or Excel, for example:  there's an enormous installed base out there, and the company has to support multiple versions (not just the latest-and-greatest), because it's not a free or automatic upgrade to newer versions of the product.  And Word & Excel files are a commodity that users farm around a lot.  If Microsoft didn't make their file formats backwards compatible, and test it, they'd be shooting themselves in the foot-- millions of angry users who keep getting sent files they can't open.

Squad has taken the approach of "there's only one valid version of the game that's actively supported, and that's the current version."  That's something that they can do, and that's also something that they pretty much have to do.

They can do it because it's a game, and the upgrade-to-newer-version is free, and they've provided an automatic upgrade mechanism.  So they've given themselves an "out", there:  if anyone comes with a problem of "this thing in the old version is broken", then the answer is simply "upgrade to the newest version, then we'll talk".  Users are free to run the older version if they want to, of course, but that's a conscious choice on the user's part, so Squad doesn't have to take responsibility for that.

They pretty much have to do it because they're a small company with relatively few resources, and KSP is being run on a relative shoestring; they don't have Microsoft's gigabucks to play with.  If they had to deal with the interaction matrix of how all the different KSP versions play together, QA would become prohibitively expensive.

So although I can understand that a decision like this can be frustrating to a player... I still suspect it's the right strategic choice on Squad's part.  If they didn't put this strict restriction in place, there would be another cost:  they'd have to either cut back on QA resources making sure that the current version of KSP works well with itself-- leading to a buggier experience for everyone-- or else they'd have to skimp on the backwards-compatibility testing-- meaning that they'd get flooded with bug reports for incompatibilities, which would be another drag on their time and come at a cost of future feature work.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...