Lisias

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.

Add to it a really big laugh on me testing and checking everything and the kitchen's sink - BUT NOT THE AWAKE AND START HANDLERS.

I'm an idiot!!!" Problem solved. It was not the 'compiling' part, KJR prevents itself from running when it detects an incompatible KSP. I already knew that (I built an 1.4.1 version, right?) but forgot about. New release on my github in some minutes.

I can do it with a custom spider, but… How Forum copes with that? I give a peek on the robots.txt and it appears to allow it (only one bot is disallowed). There're some limits I must respect? I don't intent to be locked out due a misbehaving bot!

Yeah. Known issue, I spent my Sunday trying to figure out what's happening. https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/issues/1 No. Usually recompiling fixes Reflection exceptions on hard bindings- the add-ons that don't work and don't throw reflection exceptions but are fixable by recompiling are the ones that handle the Exceptions themselves no runtime by soft binding (I already saw someones that use an empty try… catch on them - not exactly a good idea). I recompiled KJR against 1.5.1 libraries anyway - and got the exact same results. This issue is fighting back, there're no easy way out of that. — POST—POST—EDIT -- Further evidence that this IS NOT solvable by recompiling is that I took the dll I used on 1.5.1 (recompiled to 1.5.1) and… it worked fine on 1.4.5.

#sigh Well… Some debugging is on the schedule.

It can be both. It usually does, by the way.

On the other side, you can only do what they allow you to do. For every single thing you is able to do, someone had to think, decide if they want you to do so, and then implement. It's the exact opposite from KSP, where they allow us (and even encourage us) to tinker in whatever we want. We can change absolutely anything on the game, from the Aerodynamics' engine (see FAR) to the Orbital Mechanics' (se Principia). You can't have the cake and eat it too. Or we have KSP as we have and love, or we don't.