CompatibilityChecker Discussion Thread

[draeath]

@Majiir Oh 100% with you on that. It's whether or not you can work around the check without a recompile that I call to question.

@ferram4 I come from a perspective of many years of commercial software support, which admittedly biases me towards flexibility. If I can get our java-based payment processor software to function on a 15-year-old AS/400 installation, well, I think you get my point

Yes, a third-party changing the config to bypass this would be an issue, but a third-party can recompile it as well. The issue (third-parties bypassing your check) still remains.

Edited January 10, 2014 by draeath

[regex]

Looks pretty cool Majiir.

Nobody is advocating that every mod implement the greatest possible restrictions, and every mod can implement details like disabling and version checking slightly differently.

Just an aside to draeath, this is important to note; smaller mods like PreciseNode or TAC Fuel Balancer (for instance) may not even bother disabling anything since they rarely bump into anything else.

[NathanKell]

draeath: yabut your payment processor software's users aren't 14.

[Then again, 14 year olds may well be mature (maturity isn't necessarily a function of temporal age!) and also may well be more mature than your software's users. ]

I do want to make a serious point of this, however: it's worth noting that a game's user base is going to be rather different than a business application, and while the KSP community as a whole is much nicer, more patient, etc., than many games', that's still an issue. If we'd had this discussion four months ago (when it'd been years since I'd last done modding) I'd be all for the cfg override. But having seen exactly what folks can get up to when they try to install and/or use mods--or worse, as ferram says, when (well-intentioned) others try to "help" them, including using instructions that broke six months ago...nope.

[Pontiac]

TLDR; ***The DLL should verify the version of KSP against a Key=Value in a version.txt file that lives in the same directory as the DLL.**

Personally, I despise the idea of having a plugin forcibly locked out from game play because of a version change with no option as a workaround without a little bit of effort. Come on, 0.23.0 to 0.23.1 and ALL affected plugins DIE? I can understand MAJOR revision changes, but even then, the change I made to Actions On The Fly worked for 0.20 and all the way through 0.23 WITH NO MODIFICATION TO CODE. Hell the original version the original author posted still works from 0.19.0, albeit with the single bug I fixed.

I'd like to throw my two cents in and say that instead of hard coding a version number into the DLL, a simple text file is included to state what the current version of KSP the mod is supposed to work with. In that text file (Lets call it 'version.txt' and has to be located in the directory of where your DLL exists) a Key=Value setting like CompatVersion=0.23.0. The DLL checks against that value in that key and continues on. If it doesn't then lock out the plugin by all means, please do. However, the users that know how can go in and edit version.txt, make the change for the current version, and make it compatible to see "if things have to be done". Not only is that K=V setting present in the version.txt file, there is also a large wall of text stating that editing the file MAY cause the plugin to not work, etc. TYPICALLY the people who know how to navigate deeply enough into the directory tree to find versions.txt and edit the file should already know what they're doing is changing expectations of the software. I'd even go as far as NOT use an obvious name like version.txt but name it something else and put in the readme what file is needed to be changed in case of a KSP version change. That way, the user would at least have to do some research and be notified that what they're doing goes outside of the bounds of support. (To a dealer: What do you mean you're going to warranty the obviously after-market airbag suspension I installed in my Fiat?)

