Lisias

If you downgrade plugins and the file format from the previous version is different, you can have problems - it will depends of the plugin's resiliency - by experience with a lot of source code from the last months, most will recover nicely, as most of them have the defaults embedded on code. Other than that, what will happen is you reusing your old settings when you decide to reinstall it.

I would want to add something to that: KSP usually creates an <KSP>/PluginData on every installment I have. (There're also a Plugin and a Resource directories, always created by default). I had the idea to use this when I first realized them - I thought it was on purpose, by the way, and got confused when I saw people writing settings merged to the plugins data/executables.

The KSP EULA is subject to the TTI Terms of Service, and not vice versa. Any term on the EULA that contradicts any paragraph of the TTI's ToS is null and void. [not exactly - I was thinking on the site, not on the software] — POST — EDIT -- But yet, you have a good point to be discussed. — POST — POST — EDIT : Food for though. There're rights that you can "wave", and there're some few that you can't. In Brazil, trying to force me to waive an right (or to fail to comply to a duty) using the legal system is, here, a Federal Crime: Indirect Extortion. I don't know if it would be applied to a Company, but it's for sure applicable to a person working for a Company, and USA and Brazil have legal agreements that would allow the MPF (Ministério Público Federal) to prosecute (or to sue - legalese ir hard enough on my own tongue!) such a person once a denounce is filed. And vice versa, by the way - I do something unlawful to someone in USA, the USA courts can prosecute/sue/aaargh!!!! me here. Authorship is a guaranteed right around here, there must be a contract where I explicitly transfer the authorship to the contractor in advance. [correction: Authorship is not transferrable. Once I author something, there's nothing anyone can do to change that. I can transfer ownership, but the new owner will have to acknowledge my authorship for the rest of the work's existence]. The right to transfer the authorship [ownership] is [also] unwaivable, as far as I know [i.e., the only way to receive ownership of my works is the same as any other property of mine: by sell, by inheritance, by a action of the Law - the term in PT-BR is "Direito Patrimônial"). So there's a good chance that such clausule is null and void on my country - i.e., it's plain ignored by any Court of Law around here, and any attempt to force it would be acting in bad faith (AFAIK). But yet… You have a good point to be discussed. I forgot about this, it was already discussed here, on Forum. — POST — POST — POST — EDIT In time, the EULA talks about copyrights, but not on TRADEMARKS. Perhaps an exploitable loophole?

read again. I will quote every paragraph on the ToS that mentions the word "exclusive". I quoted every single mention of the word "exclusive". Please pinpoint the paragraph where you think you are granting exclusive rights for the mods you post about here. Please note that your MODs are not hosted on the Forum, but on whatever you want. Your posts, emails, et all are hosted on this site (or their servers) and so, subjected to that rule. Please note, also, that your screenshots are not hosted in this site neither. Here you grant TTI the right to sublicense the material to third-parties. Well, we are (also) these third-parties, do you know? You don't want them to have such rights? It's fine. Don't post it on the forum. Talk about it on Reddit (but not on Steam, as the Steam Forums are contracted by TTI). Just don't mention it here, and I think you should be ok. Nothing about intelectual rights. To tell you the true, I think that they are saying that they could assume exclusively your defense if something goes wrong, what makes them co-responsible. I'm not really sure, but it appears that they willing to cover your SAS on this. I don't like this paragraph - but it doesn'y says anything about granting IP rights to them. So, out of scope of your argument. Same thing. — — — — And that is EVERY mention of the word "exclusive" on the whole Terms of Service. I failed to detected where TTI is claiming full and exclusive rights on your creations. Please, identify it for us.

But he had, already, granted you the rights? By email perhaps? No. He must grant TTI right to secure access for them for TTI's users. See the "non-exclusive," on the terms of service. You still own your work, and are free to do whatever you want from it (including selling it). What happens is that TTI wants that people that had downloaded something from this site remains able to keep downloading and using it for the years to come.

Additionally, the "last option" has the merit of being similar to the "Unix Way" - that even Windows is using nowadays. /usr, /usr/local and /home should be in different separated file hierarchies. Even Windows uses /Program Files ., /Users/<login> and /Users/<login>/Program Files . This make backups and management incredibly simple and straightforward. And less prone to errors. The GameData/ hierarchy should be sacred land - once KSP fire up, nothing should be allowed to change anything on there.

My aim is to make this irrelevant to my mods. No matter what the user (or third parties tools) does, the user's settings and custom data must be preserved. So I think we can start to consider one, right? That is my proposal. People that like it, will use it. People that doesn't like it, can use something else. I'm plain sure that someone else will "fix" what he consider flaws on my add-ons. It's the Open Source way. I'm on MacOS and Linux, where Mono is a nightmare on the good days, and a night of insomnia on the bad ones. But once I decided to use it anyway, and after some good hours of system mangling, I make that to work. I was terribly unlucky, as on the next day, a lot of add-ons where updated and one of them broke terribly my KSP. And I didn't know what of them. So I had to delete everything and install one by one until I find the problematic one, and then I rolled back only that one. Not CKAN's faulty neither of that - but it's not mine too, and doing things by hand became easier and safer. Knowing how to use Midnight Commander on my three boxes (MacOS, Gentoo and Win7+Cygwin) is something that is postponing any will on trying it again. Thanks, but no, thanks. This works for me. I'm not pledging to be the Maintainer of KJR, so this doesn't really matter. I'm doing this to make my life easier. If it makes someone else life easier too, I'll be more than happy. If others think the other way is better and use something else, I will be equally happy. Well… Just a bit less. — POST — EDIT — Thinking is a very healthy habit. I should do that more times. KSPe is a FILE ROUTER. There're absolutely nothing preventing me to tell it to use anyplace in the filesystem as being the root for the PluginData - from the place where it is, to the user's Document folder or DropBox/Google Drive/Whatever. All I need to do is to create a config, where the default will be whatever the user chooses. @Tyko, you will get what you want, I will get what I want - and whatever is the standard that the thread below decides, it will get what it wants. KSPe ended up being an idea better than I expected. I wish I could had such ideas on purpose, instead of by accident!!!

You do it also in sites others than the Forum?

Never be sorry by correcting other people's errors. Thanks for the info. However... :-) There're Trademarks and Registered Trademarks. Your mileage may vary, but at least in some coutries you don't need to register a trademark unless you need (or want) some additional rights. https://en.m.wikipedia.org/wiki/Unregistered_trademark TL;DR: It's the difference between (TM) and (R) on the trademarks And trademarks are covered on some Licenses. BSD explicitly forbids association with and use of the name of the licensor. Also, give a peek on what CC BY 3.0 says about. — POST — EDIT — This is my reasoning for trademark infringement being also a copyright infringement (at least, for some licenses): From the GPLv2: 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. My understanding is that by using a trademark (registered or not) that could lead you to court, where you could be told to stop the distribution, you may not distribute the program under the GPL. Since you can't distribute the program under the GPL, any guy that had received a copy of the work, had it without the GPL terms. So, or the work has an additional license, or the thing is A.R.R., and that copy is not licensed at all. — POST — POST — EDIT -- And this is my reasoning on the Forum Rules. From the Forum Guidelines: 1.3 Notices/infractions/bans Moderators work together and use their best judgment in each situation. If these rules are broken, any member of staff may hand out a fair punishment, e.g., removing content, issuing a warning etc. Harsher punishment (such as a ban) may be used when there is a severe or repeated offense. From the TTI's Terms of Service: (enphasis are mine) (1) you will only use the Online Services for lawful purposes, in compliance with applicable laws, for your own personal, non-commercial use; […] (3) you will not use the Online Services to create, upload, or post any material that is knowingly false and/or defamatory, inaccurate, abusive, vulgar, obscene, profane, hateful, harassing, sexually oriented, threatening, invasive of one’s privacy, in violation of any law, or is inconsistent with community standards; [..] (4) you will not post, upload, or create any copyrighted material using the Online Services unless you own the copyright in and to such material; […] By creating UGC, posting messages, uploading files, creating files, inputting data, or engaging in any form of communication with or through the Online Services, you are granting the Company a royalty-free, perpetual, non-exclusive, unrestricted, worldwide license to: (1) use, copy, sublicense, adapt, transmit, publicly perform, or display any such material; and (2) sublicense to third-parties the unrestricted right to exercise any of the foregoing rights granted with respect to the material.

They allow on Ships, Scenarios , Tutorials and GameRoot. They normalize paths to prevent "file leaking" (what is a good thing, by the way - avoid files going out of the KSP installment). Anyway, I don't meant to "save trouble" on using CKAN. I meant to save trouble on my day-to-day basis. Quitting PluginData is not an option, if by some reason I will not be allowed to do this on CKAN (what's unprobable, as I still can move things to their final place on first run) then I will not use CKAN.

