Lisias

Use Steam/Console. It's tricky, but it's how I did it. Also… Google is your friend. https://help.steampowered.com/en/wizard/HelpWithGame/?appid=231410

I have a MM prototype doing exactly that. It works flawlessly. I got some issues with some mods (needlesly, by the way) accessing the cache files - funny thing is that the 'fix' was just to remove that code, as whatever they were trying to accomplish, KSP already had done that (verified, I provoked the problem they were trying to prevent and double checked it). However…. Mods that creates CFG (and other assets) that need to be accessible by the KSP engine from the GameDatabase, they *need* to be on GameData somehow. So I got that "/usr/local" idea . Since KSP usually load things ordered by name (probably using linq, by the way, I managed to simulate exactly the ordering by using linq), I choose to put all of that on a directory name to something that would be loaded last for sure - mainly due UbioWelding. So I'm playing with "GameData/__LOCAL/<mdname>/<what_the_mod_wants>". Not so "perfect" as keeping the GameData writeless, but at least all the "local data" are confined on the same place, and GameData continues to be in pristine condition. This idea is in production on my KSP for some months now. Including the __LOCAL stunt. I moved the KerbalKonstructs's NewInstaces to GameData/__LOCAL/KerbalKonstructs/NewInstances and symlinked it to the original place - not the best of the ideas, as now things are loaded twice and I didn't cared to though on the problem yet. One possible hack is to use GameData/__LOCAL/PluginData/KerbalKonstructs/NewInstances for that, but I didn't test it yet. And for the ones willing to take their chances with KSPe this is not a problem, as add-ons using KSPe open files using a internal mechanism that derives the name using introspection and the root for that sub filesystem can be changed to anything in the World without affecting the client DLLs. It's a user setting? It's a file that the user is expected to edit (as config.xml from KJR, to activate the debug mode)? So it should be on a different place. It's something that is never changed by the user? It stays where it is. Just MM or KSP too? The info I got above is that KSP would ignore such directories. This information is vital to me, as this can force me to rethink some things, as the one I proposed on this (merged) post.

Steam still have the demo for download. It's a bit tricky to find the link, but it's there. And there's also this : https://forum.kerbalspaceprogram.com/index.php?/topic/131906-the-earliest-versions-of-kerbal-space-program/&amp;

Dude. You are chatting with a bunch of naked monkeys that enjoy wasting time watching green little men/gals being exploded on half baked rockets flying on a 1/10th scale simulated solar system using physics that are not like anything in real world. This is a bin. We are the loonies on the bin.

can you please run what follows on a terminal window and screenshot the results? less "/Applications/Games/Kerbal Space Program/PluginData/KerbalJointReinforcement/config.xml" You need to have something like this:

Thank you. It was not clear on the repo. If you allow me, may I advice to commit on the repo a screenshot and a link to the post with the permission? Just in case - better safe than sorry!

Going for MIT is probably the safer option, but had you secure permissions from magico13, rem02, phwoelfel, fommil and Kerbas-ad-astra? StageRecovery was originally released under the GPL3, and you need (registered and trackable) permissions from every committer in order to relicense it - under the sanction of having the GPL revoked for you - rendering your whole worked unlicensed, unless an additional license was granted to you. It's unfortunate in this case, but you do not have the rights to relicense other people's work - only the Copyright Owner(s) of the work can do it, and ownership is the one thing that GPL does not grant to you.

It was the logic conclusion, as you proposed a 'democratic vote" by all users, without considering if the developers would agree with such decision. And even if only developers could vote, how you would convince the ones that voted "no" to comply? It's how life works. CRP and CTT were things that developers agreed to use, as it would be benefcial for them. Users got beneficed too, but that decision was took individually: "should I use this or is better to add my own?". And, guess what… Some add-ons choose not to use them. Some are "compatible" in the sense they doesn't stomp on each other's toes, but one or two I had to adapt to coexist to CRP but without using it. Things doesn't works exactly as you think.

Managed to load it. Without KJR (any of them), the booster are bouncing on the LaunchPad and on flying, but with "my" (and probably any other one recompiled without the KSP version lockl), it works as expected. It's something on your runtime. We will check this soon. https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/issues/3

And once such democratic consensus are reached, how you would force the modders to follow it? It's nonsense. For the add-ons that are Open Source, the solution is clear: fork it and update it yourself, or use the fork from someone else that did it. While every License is being respected, nobody will have problems. Some add-ons are working flawlessly since 1.2.2 (I tested ir on 1.2.2, 1.3.1, 1.4.5 and 1.5.1) without modifications or even recompilations. For at least some add-ons, this will not be a hard work.

I agree. User wise problems usually are solved by forking, and the developers perceiving people migrating to forks where the desired feature is implemented and then, merging the features to their products. Essentially, it was what drove Open Source products ahead in the past - from EMACS to every new Linux distro still in existence.

By no special reason, I remembered this one today.

I agree. If you edit a craft file on Notepad and change something on it, the thing is still "stock". It's even "vanilla stock", not a single add-on needed. But still, this stunt is not feasible using only KSP - don't know how to call it. Hell of a hack. Kudos, @buguniao!

I'm downloaded the files, and got almost all the mods. But I didn't recognized or found what follows (neither KerbalX): USGuidanceComputer USKASWedge Large.Crewed.Lab.6

Probably yes, but subject to further investigations. Volunteers?

A "file router" for add-ons I'm prototyping. From the DLL point of view, you can move anything to anywhere - if it uses KSPe, it will be found (and also any files with it). Doesn't works to Parts, obviously.

I have mixed feelings about this one. On parts, the textures and models "names" are derived from the filesystem path where the asset are. Things will work for that add-on, but other add-ons willing to access the same assets will bork. For while, I only use a "Vendor" subdir (as I call it on KSPe) for add-ons that doesn't have parts. Impossible Innovations, on the other hand, will be in the GameData/ImpossibleInnovations so anyone that had used an asset from II in the past will continue to use that asset without modification.

The main reason is other (but I got a misbehaving add-on once - programming bug, created some garbage on the dir). Think DevOps. If the add-on's code/static data is readonly, it can be symlinked/junctioned. You have a lot of installations (I do)? You can have a pool of add-ons on a special place, and symlink/bind/mklink what you want on where you want. On demand. I can't tell how much easier and faster it's to create test beds for testing specific bugs or add-ons across multiple KSP versions this way. I know, it's how I do it nowadays now that everything I have used KSPe for file routing (what renders my GameData immutable between launches). Switching versions is recreating symlimks/binds/mklinks. Deleting Making History is deleting a symlink. Reinstalling it? Recreating the symlink. OPM, Origins, or some othe huge planet pack? One physical copy, multiple symlinks/binds/junctions. Life could not be simpler. :-)

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!!!