Not to kick up a bees nest about licensing, but I'd wager that 90% of the people who love to play KSP just don't know the difference between a "computer" and a "hard drive". (Don't laugh. I did computer repair work in a mom-and-pop shop for end users for almost 6 years and some of the questions I was asked was just jaw dropping. SUPER intelligent people in their business, I won't question. I got awesome information about the car I drove from a guy who wanted me to fix the sound on his "hard drive". I still deal with that kind of thing in my job today but perhaps twice a year now.) Saying that "Code can be recompiled" may be valid for someone who knows what a compiler is, but to most, going through the process of finding, then downloading a compatible compiler, getting it configured, then getting it working with the code just to compile, then figuring out how to get the code someone else wrote to work as expected, is way out of alignment of the MAJORITY of players. Some mod authors just DO NOT ALLOW redistribution of their work without their consent. That's fine and I can get on board with that, but if a plugin goes out of date, then the author is assumed MIA which means the author can't consent to allowing modifications and/or redistribution, then there is absolutely zero chance that the mentioned user CAN use that plugin with a newer version of KSP. However, if something external to the DLL can be modified, and the user can edit it, then they KNOW that what they're doing COULD break something. Will the plugin eventually break? Yeah, maybe, but no guarantee, of course. But if it was a popular enough mod, someone else will rewrite, and redistribute, but then again, AotF can attest to working through 4 major versions. From KSP v0.19 to v0.20, something changed that affected "Actions On The Fly" in a very minor way (Just a glitch - The "Enable AotF" link repeated itself on the root part), and only because of the open license I was able to affect a change, and legally redistribute. If, say, Kethane were to go stale, I couldn't do that because redistribution can only be done in post #1 of that owners thread. Sure, I could obtain the code, rebuild on my own system, but that is because I have the 30+ years of making &^$# work on a computer that just shouldn't work. (I keep a hammer right next to the machine). But to some, they need a kid to install and update AND put a shortcut on the desktop to even PLAY KSP. (*shivers at those work-time memories*) Bottom line, more people are going to have the knowledge to edit a text file to make a change, but will be FULLY WARNED that the change could affect their game play, but they will at least have the chance to PLAY their game the way they want to, versus those that will have to learn that a hard drive isn't a computer.

[Voidryder]

Hi,

Just finished reading this thread and as a non-programmer, non-modder but big mod user I'm all for this.

[regex]

but they will at least have the chance to PLAY their game the way they want to

This is pretty much invalidated by the fact that mod authors are in no way beholden to their users to update and maintain free software, are completely free to license their work that they provide to others for free however they damn well please without any consideration to anyone (past, present, or future), and by the fact that the aforementioned players are not just "playing their game, their way", they're affecting other players and mod authors through their antics when mods don't work.

Nice rant? I guess?

Also, it's worth pointing out that mods don't even need to disable anything to use this method, it can be merely a warning.

[ferram4]

Yes, a third-party changing the config to bypass this would be an issue, but a third-party can recompile it as well. The issue (third-parties bypassing your check) still remains.

True, but here's the thing: by implementing a config bypass, I'm implicitly sanctioning a "fix" by changing the version number, and people will pick up on that. The dll-recompile doesn't have that issue.

Personally, I despise the idea of having a plugin forcibly locked out from game play because of a version change with no option as a workaround without a little bit of effort. Come on, 0.23.0 to 0.23.1 and ALL affected plugins DIE?

Did you not read the code example in the OP? Where it checks the minor version number, which would allow a plugin compiled for 0.23.0 to still function in 0.23.1? Or are you simply not recognizing that KSP is major version 0, minor version 23?

I can understand MAJOR revision changes, but even then, the change I made to Actions On The Fly worked for 0.20 and all the way through 0.23 WITH NO MODIFICATION TO CODE. Hell the original version the original author posted still works from 0.19.0, albeit with the single bug I fixed.

And last I checked Actions On The Fly spammed null reference exceptions all over the place. You might argue that this is an example of how this scheme would be bad, but considering the issues I'm aware of with Actions OTF, this is actually a situation where this would be necessary. If the code is hitting an exception and stopping execution prematurely, how do you know that there aren't strange effects causing things to break? The point of this is to prevent issues like that from occurring. Even if there are no visible errant behavior, exceptions should not be allowed to continue existing in the code.

I'd like to throw my two cents in and say that instead of hard coding a version number into the DLL, a simple text file is included to state what the current version of KSP the mod is supposed to work with. -snip- That way, the user would at least have to do some research and be notified that what they're doing goes outside of the bounds of support.

What happens when some 3rd party posts a config in a folder structure with the proper pathline and they say it "fixes" the compatibility issue and a user installs this and runs into issues without ever seeing the "setting this to X will void support" message? Am I just supposed to tell them, "tough luck, you shouldn't have done that?" It just asks for problems when ignorant but well-meaning users attempt to "help" other users.

Saying that "Code can be recompiled" may be valid for someone who knows what a compiler is, but to most, going through the process of finding, then downloading a compatible compiler, getting it configured, then getting it working with the code just to compile, then figuring out how to get the code someone else wrote to work as expected, is way out of alignment of the MAJORITY of players.

Ah, so you do see the point. The idea is to prevent computer-illiterate users from running into possible issues and then dropping it in our laps.

Some mod authors just DO NOT ALLOW redistribution of their work without their consent. That's fine and I can get on board with that, but if a plugin goes out of date, then the author is assumed MIA which means the author can't consent to allowing modifications and/or redistribution, then there is absolutely zero chance that the mentioned user CAN use that plugin with a newer version of KSP.