Good question. I need to check this. In the event it isn't, I need to add a "first run" code to move the data to the final place. — POST—EDIT -- Yep. No CKAN for some time. This thing is a nightmare to use on Linux and MacOS, due the crappy Mono installers, so I don't use it (and already heard some people discussing on an alternative tool using the same data sources), so I didn't bored to check before. In a way or another, the mainstreams mods I maintain doesn't really need this (or it doesn't persist user settings, or create them from scratch on first run), so this is not a problem on the short run - my Experimental forks are experimental, they are not meant for mainstream yet. I don't even know how CKAN would cope with multiple forks doing the same thing (so they should be mutually exclusive), I never considered publishing anything "non official".

And there's the UNIX way: find . -name MiniAVC.dll -delete I made a bash script that I run every time I install/update something. On the list of things it does, there's the command above. (and I removing that from everything I distribute too. It must had made sense at the time, but nowadays…)

Whoopsy… I totally misunderstood you. Sorry. You are right - I can't even remember the last time I used KJR from another fork than not mine, so I totally missed that. Thank you for bringing it to the discussion. I need to update the README of the project to make this clear! (that PHD thesis I wrote were meant to explain why I did what I did) In this case, ~/Library/Logs/Unity/Player.log will also be useful. Now and then, this file have some bits of information not found on KSP.log.

Humm... It's this we are talking about since the start? I'm a bit "legalistic", I talk by the letter of the law. Perhaps I I missed what you are meaning and attached myself to what you wrote instead. The name "KerbalJointReinforcement" is property of Ferram4. Point. There's no argument about. Anyone willing to use this name need his explicity and registered permission. Using this name without it is a copyright infringement, subject to sanctions from the license and from the law. You are right, a renaming is needed. But also a reasonable effort to prevent anyone to misrepresent your derivative with the original. KJR2 I don't think it's good, it implies a follow-up from Ferram4. Adding "Continued", "redux", etc, should be OK due Forum Rules. But don't try using "Star Trek Continued" stunt on Real Life, Paramount will sue you for sure.

There're no such thing. Every single "material" is copyrightable, no exceptions. One can grant public domain on his IT, but it's still a copyright. He just granted unrestricted rights on it. So you need to find a License that allow it. What's intrinsically wrong. "Open Source? So it's not stealing" is the right claim. If you don't like it, don't do Open Source. You can't have the cake and eat it too!

It looks as some add-on doing heavy computations for some time when the Start Menu appears. Then you hit "Quit", things start to get destroyed on memory before that heavy computations are finished and the add-on start to bork due it, and since KSP is being finished when it doesn't expect an add-on raising exceptions, Krakens are unleashed. How much memory has your rig? What's the CPU and OS?

Well… so let's go back to the basics. When licenses are involved, the only <redacted> ones are the ones in license violation. If you read carefully the licenses involved, you will find that every one of them explicitly forbid adding any other restrictions beyond the ones stated on the license, and, unfortunately, that's final and it's not open to debate: It's the license, comply to it or use something else. Some licenses are even harsher, they revoke the rights if you, intentionally or not, violate some of their terms - adding restrictions one of such violations. By any perspective you use, it's impossible to demand such "respect" by using any of the Open Source licenses accepted by the Open Source Org. And for the most used licenses used here, it's also a license violation itself, liable to rights revoking what could render the licensor in bad situations. Dura lex, sed lex.

Well.. I failed to reproduce the problem here, without simulating one of the errors I explained before. I redownloaded the ZIPs from the github and use them, to be sure I'm using exactly the same files as you. I used this craft (from that issue where I chased my tail, link on the text). The only other situation I can think on is the @wolderado fork had added something to config.xml that I didn't, and your craft ends up using exactly some of that modules. — POST—EDIT -- There're another hypothesis - I had problems in the past with a guy trying to use something I compiled . I'm using MacOS, and he was using Windows. Since them, I compile against Windows's libraries (rendering DLLs that works on MacOS, Linux and obviously Windows) and never heard of this again. It's a long shot, but perhaps we found yet another occurrence for this Unity's idiosyncrasy.

Craft file and KSP.log, please. If you install the config.xml on the wrong place, it will not be read - and so, KJR will not know what to do as this file is what tells it about it. If you have two .dll in the system, I don't know exactly what will happen, but I'm guessing that both will instrument the vessels with twice the joints, and your KSP will be sluggish. And, finally, if you don't install KSPe, "my" KJR just won't fire up, it's a hard dependency.

Wow! 1.0.2? The oldest I use to check some of my add-ons is 1.2.2 !! (I'm the current TweakScale maintainer, by the way) I don't even know if I have this version available for me on Steam!! <some minutes checking> Yeah, it's available from Steam, so I have access. @Xd the great is right. You need a proper release specially for your KSP version. 1.0.2 is from May, 2015 - way before my time . You need the V2.1 version available here: https://kerbal.curseforge.com/projects/tweakscale/files (it's the last file on the bottom on the page 1 at this time). Perhaps you could walk away using a version for 1.0.4 or 1.0.5 (as it can have more bugs fixed, in theory) but I recommend starting with the V.2.1 from May 2, 2015. [ I forgot about the Module Manager! Unfortunately, I didn't found a MM compatible to 1.0 series! Working on it!!] You can reach me more easily on this thread if anything goes wrong:

It's the Unix way. Mixing "code", "program data" and "user data" on the same hierarchy it's not only messed up, it's plain dangerous. The GameData folder should be 'sacred" (ideally, read/only at runtime), as it is the /usr and /usr/local file hierarchies on Unix machines. Even Windows does that, with /Windows, /Program Files and /Users/<your_login> file hierarchies. Backups are a nightmare, to say the least. Since you don't know what is changing and what's is not, you need to backup the whole GameData! My GameData currently have 7G of data, while all my PluginData has less than 2M. Now do the math and see how much easier is to backup my installments between one test and another. In time, since I play on Unix machines, I built a script that copy and symlinks the data folder from the add-ons (that I didn't forked) to PluginData, simulating what KSPe would do (in a hardcoded way, but whatever - it works for now). Since this, I don't have the slightest worries on using my "production" installments to test things. All I need to backup is PluginData and saves, and then I can mangle whatever I want without the fear of messing up my game. Yes. Right now, all my tests using the very same binary (The Experimental built) of KJR (and KSPe) worked flawlessly on KSP 1.2.2, 1.3.1, 1.4.5 and 1.5.1 (the ones I explicitly test it - it should work on everything from 1.2.0 to the latest 1.5.1, I just didn't cared to test).

It's how it works on my add-ons. KSPe has, currently, two critical facilities that my add-ons heavily relies on: centralised, runtime configurable and (in the near future) routable logging and data files "routing". Every single file that could be edited by the user, or that is written with user settings is not on GameData anymore. The plugin asks KSPe for a location, and KSPe gives him a file handler for it to use. Right now, it's all on KSP/PluginData , but since this is not hardcoded on the add-ons, in the near future this can be even configurable - one would like to have it on "My Documents" folder, right? With KSPe, it will be possible. It's not being used. Anything you put there is being ignored. The config.xml must be on <KSP>/PluginData/KerbalJointReinforcement/config.xml or it will not be found.

On MacOS cmd+Q will do exact that. On the spot, no questions asked. On a windowed window on Windows (urgh), Alt+F4 should do the trick. On fullscreen, I don't remember...

whoops… I need a bit more sleep, as it appears. https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/releases https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/PRERELEASE%2F2.1.0.1 KSPe is still beta, not mature enough to be used by third parties - but it's stable, and worked flawless on KSP 1.2 to 1.5.1, as well KJR - but it has a known issue: every single dependency on your KSP must be satisfied, I didn't handled properly when a DLL has a hard dependency unsatisfied and the reflection fails. I'm dragging my feet on it as I use it as a miner's canary on my test beds… (yeah, shame on me) The Experimental release has improved logs, this will be merged into mainstream in the next release. Please consider the whole shebang experimental (being the Experimental, heavily experimental). Backup your savegames - just in case. I never loose anything with KSPe neither KJR (and I'm using both on all my KSP installments), but at the moment, it's all I can say about. Extracted the whole shebang on your KSP_ROOT. The GameData contents should go to KSP_ROOT/GameData , and the PluginData contents into your KSP_ROOT/PluginData. All user customizable data (and settings) on my Experimental add-ons goes there, you don't have to worry about loosing data when deleting things on GameData anymore. At the moment, yes. I do not merge dependencies on the main distribution, it's too cumbersome and error prone for Experimental forks. You overwrite KSPe with an older version, and your KSP is kaput. And this can be somewhat hard to diagnose, as one would delete only the last add-one installed, without restoring the original KSPe - and now we will have a really angry user without knowing what happened. About that 1.4 thingy, I will issue a new release tomorrow (holiday around here) "repacked" to work on KSP 1.2 to 1.5.1 without bugging the user.

And that was sweet - and unexpected. I noticed that my DLLs compiled on 1.5.1, 1.4.5 and 1.3.1 had exactly the same size - not exactly what I expected, since changes on the DLLs would imply in changes on the CIL and I was expecting a few bytes change, as I already saw happening before. So I wonder… "What if?" So I installed KSPe 2.1 (Pre Release) and KJR Experimental on my 1.3.1 and 1.2.2 test beds, adapted the KJR Issue craft (as these versions doesn't have some parts) and fire them. Surprise: both worked flawlessly. So I deleted KJR from both, and tried again. The craft spaghetified as expected. I conclude that, at least for the basic parts, the physics for the joints didn't changed (or didn't changed to the point of breaking the interface). So there're no real reason, as it appears, to recompile the thing on every KSP from 1.2.2 until 1.5.1 - as my Experimental DLL was compiled against 1.5.1 and worked flawlessly down to 1.2.2 . Of course, I don't expect this to happen everywhere. But I have evidences that I can "universalize" the KJR distribution, saving me and the user some work on the thing. Problems, if detected, can be handled on the black-list on the config.xml - something infinitely easier to manage than a whole binary package. As a bonus, I probably (still to be confirmed, but evidences are promising) can extend support for some add-ons of mine to 1.2.2 and 1.3.1 users (and yes, there're still some die hards on them!). That code that prevents KJR from running was, frankly, over-zealous.