[1.12.x] Connected Living Space v2.0.2.0 (12 Feb 2022)

[dlrk]

@steve_v Could you please post your recompile?

[steve_v]

On 1/8/2020 at 10:27 AM, Jezzick said:

Is there any chance you could link / upload your recompile?

On 1/19/2020 at 7:50 AM, dlrk said:

@steve_v Could you please post your recompile?

As there hasn't been an official CLS release since 1.4.x and @Papa_Joe hasn't logged in since December, I guess I'll do that.
.dlls only, compiled from https://github.com/taniwha/ConnectedLivingSpace/tree/cls-fixes. No warranty, no support, there until it isn't, get the assets from the usual places.

Edited January 30, 2020 by steve_v
Just checking, it helps if you upload the correct files...

[p1t1o]

@steve_v Unbelievable timing, thanks for the effort

[Jezzick]

On 1/28/2020 at 11:21 PM, steve_v said:

As there hasn't been an official CLS release since 1.4.x and @Papa_Joe hasn't logged in since December, I guess I'll do that.
.dlls only, compiled from https://github.com/taniwha/ConnectedLivingSpace/tree/cls-fixes. No warranty, no support, there until it isn't, get the assets from the usual places.

Wow, thank you very much! 

[Murdabenne]

I miss having an "official" version of this

[micha]

I'm about to take over ShipManifest as @Papa_Joe seems to be MIA.  I've tried to reach him without success.

Since SM has a dependency on this mod, I'm considering also taking over maintenance of CLS for the time being.

Before I step on any toes, any other takers?

[micha]

So I know I didn't give much notice here but I think most things were already discussed in the ShipManifest thread.

I've gone ahead and made a new thread as well as an initial release. Please see the new CLS thread here:

@MODS: Please lock this thread to further comments.

[Papa_Joe]

Necroing an old thread.  With my resuming support of Ship Manifest, I'll also resume support of Connected Living Spaces.  Thanks to @micha for his support during my absence, and for keeping the mod alive.  I am deeply grateful.

My dev environment is setup now, so I'm working to get the source code repos updated with the updates that @micha has delivered.

[Papa_Joe]

Hey all,

With the release of Ship Manifest, I'm now turning my attention to CLS.  I'll be pulling the latest code and going thru it.  I'll look over the issues posted here, in @micha's thread and his Repo for any low hanging fruit.    Update soon^tm.  

Edited November 22, 2021 by Papa_Joe

[Papa_Joe]

I've just completed looking over @micha's thread, and I'm embarrassed.  I should have read this before releasing Ship Manifest.  Now that I'm properly aware of the issue (thanks to @Gotmachine), I'll set about properly addressing the dll issue.  CLSInterface.dll was originally intended to be a hard dependency in other modders' code and was implemented before we better understood reflection.  This means that it is a breaking change to convert that to a soft dependency and a fair amount of work for those mods that support it.  However, since it is typically distributed with those mods, simply renaming it in SM will only correct the issue for SM, and not for other mods. 

 CLSInterface is also a hard dependency for ConnectedLivingSpace, so I cannot simply remove the file from the CLS Distribution.  Therefore, the duplicate issue will remain for now, as both the supporting mods and CLS itself depend on that .dll.   

So, here is what I propose:

1.  Recommend other modders rename their interface file with a prefix (or suffix) referencing their mod in the filename of the distributed copy of CLSInterfaces.dll. Ex:  SM_CLSInterface.dll.  This will allow each mod to function, and not require constant changes as CLS is updated, and eliminate the concern about dll version differences.  The interface typically does not change at all, but the version currently gets updated with the release.  Going forward, I will only change the interface version If I make a change to the Interface.

2.  Long term:  Create a soft dependency class that can be embedded directly into a Mod's code, thereby eliminating the need for the interface.  Use of this will require changes to a Mod's code to support its use.  I will provide both the soft dependency class as part of the Devtools folder in the distribution. I will also include instructions for their use and distribution.

Comments?

Edited November 24, 2021 by Papa_Joe
Correction to proposals. CLS also depends on CLSInterfaces.dll

[Papa_Joe]

I have a recompiled version of CLS working on my dev environment.  I've added the dev folder to the distribution and added a dev_notes.txt file with instructions for integrating into CLS, along with a sample code file.  I've included a link to the CLS wiki on accessing the CLS API for detailed instructions.

Testing the build and distribution.  Working with Curse to regain edit upload rights to the project.  @micha If you would be so kind, can you contact curse to restore my edit/upload rights?  I have opened a ticket, but no response yet.

[Gotmachine]

2 hours ago, Papa_Joe said:

Create a soft dependency class that can be embedded directly into a Mod's code, thereby eliminating the need for the interface.  Use of this will require changes to a Mod's code to support its use.  I will provide both the soft dependency class as part of the Devtools folder in the distribution. I will also include instructions for their use and distribution.

IMO, it's not worth breaking every mod currently using the CLS API. As long as everyone "play by the rules", using a common redistribuable API assembly is fine.

I also strongly advise against putting together a reflection based API. Reflection comes with a huge performance penalty. It also becomes a mess to work with when you need to pass custom data around.

In any case, the KSP 1.12 assembly loader issue will continue to plague the modding ecosystem, we just need to cooperate and spread the awareness.
Also, I've not entirely given up on the possibility that this silly issue get fixed in an hypothetical 1.12.3 update...

[Papa_Joe]

30 minutes ago, Gotmachine said:

IMO, it's not worth breaking every mod currently using the CLS API. As long as everyone "play by the rules", using a common redistribuable API assembly is fine.

I also strongly advise against putting together a reflection based API. Reflection comes with a huge performance penalty. It also becomes a mess to work with when you need to pass custom data around.

In any case, the KSP 1.12 assembly loader issue will continue to plague the modding ecosystem, we just need to cooperate and spread the awareness.
Also, I've not entirely given up on the possibility that this silly issue get fixed in an hypothetical 1.12.3 update...

I agree that a reflection based approach comes with performance penalties.  That is one of the reasons Codepoet and I went with an interface based approach.  I'm not inclined to build such a class, but I was willing, IF the community thought it a good approach.  In SM for example the interface is embedded pretty thoroughly, so it would be a major rewrite.

[micha]

4 hours ago, Papa_Joe said:

  Working with Curse to regain edit upload rights to the project.  @micha If you would be so kind, can you contact curse to restore my edit/upload rights?  I have opened a ticket, but no response yet.

Hi @Papa_Joe, sorry, I didn't realise you didn't have access. I've checked and I was able to give you full control over both SM and CLS on Curse.  If you prefer, I can transfer the actual ownership.    I've sent you a PM to organise how to transfer ownership.

Edited November 25, 2021 by micha

[HebaruSan]

8 hours ago, Papa_Joe said:

1.  Recommend other modders rename their interface file with a prefix (or suffix) referencing their mod in the filename of the distributed copy of CLSInterfaces.dll. Ex:  SM_CLSInterface.dll.

Comments?

Would it be alright with you if CKAN did this for the current release of Ship Manifest? CKAN has the ability (rarely used) to rename files when they are installed. We could filter out CLSInterfaces.dll from the folder and then install it as SM_CLSInterfaces.dll instead.

[Papa_Joe]

4 hours ago, HebaruSan said:

Would it be alright with you if CKAN did this for the current release of Ship Manifest? CKAN has the ability (rarely used) to rename files when they are installed. We could filter out CLSInterfaces.dll from the folder and then install it as SM_CLSInterfaces.dll instead.

That's fine but I will be using the file name SM_CLSInterface.dll.  No need for the extra s at the end.  I will be releasing an update of SM when I release a new version of CLS as well, but it may be a few days.

6 hours ago, micha said:

Hi @Papa_Joe, sorry, I didn't realise you didn't have access. I've checked and I was able to give you full control over both SM and CLS on Curse.  If you prefer, I can transfer the actual ownership.    I've sent you a PM to organise how to transfer ownership.

Thanks so much!  I got your PM.  I am grateful for your assistance!

Edited November 25, 2021 by Papa_Joe

[Papa_Joe]

New release out.  Available on Git, SpaceDock and Curse.  CKAN should update normally as the same repo is in use as before.

Version 2.0.1.0 - Release 27 Nov 2021 - KSP 1.12.2
-------------------------------------------------
 - Changed: Back to previous maintainer, *Papa_Joe*.  Thanks *Micha*, for your support!.
 - New: recompiled for KSP 1.12.x and DotNet 4.8
        **NOTE:** This version is incompatible with versions of KSP before 1.8.
 - New: CLSInterfaces.dll is also updated to DotNet 4.8 so version has been updated.
        I expect no issues with older versions, but for maximum compatability, devs update your dependencies.
        To avoid the KSP dll bug, rename your CLSInterfaces.dll to some unique name such as: "myMod_CLSInterface.dll"
 - New: Added a Dev folder with instructions for integrating CLS into a mod.  Added a code sample to folder for embedding in a mod.
        Added notes for renaming the dll due to the KSP 1.12 duplicated DLL bug.
 - New: Added maximum scroll height to scroll display for crew and parts list.  Can be set in the Options Window.  Default is 600 px.
 - Fixed: Corrected scrolling of crew or parts lists when viewing a selected space details. Window no longer grows too large for screen.

