Constant updates - modders still happy?

[p1t1o]

Hi All,

How are modders feeling about needing to update their mods every time there is an update?

Have many mods been left by the wayside due to modders moving on to other things?

Modders are the ones that really make KSP come alive IMO, no disrespect to Squad at all, and I hate the idea that as updates come in I might have to discard some of the mods that I like.

It takes me many hours to remake my mod build each update, is every projected updated expected to break mods?

It makes sense that bug fixing and other code optimisations affect mods, but will there come a time where updates are more content-based (eg: the upcoming DLC) that wont be expected to break mods?

Or should I treat the list of available mods as an ever-changing ecosystem with no two updates having the same selection available?

Because I really dont like the idea that some really well established, mature mods (and frankly, many younger, smaller, but extremely useful/fun mods), might disappear of the compatible list. Modders cant be expected to maintain their mods forever. I hate being in a constant state of waiting for the next big shake-up.

Thanks!

P

[Streetwind]

Now I'm not a modder - I just help out a bit occasionally - so I'm not really someone this thread is addressed to. But I'd like to say at least one thing:

"Constant" updates? This game is post-release. It was updating much faster before 1.0. Let's not needlessly dramatize things  

[stibbons]

• Version 1.3 released 25th May 2017.
• Version 1.2.2 released 6th December 2016.
• Version 1.2.1 released 1st November 2016.
• Version 1.2 released 11th October 2016.
• Version 1.1.3 released 21st June 2016.
• Version 1.1.2 released 30th April 2016.
• Version 1.1.1 released 29th April 2016.
• Version 1.1 released 19th of April 2016.

Five releases in a year? HELP WE'RE DROWNING UNDER CONSTANT UPDATES.

 

[p1t1o]

I guess I didnt mean "constant" as in "often" but in the way that as soon as an update arrives, there is something to be fixed or added, and they commonly require mods to be updated. Since 1.0 there hasn't been a period where nothing needed fixing and looked forward to in the next update. And I wouldn't hold it against anyone who has created a mod, to be frustrated at having to revise it even just a few times in a year - what if they are into something else by now?

Im not trying to say there is anything wrong, just asking a few questions, I mean no offence

 

 

Edited June 2, 2017 by p1t1o

[stibbons]

So what you mean is how do people who voluntarily write code against a changing API feel about the API changing. Fair enough.

Edited June 2, 2017 by stibbons

[Gordon Fecyk]

3 minutes ago, stibbons said:

So what you mean is how do people who voluntarily write code against a changing API feel about the API changing.

Last I checked, that is every operating system ever since 1994, and more so since 2007. A developer either changes with the API changes, or moves on to a different platform, or stops developing. Otherwise we'd all still be using Commodore 64s and we'd have this:

 

[SchwinnTropius]

1 hour ago, Gordon Fecyk said:

Last I checked, that is every operating system ever since 1994, and more so since 2007. A developer either changes with the API changes, or moves on to a different platform, or stops developing. Otherwise we'd all still be using Commodore 64s and we'd have this:

 

To be fair, that does look like a lot of fun to play.

[Nertea]

Modders are never happy :P. 

[Benjamin Kerman]

I personally dont mind the updates, because the brunt of the work happens when you are first getting it to a release. Beyond that, its just new features and bug fixes, along with the everysooften api change.

And the real thing is, i dont mind, because i enjoy doing it.  

[HeyThisIsntFallout]

8 hours ago, Gordon Fecyk said:

Last I checked, that is every operating system ever since 1994, and more so since 2007. A developer either changes with the API changes, or moves on to a different platform, or stops developing. Otherwise we'd all still be using Commodore 64s and we'd have this:

 

This is why I use the internet, nothing else matters

[HebaruSan]