Tough, but I don't see how that has any bearing over whether this changes whether the lockout makes sense. It's not like plugins are created by modders to add to some great collective good of the community where we all live in a nice, happy utopian vision of rockets and happiness; most of us probably do it for our own selfish reasons. For example, I release my plugins (with the exception of KIDS) so I have more... data points about how it handles.

However, if something external to the DLL can be modified, and the user can edit it, then they KNOW that what they're doing COULD break something.

For the intelligent user, correct. For the foolish user, the modder just gave them a way around the compatibility check; WHY DOESN'T IT WORK?! ARGGHHH!

Bottom line, more people are going to have the knowledge to edit a text file to make a change, but will be FULLY WARNED that the change could affect their game play, but they will at least have the chance to PLAY their game the way they want to, versus those that will have to learn that a hard drive isn't a computer.

The problem is they likely will not be warned; they will obtain the "fixed" config second-hand, or they will gloss over the warning as irrelevant. They'll read somewhere to "ignore the warning, it's full of it," and believe that. The key is that someone with coding knowledge take responsibility for the code working, and if it can be handled through a config change that cannot be guaranteed.

[draeath]

True, but here's the thing: by implementing a config bypass, I'm implicitly sanctioning a "fix" by changing the version number, and people will pick up on that. The dll-recompile doesn't have that issue.

Not if you explicitly state, right there, that it isn't a sanction. Again I ask, what does that stop happening that a config file-based override doesn't? "Helpful" third party users can still hand out modified DLL files, and you'll still have to deal with that.

Yes, the correct answer is to say "you shouldn't have done that." Don't try to make it idiot-proof, that's impossible - you can only aim for fool-proof.

The problem is they likely will not be warned; they will obtain the "fixed" config second-hand, or they will gloss over the warning as irrelevant. They'll read somewhere to "ignore the warning, it's full of it," and believe that. The key is that someone with coding knowledge take responsibility for the code working, and if it can be handled through a config change that cannot be guaranteed.

"They will obtain the 'fixed' dll second-hand" - there's really no difference when it comes down to it. You assume (incorrectly I'd hazard) that someone building a DLL infers some sorts of responsibility for it working. That is simply not true, any more than whatever imaginary responsibility comes with changing the config value(s) I'm pressing so hard for.

The only way around this is some form of digital signature... and there's two problems with that:

1. You have no chain of trust, since such a thing doesn't come with the engine it can be defeated at whatever point it's implemented.

2. Squad would have a fit.

Edited January 10, 2014 by draeath

[ferram4]

I'm assuming that users will be treat replacing the plugin's library with greater weight than changing a value in a config, in the same way that I assume that users will consider a HighLogic-skinned window to be more official than a standard Unity-skinned window. Perhaps it's not the best assumption, but replacing a file of a type they know nothing about should seem more significant than changing a value in a text file.

[J.Random]

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.

[draeath]

Perhaps it's not the best assumption, but replacing a file of a type they know nothing about should seem more significant than changing a value in a text file.

Oh, you just haven't met the right users, is all

KSP requires a bit of brainpower to enjoy, so I guess the absolute rock-bottom wouldn't be around. Often.

[J.Random]

Oh, you just haven't met the right users, is all

Just look at RT2 thread or github. DLLs EVERYWHERE. Cilph will be shocked when he gets back to it.

[Majiir]

"They will obtain the 'fixed' dll second-hand" - there's really no difference when it comes down to it.

There are two important differences:

1. There's a significantly higher skill barrier to building a modified plugin. That means that the second-hand fix is more likely to actually be fixed as compared to a small config patch which only switches from one failure mode to another. It improves the signal-to-noise ratio, which is hugely important to modders.
   
2. Modified plugins can be regulated through licensing.

The only way around this is some form of digital signature... and there's two problems with that:

1. You have no chain of trust, since such a thing doesn't come with the engine it can be defeated at whatever point it's implemented.

2. Squad would have a fit.

I advocated a scheme for signed assemblies some time ago. There wasn't much interest, likely because it seemed to be attacking a nonexistent problem, but I still think it's doable in increments. You're correct that an individual mod can't do anything about it; an ecosystem must be built around the idea. That said, it would certainly be possible for mods to enforce authorship verification with enough critical mass. (If 80% of mods are configured to digitally verify each other, it will be difficult for a user to install many mods if one is using a forged signature.)

