CompatibilityChecker Discussion Thread

[ferram4]

The latest version of CompatibilityChecker can be found in this post. Be aware that it is not a separate plugin, but a piece of source code intended to be implemented in a plugin. It is intended for use by modders for easy implementation of mod compatibility checking and to make displaying these incompatibilities clear to users.

The following thread covers the discussion over the extent and implementation of the CompatibilityChecker utility used to warn users of incompatible mods in their installs. The resulting code (by Majiir) can be found in the above link; the rest of the thread is left as it was for historical purposes.

Voluntarily Locking Plugins to a Particular KSP Version

---------------------------------------------------------------------------

So after dealing with the recent wave of support requests following the update to KSP v0.23, I've come to an amazing, and yet unsurprising conclusion: the average mod user is completely unaware of the fact that plugins can be incompatible with different versions of KSP. I had thought that it was somewhat common knowledge that updates to the underlying software could break plugins, but apparently it isn't. Unfortunately, plugins that handle the upgrade gracefully only make things more confusing. And this leads to three big issues for modders and mod users following an update:

1. Users suffer from compatibility issues that could be easily solved by updating the plugin or waiting for a new update.
   
2. Modders get a huge number of bug reports entirely due to compatibility issues, making the standard mod support responsibilities even more frustrating than usual, as well as possibly burying bug reports in the most recent version that should actually get the modder's attention.
   
3. Due to the strange ways that compatibility issues arise, bugs are blamed on the wrong mod, causing two major effects:
   
   • "Common knowledge" that a certain mod causes a certain bug, even though it does not; this causes a large number of bug reports to the wrong modder as well as damaging their reputation, which is essentially all we get out of modding.
     
   • Users attempt to "fix" their installs in foolish ways (for example, deleting ModuleManager_X.dll) because it "fixes" the issue, but unknown to them, causes others; this will simply lead to more issues requiring support.
     

However, there is a way around this; we have access to the game version through the Versioning class. Therefore, I propose that we shift towards having each plugin check the version number against the version that it is compatible for. This would be done by hardcoding the check into the dll, like so:

if(Versioning.version_minor != 23)
{
  AlertUserAboutIncompatibility();
  TurnOffAsMuchOfPluginAsPossible();
  return;
}

Convenient Nameless Other Person: But Ferram, doesn't this restrict the plugin needlessly? What if it happens to work in a new version of KSP?

Sure, it restricts it, but that can be easily circumvented by recompiling the source code. Most importantly, recompiling means that someone has to take responsibility for it working, as well as taking the time to fix any compiler errors that pop up. If a random user decides to simply recompile the code referencing the new game files and changing the version number and it works, good for them, but a new version will probably be up changing the version restriction anyway. If it doesn't work, then the restriction justified itself, and anyone trying to use the broken version should be able to realize that they're playing with fire.

The key thing is that the user gets a message saying, "This plugin will not work because you updated the underlying software; you should go and update the plugin to be compatible; if a compatible version isn't out, you'll have to wait until the issues can be sorted out," which should make sure that the modder doesn't get inundated with compatibility issues well after KSP has been updated. Further, since it does require recompiling the dll, someone has to deal with the compiler errors (which have been the source of a lot of bugs that I've seen) and take responsibility for any runtime issues that might occur.

That said, I don't think this is something that should be forced on modders, rather, something that should be encouraged, like not using GOTOs everywhere. The average modder is more than capable of telling if their plugin is likely to break during a KSP update, and if so, they should take it on themselves to lock it down to that version of KSP so that somewhat foolish users can be warned about compatibility issues and so that other modders don't have to deal with bug reports caused by a 3rd party mod.

Anyway, those are my thoughts, mostly caused by seeing a large number of complaints blaming FAR for things it doesn't do / ModuleManager getting heat for working properly, but breaking when other plugins include broken code / general mod user foolishness.

Edited July 15, 2014 by ferram4

[dlrk]

Your frustration makes sense, but I think a warning message is enough, especially since some developer don't open their source code.

[ferram4]

All the source code has to be available if it's on the forums. Further, no license can ban compiling the code for personal use, so even if Kethane broke nothing stops someone from modifying it and recompiling it for themselves; they just can't share it.

Edited January 9, 2014 by ferram4
Can != can't

[dlrk]

