CompatibilityChecker Discussion Thread

[Greys]

It seems that, starting with #41, you're discussing some sort of "always online" DRM here. For free mods for DRM-free game. I guess Average Joe mod user like me will be forced to learn C# after all and actually review the code and build every mod by himself. Fun times.

I'm by no means advocating an always online system at all. The process I described uses as online check if available to override the lockout, and would attempt to make that check as few times as possible.

That is to say; instead of

if (currentVersion!=specifiedVersion) { fail }

if (currentVersion!=specifiedVersion) { try something else }

Because it is entirely possible that the DLL may work fine with the new version; if so the creator gets to check this and say on this service "yes, my version X does also work with KSP A, Z, Y, if a user tries to run the DLL in those versions, allow it"

[ferram4]

Anyway, imo you are missing a major selling point. Updating a dozen mods is hard for someone who thinks about mods once every KSP update, thus once every about 4-6 month. Even for me finding the latest versions of the few addons installed took a while. Why can't you at least pretend to help your users? For example by pointing them to the official source for those mods by providing click-able links.

I thought it was common to provide a link to the forum thread in the Readme? At least that's what I've always done. As for helping users, protecting them from the ever-present threat of KSP updates screwing up their mods seems like helping them out.

As for the "cfg or recompile"... if you are afraid of 3rd parties providing cfg fixes, you should also be afraid of the same for dll's that knock out the version check entirely, what would be even worse. Think i would prefer the dialog to be skip-able, but only with "annoying" user interaction (maybe re-typing a sentence?). It does give them a way to ignore the version check, so they don't have to look for that from "unofficial" sources, but also still a huge kick in the a** to update their addons. It would also allow it CompatibilityChecker to log that there are outdated mods, since at least output_log does not seem to mention assembly versions.

Every single time a KSP update has broken FAR the game-breaking bug was caught in the compiler. Every single time. At that point, a dll being redistributed doesn't bother me so much, because it would require the compiling user to fix the bugs. The alternative is that they reference the old KSP libraries to build the dll, at which point it'll quickly become apparent that the dll is broken and every single one of us can say, "This is why the version compatibility check is there; to prevent this. We tried to stop you from running into this, but you've insisted on bringing this issue on yourself." A config file change, or an in-game work-around would have to be coded in by us as an "intended" way to "fix" the issue; it seems harder to justify, "Sucks for you, you shouldn't have done that." What's the point of adding a button if they're not ever supposed to press it?

The only way that I could support an in-game work-around is if it requires the user to type out something ridiculous and over the top, like the below, in full:

I realize that I shouldn't be doing this. I am being foolish by insisting on using this plugin in a version of KSP it was not designed for. All the problems stemming from enabling the plugin despite the warning are my own fault, not <MOD_CREATOR>'s. If I enable it anyway I shouldn't complain to <MOD_CREATOR>.

I fully realize the above is heavy-handed, nasty and a pain to type out, but I get the feeling that the heavy hand might be necessary for the users I'm envisioning complaining about the compatibility issues if I ever decide to allow a non-compiling solution to the issue. A "simple" work-around I would be too likely to lead to people ignoring the message and complaining because "the mod didn't work," like all the people who asked for a confirmation dialogue for "End Flight," not realizing it was already there because they automatically went to click "Yes" and that their brain filtered that out.

That said, I probably wouldn't implement that particular wording; it's just too mean and nasty.

Edited January 11, 2014 by ferram4
Made the example text nicer; in hindsight it was too much, even as a ridiculous example. Emotion in arguing is not good.

[Majiir]

This is a more complete and better-documented version of CompatibilityChecker. It is not thoroughly tested, so I recommend you evaluate it with your specific compatibility function before deploying it in production. I highly recommend leaving all comments intact in case someone chooses to copy your implementation instead of coming to this thread.

The following is released under the BSD 2-Clause license.

/**
 * Copyright (c) 2014, Majiir
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without modification, are permitted 
 * provided that the following conditions are met:
 * 
 * 1. Redistributions of source code must retain the above copyright notice, this list of 
 * conditions and the following disclaimer.
 * 
 * 2. Redistributions in binary form must reproduce the above copyright notice, this list of 
 * conditions and the following disclaimer in the documentation and/or other materials provided 
 * with the distribution.
 * 
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR 
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
 * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
 * POSSIBILITY OF SUCH DAMAGE.
 */

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