I don't think that discussion belongs here, though. We're trying to require users to recompile in order to bypass restrictions, not prevent them from making modifications whatsoever. (In other words, you must know how to modify a plugin in order to enable an out-of-date mod's behavior.)

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.

Nobody's discussing always-on DRM. Greys has suggested a method whereby mods that don't break in a KSP update can remain operational. It's worth noting that digital signing is quite workable (and probably necessary) under that scheme.

[ferram4]

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.

Maybe Greys will want to do something like that, but that system just strikes me as unnecessarily complicated, and it doesn't shut off your mod if it doesn't come from an "approved" source or some other nonsense like DRM causes. It simply identifies whether you're trying to run a mod with a version of KSP that it was not compiled for, and if so, adds an additional (IMO unnecessary) server check to see if the mod is compatible in that particular KSP version, since it wasn't intended to work with that version.

Since Firefox disables plugins when they might not work after an update, that means that that function is DRM, not simply a hassle-saving feature for supporting plugins, correct? At least according to your definition.

[Pontiac]

Did you not read the code example in the OP? Where it checks the minor version number, which would allow a plugin compiled for 0.23.0 to still function in 0.23.1? Or are you simply not recognizing that KSP is major version 0, minor version 23?

Honestly, no, I did not read the code Majiir posted, and just now I acknowledged the property. I glanced at the 'logic' posted by Majiir but didn't run the line-by-line through the compiler in my head. It's past midnight and I'm off the clock. If its checking the MINOR version and not the BUILD, I'm still iffy, but still against. True it'd be LESS reports, and it'd only happen when Squad releases a major-minor build, but the fact of the matter is that its reports. You'll get reports with or without it. Lets say that after a week into 0.24 you decide KSP just isn't for you, and you walk away without a g'bye. People are going to ransack your mod and post it somewhere outside of your control. Rebranded or otherwise.

Now, looking at a change from 0.23.0 to 0.24.0 and not 0.23.0 to 0.23.1, OK, sure, fine, it isn't going to cause a massive fiasco every day of the week, but this is a type of DRM that has LEGAL consequences if the product were to become of age. I've not heard of anyone going to court over a KSP mod yet, but, hey, stranger things have happened. Since I have been, or will be, picking on Majiir, I know he's got a very restrictive license stating at least that no redistribution is permitted. If I were to push something out for Kethane, and he found out about it, and wanted to put the effort into charging me, he's got the rights to do so, and probably would succeed. I'm not saying he WOULD. He'd probably be very pissed off at me, but, hey.. I'm just a peon on the interwebz.

And last I checked Actions On The Fly spammed null reference exceptions all over the place. You might argue that this is an example of how this scheme would be bad, but considering the issues I'm aware of with Actions OTF, this is actually a situation where this would be necessary. If the code is hitting an exception and stopping execution prematurely, how do you know that there aren't strange effects causing things to break? The point of this is to prevent issues like that from occurring. Even if there are no visible errant behavior, exceptions should not be allowed to continue existing in the code.

Irrelevant. What the [good/bad/working/non-working] code is doing isn't what I'm questioning. I fully acknowledge that stuff could break from KSPs version to version, or even build to build. I'm questioning the restrictions imposed that require someone to load up a compiler to play the game the way they want to play. I get that your contribution to the community is yours and I may sound like I'm being an entitled prick, but I assure you the angle I'm on doesn't even come close to that topic. If I get pissed off enough that I can't play my game the way I want to play my game using YOUR MOD on MY TIME, I seriously would take that as a major COMPLIMENT to your work, not as a sense of entitlement.

What happens when some 3rd party posts a config in a folder structure with the proper pathline and they say it "fixes" the compatibility issue and a user installs this and runs into issues without ever seeing the "setting this to X will void support" message? Am I just supposed to tell them, "tough luck, you shouldn't have done that?" It just asks for problems when ignorant but well-meaning users attempt to "help" other users.

You can act on that in three ways

The first way, from the day that Squad releases the new version of KSP, until the time you punch out another release, all support questions are null and void. They don't exist. They were never read by your eyes. If some well meaning user puts out a config out there, so be it. You didn't put it out there, any MENTION to the new config becomes null and void. Once the people who have gotten the new config note that you've released a new version, they're PROBABLY going to download the newest version ANYWAYS. But what to do with the people sitting on 0.22 and you're DRM is set to 0.23? Well.... You can't support what you don't run? Depending on your license, and if you really want to go that far, you can even report the user who posted the config change since it'd be outside of your distribution setup, and it can be considered an important part of your package.

The second way, develop the thick skin I developed and inform users that if they use the software in unintended ways, the software is going to work in unintended ways. LET them scream and shout and let it all out (background music). The worst thing that can happen to you is they don't use your mod.

The third way is open a new thread for each release of your product, and start with a brand new clean slate. The forum software used here isn't the best for software distribution. Unless permissions are given to let the OP have total control over the entire thread, you're going to develop a lot of garbage that no one is going to read if you have multiple versions of your product in one thread. Look at MJ. Change the old thread title to a tag of "[uNSUPPORTED]" and leave it at that.

Its great that you seem to think that you have to answer every single question and answer to every complaint on the internet relating to your product. Bottom line is that you owe us nothing and we (the decent ones) owe you gratitude for enhancing our experience. You don't have to reply to any question, nor complaint. You can even just post updates, and NEVER reply to a single question. We don't pay you, we don't give you anything other than maybe an ego boost. Sure as hell there are griefers out there that shouldn't be using a computer, but, well, thats the internet.

Tough, but I don't see how that has any bearing over whether this changes whether the lockout makes sense. It's not like plugins are created by modders to add to some great collective good of the community where we all live in a nice, happy utopian vision of rockets and happiness; most of us probably do it for our own selfish reasons. For example, I release my plugins (with the exception of KIDS) so I have more... data points about how it handles.

Selfish reasons are selfish reasons. They're personal, and not relevant to this discussion, but don't take a microsecond thinking that I don't understand and KNOW your selfish reasoning.

I didn't attempt the fix to AotF to bring in the bajillions of dollars I wanted. I didn't do it to become famous as I should have been. I did it because I was driven to annoyance with the issue at hand. I also knew that other people were going to have the same problem, so with looking at the source code in PSPad and thinking I understood enough of it, I downloaded two different compilers, got both working with the OAs code, examined the code, found the fix, pushed it out the door. I didn't do anything more to it. TBQH I don't even know if my "fix" is what started the null references you mentioned. It was a bit of an ego boost to have a few people thank me profusely for the fix. I even was offered a non-paying job out of it because of a discussion I had about enhancements I COULDN'T do. NEITHER of those reasons were why *I* pushed myself to fix the problem, but the primary reason WAS to promote the vision of rockets and happiness. With full respect to you and EVERY other single modder in ANY game, not only KSP, if you want to throw the DRM into your tools and addons, then by all means do so. I most certainly can't and won't stop you. But fully expect people to get work arounds faster than you can push an update.

I have published, working software, used in the insurance industry, that IS loaded with DRM. If I die, that program dies at next renewal. If you die (And seriously, I do hope you live to mid-nineties :]), legally speaking, I'm not out much as I have the know-how create an environment to rebuild, but, anyone who CAN'T recompile, well, there goes their fun until someone re-makes your product, or they have to learn patience and await for your fix.