I wasn't aware about the source being required, where can I see that rule?

[Greys]

I fully support any action that reduces the amount of time modders have to spend dealing with nonsense, but wouldn't it be a marginal addition to the complexity if you were to instead do

if (Versioning.version_minor != 23)
{
  AlertUserAboutIncompatability();
  if (QueryUserToAbort() == True)
  {
    TurnOffAsMuchOfPluginAsPossible();
  }
  return;
}

This way users are informed in a way that they better not be able to ignore; and given an in-code option to ignore it; also probably a lecture on how it's probably not going to work right so don't go complaining to George, cuz George don't want your outdated sass.

[Majiir]

I've had these same thoughts recently, and my experiences have mimicked your own in past updates. I fully support this. I'll plan on adding this to the next Kethane release. (Harass me if I don't!)

If anyone has concerns about mods doing this and then going unmaintained, remember that while some KSP updates don't break mods, many do. If a mod is unmaintained, it's at risk of not working, plain and simple. Whether the mod becomes totally inoperable in one update or three is irrelevant to this fact.

[hoojiwana]

I wasn't aware about the source being required, where can I see that rule?

http://forum.kerbalspaceprogram.com/threads/30064-Community-Rules-October-27th-2013

5.2 Addon licensing

All addons, plugins and similar works (such as code, textures or models) posted on the services as meant in 1.1 must be accompanied by the source code (if applicable) and a license in both the post and the download file. Any works derived from addons, plugins and similar works, if permitted, must attribute the original work and provide proof of rights to use the original work.

[ferram4]

@dlrk: Plugin Posting Rules and Stuff. First big rule.

@Greys: If you tell them that they might be able to ignore the issue and get away with it (which is essentially what that does) the average user will try to ignore it, and then rage when it doesn't work. It sounds nice, but I think it fails when put up against general human stubbornness.

@Majiir: Glad to hear it! More people on board, the better.

[dlrk]

I'd say this is a good idea then, but only if accompanies with a permissive license that allows for it to be adopted by a new maintainer.

[Greys]

I'd say this is a good idea then, but only if accompanies with a permissive license that allows for it to be adopted by a new maintainer.

This is completely unrelated to the debate (is this even a debate, everybody is agreeing) at hand, please don't destroy the thread by turning it into yet another smoldering remains of uninformed nobodies trying to decide how we license our work based on reasons that won't apply to them anyways.

[Majiir]

To reiterate Greys' statement without invoking so much prior knowledge on the subject: Licensing is irrelevant to this discussion because if a mod is maintained, it will remain compatible; if it is not maintained, it will cease working anyway. This is a way to improve the user experience and reduce the support load (and sometimes harassment) that modders have to handle in one stroke.

[regex]

This is a great idea. I don't know if my mod really needs this, but I'm doing it on principle at the very least.

[ferram4]

It might make sense for us to come up with a sort of universal code for this, with similar looking GUIs and text. Seeing the same message from multiple plugins, with only a few words changed might give the message more weight than unique windows popping up. Especially since then it can be made publicly available for all plugin authors so that it's a simple copy-and-paste the code + change some strings to implement into their mod.

[regex]

"<Mod Name><Mod Version> is not compatible with Kerbal Space Program <KSP Version> and will be disabled. Please check for a new version of <Mod Name>."

The function names you have there work pretty well.

[NathanKell]

Makes a lot of sense! I'm in too.

[ferram4]

@Regex: Seems good, but also add a click-able link to the forum thread in the GUI so that people don't have to search for it.

[regex]

@Regex: Seems good, but also add a click-able link to the forum thread in the GUI so that people don't have to search for it.

Good idea. I also suggest everyone standardize (Edit) the dialogue(!) on HighLogic's skin; much as I hate it, it'll make it look that much more official.

E: @ferram4 Yeah, I meant "everyone" in the "we should" sense, sorry that wasn't clear.

Edited January 9, 2014 by regex

[ferram4]

Part of my desire to make a sort of "official" version is so that new modders can also get in on the version-locking. It would really suck for users to get used to the idea of incompatible (or possibly incompatible) mods yelling at the user to update, but then some new guy comes along with a cool plugin and doesn't include that and gets hell for not including the feature, especially if he doesn't know how to include it.

I'd also suggest standardizing this to happen on the Main Menu, so that users don't have to get into the game for the issue to come up, since having one pop up in the Flight scene, another in the VAB / SPH, another in the Space Center would get irritating. Especially irritating for the user who decided to close KSP and update each mod that prompted them.

[sarbian]

Anyway, those are my thoughts, mostly caused by seeing a large number of complaints blaming FAR for things it doesn't do / ModuleManager getting heat for working properly, but breaking when other plugins include broken code / general mod user foolishness.

So true.

I'm in too.

[lincourtl]

My two cents as a user: While I agree in general, the implementation as described -- literally locking out the plugin -- would make me very angry, since I should be able to decide whether I want to continue using something which may or may not break my game.

The better implementation, I think, would be to have a single dialog appear on the start screen (the launcher would be even better but not everybody uses that) listing the plugins that are out of date and a stern warning.

[Greys]

My two cents as a user: While I agree in general, the implementation as described -- literally locking out the plugin -- would make me very angry, since I should be able to decide whether I want to continue using something which may or may not break my game.

The better implementation, I think, would be to have a single dialog appear on the start screen (the launcher would be even better but not everybody uses that) listing the plugins that are out of date and a stern warning.

Do you swear upon punishment of having your face removed that you nor anyone else will ever ignore the stern warning and complain to us about bugs when using this version of X with a version of Y that it's not expected to work with?

[sarbian]

lincourtl : some user are able to understand that when they use a plugin made for .22 in .23 some thing can break. The important word is some

I have to deal with user who install their mod thr wrong way, use an old version and can't even take 5 min to read the last 2 page of the thread. In the first days after an update 2/3 of the post in the MJ thread are useless, and that's with me posting a working dev version in the first hour after .23 was available...

A popup you can bypass would only work for the user who already know that a new version is dangerous. Some user don't even read the damn message you wrote ...

In MM I have a popup that tell use that they have MM 1.3 installed and they need to delete it. This popup display the exact path of the file you need to delete. And yet today I saw 2 thread with people complaining about not finding why they had the popup (thanks ferram4 for replying to one of those )

Mods dev are wasting their time trying to debug problem some user create themselves.

[blizzy78]

I'm with sarbian and Greys here, in that people tend to not read messages. The issue must be forced.

Mods dev are wasting their time trying to debug problem some user create themselves.

... or other mod authors... *cough* NavyFish *cough*

Edited January 9, 2014 by blizzy78

[lincourtl]

Do you swear upon punishment of having your face removed that you nor anyone else will ever ignore the stern warning and complain to us about bugs when using this version of X with a version of Y that it's not expected to work with?

Hah! I swear by pain of having my mainsail permanently deleted that I would never ever complain about bugs in an out-of-date plugin.

lincourtl : some user are able to understand that when they use a plugin made for .22 in .23 some thing can break. The important word is some

I have to deal with user who install their mod thr wrong way, use an old version and can't even take 5 min to read the last 2 page of the thread. In the first days after an update 2/3 of the post in the MJ thread are useless, and that's with me posting a working dev version in the first hour after .23 was available...

A popup you can bypass would only work for the user who already know that a new version is dangerous. Some user don't even read the damn message you wrote ...

I hear you. In real life I'm a webdev so I know the frustration well. I also get tired of answering the same three damn questions over and over and over.

But I seriously think disabling out-of-date plugins is wrong. That's the kind of thing that causes me to add rules to my firewall to block certain apps from getting access to the internet.

I also dislike the idea of this code being implemented in every single addon for KSP since that just leads to bloat. Ideally this would be handled by a separate addon which scans folders in GameData for a specially named text file containing the versioning and repository info.

[regex]

I also dislike the idea of this code being implemented in every single addon for KSP since that just leads to bloat. Ideally this would be handled by a separate addon which scans folders in GameData for a specially named text file containing the versioning and repository info.

Any perceived bloat would be quite small, if at all noticable; the shared code for this sort of locking is quite simple to write. In fact, if no one does it by the time I'm home from work, I'll bang out a first draft myself.

As for the rest, I haven't had to deal with these problems myself here, but I am perfectly willing to alienate a few "smart" users to reduce the noise from "dumb" users. This also goes for my mod, which may interact with other mods in a bad way under a new version of KSP and cause problems for other mod authors.