/*-----------------------------------------*\
|   SUBSTITUTE YOUR MOD'S NAMESPACE HERE.   |
\*-----------------------------------------*/
namespace Compatibility
{

    /**
     * This utility displays a warning with a list of mods that determine themselves
     * to be incompatible with the current running version of Kerbal Space Program.
     * 
     * See this forum thread for details:
     * http://forum.kerbalspaceprogram.com/threads/65395-Voluntarily-Locking-Plugins-to-a-Particular-KSP-Version
     */

    [KSPAddon(KSPAddon.Startup.MainMenu, true)]
    internal class CompatibilityChecker : MonoBehaviour
    {
        public static bool IsCompatible()
        {
            /*-----------------------------------------------*\
            |    BEGIN IMPLEMENTATION-SPECIFIC EDITS HERE.    |
            \*-----------------------------------------------*/

            // TODO: Implement your own compatibility check.
            //
            // If you want to disable some behavior when incompatible, other parts of the plugin
            // should query this method:
            //
            //    if (!CompatibilityChecker.IsCompatible()) {
            //        ...disable some features...
            //    }
            //
            // Even if you don't lock down functionality, you should return true if your users 
            // can expect a future update to be available.
            //
            return false;

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

        // Version of the compatibility checker itself.
        private static int _version = 2;

        public void Start()
        {
            // Checkers are identified by the type name and version field name.
            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 execute.
            if (_version != fields.Max(f => (int)f.GetValue(null))) { return; }

            Debug.Log(String.Format("[CompatibilityChecker] Running checker version {0} from '{1}'", _version, Assembly.GetExecutingAssembly().GetName().Name));

            // Other checkers will see this version and not run.
            // This accomplishes the same as an explicit "ran" flag with fewer moving parts.
            _version = int.MaxValue;

            // A mod is incompatible if its compatibility checker has an IsCompatible method which returns false.
            String[] incompatible =
                fields
                .Select(f => f.DeclaringType.GetMethod("IsCompatible", Type.EmptyTypes))
                .Where(m => m.IsStatic)
                .Where(m => m.ReturnType == typeof(bool))
                .Where(m =>
                {
                    try
                    {
                        return !(bool)m.Invoke(null, new object[0]);
                    }
                    catch (Exception e)
                    {
                        // If a mod throws an exception from IsCompatible, it's not compatible.
                        Debug.LogWarning(String.Format("[CompatibilityChecker] Exception while invoking IsCompatible() from '{0}':\n\n{1}", m.DeclaringType.Assembly.GetName().Name, e));
                        return true;
                    }
                })
                .Select(m => m.DeclaringType.Assembly.GetName().Name)
                .ToArray();

            Array.Sort(incompatible);

            if (incompatible.Length > 0)
            {
                Debug.LogWarning("[CompatibilityChecker] Incompatible mods detected: " + String.Join(", ", incompatible));
                PopupDialog.SpawnPopupDialog("Incompatible Mods Detected", "Some installed mods are incompatible with this version of Kerbal Space Program. Some features may be broken or 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;
                }
            }
        }
    }
}

[TMS]

I'm generally supportive of a system that handles mod comparability - especially with SQUAD firing N3X15 and Spaceport 2 looking like another indefinite shelving. However, I'm not a total fan of what's being described here. Basic fact is that I should have the option of bypassing the block, after being appropriately warned. Having the ability to choose whether to leave, disable or re-enable mods should be in the users hands.

If you're concerned about current signal to noise ratio in support threads and think that this will improve it, then I think that's slightly short-sighted. All that's going to happen is that that the noise caused by inappropriate (and unsupported) usage will be replaced by noise caused by people asking how to circumvent, edit or recompile. Surely you must see that?

Maybe that won't happen for the bigger modding players who jump on updates quickly (much love), but I can see it being a problem with smaller mods whose authors implement this without thinking it through. Should they leave their project (as often happens), but the mod is still functional in the new version (as often happens), I can see those support threads becoming clogged with requests for instruction on how to circumvent.

Today's solutions are sometimes tomorrow's problems.

Or am I grossly misunderstanding?

[ferram4]

Basic fact is that I should have the option of bypassing the block, after being appropriately warned. Having the ability to choose whether to leave, disable or re-enable mods should be in the users hands.

You do have an option to bypass the block under the most restrictive proposal being discussed; recompile the source and fix the bugs. If all it did was provide a stern the warning is users will ignore it since they will either hear from others or learn through experience that the "ignore incompatibility" button is actually the "make it work" button, and then we'll be back to where we are currently, with users suffering compatibility issues and the resultant complaints.

If you're concerned about current signal to noise ratio in support threads and think that this will improve it, then I think that's slightly short-sighted. All that's going to happen is that that the noise caused by inappropriate (and unsupported) usage will be replaced by noise caused by people asking how to circumvent, edit or recompile. Surely you must see that?

Except there won't be any noise of the form, "ModuleManager eats your all parts; delete the dll or else!" which was the essence of a PSA someone tried to get started on reddit shortly after 0.23 released. There won't be any "FAR causes <issue that isn't caused by FAR> in 0.23," with me getting bug reports that aren't even my fault. There will be fewer effects of ignorant "common knowledge" that X is the solution to a problem, where X is actually a bad idea that simply replaces the visible issue with a more subtle one. That background noise of well-meaning but incorrect mod support is really the key thing to reduce, since it reduces issues in the long term. Sure, people will ask how to circumvent the compatibility check, but that blends in with the demands to update the mod anyway.

Maybe that won't happen for the bigger modding players who jump on updates quickly (much love), but I can see it being a problem with smaller mods whose authors implement this without thinking it through. Should they leave their project (as often happens), but the mod is still functional in the new version (as often happens), I can see those support threads becoming clogged with requests for instruction on how to circumvent.

I actually don't see how this is a bad thing. When a mod goes unsupported it's only a matter of time before it causes game-breaking issues and it's better that it be closed down before that happens. Even when a mod is "functional" from a user's perspective there can be a lot of errors quietly occurring; exceptions are thrown, the game and the mod fight over things, the mod conflicts with other mods, but if there's no overt issues users declare that it's still fully functional, even though it's not. If there are users that think that a mod should be maintained, but the original author isn't interested anymore, they should look into maintaining it themselves. If they don't have the skills, learn them. I didn't know C# until I started coding KSP plugins. Leaving a plugin in a semi-working state is worse than it disappearing; it becomes a complication in bugfixing any other mod, since of all the mods this person is running, there's this one random plugin that's from 0.18 that is probably causing weird interactions, but given the poor quality of most bug reports quantifying those interactions is a pain.

Ultimately though, how a modder implements the compatibility check is up to them. There are some that might just have the game yell at you and then let you continue. There are others that will disable the mod because they know that it will break horribly.

[regex]

Ultimately though, how a modder implements the compatibility check is up to them. There are some that might just have the game yell at you and then let you continue. There are others that will disable the mod because they know that it will break horribly.

I think a lot of newcomers to this discussion are missing this fact entirely because of the thread title. There are quite a few plugins that will probably use this only as an alert system rather than an alert->lockout system.

[Trueborn]

SteamGauges will incorporate Majiir's Version Checker starting with the next release.

Currently I'm not disabling anything, just throwing the warning. If an upcoming version sounds like it might break some stuff that could change though.

[malkuth]

Interesting. Might have to look into this. I have a pretty bad feeling the next update is going to cause havoc.

[Diazo]

Hmmm.

While my mod has a small enough user base I'm not running in to the issues being talked about in this thread, I'm thinking this is a good idea.

However, rather then disable functionality of my mod, all I'm going to do is display a "Mod Update Required" somewhere on my GUI. This does make any extra demand of the user to use my mod while outdated, while at the same time continuously reminds them that it is outdated.

That way if they want to keep using my mod they can, but any support request I get which includes a screen shot (which is most of them due to what my mod does) I can immediately tell if they are using the version of my mod on the version of KSP it was programmed for.

Only displaying the text that an update is required is the middle ground I think. They can use the mod all they want with the text displaying but to remove the text would require a recompile.

As my mod is unlikely to break with a KSP update, this feels like the right balance for what I'm doing.

After all, the point here is to make is clear to the end user that they need to update. I don't think I need to disable any functionality to do that for my mod, but the bigger and/or more likely a mod is to break on a KSP update, the more likely disabling features of the mod will be desired.

D.

[Majiir]

Diazo, a few people seem to be going that route. You can still integrate with CompatibilityChecker in that case, since disabling functionality is implemented on a per-mod basis. Integrating will give users a more cohesive experience. If you choose not to use CompatibilityChecker, I'd be interested to hear why.

[Diazo]

Oh. Yes, I am going to use CompatibilityChecker for the check. (I never did actually say that in my last post, oops.)

But all I'm going to do in my own mod if it comes back false is (in addition to the dialog box CompatibilityChecker displays) display the text "Mod Update Required" in the corner of my GUI window so it is always present and the user can't 'forget' the fact they are using an outdated version and any screenshots I get as part of a support request show me that it outdated.

I suppose the point of my previous post was that you can display something on your GUI as a middle ground between simply allowing users to keep using your mod with no warnings, and disabling features.

D.

Edited February 6, 2014 by Diazo

[Diazo]

Okay, something's up with the code posted here in post #78 of the thread.

Running into problems trying to integrate this, I created a fresh project (with the 2 dependencies for KSP) and copy/pasted the code in in order to test.

It compiles without error, but when I run the following appears in the debug.log:

[ERR 18:59:57.907] AssemblyLoader: Exception loading 'CompatibilityCheckerTest': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 
Additional information about this exception:
 System.TypeLoadException: Could not load type 'Compatibility.CompatibilityChecker' from assembly 'CompatibilityCheckerTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
 System.TypeLoadException: Could not load type '<getAllTypes>d__14' from assembly 'CompatibilityCheckerTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Then the game runs as normal, just without the mod loaded.

To be clear, this is a Ctrl-C/Ctrl-V of post #78 with no changes at all.

The only GetTypes I could see was on line 135 near the end in the getAllTypes() methond, but looking at the code it appears correct to my limited programming knowledge.

Any ideas?

D.

[Trueborn]

I think it might be your .NET version. Try compiling against 3.5.

[Diazo]

FFS.

That was it, my install of Visual Studio defaulted to compiling against .NET version 4.5.

Change to 3.5 and it works fine.

D.

[Kermunist]

This all looks like a fairly good idea to me.

Some suggestions:

Require the mod using Compatability Checker to provide a version number for itself, and display that on the alert. This will make it clearer to the player what they currently have and hopefully make it a bit easier to find out if an update is available. It would also make it possible to check the version of other mods and disable the plugin if, for example, you need a newer version of modulemanager than is installed.

Allow the mod to add a UI element (text or button) So the player has instant feedback as to what the mod did when it found incompatibilities. Most mods will either carry on regardless (and display some text saying "Possibly buggy") or disable themselves (and display "disabled"). Some may want to offer choice to the player, or provide more information than fits in the alert box, and a button opening a mod-specific dialogue box allow that.

so the alert would look like:

One or more of your mods are not compatible
+----------------------------------------------+
| Mod        0.1.6      disabled               |
| OtherMod   1.3.5      disabled               |
| funMod     0.6      some features disabled   |
| cheatyMod  6.3.1    disabled [read more]     |    <--- read more is a button that pops up an extra dialog, handled by the mod
| noisyMod   1.2.3b6  possibly buggy [disable] |    <--- again, the button event is provided by the mod
+----------------------------------------------+

IMO the first suggestion should be very easy to implement and would be quite useful to players. The second one would probably more work to do, so having suggested it I'll leave it to people who regularly write mods to comment on it's value.

[Majiir]

Kermunist, I like the suggestion. How do you suggest handling mods using an old version of Compatibility Checker? A new version will override the old ones just fine, but it will need some kind of default way to fill in those fields. Version could be filled in with the AssemblyInformationalVersion, or a blank if that attribute is missing. Should the other field just be blank? "Unknown"?

[Trueborn]

I would say blank for the version string, and "Unknown" for the status field would work fine. Plus, it would probably only be an issue for a little while. I don't think there's a lot of abandoned mods using compatibility checker.

[Majiir]

It occurs to me that version compatibility goes both ways: we want to show a warning for a too-new KSP version and for a too-old version. The error message is currently not very helpful in that regard. I'd like to keep CompatibilityChecker fairly flexible, but would it be helpful to incorporate a sort of "expected version" value that could be reported to the user? Should that be decided on a per-mod basis?

[Kermunist]

Well, to be totally honest I didn't look how long the thread had been running, and thought my suggestions might make it in before many mods adopted it.

I would probably go for a blank version if it's not defined, as the assembly version is potentially misleading/confusing if it isn't the same as the version number the author uses when releasing the mod on the forum. Better blank than potentially wrong IMO.

Hopefully it'll become a non-problem fairly quickly, as plugin authors who are early adopters of ComptatbilityChecker will probably also update it fairly quickly.

I would probably avoid putting an 'expected KSP version' column or similar in. The reason being that the logic behind a plugin being incompatible is entirely up to the plugin and is unstructured. As it stands, a plugin author can flag up incompatibilities for any reason: KSP minor version; KSP build; another plugin version; operating system etc. The GUI should not structure something the code behind it does not, or it will get messy as people try to wedge unstructured information in.

How about another field? Like this:

One or more of your plugins have compatibility problems:
+------------------------------------------------------------------------------+
| Plugin     Version   Problem               Plugin Status                     |
+------------------------------------------------------------------------------+
| Mod        0.1.6     Expects KSP 0.23      disabled                   [more] |
| OtherMod   1.3.5     Expects KSP 0.23.1    disabled                          |
| funMod     0.6       Needs Modulemanager   some features disabled     [more] |
| cheatyMod  6.3.1     Only works on Linux   trying to continue (bugs!) [more] |  
+------------------------------------------------------------------------------+

I also think that while it is good to make the code as versatile as possible, there is nothing wrong with writing clear guidelines on how it is to be used. For example (and this is an example of the type of guideline, not necessarily what they should be):

Version Define a version number via the variable pluginVersion The version number should be the same as in the forums/spaceport, as it's primary purpose is making it easier for players to find upgrades. If no version number is available, this will be left blank

Reasons If IsCompatible returns false, the variable failureReason should be set to explaining why. This should be a string of no more than 40 characters, for multiple or longer reasons, use the more button. Good examples of what to set this to are "Needs KSP 0.23" or "Needs ModuleManager".If not set, it will default to '???'

Plugin Status If IsCompatible returns false, the variable pluginStatus should be set to explaining the actions taken as a result. This should be a string of no more than 40 characters, for multiple or longer explanations, use the more button. Good examples of what to set this to are "disabled" or "featureX disabled". It should not be left blank, if the mod isn't disabling any functionality, use "Attempting to continue" or similar. If not set, it will default to '???'

More button If you #DEFINE USE_MORE_BUTTON then you must also define callbackMoreButton(). A button will appear next to your mod which will call callbackMoreButton() when clicked, this should open an additional dialog box. Clicking the button should not have any other side effects, to change the state of the plugin, use controls within the new dialog box. Good examples of how to use this are: Simple text boxes elaborating on failureReason or pluginStatus; A web update checker; A re-enable plugin button with disclaimers. If USE_MORE_BUTTON is not #DEFINED then no button will be shown.

Finally, one other thing. I think text should refer to 'plugins' not 'mods'. Because: this method only works for mods with plugins; I think it is good to keep the distinction between parts packs and plugins in the minds of players; a disabled plugin will probably not remove parts, just make them inactive.

Well. These are my ideas. I would define them as such, not feature requests as I don't do much mod writing. Feel free to use or ignore as you see fit.

edit: On second thoughts, maybe using preprocessor directives isn't the best way to do the more button. I had though that it would be a neat way of avoiding compiler errors if callbackMoreButton is not defined, but that's more of a C++ tiny-microprocessor must-save-memory way of thinking, and some plugin authors might want to enable/disable the button at runtime in IsCompatible.

Edited February 7, 2014 by Kermunist

[Diazo]

My only thought is that we are starting to get maybe too complex.

This is a simple mod that people can copy-paste into their mod to tell them a mod is out of date.

All I'd like to see is a 'Name' and a 'Text' string added.

Name is the name of the mod, if blank use the Namespace as current.

Text is a short string (would be character limited, 60?) the mod author can add about what/why the mod is doing now that it is detected that it is out of date. This stays blank if left blank.

I'm asking for the Name because the namespace does not necessarily have anything to do with the mod. My Vertical Velocity mod started out as a simple thrust canceler at 'Thurst-Weight Ratio 1' so my mod's namespace was TWR1, which then came up as the mod out of date. This really has nothing to do with Vertical Velocity so a player would have no clue which mod was throwing the out of date warning.

Text is then a bit more detail if the author wants, or they can just leave it blank if all they want is the out of date warning.

The plugin status/reasons/more button I think is something that should be incorporated into the mod themselves based on the IsCompatible flag.

The simpler CompatibilityChecker stays, the wider adoption it is going to get (IMO).

D.

[blizzy78]

Lesson learned today: DO NOT check for Versioning.BuildID - it WILL bite you.

[Majiir]

The KSP 0.23.5 release was the first real test of CompatibilityChecker. Some things I noticed:

• The ARM patch was a departure from KSP's established versioning scheme. I'm hoping this was a one-time mistake. Still, it's important that implementers consciously decide which version components to check against (and how) rather than copy-pasting an existing implementation.
  
• Some users saw warnings from mods and concluded that any mod which was not listed must be working fine. This is obviously incorrect. (Not all mods implement CompatibilityChecker.) To alleviate this, I suggest the next version additionally list mods which do implement the checker but pass the compatibility check. The warning can then communicate that no compatibility information is known about the remaining mods.
  
• A number of people wrote things like "it gave me a warning, but the mod seems to work anyway". I haven't yet seen any implementations that actually lock down when incompatible, but that's probably still worth considering.
  
• The warning has effectively dissuaded people from using newer versions of mods with older versions of KSP. Keep this in mind when designing your compatibility function: only allow older KSP versions if you know for sure your mod is still compatible.

[blizzy78]

The ARM patch was a departure from KSP's established versioning scheme. I'm hoping this was a one-time mistake.

Don't count on it. I am working in the software business, too, and I've seen this happening here.

To alleviate this, I suggest the next version additionally list mods which do implement the checker but pass the compatibility check. The warning can then communicate that no compatibility information is known about the remaining mods.

Sounds fine by me, but the popup could get quite big.

A number of people wrote things like "it gave me a warning, but the mod seems to work anyway". I haven't yet seen any implementations that actually lock down when incompatible, but that's probably still worth considering.

I would be unsure about what features to lock, so I just didn't lock any. Also, being in the experimentals team helps to figure out what broke

[ferram4]

The ARM patch was a departure from KSP's established versioning scheme. I'm hoping this was a one-time mistake. Still, it's important that implementers consciously decide which version components to check against (and how) rather than copy-pasting an existing implementation.

I'm hoping the same; KJR implemented CompatibilityChecker, but I expected 0.24 to be the update with the joint fixes, not 0.23.5, so problems. I'll have to remember to check the revision number as well for the next update.

A number of people wrote things like "it gave me a warning, but the mod seems to work anyway". I haven't yet seen any implementations that actually lock down when incompatible, but that's probably still worth considering.

Hopefully locking things down won't be necessary, but I also think that the warning message needs to be tailored so that too many players don't decide that they're all completely bogus and can be ignored. It would really suck for the warning to receive the same amount of attention a EULA gets, because then we'll be back where we started.

[stupid_chris]

My implementation for RealChute does lock down if incompatible. Since the moving parts are only two PartModules, returning in the overrides and in the Unity functions if incompatible does the trick.

Apart than that, I do support listing mods that do pass the test. It would probably be a little clearer for the end user.