Making the actual updates is trivial (partly because the API changes are generally cosmetic and unnecessary, but that's a gripe for a different time ), so you can count me as "happy" if it's just a question of being able to maintain my code privately for my own use.

The real problem is the whirlwind of chaos unleashed everywhere else in the modding ecosystem. When users report crashes due to incompatible mod versions (that didn't really need to be made incompatible by stock code changes), this adds a lot of noise, wasting support time with non-issues and potentially masking real bugs, both for modders and for SQUAD. The methods that we should be able to use to deal with this do not always work; several mods hosted on Curse have been incorrectly marked as compatible with 1.2.2 because there was no 1.3 option at the time of upload, so even people taking the conservative route of sticking with the old version aren't safe! Similar things can happen if a mod author or CKAN metadata maintainer makes a simple typo in their AVC files. All the mod threads are taken over by announcements of or requests for updates, which is also more noise when compared with real features or fixes. As long as the public API continues to be made incompatible with each release, it's not honest of us to upload mods with installation instructions that don't include a big red caution sign explaining to new players what will happen at the next update. And yes, it bothers me that old mods go away. It's not even a matter of their authors quitting out of frustration; nobody stays active in any community forever, and if there's an update after you move on, then KSP's mod portfolio has just gotten weaker.

So yes, I would like to see a commitment to preserving stock's public APIs, but not because I'm "unhappy" at having to do a simple search-replace and publish a new version.

[Alshain]

@p1t1o To answer your question, I have no problem with it.  Updates have actually slacked off and most modders who have been around for a while are accustomed to Early Access when we really did have constant updates, a real update, every month or two.  Realistically we've only had two updates in the last year.  Incremental bug fix patches don't typically break mods so the only updates we've had are 1.1, 1.2, and 1.3.  Even when to do push major updates, it's not as if mod authors have to re-write their mod from scratch.  Many of the times when a mod does break, all it needs is a reference update (recompile against the new DLL) without actually changing any code at all.  It's actually pretty infrequent that a massive breaking patch comes along, 1.2 was an engine change, so that is expected.

Edited June 2, 2017 by Alshain

[Alshain]

On 6/2/2017 at 4:21 PM, HebaruSan said:

So yes, I would like to see a commitment to preserving stock's public APIs, but not because I'm "unhappy" at having to do a simple search-replace and publish a new version.

The problem is that it isn't really a public API.  Squad has occasionally added something to help mod developers, but they don't really actively support modding.  (That's not to say they don't encourage it!)

In this case they just leave the members public and let modders do with it what they will.  But it's not an API in the general sense.  If it were an API you would be much more careful about changing things and proper use of deprecation tags to prevent breaking things all at once with little warning (other than the beta versions they have been doing).  This is the sort of thing that Unity does, but not KSP.  The KSP devs do what they need to do for their development and aren't concerned if they break mods on a whim.  That isn't an API.  As I said earlier, that doesn't mean they will break, but they aren't going to hold back to prevent it either.

Edited June 2, 2017 by Alshain

[HebaruSan]

1 hour ago, Alshain said:

The problem is that it isn't really a public API.

Semantics, vOv. The problems are caused by the way SQUAD does development, and they could choose to stop causing them, or not.

[Alshain]

On 6/2/2017 at 6:41 PM, HebaruSan said:

Semantics, vOv. The problems are caused by the way SQUAD does development, and they could choose to stop causing them, or not.

It's not semantics.  An API is a separate piece of code which provides access to the underlying code.  It's in the very definition Application Programming Interface.  It is a special piece of code which outside programmers use to access the underlying code which has a private designation and cannot be accessed from the outside.  KSP modders directly access the underlying code, it is marked as public, and there is no API.

[linuxgurugamer]

All of my mods, 77 of them, and I only had to change code in 3 or 4 of them.

 

[Moach]

keep in mind - only major releases are actually expected to cause mods to fail completely - that's the second number left-to-right in the version tag

say, going from 1.2.1 to 1.2.2 should not normally cause any major issues (not saying it doesn't happen, you know... Murphy's law) - but usually one can even get a very large percentage of mods across between a major update, like 1.2.x to 1.3.x, and no big deal

 

problem is -- there are a FEW mods, which do fail - and a few of those few (Firespitter, for one) happen to be a dependency for many others - some of which, may even be a dependency for a third layer of fail....  THAT's where trouble starts

as far as parts-only packs go, they are more or less impervious to aging - and one can run packs which have been around for eons and get away with it fine (albeit inefficiently, since newer parts can make better use of more recent and streamlined parts of the API)

 

but let this fact never be lost from reckoning:  THERE IS AN API, and it has been deliberately designed to facilitate and allow mods as widely as possible - sometimes this was extremely difficult to achieve, I recall my brother ranting - but it had always been, and hopefully shall continue to be an overriding priority in all development cycles, that if there's anything a player might look upon and think "that could maybe work better...."  that he has all the resources to implement whatever he wishes without having to resort to hacking the game

that is what allows mods to remain as mutually-compatible as possible, even in the face of updates throwing everyone off their feet in a jostle every now and then

but take a game that actually DOESN'T have an API, and the difference is massive - for example, several years after the last "official" update to IL2:1946, most mods are allergic to each other unless painstakingly assembled into a pre-built collection (and good luck adding stuff on top of those) - when the team who still makes updates for that game do release a new one, it takes months, even years - definitely not days, before ANY mods port over - and any compatibility across them has to start again from scratch

 

KSP mods take days, months at worse.... by then the (also deliberately devised) must-be-open-source policy ensures that anyone who's less patient than he is handy has all the freedom to solve his own problem, and publish the solution, provided he sticks to the original licensing terms

 

 

Edited June 3, 2017 by Moach

[HebaruSan]

45 minutes ago, Alshain said:

It's not semantics.

Yeah, it is. You're saying "there is no API" (and disputing the definition of "API"), and I'm saying "the API could be maintained in a way that doesn't break mods." The consequences are the same; mods break on updates, but that could be avoided.

[Alshain]

4 minutes ago, HebaruSan said:

Yeah, it is. You're saying "there is no API" (and disputing the definition of "API"), and I'm saying "the API could be maintained in a way that doesn't break mods." The consequences are the same; mods break on updates, but that could be avoided.

In order todo that they would have to first develop an API though.  That is a project in itself.  There is no way to effectively make changes to a project like KSP without occasionally altering the method definitions if you don't have an API.  Developing an maintaining an API would require another team of developers, which isn't practical, especially given that until 3 days ago it was an indie title.

[artwhaley]

12 hours ago, Gordon Fecyk said:

Last I checked, that is every operating system ever since 1994, and more so since 2007. A developer either changes with the API changes,

Yes...  things change with MAJOR OS rollouts every 5 years or more...   though to be fair WinXP applications, unless they did something VERY low level, tend to still run in Windows 10.   

The way Operating Systems get around this - multiple versions of .DLLs.  Windows carries DLL's for .net 3.5, 4.0, 4.5, 4.51, 4.52.... etc....   So when I pull up an application that's linked to a .Net version other than the latest, it's no big deal.  But that's a very different animal.   

They COULD do something like create a KSP_API.dll that used reflection to grab all the publicly exposed bits and then provided them to modders...  then you'd link to the KSP_API.dll and then you'd only have to recompile when major versions came about and required a change to the API dll.  But...  really... even the relatively minor updates to KSP include new features that mod makers WANT to get their hands on.  So...  I think most of us prefer to have full access to everything and just deal with the updates as they come.   

As to mods dying because of it - all the more reason for mod makers to keep current code on their public repo's and to remind us to choose licenses that allow others to continue where we leave off when we get busy.   It really takes the meagerest coding ability to recompile a mod.   Sometimes it just WORKS when you click the button.  Most other times it gives you a dozen error messages that are self-explanatory...  sorta... once you look up the vocabulary!   

Also, to your other question - it would be TOTALLY possible for Squad to release an update that DIDN'T involve a new version of those few files we actually link to, and that would be an update that didn't break mods.   So they COULD release a content only update at some point - that just changed parts/contracts/etc.   But if there are mechanics changes at all...  it's going to require recompiling.  Maybe not a lot of editing, but definitely hitting the compile button.   

 

 

 

[HebaruSan]

42 minutes ago, Alshain said:

There is no way to effectively make changes to a project like KSP without occasionally altering the method definitions if you don't have an API.

I guess this argument hinges on the meaning of "occasionally." Yes, there can be structural changes where an old function simply can't be supported anymore. Let's say they replaced patched conics with N-body physics; then Orbit.referenceBody would no longer make sense to have because spheres of influence are no longer a thing and your ship is always affected by multiple bodies' gravitation. Of course in a case like that, you have no choice but to break compatibility, probably in a huge number of places.

That's not how KSP operates currently. Let's take the two changes that broke my mod in 1.3, not because I'm particularly sore about them (I'm not, I swear!), but because I know the details well. (I can say the situation is very similar for Procedural Parts because I prepared a pull request to update it to 1.3 on a lark).

Rather than removing CelestialBody.theName, it could have been changed to return CelestialBody.displayName. Not functionally identical, but the function still exists and will be good enough in practice. The mod author has the option to update to newer functions, but in the mean time users can still load the game and even use the mod.

Rather than removing MultiOptionDialog(string msg, string windowTitle, UISkinDef skin, params DialogGUIBase[] options), it could have been changed to call the new MultiOptionDialog(string name, string msg, string windowTitle, UISkinDef skin, params DialogGUIBase[] options) and pass windowTitle in the name parameter, which is how the old version worked and therefore functionally backwards compatible (windows with the same title conflicted with one another, presumably the reason a name parameter was added in the first place).

There you go, a 1.3 release that would have had at least one more mod work without changes, probably many more than that, for on the order of 10 minutes of development effort. Apply that practice across the board for public functions, and only mods that are truly functionally incompatible with the new release would break (i.e., the N-body physics example above).

Edited June 3, 2017 by HebaruSan

[Alshain]

@HebaruSan That is a procedural difference between an API, and internal methods that are simply left public.  An API would have flagged CelestialBody.theName as deprecated and had it return CelestialBody.displayName, only removing it a few versions later after mod developers were sufficiently warned to stop using it. 

Squad isn't developing an API though, they are developing a game... if they have no more use for it, it gets removed.  They aren't developing for mod makers, they are developing for the players and what is easiest for them to do that.

[HebaruSan]

5 minutes ago, Alshain said:

@HebaruSan That is a procedural difference between an API, and internal methods that are simply left public.  An API would have flagged CelestialBody.theName as deprecated and had it return CelestialBody.displayName, only removing it a few versions later after mod developers were sufficiently warned to stop using it. 

Right. It would be nice if they started doing that.

5 minutes ago, Alshain said:

Squad isn't developing an API though, they are developing a game... if they have no more use for it, it gets removed.  They aren't developing for mod makers, they are developing for the players and what is easiest for them to do that.

This thread is asking modders how they feel about updates. My response is that it would be nice if SQUAD preserved compatibility. What is or is not an "API" or what SQUAD is or is not developing frankly is irrelevant. The effect on users and modders is the same, and my attitude toward updates is the same, regardless of your definition of "API" or what you think SQUAD's deliverables are.

[Gordon Fecyk]

38 minutes ago, artwhaley said:

Yes...  things change with MAJOR OS rollouts every 5 years or more...   though to be fair WinXP applications, unless they did something VERY low level, tend to still run in Windows 10.   

I wish this really were the case. I've been doing this nonsense for over twenty years and I've seen a lot of garbage still passed off as mission-critical, written like it was for Windows 95. As in all admin all the time, turn-off-UAC-or-else garbage. And even with Microsoft going whole hog with regression testing. Heck, even MS is guilty of this; it took them until Office 2003 before they got their own act together. It's embarrassing to see a point-of-sale register still needing local admin access just to run, plus needing full internet access, leaving simpleton cash register jocks open to social engineering: "Your credit card processing is at risk; no, don't call your IT helpdesk, install our software right now..."

...sorry. Twenty+ years in IT and dealing with morons is getting to me. Even WannaCrypt won't wake some of these folks up. The rules have changed so much since XP's release, but the frameworks for new rules were in there since Windows 2000 and vendors are still writing like it's 1995.

Having dipped a toe into basic part modding, I wondered what was going to happen with 1.3. Turned out to be not a big deal; I just had to spend some time reading, trying some things out and testing. Some things about ModuleResourceHarvester have changed and I'll need to re-tune some parts.

The point is, I'll deal with part module changes and text translations if I want folks to use my mod in 1.3. This is Squad's sandbox (now Take Two's sandbox) and I have to play by their rules. Just as Squad / TT need to play by Microsoft's rules if they want their game to run on Windows. Or Sony's rules on PS4.

[Maelstrom Vortex]

On 6/2/2017 at 11:22 AM, Nertea said:

Modders are never happy :P. 

But.. but.. tips man! Tips!