CompatibilityChecker Discussion Thread

[Rich]

I was toying with this idea last week but rejected it on the basis that my plugin probably will not be broken by version updates. However, the discussion in this thread had changed my mind, specifically the mention of accountability.

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.

While that might be true, it is a mod developer's decision to decide whether to give the user the decision or not.

[J.Random]

How about settings option instead of dialog window to disable this feature?

DISABLE_VERSION_CHECK_I_KNOW_WHAT_I_AM_DOING_AND_TAKE_FULL_RESPONSIBILITY_FOR_DECISION_PLEASE_PROCEED = True?

[Rich]

How about settings option instead of dialog window to disable this feature?

DISABLE_VERSION_CHECK_I_KNOW_WHAT_I_AM_DOING_AND_TAKE_FULL_RESPONSIBILITY_FOR_DECISION_PLEASE_PROCEED = True?

I like it.

[regex]

I like it.

I don't because it circumvents the entire purpose of doing this. I can just imagine the forum conversation:

"I CANT MECHJEB"

"TURN OFF THE VERSION CHECK HERE"

"IT BROKE WITH THE RT2 FIX THE BUGS!!!"

Under this scheme we'd probably see:

"I CANT MECHJEB WHEN IS TEH UPDATE"

"I CANT MECHJEB WHEN IS TEH UPDATE"

"I CANT MECHJEB WHEN IS TEH UPDATE"

Which is a damn sight better than a ton of false error reporting to the wrong mods, users passing around stories of how one mod broke another, etc... As ferram4 points out in the OP, a smart user who depends on the mod will just recompile it for themselves if it's taking too long for them.

Edited January 9, 2014 by regex

[lincourtl]

How about settings option instead of dialog window to disable this feature?

DISABLE_VERSION_CHECK_I_KNOW_WHAT_I_AM_DOING_AND_TAKE_FULL_RESPONSIBILITY_FOR_DECISION_PLEASE_PROCEED = True?

I could live with that.

[lincourtl]

While that might be true, it is a mod developer's decision to decide whether to give the user the decision or not.

Absolutely. It's the developer's choice of how considerate of the user they want to be.

[TBryson2]

(From an "outsider" looking "in") I think that is a great idea! I get (sort of) frustrated having to compare what I have, to what's out there because the author does not update the release date on the "item" or web page.

My question would be; what about the MOD's that affect other MOD's? It isn't always KSP that gets blamed, or is to "fault" (for the lack of a better explanation). How do "we" determine what's causing the issue? I think the above would go a LONG way to eliminate some of the equation.

And THANKS to all who take the time to make the MOD's for everyone. We DO appreciate it!

TB

[draeath]

You're never going to get rid of all the idiots, the goal is to reduce the number somewhat.

I fully support this, provided there is a way to continue - whether it's a dialog or an obscure ritual that must be performed on the first full moon of a new year.

I do have to say though, a big part of releiving the crappy-bug-report pain is having an actual bug tracker that people can see and submit to. Handling bug reports on a forum is like herding cats - never going to end well. It's so much easier to just mark "INVALID" and move on.

Bitbucket (and I presume github?) have bugtracking features, and if not it's not to hard to keep a flyswatter or bugzilla page up somewhere. Assuming you have hosting. If you don't, that's not your fault at all. Heck you should go all the way and use a project management tool anyway - no sense keeping your ideas and plans scribbled on a napkin when the tools software development houses use are available, right?

Edited January 9, 2014 by draeath

[regex]

I fully support this, provided there is a way to continue - whether it's a dialog or an obscure ritual that must be performed on the first full moon of a new year.

Here's an obscure ritual: Wait for the update patiently or compile it yourself. As ferram4 notes, this takes care of compiler errors (one way or the other) which comprise the majority of new version errors (if any).

I do have to say though, a big part of releiving the crappy-bug-report pain is having an actual bug tracker that people can see and submit to. Handling bug reports on a forum is like herding cats - never going to end well. It's so much easier to just mark "INVALID" and move on.

