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

[Papa_Joe]

Check out the configs DangIt uses. I know they are able to apply the possibility of failure to all parts but they differentiate part categories based on modules.

Something like this.

@PART
[*]:HAS[!MODULE[ModuleEngines],!MODULE[ModuleLight]   followed by the CLS config 

My syntax is way off, but you get the idea, if the part is an engine, or a light bulb, then it gets passed over etc.

Course then you run into the issue of those custom pods which have their own build in engines.. lol.

Ugh. Yeah, that's not ideal. Off the cuff, I guess if it's surface attached and it doesn't have any other attachment nodes, then it probably never needs to be passable? My Module-Manager-fu is weak, so I don't have a good filter rule for you.

Ya, not my idea of a great result either. I'm going to look at filtering the list somehow, or making the addition of a CLS module a user option. Let me give this a bit of thought...

Edited July 10, 2015 by Papa_Joe

[codepoet]

I am not sure that adding CLS to ALL parts would be a good thing for CLS's reputation. If a load of CLS options that do not make any sense appear on parts such as RCS thruster blocks for example, then it is just going to make people think CLS is a bit daft.

Having said that, I am not sure what the better solution is.

[Papa_Joe]

I am not sure that adding CLS to ALL parts would be a good thing for CLS's reputation. If a load of CLS options that do not make any sense appear on parts such as RCS thruster blocks for example, then it is just going to make people think CLS is a bit daft.

Having said that, I am not sure what the better solution is.

Agreed. I'm looking at the various MM filters available, and considering the limitations of that approach. It may make more sense to provide a option to add a CLS module on demand.

[Climberfx]

Yeah Papa_Joe, all that will be amazing. Can't wait to have it in my hands.

May the force be with you my friend.

[Papa_Joe]

Yeah Papa_Joe, all that will be amazing. Can't wait to have it in my hands.

May the force be with you my friend.

Thanks!

I've made some progress. I've filtered by needing a bottom node and that has done wonders. Now I'm going to filter by anything greater than 0.625 metere. That would not be passable in any case, and see where that leaves me.

Looking good so far, but I may still scrap this approach if it does not result in a "logical" list of available parts to alter...

Edited July 10, 2015 by Papa_Joe

[Papa_Joe]

Thanks!

I've made some progress. I've filtered by needing a bottom node and that has done wonders. Now I'm going to filter by anything greater than 0.625 metere. That would not be passable in any case, and see where that leaves me.

Looking good so far, but I may still scrap this approach if it does not result in a "logical" list of available parts to alter...

Ok, this is what I have so far...

@PART
[*]:HAS[!MODULE[ModuleConnectedLivingSpace],#node_stack_bottom
[*],~bulkheadProfiles[size0*],#bulkheadProfiles[size*]]:Final
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = false
    }
}

This runs after everything else does, finds all parts that do not have a CLS module, & have a bottom node, do not contain a 0.625m node, & have 1.25m or larger nodes.

This seems to give a pretty decent list of likely candidates, and disallows almost (but not quite) all obviously non passable parts. Still tweaking as there looks like there are still a few I want to omit. I just don't want to be in a position where I have to manage part names...

A filter may well meet our needs.

As far as the RMB display and the buttons, I've modified them to behave as we have discussed. If the part is not passable, that is pretty much all you will see in the part description. in the tweakable you will only see the passable button.

Once you press the passable button and make passable = Yes, then the other buttons appear. However, you will still only see the passable in the tool selector, as the original config of the part of course does not change, only the part installed on the vessel under construction.

If you really want to get fancy with a part and start adding passable and impassable nodes, you really need to be creating a MM config for that part anyway.

Edited July 11, 2015 by Papa_Joe

[Gryphon]

That sounds great to me. I think it's a good way to make it work, without being too aggressive. Using bulkhead profile with a default of impassable is a good filter - after all, the bulkhead profile identifies both a size and a shape that at least might be passable.

[Papa_Joe]

That sounds great to me. I think it's a good way to make it work, without being too aggressive. Using bulkhead profile with a default of impassable is a good filter - after all, the bulkhead profile identifies both a size and a shape that at least might be passable.

Latest revised revision .

This exclude engines, fuel tanks, and KAS/KIS parts as well... that seems to make the most sense. Still a few nosecones show up, but not bad:

@PART
[*]:HAS[!MODULE[ModuleConnectedLivingSpace],!MODULE[ModuleEngines*],~category[Engine],~category[FuelTank],~category[Propulsion],~stagingIcon[],~name[K?S_*],#node_stack_bottom
[*],~bulkheadProfiles[size0*],#bulkheadProfiles[size*]]:Final
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = false
    }
}

btw, you can test this on a test save by simply adding it to the GameData folder. Dont do it on your main save as it will alter your save when you load it. I you are willing, you can see what you think. All parts with this added will show up on the RMB with a Conneected Living Space entry as not passable (albeit with the old wordy text in the existing version)

Edited July 11, 2015 by Papa_Joe

[Gryphon]

Latest revised revision .

This exclude engines, fuel tanks, and KAS/KIS parts as well... that seems to make the most sense. Still a few nosecones show up, but not bad:

I was all set to be worried about what this would do to someone with a Space-X Crew Dragon, with its built-in escape rockets. Then I realized: that would be a mod part. Let the mod author include a CLS config!

[codepoet]

That is an interesting complication - crewed pods with built in RCS might cause a bit of confusion. Obviously the best solution is for mod authors to provide a CLS config themselves.

Are we going to get into a situation where we are asking mod authors to provide a CLS config to disable CLS in their part, as it is getting erroneously enabled by default? I can see that most mod authors would not be interested to do this.

Also will it become harder to persuade mod author to provide CLS config if it mostly works by default, and the user can tweak the options however they want? I suppose there is nothing much wrong with this, but it does take away that aspect of "How did the mod author envisage this part would be on the inside?".

These are not criticisms, just considerations. If there was a perfect solution to the problem of providing config for CLS I would have already written it myself last year!

[Papa_Joe]

That is an interesting complication - crewed pods with built in RCS might cause a bit of confusion. Obviously the best solution is for mod authors to provide a CLS config themselves.

Are we going to get into a situation where we are asking mod authors to provide a CLS config to disable CLS in their part, as it is getting erroneously enabled by default? I can see that most mod authors would not be interested to do this.

Also will it become harder to persuade mod author to provide CLS config if it mostly works by default, and the user can tweak the options however they want? I suppose there is nothing much wrong with this, but it does take away that aspect of "How did the mod author envisage this part would be on the inside?".

These are not criticisms, just considerations. If there was a perfect solution to the problem of providing config for CLS I would have already written it myself last year!

No offense taken at all and your thoughts are a primary concern of mine as I in no way wish to run in a direction counter to your original intent.

In truth, I'm disabling CLS passability on them by default, so there is no change to the original behavior of the part. This only introduces the "opportunity" for the user to enable CLS on a part they choose, and ONLY for the vessel they are constructing. So it is by design a benign change. So, in the end, the only thing we have been discussing with the filter is how big a net to cast on parts that we will allow the user to alter to allow crew movement.

If a mod author later includes a config for a part that "was" captured under this filter, that will override this modification, as this runs after all other MM configs are run, and does not alter any previous modifications.

Finally, I've been wondering if I need to return any details at all on part that is not passable. If I don't, then the only indication that a part can be altered would be when they open the tweakables. I'm bouncing back and forth on that, as on one hand I see value in knowing what part can possibly be altered, and on the other hand, wanting to avoid any "confusion".

At the moment, I'm thinking since I only show 1-2 lines max for a disabled (passable= false) part, that the former is preferred over the latter choice.

Edited July 11, 2015 by Papa_Joe

[Papa_Joe]

No offense taken at all and your thoughts are a primary concern of mine as I in no way wish to run in a direction counter to your original intent.

In truth, I'm disabling CLS passability on them by default, so there is no change to the original behavior of the part. This only introduces the "opportunity" for the user to enable CLS on a part they choose, and ONLY for the vessel they are constructing. So it is by design a benign change. So, in the end, the only thing we have been discussing with the filter is how big a net to cast on parts that we will allow the user to alter to allow crew movement.

If a mod author later includes a config for a part that "was" captured under this filter, that will override this modification, as this runs after all other MM configs are run, and does not alter any previous modifications.

Finally, I've been wondering if I need to return any details at all on part that is not passable. If I don't, then the only indication that a part can be altered would be when they open the tweakables. I'm bouncing back and forth on that, as on one hand I see value in knowing what part can possibly be altered, and on the other hand, wanting to avoid any "confusion".