The problem is they likely will not be warned; they will obtain the "fixed" config second-hand, or they will gloss over the warning as irrelevant. They'll read somewhere to "ignore the warning, it's full of it," and believe that. The key is that someone with coding knowledge take responsibility for the code working, and if it can be handled through a config change that cannot be guaranteed.

Disclaimer: I'm usually the one that ignores the warnings. I know they're there, but I also know that I could turn my CPU into C4. I tinker. Thats me. Others shouldn't own a computer or have access to a forum because they're entitled rats. Then again, some of those rats might just be hitting a linguistic barrier that makes it SOUND like they're entitled. ... then again.. some just think they are because of their nationality.... (*shivers at that past store work-day*)

And here is my point. The source code exists for everyone to use and compile. Its there, character for character, as you typed it out and distributed. Its either packaged in the zip file or put out on a source code tracker that is accessible. (I can't remember if the code HAS to be in the archive or not, but not relevant). You can't guarantee that that the DLL isn't going to be redistributed outside your required channels, so whether the config file gets distributed, or a DLL gets distributed, you're going to lose control if too many people get pissy about the updates, and you're still going to hear the screaming. The ONLY thing you're doing is slowing the pace from the '3rd party patch' to be released by hard coding the version check. If you're as active and as attentive as Majiir, then you've got no worries. However, you're going to get yelled at in your forum thread when you've not pushed an update 3 days later, if at all.

[Majiir]

Pontiac, it seems that you're trying to convince Ferram and I that we don't want this, but we've already concluded that we most certainly do.

You mention having "thick skin" with regard to user reports, but you're missing some perspective. When you run a mod as large as Kethane or FAR, the hours required to support that mod can easily balloon. There was a time when I spent more than thirty hours a week (!) on Kethane support. That's why I took the time to add the InstallChecker utility, and support request rates dropped like you wouldn't believe. I've also invested time in establishing and documenting bug reporting policies so I can spend less time sorting through the mess. Now consider that the playerbase is ever larger and that many of us publish several mods.

It does not work to simply ignore issues between KSP release and mod update. The old users persist. Other users feed them false information. Bug reports come in for mismatched version combinations. You have to delete the mess, but you know that up-to-date issues are coming in as well, and valid issues from previous versions are also coming in for people who haven't yet updated. If what you say is true, I should have no problems because my updates are usually out too fast for anyone to have downloaded the new KSP version.

Consider the positive externalities of this scheme if widely adopted. ISA went unmaintained in a buggy state for months. It's since been replaced by the superior SCANsat mod. Had ISA immediately become non-functional in 0.20, we'd have seen such a replacement much sooner. It benefits the community for there to be a high turnover of mods. It brings in new talent and keeps old modders on their toes.

[ferram4]

Honestly, no, I did not read the code Majiir posted, and just now I acknowledged the property. I glanced at the 'logic' posted by Majiir but didn't run the line-by-line through the compiler in my head. It's past midnight and I'm off the clock.

Majiir's code allows the mod author to implement whatever kind of version-checking procedure they want. I was talking about my psuedocode in the original version, which references the minor version.

If its checking the MINOR version and not the BUILD, I'm still iffy, but still against. True it'd be LESS reports, and it'd only happen when Squad releases a major-minor build, but the fact of the matter is that its reports. You'll get reports with or without it.

I see that you have not had the issue of maintaining a mod that broke horribly during a KSP update. I'm still getting bug reports for versions of FAR from KSP 0.22 not working in KSP 0.23; I've had some reports of people trying to use 0.23-compatible version of FAR in 0.22.

Now, looking at a change from 0.23.0 to 0.24.0 and not 0.23.0 to 0.23.1, OK, sure, fine, it isn't going to cause a massive fiasco every day of the week, but this is a type of DRM that has LEGAL consequences if the product were to become of age.

When did a plugin checking its running environment's version become Digital Rights Management? That actually makes DRM sound somewhat reasonable, I might have to rethink my attitude on it being pure evil if version checking == DRM.

Irrelevant. What the [good/bad/working/non-working] code is doing isn't what I'm questioning. I fully acknowledge that stuff could break from KSPs version to version, or even build to build. I'm questioning the restrictions imposed that require someone to load up a compiler to play the game the way they want to play. I get that your contribution to the community is yours and I may sound like I'm being an entitled prick, but I assure you the angle I'm on doesn't even come close to that topic. If I get pissed off enough that I can't play my game the way I want to play my game using YOUR MOD on MY TIME, I seriously would take that as a major COMPLIMENT to your work, not as a sense of entitlement.

Sure, I can see it as a compliment, but it's essentially phrased as a demand, and it ignores the consequences... "I want to play your mod so badly that you should have to deal with more bug reports and compatibility issues so I can play with it."

-snip- The Three Ways -snip-

The first one is pretty much what I already do. The second strikes me as a really nasty way to handle it, and since I'm dealing with an aerodynamics overhaul (and the associates changes in playstyle that come with it), I don't want a harsh support attitude to discourage users having trouble from asking for tips. Especially since I'd prefer to not to risk becoming nasty when I've heard the same gameplay question the 100th time, from a well-intentioned user. The third might work, but useful information can be hidden when the thread disappears.

I have published, working software, used in the insurance industry, that IS loaded with DRM. If I die, that program dies at next renewal. If you die (And seriously, I do hope you live to mid-nineties :]), legally speaking, I'm not out much as I have the know-how create an environment to rebuild, but, anyone who CAN'T recompile, well, there goes their fun until someone re-makes your product, or they have to learn patience and await for your fix.