Bitbucket (and I presume github?) have bugtracking features, and if not it's not to hard to keep a flyswatter or bugzilla page up somewhere. Assuming you have hosting. If you don't, that's not your fault at all. Heck you should go all the way and use a project management tool anyway - no sense keeping your ideas and plans scribbled on a napkin when the tools software development houses use are available, right?

Personally I think this is more of a personal choice thing, much like this locking suggestion. From my point of view I would ask what else is a forum thread for a mod for, a big circle-jerk of praise? I mean, I can see bug trackers working well for larger, more popular mods but for something like what I write there's no reason to link to the GitHub tracker and tell all my users to "POST BUG HERE OR I IGNORE YOU" because the forum thread works perfectly well and, quite frankly, I don't want to look at GitHub any more than I have to. I managed a much larger software project for three years from a forum thread and did quite well, IMO.

[ferram4]

My question would be; what about the MOD's that affect other MOD's? It isn't always KSP that gets blamed, or is to "fault" (for the lack of a better explanation). How do "we" determine what's causing the issue? I think the above would go a LONG way to eliminate some of the equation.

The most effective way to deal with that is for users to provide more information about their issues, up to and including all the mods they're using and their version numbers, plus a full copy of the output_log.txt. Unfortunately, trying to get an entire modlist is often a problem, and most users don't seem to be aware that mods actually have version numbers. Finally, lots of users seem to try to be "helpful" or "smart" when they provide the output_log.txt and truncate it, possibly hiding the source of the error.

Honestly, the only true way to determine that it's two mods conflicting is that a bug appears only when those two mods are installed, but doesn't when either is installed alone the bug doesn't occur, with no other issues occurring whatsoever. The last part is significant because then you get the "deleting ModuleManager fixes the problem" issue.

I fully support this, provided there is a way to continue - whether it's a dialog or an obscure ritual that must be performed on the first full moon of a new year.

As regex pointed out, you can recompile it yourself. Ultimately, this is a relatively low barrier to entry IMO for a competent user, but does prevent the computer-illiterate from trying to mess with things they don't understand and possibly messing up their install (in the worst-case scenario). I also like the fact that rather than being some type of "official" GUI-approved circumvention, it involves having to reqork the source code (even the slightest), which should carry some weight for the vast majority of users; they're not relying on the modder to make sure it works at that point, they're taking it into their own hands and will be subject to the consequences.

I do have to say though, a big part of releiving the crappy-bug-report pain is having an actual bug tracker that people can see and submit to. Handling bug reports on a forum is like herding cats - never going to end well. It's so much easier to just mark "INVALID" and move on.

It's more the "common knowledge" of a certain mod causing bugs that I'm concerned about; it leads to lots of ill-informed, self-propagated bad "bugfixes" to float around the community, getting more people ticked off at us when they shouldn't be. Just look at what the majority of the community calls a gravity turn (45 degree pitchover at 10km) and then look at what a gravity turn actually is, then realize that this happens with everything the KSP community discusses. Including mod issues. It also might happen that I have a burning hatred of incorrect information being spread, and when it affects me somewhat directly I get quite annoyed.

[TMS]

Who'll be the first to write a mod that disables the version check code in other mods?

[sarbian]

Sorry about all those MJ users who whine about their rocket doing loops ferram4

I'll look into adding a proper gravity turn mode one of those days.

[ferram4]

It's not your fault for that one. The only thing I'd ask is that the ascent autopilot says "Executing pitch program" rather than "Executing gravity turn" or whatever it does currently, so it's not saying it's doing something it's not.

As for a gravity turn mode, that's seems kind of simple if you can get the rocket to point surface prograde. Have it wait until a set altitude, then switch to angle 5 degrees in the direction it has to go, then once the velocity vector is past that point have the rocket point surface prograde. There are certainly complications that I'm not thinking of here, since I don't know the MJ internals, but it seems doable using the already existing Smart ASS code.