At the moment, I'm thinking since I only show 1-2 lines max for a disabled (passable= false) part, that the former is preferred over the latter choice.

Okay, I've taken another pass and here is the resultant MM config:

@PART
[*]:HAS[!MODULE[ModuleConnectedLivingSpace],!MODULE[ModuleEngines*],~category[Engine],~category[FuelTank],~category[Propulsion],~stagingIcon[],~name[K?S_*],#node_stack_top
[*],#node_stack_bottom
[*],~bulkheadProfiles[size0*],#bulkheadProfiles[size*]]:Final
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = false
    }
}

I added node stack top to further limit the scope.

With this, almost all nose cones are excluded. I'm inclined to err on the side of fewer parts than more, and this seems to provide a good list of candidates for changing passable states.

Further, I've added an option to enable or disable this feature, leaving it disabled by default so that existing behavior is preserved. If you enable/disable the Passability customization feature, a game restart is required, as the RMB info for each part is loaded when the parts are loaded at startup.

Once enabled you can enable passable on certain parts and alter surface passable states on any parts with passable enabled.

So, the planned behavior is this:

1. Customization is off by default. This emulates the existing behavior of CLS prior to the new version.

1a. If a part is passable, you can change the passable and surface passable states via a tweakable on the part during assembly of your vessel (new Behavior).

1b. if a part is Non passable by default, no info is show in the Tool selector on RMB

1c. If a part is Non passable by default, the part does not contain any CLS module, unless the part had an existing CLS MM config (existing behavior).

2. If customization is ON, then non passable info is now shown in the Tool Selector on RMB. (new Behavior)

2a. Non passable parts included in the default part MM config filter now contain a CLS module and passable is off by default. (changing the part's persistence, but no change to part's original behavior)

2b. Included non passable parts can now be enabled, allowing passabllity through the part. (new Behavior)

2c. parts that have passable ON, can have the surface passable state change vis tweakable (same as 1a, above)

Finally, with the addition of another option, it made sense to include a options window and remove the options from the main CLS window, making for a cleaner appearance, I also now save the CLS window position, so it will be remembered between scenes and games.

Thoughts?

Edited July 15, 2015 by Papa_Joe

[codepoet]

When do we get to play?

[Papa_Joe]

When do we get to play?

As soon as I can figure out how to get my pull request to merge...

Screenies of changes follow:

[Gryphon]

I like. I think leaving the new functionality off by default is quite nice.

[Papa_Joe]

As soon as I can figure out how to get my pull request to merge...

...

I like. I think leaving the new functionality off by default is quite nice.

I'm still working out the pull request Merge. I may need to manually update the master

I expect to publish an update later tonight (CST US).

[Jivaii]

What defines "Same living space"? I've got two ships docked together, and want to transfer crew from one to the other, but get a message about the docked assembly being "not same living space" even though the docking port hatches are open (using the standard docking port, haven't unlocked the senior and not using the Jr.). CLS and Ship Manifest are installed

[Grumman]

Is there any way to have a part with four nodes split them into pairs for passability purposes?

The various cargo bays have nodes top, top2, bottom, bottom2 and I'd like them to be connected such that a docking port on the inside front node and a cockpit on the outside front node are connected, and the same is true of the inside and outside rear nodes.

[Papa_Joe]

What defines "Same living space"? I've got two ships docked together, and want to transfer crew from one to the other, but get a message about the docked assembly being "not same living space" even though the docking port hatches are open (using the standard docking port, haven't unlocked the senior and not using the Jr.). CLS and Ship Manifest are installed

I'm not sure what docking port you are referring to. You can tell if it is passable by looking at the part selector in the VAB/SPH. If you right click on the part, an expanded menu appears. If the Part is Passable, there will be a Section titled "Connected Living Space".

If not, then the part is not passable. Note that generally speaking parts smaller than 1.25 meters are not considered passable. Think of the width of a kerbal with a space suit on...

Is there any way to have a part with four nodes split them into pairs for passability purposes?

The various cargo bays have nodes top, top2, bottom, bottom2 and I'd like them to be connected such that a docking port on the inside front node and a cockpit on the outside front node are connected, and the same is true of the inside and outside rear nodes.

Without knowing which part you are referring to, it is hard to tell, but if for example it is 4 way symmetry, then you owuld have to believe that internally, all four ports are accessable, so there would be no "tunnels" so to speak. There is currently no way to simulate non interconnecting tunnels withing a given part...

