Lisias

Real-life is an issue for everybody, including me. Every hour one expend fixing something, it's an hour we doesn't expend playing with something else. Fixes can bork - usually we mess up one or two times until we got it. If the maintainer hasn't the time to fix the problem, would he has the time to fix the fix? This way we are doing know, when he find the time to update, he will gain the fixes implementated and validaded on the field. Ideally, more than one fix so he can even choose the one he likes more. Pull requests works both ways. He can merge back the code from anyone that had forked his own, he doesn't have even to ask - it's the Open Source way. And with us tacking down problems openly here, he don't have to search by himself neither: all the needed info is already consolidated to be analysed. :-)

Ok, boys. New toy - and this one is working. (I think). Release 3.4.0.1 for KJR/L here. It's advised (but not needed - the "bug" was harmless) to update KSPe to 2.1.0.2 here. And if someone is willing to know what happened, a PHD thesis about this mess can be found here: https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/issues/3#issuecomment-443509433 — POST — EDIT -- A new release was issued. No big deal, if you don't use Ground/Global Construction , you don't need to rush into updating from 3.4.0.1 (that was ditched) in time, this is the Saint Graal of this saga: [LOG 19:19:54.701] [KerbalJointReinforcement] INFO: Configuration file loaded.

The CSharp plugin for Eclipse is terrible!

That's why I eye ball everything I merge. And I failed on this twice. well, small commits are good commits. I will avoid merging large chunks of code at once in the future. about typos... I'm almost asking forum to be hosted on Github, so many are my editions on my posts. Jeez, would I had to earn a living by writing, I would starve to the death! watahell² ??? O.o I'm trusting automation too much. Anything changes, the scrips silently fail on me. I will fix this tomorrow. — POST — EDIT — Thank you very much for the heads up. Your hint pinpointed an error on my automation scripts, what leaded me to testing the wrong DLL while publishing a (probably) untested one.

My Favorite Editor for CSharp development is Monodevelop, that I can't compile again on my machine due an update from Apple. this is my problem. Somehow, Apple broke the MacPlatform.csproj from MonoDevelop. I can't even compile again the previous version as I did some months ago. In a nutshell, I can't do exactly what you suggested me to do!

Agreed²