For Majiir's stuff, perhaps. For mine, it's mostly copylefted. So all it takes is recompiling to update the compatibility and fixing any compiler errors, and people are free to redistribute FAR, KJR, KIDS, etc. as they see fit.

Disclaimer: I'm usually the one that ignores the warnings. I know they're there, but I also know that I could turn my CPU into C4. I tinker. Thats me. Others shouldn't own a computer or have access to a forum because they're entitled rats. Then again, some of those rats might just be hitting a linguistic barrier that makes it SOUND like they're entitled. ... then again.. some just think they are because of their nationality.... (*shivers at that past store work-day*)

And here is my point. The source code exists for everyone to use and compile. Its there, character for character, as you typed it out and distributed. Its either packaged in the zip file or put out on a source code tracker that is accessible. (I can't remember if the code HAS to be in the archive or not, but not relevant). You can't guarantee that that the DLL isn't going to be redistributed outside your required channels, so whether the config file gets distributed, or a DLL gets distributed, you're going to lose control if too many people get pissy about the updates, and you're still going to hear the screaming. The ONLY thing you're doing is slowing the pace from the '3rd party patch' to be released by hard coding the version check. If you're as active and as attentive as Majiir, then you've got no worries. However, you're going to get yelled at in your forum thread when you've not pushed an update 3 days later, if at all.

None of this discussion has included restricting the source; it has simply focused on making sure that the plugin is confirmed to have no compiler errors stable by recompiling it using the appropriate (hopefully) references, with a small change to the source to make compatibility work. I think that you're seeing licensing issues here where there ultimately, are none.

[Rich]

Yes, a third-party changing the config to bypass this would be an issue, but a third-party can recompile it as well. The issue (third-parties bypassing your check) still remains.

A recompile is a much stronger solution for several reasons: 1) There is a technical barrier on the recompile; 2) Redistribution of "fixes" can easily be limited to personal use by an appropriate licence and 3) If the licence allows redistribution, then the person who did the recompile and release will clearly be responsible for any resultant explosions.