[Grumman]

Without knowing which part you are referring to, it is hard to tell, but if for example it is 4 way symmetry, then you owuld have to believe that internally, all four ports are accessable, so there would be no "tunnels" so to speak. There is currently no way to simulate non interconnecting tunnels withing a given part...

As I said, it's the cargo bays that prompted this question.

Each cargo bay has four nodes: top facing upwards, top facing downwards, bottom facing upwards, bottom facing downwards. Since there is literally nothing between the top-facing-upwards and top-facing-downwards nodes, they should logically be connected. They aren't.

As a partial fix for this problem I wrote a new cfg:

@PART[mk2CargoBayS]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom , bottom2
	}
}

@PART[mk2CargoBayL]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom , bottom2
	}
}

@PART[mk3CargoBayS]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom , bottom2
	}
}

@PART[mk3CargoBayM]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom , bottom2
	}
}

@PART[mk3CargoBayL]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom , bottom2
	}
}

...but this only fixes the top end and not the bottom end.

[Jivaii]

I'm not sure what docking port you are referring to. You can tell if it is passable by looking at the part selector in the VAB/SPH. If you right click on the part, an expanded menu appears. If the Part is Passable, there will be a Section titled "Connected Living Space".

If not, then the part is not passable. Note that generally speaking parts smaller than 1.25 meters are not considered passable. Think of the width of a kerbal with a space suit on...

The docking port I'm using is the stock clamp-o-tron.

[Papa_Joe]

As I said, it's the cargo bays that prompted this question.

http://i.imgur.com/CQjDDSm.jpg

Each cargo bay has four nodes: top facing upwards, top facing downwards, bottom facing upwards, bottom facing downwards. Since there is literally nothing between the top-facing-upwards and top-facing-downwards nodes, they should logically be connected. They aren't.

As a partial fix for this problem I wrote a new cfg:

@PART[mk2CargoBayS]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom , bottom2
    }
}

@PART[mk2CargoBayL]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom , bottom2
    }
}

@PART[mk3CargoBayS]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom , bottom2
    }
}

@PART[mk3CargoBayM]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom , bottom2
    }
}

@PART[mk3CargoBayL]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom , bottom2
    }
}

...but this only fixes the top end and not the bottom end.

Interesting. in the photo above, the configuration should be non passable, as the docking ports are really open to space... the fact that there is a cargo bay does not ensure an atmosphere... so it would really be an eva for our kerbals don't you think?

The docking port I'm using is the stock clamp-o-tron.

I see a Clamp-o-tron Jr, and a Clamp-o-tron Sr, but no stock clamp-o-tron. maybe you can post a screenshot of the part in the VAB?

Edited July 21, 2015 by Papa_Joe

[Grumman]

Interesting. in the photo above, the configuration should be non passable, as the docking ports are really open to space... the fact that there is a cargo bay does not ensure an atmosphere... so it would really be an eva for our kerbals don't you think?

Yes, which is why I was asking about making the leftmost two nodes connected - so that you can transfer from the cockpit into a shuttle docked in the cargo bay, for example - but not connected to the rightmost two nodes. In that screenshot I posted the leftmost docking port should be yellow (indicating a passable part that cannot be occupied).

[Jivaii]

Link of the part from the wiki, my game isn't wanting to boot up right now, and I'm getting ready to head to bed.

Here's a picture of the vessel, it's docking ports, the Ship Manifest screen, and the pop ups.

Javascript is disabled. View full album

Upon further play, it seems it's just radially attached docking ports not wanting to work. Node attached ports work fine.

Edited July 22, 2015 by Jivaii
Added station photos and some more info.

[Papa_Joe]

Link of the part from the wiki, my game isn't wanting to boot up right now, and I'm getting ready to head to bed.

Here's a picture of the vessel, it's docking ports, the Ship Manifest screen, and the pop ups.

http://imgur.com/a/9eNFx

Upon further play, it seems it's just radially attached docking ports not wanting to work. Node attached ports work fine.

that would make sense. The config for the part in question does not allow radially attached parts.

However, the upcoming update will allow you to "tweak" your vessel designs to allow these kind of activities and to see that they are correct while in the VAB/SPH.

Read up in the earlier posts about the new VAB/SPH tweakables...