Nothing changed on Remote Tech since I released my last binary. I also found @PiezPiedPy repository here, and what he did is EXACTLY what I did - that was exactly what he told me to do! I used the latest Remote Tech DLL from the official distribution, just to be sure. There's something more on this that what you are telling - I recompiled my code-tree against 1.4.1 (that I used originally), 1.4.5 and also 1.5.1 just for the lulz, and I got exactly the same binary I published on August, 26th. Be aware that I "locked" my CC_RemoteTech.dll to work on the same ContractConfigurator I compiled, that it's not the same one that is from the last Official Distribution. I also locked it to work with Remote Tech 1.8 and above (currently, it's on 1.9 version). You can't use "my" CC_RemoteTech without meeting these requirements: [assembly: KSPAssemblyDependency("ContractConfigurator", ContractConfigurator.RemoteTech.Version.major, ContractConfigurator.RemoteTech.Version.minor)] [assembly: KSPAssemblyDependency("RemoteTech", 1, 8)] Where: namespace ContractConfigurator.RemoteTech { static class Version { public const int major = 1; public const int minor = 25; public const int patch = 0; public const int build = 2; public const string Number = "1.25.0.2"; public const string Text = Number + " Unofficial"; } } Since the upstream's AssemblyInfo says: [assembly: AssemblyInformationalVersion("1.25.0")] [assembly: KSPAssembly("ContractConfigurator", 1, 0)] It's clear what's happening: you are using "my" DLLs with incompatible binaries. We don't mix DLLs from different sources and expect it to work properly - and since I don't intent to stomp on the Maintainer's toes, my DLLs are 'designed" to work only with the DLLs from the same package they belongs. You gave me gave me a run for my , my friend. And hinted me that I need to proper instruct people to do not mix DLLs and assets from my Unofficial distributions with the Official (or other unofficial) ones! I created this issue just for you! https://github.com/net-lisias-kspu/ContractConfigurator/issues/1

./GameData/KJR: total 200 -rwxr-xr-x@ 1 <d>staal staff 122 Oct 18 16:08 Instructions.txt -rwxr-xr-x@ 1 <d>staal staff 43520 Oct 18 16:03 KerbalJointReinforcement.dll -rwxr-xr-x@ 1 <d>staal staff 35120 Oct 18 15:57 LICENSE drwxr-xr-x@ 3 <d>staal staff 96 Nov 21 20:32 PluginData -rwxr-xr-x@ 1 <d>staal staff 16363 Oct 18 15:57 README.md ./GameData/KJR/PluginData: total 0 drwxr-xr-x@ 2 <d>staal staff 64 Oct 30 19:42 KerbalJointReinforcement ./GameData/KJR/PluginData/KerbalJointReinforcement: << WHERE IS CONFIG.XML?? >> ./GameData/KOOSE: Whatever the version of KJR you are using (I don't remember doing a release on the original KJR folder), it's not working as the config.xml is not on the original place! About the file permissions… They are similar to what I have here. As long you run KSP with your account, things will work fine due some files having this "-rw-r--r—" - any other user would had the "-w" permission, and at least for me (and on the last time I checked it!), KSP have a problem with r/o DLL files. Don't ask. Hummm.. Yeah. "<string name="exemptModuleType9">ModuleDockRotate</string>" is the dup . Will be fixed in the next release - but it's harmless, don't bother to fix it on your installments.

There's a option on the config.xml called "debug". Shove a '1' on it, fire up your KSP with the 3.4.0.0 KJR and then post the log file here: https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/issues/3 If there's anything wrong on KJR, the logs will show for sure. Just don't fart while playing, it will be logged too. It's not a duplicate, it's a typo from one of source branches I merged. I didn't had the time do figure out what one is the right (with or without "s") so I leaved both.

And then I had to download that whole piece of Kraken's Poo called Visual Studio for Mac, as I can't compile MonoDevelop on my machine anymore due some <insert your favorite non-forum compliant "compliment" here> update on my MacOS. Having to handle Unity us already bad enough - I prefer to use Blender with the KSP plugin to use that piece of KRAP. But now, I have to use VS too - with all of the enormous amount of <insert your favorite non-forum compliant "eulogy" here>. Software Developers are something that I'm starting to hate more than I hate lawyers. And I'm a Software Developer.

Problems will be solved when people solve them. An Official version should merge the fixes (or perhaps solve it in a better way), but until this happens you will need to choose between fixing it yourself (and then, why don't share the fix?), choose an Unofficial fork that solve your problem without creating another (it can happens!), or play KSP without it.

I have a n Unofficial that works with RemoteTech. There's a branch called "Experimental". Keep away from that (and from any zip with this on the name), I made a mistake on that branch and didn't fixed it yet. https://github.com/net-lisias-kspu/ContractConfigurator/releases

I don't need such a feature, my vesses already drop and burn on reentry by themselves

On 1.3.1 times, when they forgot or messed up the helmet's collision meshes, perhaps. From 1.4, at least for me, falling from the VAB is enough to kill mine!

What's still the least of your problems! It's not the speed that kills you. It's the sudden stop!

If you are plummeting to the ground above Mach 1.5, I think that the parachutes are the least of your problems!

Alternatively, perhaps they had awaited you finishing your renovation fest before sending you the letter.

Auto Struts are tricky due the way they works. When you autostrut to the heaviest part, and then dock to something heavier or that part that was heaviest is a fuel than and became lighter, autostruts will rearrange themselves and this can make the vessel(s) to oscilate heavily, sometimes above the stiffness of the parts. So things blows up. I carefully choose a root part and than autostrut it to root. This helps a lot. But as far as I know, KJR is the one that solves it properly as it just created or destroy joints, without rearranging them - the reason for oscilations that can be the reason for Unplanned Rapid Disassemblies. Or put lifting surfaces on KJR's exempt list on config.xml

Thank you! :-) i'm glad you offered help. Currently, I have a issue with the resource naming. By some reason, the new names I choose works but are rendered chopped on the screen. Do you want to try some new names on the resources to see what happens?

If this is what you get when things don't work, I wonder what Krakens you will accomplish when you manage to make it work!

So he broke the GPL terms, rendering the GPL "null and void", and then the whole shebang is ARR. Including third-party material. Do not redistribute that tarball. Don't even post the link.

I do some modding. And use my save games to test things (backups, obviously). Once I made a really huge and stupid mistake that prevented a lot of mods to load. Didn't realized until I loaded a savegame with a very important career, had everything ruined by disappearings or explosion and, after quiting KSP, I realized I forgot to backup the thing. About two weeks of heavy playing vanished. At least I have the screenshots.

Understood. But you raised a really important issue - so I thought it would be a good idea to publish what I found about. When I decided to remerge things, I didn't had thought about this - it was motivated sorely to make the code review easier, it's hard to detect small errors and typos on a huge tarball of code. But, frankly, now I would do it ii had not done it before, as it enhances traceability. It's now easier to follow up the merges and pinpoint the source of the commits. — POST — EDIT -- In time… What do you mean as "code' ? He published the source code? How? Where? The Add-On is GPL, so if he published the thing in any form, it's also GPL - unless he deleted the license terms and mentions, what renders his own code as ARR and the rest as unlicensed (i.e. in copyright infringement). Unless, of course, he only published his code (as a git patch, for example).

Besides not being exactly about "etiquette", it's about licensing. I had came to my attention a situation in which a GitHub repository could be on copyright infringement due a hypothetical unreleased code that could had been merged. This is to clarify that, as long pull request itself is not forged (if this is possible) and the committer is the author of the material (and he's not committing himself unlicensed material), at least on GitHub, such commits are licensed under the same license as the repository receiving the Pull Request. Does my project need an additional contributor agreement? Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make “inbound=outbound” the explicit default. Source.

If he never released the code, how could I had merged it? Or had someone improperly committed his code, and everybody that cloned that repo is tainted? — POST — EDIT — It's was a valid questioning - so I dig up again on the commit history (better safe than sorry). Well, every commit from MeiruMeiru that I had merged has the header stating the authorship from ferram4 and MeiruMeiru as well a GPL notice. So, as far as I know, unless that commits were forged somehow, I only merged GPL code. But yet, good to know about that "v2". I will keep an eye about. — POST — POST — EDIT -- To prevent polluting this thread with unrelated material, I posted the follow up here.