[JordanL]

I wish it was easier to manage versions of a mod as a user. Updating mods is sort of a pain, especially when some maintainers don't keep super detailed change logs so I'm not sure if my problem has be patched or not.

[dewin]

Along these tangents, I've posted a suggestion for better addon management recently, which includes the notion of each mod having a "manifest" of sorts including its name, version, KSP-compatible version, license and some other metadata. This'd solve the version issue -- really, if a user wants to try to run an outdated mod they should be allowed to do so but it should be made clear that they shouldn't expect it to work.

[Greys]

Just a thought but what if....

Remote Compatability Check would query a server maintained by the creator or through a third party and updated by the creator, and would indicate if the version of the DLL they have is compatible with the version of KSP they're running as a boolean.

Said server would return null if it didn't know, prompting the check to fail and not store a value

... but how to store it such that users couldn't fiddle with the value in a cfg file... maybe some kind of checksum unique to the two versions and the user's machine?

eh.

[draeath]

I fully support this, provided there is a way to continue - whether it's a dialog or an obscure ritual that must be performed on the first full moon of a new year.

As regex pointed out, you can recompile it yourself. Ultimately, this is a relatively low barrier to entry IMO for a competent user, but does prevent the computer-illiterate from trying to mess with things they don't understand and possibly messing up their install (in the worst-case scenario). I also like the fact that rather than being some type of "official" GUI-approved circumvention, it involves having to reqork the source code (even the slightest), which should carry some weight for the vast majority of users; they're not relying on the modder to make sure it works at that point, they're taking it into their own hands and will be subject to the consequences.

My objection to this (requiring recompilation specifically) is that it requires one to have the compiler tools available and installed, and knowledge on how to use them. I am by no means an idiot, but I do not have these tools handy nor do I really have any wish to do so - I have no plans to touch unity etc for the foreseeable future. Take the compiling step out and it would be a different story (eg, interpreted like Python).

Edited January 10, 2014 by draeath
adding to quote for clarity

[ferram4]

You do realize that all you need to compile code for a KSP mod is Visual Studio, have the project reference Assembly-CSharp.dll and UnityEngine.dll in KSP_Data/Managed, and compile the dll, right? All you need is a C# compiler, which isn't hard to find.

[Majiir]

I've built a proof-of-concept compatibility checker. Here's a shot of it in action:

Some things to note:

• Checker code is present in both Kethane and KAS. Either of them can display the compatibility notice.
  
• The KAS checker executes first, but the Kethane checker is the one that runs. This is because the Kethane checker is a newer version, and the KAS checker lets it run. In other words, checkers perform version negotiation so that only the newest checker code will run. (If multiple copies of the same version of the checker are present, only one will execute.)
  
• Responsibility for disabling plugin functionality rests with each mod. (Notice the Kethane grid still present in the background.)
  
• Each mod also defines how compatibility is defined. A mod can define its own range of version compatibility or even do something more complex like check a webserver (as Greys suggested).
  
• All communication is done through reflection, so there are no DLL dependencies.

Now, I do not believe this code is ready for use in production. In particular, I haven't done much testing of the error handling in the reflection code, and the version negotiation must work. I also think that type names should be vetted before deployment.

The following is released for review purposes only.

/**
 * Copyright (c) 2014, Majiir
 * All rights reserved.
 */

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;

[KSPAddonFixed(KSPAddon.Startup.MainMenu, true, typeof(CompatibilityChecker))]
internal class CompatibilityChecker : UnityEngine.MonoBehaviour
{
    public static bool IsCompatible()
    {
        // TODO: Implement your own compatibility check here.
        return false;
    }

    /*-----------------------------------------------*\
    | IMPLEMENTERS SHOULD NOT EDIT BEYOND THIS POINT. |
    \*-----------------------------------------------*/

    private static int _version = 1;
    private static bool _ran = false;