[Faark]

Hell, this thread has "mod manager" written all over it between the lines. Auto-updating mods, disabling incompatible mods, preventing KSP from updating until compatible versions are available, and so on... would love Squad to take care of it. But guess Spaceport2 will just be another mod database?

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.

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.

[sarbian]

Why can't you at least pretend to help your users?

Sorry but WHAT ? What do you think I(we) do for hours each day ? If I did not want to help user I'll maintain my version of MJ that does the think I want and keep it to myself. I don't do this for glory or cookies, and if it wasn't the official forum my reply would be far more graphic.

And to come back to the actual subject :

After looking at Majiir code and screenshot I thing I should at least add something that check if MJ is well installed ASAP. This will help with some of the faulty steam install and those who still want to install in KSP/plugins

And if I does that the version checker will most likely follow fast. Next step is adding a variable in the build process ( or display a checksum ) that will let me know if the version run is "official".

I wonder if I could use the fact that MM is installed nearly everywhere to add a tool to help us with debugging. Like a report that list KSP version, installed DLL and other useful things.

Edited January 10, 2014 by sarbian

[pizzaoverhead]

Hell, this thread has "mod manager" written all over it between the lines. Auto-updating mods, disabling incompatible mods, preventing KSP from updating until compatible versions are available, and so on... would love Squad to take care of it. But guess Spaceport2 will just be another mod database?

Automatic version checking through Spaceport2 would be great, but I think that project is cancelled due N3X15 having left the team.

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.

Providing information to users is a big part of this. How many people are running mods with no idea of what version they are or what they support? In most cases there is no easy way to get this information either.

If every plugin dumped its details, compatibility and forum link into one text file that was easily available, it could be required to be provided by users reporting bugs, much like output_log.txt. It would give some insight into versions, conflicts and provide the information that users are missing at the moment.

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.

The law of unintended consequences. A DLL lock forces non-technical users to compile and make their own changes. Installing an IDE isn't a particularly difficult process and there are plenty of tutorials. You suddenly have many users running their own custom edits, and complaining about them not working, if previous comments are anything to go by. It's much easier to support inter-release issues than an arbitrary number of random DLLs.

[Majiir]

Faark, the focus of this thread is on serving a common need of modders (reducing workload) while having some positive side-effects for users. You are correct that much of this could be made better with a full-fledged mod management solution, but that will require substantially more effort. We're making an incremental improvement, and yes, it's largely self-serving. The discussion has (hopefully) ensured that it won't come at the expense of users.

