[1.3] Kerbal Joint Reinforcement v3.3.3 7/24/17

[linuxgurugamer]

10 minutes ago, shifty303 said:

Hey everyone, this mod and the fork from @linuxgurugamer and the fork from @Lisias don't seem to work in 1.5.1. Here's a simple ship that's always worked in previous versions but bends like a noodle in 1.5.1.

https://imgur.com/tKh1K54

ummm, maybe because I didn't compile it for 1.5 yet?

[shifty303]

1 minute ago, linuxgurugamer said:

ummm, maybe because I didn't compile it for 1.5 yet?

Maybe that's why... I had yours installed originally so that's why I noticed it first. Then I tried the original and another fork that I thought included your modifications but was compiled for 1.5.

[Lisias]

7 hours ago, shifty303 said:

Hey everyone, this mod and the fork from @linuxgurugamer and the fork from @Lisias don't seem to work in 1.5.1. Here's a simple ship that's always worked in previous versions but bends like a noodle in 1.5.1.

https://imgur.com/tKh1K54

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

 

6 hours ago, shifty303 said:

Maybe that's why... I had yours installed originally so that's why I noticed it first. Then I tried the original and another fork that I thought included your modifications but was compiled for 1.5.

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.  



 

Edited November 19, 2018 by Lisias
MOAR INFO

[Lisias]

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_Killed_Jeb]

A BIG shoutout to @linuxgurugamer and @Lisias, as well as all the tireless KSP do-gooders here. Your work is extremely appreciated, if seldomly noted.

[Lisias]

13 minutes ago, I_Killed_Jeb said:

A BIG shoutout to @linuxgurugamer and @Lisias, as well as all the tireless KSP do-gooders here. Your work is extremely appreciated, if seldomly noted.

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.  

Edited November 19, 2018 by Lisias
tyops as usulla...

[Lisias]

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.

Edited November 19, 2018 by Lisias
tyops as usulla...

[Geonovast]

Wait - so does that mean your KJR is good for 1.5.1?

Because without KJR, I will become one of those diehard 1.3.1 users again.

Please say yes Please say yes Please say yes Please say yes Please say yes

[JH4C]

We need to use the 1.4 version of KSPAPIExtensions to get this working on 1.5? It'd be nice if this could still be a self-contained mod.

Edited November 19, 2018 by JH4C

[Tyko]

@Lisias thanks for working on this!

Your releases have two folders - GameData and PluginData. Do I need to do anything with the contents of PluginData to play the game?

[FreeThinker]

14 hours ago, Lisias said:

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.

So where can we download it?

[Snark]

Moderator's note:  A large swath of posts derailed this thread for a page or two, going into a completely off-topic debate about mod licensing and "etiquette".

A worthwhile discussion, but not about KJR itself and therefore doesn't belong here.  Those posts have been split off into their own thread, so please continue that topic over there if that's what you'd like to talk about:

Let's try to keep it on-topic here, please?  Thank you for your understanding. 

[capi3101]

14 minutes ago, FreeThinker said:

So where can we download it?

https://github.com/net-lisias-ksp/Kerbal-Joint-Reinforcement/releases

[Lisias]

40 minutes ago, FreeThinker said:

So where can we download it?

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.

1 hour ago, Tyko said:

@Lisias thanks for working on this!

Your releases have two folders - GameData and PluginData. Do I need to do anything with the contents of PluginData to play the game?

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.

 

1 hour ago, JH4C said:

We need to use the 1.4 version of KSPAPIExtensions to get this working on 1.5? It'd be nice if this could still be a self-contained mod.

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.

Edited November 19, 2018 by Lisias

[Geonovast]

Yes!  Thank you @Lisias!

Installed KSPe and KJR in an otherwise stock install (had to create the PluginData folder... wasn't there for some reason), but it seems to be working!

[Geonovast]

Actually... I built something bigger and I'm still having some noodlyness.

Before digging further, this is the correct directory structure, yes?

[FreeThinker]

6 minutes ago, Geonovast said:

Actually... I built something bigger and I'm still having some noodlyness.

Before digging further, this is the correct directory structure, yes?

@Lisias  Seems to me the Zip file for the experimental is all wrong, it contains a GameData and Plugin folder in the root, this will never work!

[JH4C]

1 hour ago, FreeThinker said:

Seems to me the Zip file for the experimental is all wrong, it contains a GameData and Plugin folder in the root

 

3 hours ago, Lisias said:

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.

It's a unique method of storing settings, not sure if it'll catch on but I can understand the thinking behind it.

ETA: It should also be noted that the latest release of KJR uses a different folder name to the previous major releases, so people need to be sure to clear out the old version before installing the new one.

Edited November 19, 2018 by JH4C
extra thoughts

[DStaal]

4 hours ago, Lisias said:

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.

I know I've tried to push for something similar a couple of times, but since I didn't have a mod which needed settings it was hard to push...

[Lisias]

4 hours ago, FreeThinker said:

@Lisias  Seems to me the Zip file for the experimental is all wrong, it contains a GameData and Plugin folder in the root, this will never work!

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.

5 hours ago, Geonovast said:

Yes!  Thank you @Lisias!

Installed KSPe and KJR in an otherwise stock install (had to create the PluginData folder... wasn't there for some reason), but it seems to be working!

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.

[Lisias]

3 hours ago, JH4C said:

ETA: It should also be noted that the latest release of KJR uses a different folder name to the previous major releases, so people need to be sure to clear out the old version before installing the new one.

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.
 

Wait - so does that mean your KJR is good for 1.5.1?

Please say yes Please say yes Please say yes Please say yes Please say yes

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).

Edited November 20, 2018 by Lisias
adding a reply to save some spam on the thread.

[DStaal]

@Lisias - Your most recent build didn't work for me.  I went to launch a ship and the side boosters looked like they were mounted on springs instead of decouplers - even after I added some struts on.  I reverted back to @wolderado's version, and the ship was fine.

[Lisias]

29 minutes ago, DStaal said:

@Lisias - Your most recent build didn't work for me.  I went to launch a ship and the side boosters looked like they were mounted on springs instead of decouplers - even after I added some struts on.  I reverted back to @wolderado's version, and the ship was fine.

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.

Edited November 20, 2018 by Lisias
more info.

[DStaal]

49 minutes ago, Lisias said:

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.

I don't have time to fire KSP up again tonight (why I didn't have them attached already...).  I'll get them tomorrow.  I do have the config.xml file in the right place and KSPe installed.

[Lisias]

48 minutes ago, DStaal said:

I don't have time to fire KSP up again tonight (why I didn't have them attached already...).  I'll get them tomorrow.  I do have the config.xml file in the right place and KSPe installed.

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.

Edited November 20, 2018 by Lisias
moar hypothesis….