    public void Start()
    {
        FieldInfo[] fields =
            getAllTypes()
            .Where(t => t.Name == "CompatibilityChecker")
            .Select(t => t.GetField("_version", BindingFlags.Static | BindingFlags.NonPublic))
            .Where(f => f != null)
            .Where(f => f.FieldType == typeof(int))
            .ToArray();

        // Let the latest version of the checker show the warning.
        if (_version != fields.Max(f => (int)f.GetValue(null))) { return; }

        bool done =
            fields
            .Select(f => f.DeclaringType)
            .Select(t => t.GetField("_ran", BindingFlags.Static | BindingFlags.NonPublic))
            .Where(f => f != null)
            .Where(f => f.FieldType == typeof(bool))
            .Any(f => (bool)f.GetValue(null));

        // Only run the UI checker once.
        if (done) { return; }

        _ran = true;

        String[] incompatible =
            fields
            .Select(f => f.DeclaringType)
            .Select(t => t.GetMethod("IsCompatible", Type.EmptyTypes))
            .Where(m => m.IsStatic)
            .Where(m => m.ReturnType == typeof(bool))
            .Where(m => !(bool)m.Invoke(null, new object[0]))
            .Select(m => m.DeclaringType)
            .Select(t => t.Assembly)
            .Select(a => a.GetName().Name)
            .ToArray();

        Array.Sort(incompatible);

        UnityEngine.Debug.LogWarning("[CompatibilityChecker] Checker running from " + Assembly.GetExecutingAssembly().GetName().Name);
        UnityEngine.Debug.LogWarning("[CompatibilityChecker] Incompatible mods: " + String.Join(", ", incompatible));

        PopupDialog.SpawnPopupDialog("Incompatible Mods Disabled", "Some installed mods are incompatible with this version of Kerbal Space Program and have been disabled. Please check for updates to the following mods:\n\n" + String.Join("\n", incompatible), "OK", false, HighLogic.Skin);
    }

    private static IEnumerable<Type> getAllTypes()
    {
        foreach (var assembly in AppDomain.CurrentDomain.GetAssemblies())
        {
            Type[] types;
            try
            {
                types = assembly.GetTypes();
            }
            catch (Exception)
            {
                types = Type.EmptyTypes;
            }

            foreach (var type in types)
            {
                yield return type;
            }
        }
    }
}

[draeath]

You do realize that all you need to compile code for a KSP mod is Visual Studio, have the project reference Assembly-CSharp.dll and UnityEngine.dll in KSP_Data/Managed, and compile the dll, right? All you need is a C# compiler, which isn't hard to find.