Let me know if you have any issues.

Enjoy!

[quasitonality]

hey since no one else seems t've mentioned it yet, the CKAN listing for the new release still shows 1.11.9 as the max game version (mod version # looks up to date tho), so ckan considers it imcompatible with 1.12

[Papa_Joe]

On 1/4/2022 at 12:50 PM, quasitonality said:

hey since no one else seems t've mentioned it yet, the CKAN listing for the new release still shows 1.11.9 as the max game version (mod version # looks up to date tho), so ckan considers it imcompatible with 1.12

Not sure if this has been addressed yet with CKAN.  I noted pull request to correct that a bit back in GitHub.  I'll look at the last release and see if I can issue a maintenance release.

[HebaruSan]

24 minutes ago, Papa_Joe said:

Not sure if this has been addressed yet with CKAN.  I noted pull request to correct that a bit back in GitHub.  I'll look at the last release and see if I can issue a maintenance release.

You can update the compatibility of the current release by editing KSP_VERSION_MAX in the remote version file (that's where the current 1.11.99 value comes from):

https://github.com/codepoetpbowden/ConnectedLivingSpace/blob/master/Distribution/GameData/ConnectedLivingSpace/ConnectedLivingSpace.version

[garwel]

Hi, I want to report an issue I encountered between CLS and SSPX. I don't know which side this problem is on, so I've reported it at the SSPX thread and here too.

The problem is, CLS doesn't recognize SSPX parts as passable even though they seem to be configured this way and the part info tip says they are passable. Here is an example screenshot: the two parts should form one CLS space, but they don't for some reason. The same thing happens to other SSPX parts and for both top and bottom nodes.

I've had a superficial look at the patch (provided by SSPX) and the part config and compared them to those that work correctly, and I don't see any obvious errors. Hope you'll have a moment to look at it.

I'm using KSP 1.12.2, CLS 2.0.1, SSPX 2.0.6.

[panarchist]

4 hours ago, garwel said:

Hi, I want to report an issue I encountered between CLS and SSPX. I don't know which side this problem is on, so I've reported it at the SSPX thread and here too.

The problem is, CLS doesn't recognize SSPX parts as passable even though they seem to be configured this way and the part info tip says they are passable. Here is an example screenshot: the two parts should form one CLS space, but they don't for some reason. The same thing happens to other SSPX parts and for both top and bottom nodes.

I've had a superficial look at the patch (provided by SSPX) and the part config and compared them to those that work correctly, and I don't see any obvious errors. Hope you'll have a moment to look at it.

I'm using KSP 1.12.2, CLS 2.0.1, SSPX 2.0.6.

Did you check to make sure neither of them have a hatch? The Command Pod might. (it's not likely, but it would cause that behavior) On the parts I've looked at, I'm not seeing that behavior - but I didn't check the inflatable.

[garwel]

3 hours ago, panarchist said:

Did you check to make sure neither of them have a hatch? The Command Pod might. (it's not likely, but it would cause that behavior) On the parts I've looked at, I'm not seeing that behavior - but I didn't check the inflatable.

They don't as far as I can tell (from the part.cfg files at least). And the problem is apparently not in the stock Mk1-3 Pod, because I've tried attaching to different parts. If you attach a Hitchhiker instead, they are considered connected.

Maybe the problem is due to the parts being inflatable? By default, they have CrewCapacity = 0 and use a custom part module (ModuleDeployableHabitat) to change that. However, as seen on the screenshot, the part is recognized as a habitable, it just isn't getting connected to its neighbours.

Edited January 28, 2022 by garwel

[eberkain]

the screenshot is in the vab, did you take it into the flight scene and inflate it to see what happens? 

[panarchist]

8 hours ago, garwel said:

They don't as far as I can tell (from the part.cfg files at least). And the problem is apparently not in the stock Mk1-3 Pod, because I've tried attaching to different parts. If you attach a Hitchhiker instead, they are considered connected.

Maybe the problem is due to the parts being inflatable? By default, they have CrewCapacity = 0 and use a custom part module (ModuleDeployableHabitat) to change that. However, as seen on the screenshot, the part is recognized as a habitable, it just isn't getting connected to its neighbours.

I think you might be on to something there. I would try "launching" on the ground with it deflated, and inflate on the pad, then try it again inflated in the VAB and launch with it already inflated, and see if the behavior differs. I don't know when CLS makes the check for CrewCapacity, but I wouldn't be surprised if the second space is happening because the part has 0 CrewCap when instantiated in the flight scene.