After looking at Majiir code and screenshot I thing I should at least add something that check if MJ is well installed ASAP. This will help with some of the faulty steam install and those who still want to install in KSP/plugins

And if I does that the version checker will most likely follow fast. Next step is adding a variable in the build process ( or display a checksum ) that will let me know if the version run is "official".

Here's the code from Kethane. I release it into the public domain with a CC0 Public Domain Dedication.

using System;
using System.IO;
using System.Linq;
using System.Reflection;
using UnityEngine;

namespace Kethane
{
    [KSPAddonFixed(KSPAddon.Startup.MainMenu, true, typeof(InstallChecker))]
    internal class InstallChecker : MonoBehaviour
    {
        protected void Start()
        {
            var assemblies = AssemblyLoader.loadedAssemblies.Where(a => a.assembly.GetName().Name == Assembly.GetExecutingAssembly().GetName().Name).Where(a => a.url != "Kethane/Plugins");
            if (assemblies.Any())
            {
                var badPaths = assemblies.Select(a => a.path).Select(p => Uri.UnescapeDataString(new Uri(Path.GetFullPath(KSPUtil.ApplicationRootPath)).MakeRelativeUri(new Uri(p)).ToString().Replace('/', Path.DirectorySeparatorChar)));
                PopupDialog.SpawnPopupDialog("Incorrect Kethane Installation", "Kethane has been installed incorrectly and will not function properly. All Kethane files should be located in KSP/GameData/Kethane. Do not move any files from inside the Kethane folder.\n\nIncorrect path(s):\n" + String.Join("\n", badPaths.ToArray()), "OK", false, HighLogic.Skin);
            }
        }
    }
}

I wonder if I could use the fact that MM is installed nearly everywhere to add a tool to help us with debugging. Like a report that list KSP version, installed DLL and other useful things.

You missed a good discussion in #kspmodders on this topic. I'll fill you in next time you're around.

[sarbian]

I miss a lot of good discussion since I go to sleep earlier

[Garek]

So I don't create Mods, but use a lot of them. Also, I work as a software developer who is quite happy to let other people do the first-level support.

I think the system proposed here is a very good idea. About config-entry vs. recompile, I think forcing a recompile is a good idea. Basically, you choose what skill level you require from a user to circumvent the version lock. Most people which are using computers at all are propably capable of editing a text file, especially if it gets explained a hundred times in the forum. They could probably also install a compiler, follow a script to set up the project and fix compile bugs and recompile, but that's propably the point where most people realise there are doing something they don't understand the consequences of and rather wait for an official update. Of those that would do a recompile you hopefully get a far better ratio of those that understand at least enaugh to not go annoy the developer needlessly to those that go whine on the forum anyway.

Since I said that I'm a software developer one could argue that recompiling isn't that much of a hassle for me. But setting up projects for half a dozen mods and fixing their compile bugs, while their developer is probably doing exactly the same better is something I will likely not do. Mind, I'm running without B9 for the moment because it's not updated for .23 even though there are a number of fixes to get the .22 version working with .23. That's because I don't trust the ability of mod users (including myself) to make it work without stuff breaking down for no apparent reason. I just can't understand the interactions well enaugh without investing amounts of time which are unreasonable for something which will be superseeded by an official update hopefully sooner than later. Of course, Mods can get abandoned, but that's a different discussion entirely, and the version lock doesn't prevent a takeover, because whoever takes over a mod should be more than able to correct it.

[draeath]

A recompile is a much stronger solution for several reasons: 1) There is a technical barrier on the recompile; 2) Redistribution of "fixes" can easily be limited to personal use by an appropriate licence and 3) If the licence allows redistribution, then the person who did the recompile and release will clearly be responsible for any resultant explosions.

The same people who would be passing config files or DLLs around to bypass the check are the same people who would ignore licensing details. Just saying... and there's never been any responsibility unless you put it into your license for some reason. This stuff is all at-your-own-risk and a modder would have to be insane to state or imply any sort of warranty whatsoever.

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.

Agreed. You want just enough pain to get people to clue in, but not enough to "force" them into finding fixed configurations or DLLs or whatever it is you end up implementing. It's a like an aerocapture - not enough and you won't aerobrake, too much and you'll lithobrake instead.