Yes (though the dll specifics I did not, as I've not done plugin development myself), though I find requiring someone to install MS Visual Studio to be unacceptable.

For one, they may not even be able to do so! To say nothing of the bloat required for one little thing. It would be different if they had it around for other uses, but you have to admit that installing such a thing to even test if a mod behaves correctly on a "nonsupported" version is a bit much... from MS, VS2012 requires 10gb for the base install plus another 600mb per language pack.

Compare that to just a few config values, such as:

PROTECT_ME_FROM_MYSELF
{
    // if you touch these, NO SUPPORT FOR YOU
    // seriously, if you complain after changing these
    // we will publically ridicule and ostracize you endlessly.
    ignore_ksp_version = 0
    i_know_what_i_am_doing = 0
    seriously_i_really_do = 0
}

No matter what you do, you're not going to be able to get rid of any idiots that remain after that. They will find a way to annoy you. Trust me.

Edited January 10, 2014 by draeath

[ferram4]

@Majiir: That looks really cool Majiir. Only thing I'd suggest is that the window's title say, "Incompatible Mods Detected" and mention in the pop up that there may be side-effects of leaving the code available.

Other than that, I'm not sure exactly how I would implement that code into a mod; would I simply copy the compatibility checker code over into the FAR source, add my disabling code to it, and it would work (in the final release)?

@draeath: Then they can use MonoDevelop instead; ultimately, trying to force a plugin to run with a possibly incompatible version of the underlying software falls more into "software development" than simple user stuff. And I'd rather not set the bar so low that it can be circumvented using a change to a config somewhere, since that defeats the purpose of this.

I can see exactly how your config option will play out:

Some people will disable the check, and that will be fine. Others will download a "special" config from someone else that "makes <MODNAME> work in KSP <VERSION>"" without knowing what it does. Then they get issues, they complain and then get super, super pissed when the modder doesn't provide support for them, after all, they didn't change anything. No one will blame the 3rd party source of the config, they'll blame me. For giving them the option to disable the check.

Edited January 10, 2014 by ferram4
addressing draeath's additional points

[Majiir]

I am also a big fan of tamper-proofing the system to the point that recompiling is the only option.

That looks really cool Majiir. Only thing I'd suggest is that the window's title say, "Incompatible Mods Detected" and mention in the pop up that there may be side-effects of leaving the code available.

What do you mean by that last bit? That some parts of the mod might not be properly disabled, or that the mod should be uninstalled? (Both?)

Other than that, I'm not sure exactly how I would implement that code into a mod; would I simply copy the compatibility checker code over into the FAR source, add my disabling code to it, and it would work (in the final release)?

You copy/paste, fill in your implementation of IsCompatible (which should check the current KSP version against a known working version, or check a webserver, or do something) and also write your own code to disable features in the event IsCompatible returns false. Note that you can do this at any time. If your mod runs some tasks earlier than the main menu, you could check IsCompatible early on to enable/disable features and then the warning will appear in the main menu.

[draeath]

Fair enough, you guys are the bigshot plugin developers, I only get to watch from the sidelines Just offering my opinion on it. As stated, I really like the idea at the core, just disagree with how far you want to take it.

[Majiir]

Fair enough, you guys are the bigshot plugin developers, I only get to watch from the sidelines Just offering my opinion on it. As stated, I really like the idea at the core, just disagree with how far you want to take it.

I release updates within minutes of new KSP releases, and yet I still get weeks of support requests because people are running an old version. Some people insist on doing it because they don't like a new change or they want to maintain compatibility with something elseâ€â€but, of course, they demand I fix the problems it causes. Nobody is advocating that every mod implement the greatest possible restrictions, and every mod can implement details like disabling and version checking slightly differently.

The reason a single implementation is useful is it allows for a UI like the one I posted. It looks like KSP itself is detecting mod issues and disabling them. I did something similar for Kethane months ago when I had a flood of issues from people installing it into the wrong folder:

Most users seem to think that KSP, not Kethane, is displaying this warning. It's a subtle but powerful way to give some authority to the message.

[ferram4]

What do you mean by that last bit? That some parts of the mod might not be properly disabled, or that the mod should be uninstalled? (Both?)

Mostly the first one, with the suggestion of the second. For example, ModuleManager will likely still run even if FAR is disabled; since FAR needs the wing aero parameters applied by ModuleManager, it will break the stock wings completely.

You copy/paste, fill in your implementation of IsCompatible (which should check the current KSP version against a known working version, or check a webserver, or do something) and also write your own code to disable features in the event IsCompatible returns false. Note that you can do this at any time. If your mod runs some tasks earlier than the main menu, you could check IsCompatible early on to enable/disable features and then the warning will appear in the main menu.

Okay then, just making sure. This seems like the kind of system that can easily break everything if implemented wrong.

Fair enough, you guys are the bigshot plugin developers, I only get to watch from the sidelines Just offering my opinion on it. As stated, I really like the idea at the core, just disagree with how far you want to take it.

You make good points, but IMO the options you want simply allow the existing problem to continue, or worse, for an unsuspecting user to get a 3rd party config that "fixes" the compatibility check problem, but leads them into the actual compatibility problems, and then they get angry because they don't get support due to the changes to their config file. It adds the possibility for modder-mod users relations to go really, really far south just after an update, particularly for something like MJ or RemoteTech, which need quite a few changes to maintain compatibility every update.