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

[MikeO89]

On 10/18/2018 at 11:03 AM, wolderado said:

No problem. Just be careful. I don't know what I did

Well whatever you did is still working for me in 1.5.1. Since it's working fine at the moment and the dreaded noodle joints have not returned, I'm not going to touch anything. When I get the game running just right, I hold my breath each time a new mod or game update comes out. Comes with the territory of running with mods and praying they don't turn on you and eat you up.

Edited November 20, 2018 by MikeO89

[DStaal]

10 hours ago, Lisias said:

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.

Possible - but I use MacOS as well.

I'll get you those logs as soon as I get a chance.

[JH4C]

14 hours ago, Lisias said:

It's the Unix way.  

<snip>

An interesting discussion point, but totally unrelated to what I was saying. The last few dozen releases of this mod used the folder <KSP_ROOT>\GameData\KJR but this version uses <KSP_ROOT>\GameData\KerbalJointReinforcement. That's why I said people needed to make sure to clear out the old mod first, otherwise they may have conflicts due to there being two KerbalJointReinforcement.dll files being loaded.

[Lisias]

33 minutes ago, JH4C said:

An interesting discussion point, but totally unrelated to what I was saying. The last few dozen releases of this mod used the folder <KSP_ROOT>\GameData\KJR but this version uses <KSP_ROOT>\GameData\KerbalJointReinforcement. That's why I said people needed to make sure to clear out the old mod first, otherwise they may have conflicts due to there being two KerbalJointReinforcement.dll files being loaded.

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)

 

44 minutes ago, DStaal said:

Possible - but I use MacOS as well.

I'll get you those logs as soon as I get a chance.

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.

Edited November 20, 2018 by Lisias
avoiding cluttering the thread with multiple posts of mine,

[FreeThinker]

16 hours ago, Lisias said:

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.

3

But won't this structure be incompatible with CKAN?

 

[Lisias]

13 minutes ago, FreeThinker said:

But won't this structure be incompatible with 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".

Edited November 20, 2018 by Lisias
more info.

[FreeThinker]

13 minutes ago, Lisias said:

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.

I thought it was not allowed to get outside of GameData folder. Why not put it in the same folder as the mod is located, it will save you a lot of trouble I think

Edited November 20, 2018 by FreeThinker

[Lisias]

8 minutes ago, FreeThinker said:

I thought it was not allowed to get outside of GameData folder. Why not put it in the same folder as the mod is located, it will save you a lot of trouble I think

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.

Edited November 20, 2018 by Lisias
hit "Save" too soon

[Tyko]

@Lisias Despite moving things out of GameData being "good coding practice" I think it'll cause a ton of confusion and issues for players and for supporting the mod.

I'd humbly suggest you use GameData if at all possible so you don't face wave after wave of "this mod is broken (because I install all other mods one way and this mod installs a different way and I didn't bother to read the readme)"

Consider the KJR doesn't have any visible sign that it's working. People may not even know it's not working right versus just not strengthening the joints as much as they expected.

 

Edited November 20, 2018 by Tyko

[linuxgurugamer]

2 hours ago, Lisias said:

nyway, 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

CKAN  can do this, but I second @Tyko in that this will be one of very few mods which do this.  In my mods, I use a different layout:

GameData/modname/PluginData

Seems to work well.

[DStaal]

1 minute ago, linuxgurugamer said:

CKAN  can do this, but I second @Tyko in that this will be one of very few mods which do this.  In my mods, I use a different layout:

GameData/modname/PluginData

Seems to work well.

I *hate* that layout.  It means I lose my setting every time I update a mod.

To add to the above: If it has to be in 'GameData', far better would be 'GameData/PluginData/modname'.

'GameData/modname/PluginData' doesn't work well.  It's just the standard and KSP players are used to it.  It's horrible, but it's what everyone uses.

[linuxgurugamer]

My mods can usually be updated without deleting the folder, to avoid the necessity of deleting.

Unfortunately, there is no consensus, and Squad provided no guidance or recommended standards/layouts. So we are stuck with a mishmash of layouts 

[DStaal]

3 minutes ago, linuxgurugamer said:

My mods can usually be updated without deleting the folder, to avoid the necessity of deleting.

Unfortunately, there is no consensus, and Squad provided no guidance or recommended standards/layouts. So we are stuck with a mishmash of layouts 

Honestly, I know I *could* update most of my mods without deleting that folder - but that's to fiddly and to much work.  I have to work out which mods use this layout, which I have settings that I need to keep, selectively delete, then overwrite...

vs. drop in and replace.  (And then reset settings if they bug me.)

And I disagree - there is consensus, on the 'GameData/modulename/PluginData' format.  I can't think of another mod that doesn't use that format.  It's a *bad* consensus, and the wrong layout by any objective measure (it's only redeeming value is it's ease of initial install), but it is the consensus.

[linuxgurugamer]

While not part of this discussion, I prefer to use CKAN for 99% of the mods I use, and CKAN updates mods without any problems; my main game has over 255 mods installed, so I speak from experience.  I do recognize that not all mods are listed in CKAN, and not all people like to use CKAN

On another note, if Squad were to come out with a recommended layout for mods, I would work at updating all my mods to support that.

[Tyko]

9 minutes ago, linuxgurugamer said:

While not part of this discussion, I prefer to use CKAN for 99% of the mods I use, and CKAN updates mods without any problems; my main game has over 255 mods installed, so I speak from experience.  I do recognize that not all mods are listed in CKAN, and not all people like to use CKAN

On another note, if Squad were to come out with a recommended layout for mods, I would work at updating all my mods to support that.

I wish that were the case...now I just get in the habit of keeping a backup copy of my setting folders for key mods. My KER settings are a great example where I've spent a ton of time getting my layout right and would hate to have to redo it.

Until Squad changes it though it's still better to have a consistent, if imperfect, "standard" than having mods on a variety of standards. The annoyance you know is way better than an annoyance you haven't figured out yet.

[DStaal]

I understand that.  I don't use CKAN myself - because it flat out refused to work on my computer when I started playing KSP.  (I was on an older computer and an older OS, and while KSP ran fine on it, CKAN didn't.)  I haven't tried CKAN recently.

And I agree on the point of a standard - but on the other hand, having a bad standard shouldn't prevent people from trying to push for better, and saying 'it's standard!' shouldn't be the reason to stick with a stupid design - and the current 'standard' is stupid.

(And honestly - LinuxGuruGamer has the position to push through a good change here, if he wants to make life better for people.  If he changed his mods to use either of the other two folder structures under discussion, that would basically be the new standard and would make life easier for lots of people.)

[linuxgurugamer]

I've created a new thread to continue this discussion, and avoid cluttering up the KJR thread here

 

[Lisias]

1 hour ago, linuxgurugamer said:

My mods can usually be updated without deleting the folder, to avoid the necessity of deleting.

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.

 

1 hour ago, linuxgurugamer said:

My mods can usually be updated without deleting the folder, to avoid the necessity of deleting.

[cut by me] Squad provided no guidance or recommended standards/layouts. So we are stuck with a mishmash of layouts 

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.

1 hour ago, DStaal said:

I understand that.  I don't use CKAN myself - because it flat out refused to work on my computer when I started playing KSP.  (I was on an older computer and an older OS, and while KSP ran fine on it, CKAN didn't.)  I haven't tried CKAN recently.

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.  

2 hours ago, Tyko said:

@Lisias Despite moving things out of GameData being "good coding practice" I think it'll cause a ton of confusion and issues for players and for supporting the mod.

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

Edited November 20, 2018 by Lisias
new feature "request" for KSPe.

[linuxgurugamer]

Another aside, but directly related to KJR, @Rudolf Meier is planning on picking up his development of KJR soon.

[Tyko]

59 minutes ago, Lisias said:

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

I'm just glad work on this and other mods continues...it's a great community. 

Thanks for considering and responding, regardless of which way you go   

[DStaal]

And backing things up a bit - here's my logs:

http://magehandbook.com/owncloud/index.php/s/N3OnwBxUeMrsqZz

http://magehandbook.com/owncloud/index.php/s/8FLUk0dBGKiNVdL

And the craft file:

http://magehandbook.com/owncloud/index.php/s/fC8pZej7E1P4jI4

I run a long list of mods - the craft file I know uses SSPXe, Near Future Spacecraft, Better Science Labs, Pathfinder, Surface Lights, Koose, and at least one other for the boosters.  However, the part that was noticeably rubbery was a stock radial decoupler.  (A TT-70.)

Edited November 20, 2018 by DStaal
Forgot Koose.

[linuxgurugamer]

4 hours ago, Lisias said:

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.

What is KSPe ?

[Lisias]

19 hours ago, linuxgurugamer said:

What is KSPe ?

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.

[Lisias]

On 11/20/2018 at 8:58 PM, DStaal said:

I run a long list of mods - the craft file I know uses SSPXe, Near Future Spacecraft, Better Science Labs, Pathfinder, Surface Lights, Koose, and at least one other for the boosters.  However, the part that was noticeably rubbery was a stock radial decoupler.  (A TT-70.)

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

[DStaal]

33 minutes ago, Lisias said:

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

First two are from Universal Storage II - Though the second probably needs KIS/KAS to appear as well, and the first appears to need either MechJeb of KOS (I have MechJeb.)

I thought the last was from Better Science Labs.  Apparently it's actually from Science Lab Info: https://github.com/yalov/ScienceLabInfo/releases  It's also just a clone of the stock science lab.