[0.90] [Up for adoption] Connected Living Space v1.1.2.0 (27th Feb 2015) Hatches and Highlighting

[TerrificToby]

done, see previous post.

[Papa_Joe]

Hi people,

I have run into a small problem.

I have assembled two modules in orbit, but due to an inconvieniently placed probe core and fustek bulkhead, two of my modules aren't connected when logically they should.

http://i102.photobucket.com/albums/m111/toby_foster1/screenshot3_zps6fc89fc0.png

http://i102.photobucket.com/albums/m111/toby_foster1/screenshot3_zps17048d3a.png

please help,

Toby

You can solve this problem by creating custom configs for those parts. See codepoet's OP for info on making Module Manager configs. While this may not be a "correct" solution, it will allow you game play.

Edited May 10, 2014 by Papa_Joe

[diomedea]

Hi people,

I have run into a small problem.

I have assembled two modules in orbit, but due to an inconvieniently placed probe core and fustek bulkhead, two of my modules aren't connected when logically they should.

...

I would create an ad-hoc config file (yourname.cfg) to be placed with ConnectedLivingSpace/Plugins, holding CLS modules for all the parts you need to become passable, like below for the battery bank:

@PART[batteryBankLarge]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

Then restart your game, that config file is parsed and the parts become passable.

EDIT: (and I see Papa_Joe was faster than me!)

Edited May 10, 2014 by diomedea

[Papa_Joe]

I would create an ad-hoc config file (yourname.cfg) to be placed with ConnectedLivingSpace/Plugins, holding CLS modules for all the parts you need to become passable, like below for the battery bank:

@PART[batteryBankLarge]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

Then restart your game, that config file is parsed and the parts become passable.

EDIT: (and I see Papa_Joe was faster than me!)

Yes, but you were more thorough. Thanks for that, as you have helped me in the past as well.

[TerrificToby]

could you upload a link to a file for that?

I don't really trust myself in case i stuff it up.

cheers,

Toby

EDIT: perhaps a config file for all relevant fustek parts.

Edited May 10, 2014 by TerrificToby

[TerrificToby]

Hi,

Done all the things you asked, yet i can't get the EVA module to become one with the rest of the station, though i have worked out that there is no bulkhead there, it just won't join.

cheers,

Toby

[diomedea]

Done all the things you asked, yet i can't get the EVA module to become one with the rest of the station, though i have worked out that there is no bulkhead there, it just won't join.

I don't use Fustek parts (not yet, probably in future but am already too heavy with other mods), but the proper config to make those parts work with CLS is already included in the currrent Fustek version. Apart from the battery bank, I can't really figure what are the other parts in your vessel. That EVA module you name tells nothing to me.

Anyway, making a custom config is really easy (as we are not dealing with any of the more advanced features of CLS). You certainly know what parts are to be made passable to reach the EVA module, for any of those you have to find the proper part.cfg (look in the subfolder where the mod defines those parts, standard parts are in Gamedata/Squad/parts or Gamedata/NASAmission/parts). Any part.cfg begins with (e.g. the Fustek bulkhead):

PART {
    name = [COLOR=#0000ff]FusTekKarmonyBulkhead[/COLOR]

What appears after "name =" is exactly what must be copied (between the @PART brackets) in the section of the config file, e.g.:

@PART[[COLOR=#0000ff]FusTekKarmonyBulkhead[/COLOR]]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

Nothing else to change.

[sumghai]

As the author of the FusTek Station Parts, I would like to state that the latest version does natively support CLS via the FusTek_MMPatch_ConnectedLivingSpaces.cfg patch included in the pack.

I've also figured out the source of the problem with regards to the lower section of Toby's station:

- The Karmony Bulkhead's configuration is

@PART[FusTekKarmonyBulkhead]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

which works just fine.

- The Kuest Legacy Airlock's configuration is

@PART[FusTekKuestLegacyAirlock]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        impassablenodes = top
    }
}

which by design allows passage only via the bottom (yellow-rimed hatch end) node. This worked as intended for CLS 1.0.3.0, but not for CLS 1.0.4.1. By making the following modification to my CFG, it now works for CLS 1.0.4.1 (i.e. will allow access from the back while still blocking the front).

@PART[FusTekKuestLegacyAirlock]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = top
    }
}

My recommendation is for Toby to locate GameData\FusTek\Station Parts\Parts\MM_configs\FusTek_MMPatch_ConnectedLivingSpaces.cfg and add the passable = trueargument to the two airlocks and the cupola module patches. I'll also push a hotfix out later today to address this issue.

[Deadpan110]

As the author of the FusTek Station Parts, I would like to state that the latest version does natively support CLS via the FusTek_MMPatch_ConnectedLivingSpaces.cfg patch included in the pack.

I didn't even notice that patch when i made a pull request to Connected Living Spaces on Git - Complete list of parts (without the bulkhead) available here:

https://github.com/codepoetpbowden/ConnectedLivingSpace/blob/develop/configs/CLSFSPX.cfg

(Could be useful for anyone still using older versions)

And as sumghai stated above, if you are using CLS 1.0.4.1 or above, you will need to add passable = true to any parts that have impassablenodes

[Papa_Joe]

Just a heads up. New Version Ship Manifest out.

Version 0.23.5.3.2.3 - 11 May, 2014 - Settings, Roster & Bug Fix Edition.

- New: Roster Window now allows adding and removing individual Kerbals during pre-flight in Realism Mode, and also In-Flight in Standard mode.

- New: Additional changes to Settings.

- Now sepearate sections make finding things easier.

- Changed LockRealismMode to LockSettings, as Realism Mode is not a parent setting.

- Added Locksettings to the Settings Window. Once set, must be turned off in config file.

- Made Enable CLS a child of Enable Crew

- Bug: SM not detecting Changes in CrewCapacity with Inflatable Parts...

- http://forum.kerbalspaceprogram.com/threads/62270-0-23-5-Ship-Manifest-%28Crew-Science-Resources%29-v0-23-5-3-2-1-22-Apr-14?p=1118517&viewfull=1#post1118517

- Bug: SM Erros when attempting to transfer to a pert with no internal model

- http://forum.kerbalspaceprogram.com/threads/62270-0-23-5-Ship-Manifest-%28Crew-Science-Resources%29-v0-23-5-3-2-2-2-May-14?p=1140559&viewfull=1#post1140559

- Bug: SM still allowing negative numbers in resource transfers.

- http://forum.kerbalspaceprogram.com/threads/62270-0-23-5-Ship-Manifest-%28Crew-Science-Resources%29-v0-23-5-3-2-2-2-May-14?p=1136419&viewfull=1#post1136419

I'm hoping with a change I made to fix Inflatable Habs, I also fixed the LS resource doubling. if someone would be so kind as to test that, I cannot.

I think we are getting pretty stable now. Add soft dependencies and we are looking pretty good. Let me know what you all think!

Enjoy!

Edited May 11, 2014 by Papa_Joe

[diomedea]

... By making the following modification to my CFG, it now works for CLS 1.0.4.1 (i.e. will allow access from the back while still blocking the front).

...

Excellent, many thanks for this, I just learned how to further customize parts with CLS .

[TheSolty]

Hey codepoet, I love your mod and I made an account here just to comment a question here.

Will there be support for raidially attached docking ports soon?

My Solt Space Station Should have two spaces but instead has a bunch since the radial ports aren't recongized as being part of the space.

[Papa_Joe]

Hey codepoet, I love your mod and I made an account here just to comment a question here.

Will there be support for raidially attached docking ports soon?

My Solt Space Station Should have two spaces but instead has a bunch since the radial ports aren't recongized as being part of the space.

In an earlier post, codepoet released version 1.0.4.1 it has support for surface attached parts. I'm thinking that is what you are requesting.

If so, then you might look at the parts being used to attach radially, and see if they have appropriate passable flags set up in an MM config. Thea may be the source of your issue, IF you are using the latest version...

[codepoet]

Just to clarify - CLS v1.0.4.1 supports the concept of radially attached parts being passable, however it still has to be configured per part. It also has to be configured appropriately on both the radially attached part, and the part it has been attached to the surface of.

Anyhow, at the moment the only stock part that is configured to be attached to be radially attached is the surface attaching adapter thingie.

In response to your post I have had a look at the config, and noticed that the standard sized docking port can also be radially attached. Since a docking port really ought to be passable, I have changed the config so the next release of CLS will allow radially attached standard sized docking ports to be passable. If you wand this now, then you can edit your stock.cfg file in the CLS install to have the following in it:

@PART[dockingPort2]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		passableWhenSurfaceAttached = true
	}
}

[TheSolty]

Just to clarify - CLS v1.0.4.1 supports the concept of radially attached parts being passable, however it still has to be configured per part. It also has to be configured appropriately on both the radially attached part, and the part it has been attached to the surface of.

Anyhow, at the moment the only stock part that is configured to be attached to be radially attached is the surface attaching adapter thingie.

In response to your post I have had a look at the config, and noticed that the standard sized docking port can also be radially attached. Since a docking port really ought to be passable, I have changed the config so the next release of CLS will allow radially attached standard sized docking ports to be passable. If you wand this now, then you can edit your stock.cfg file in the CLS install to have the following in it:

@PART[dockingPort2]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        passableWhenSurfaceAttached = true
    }
}

I have added "passableWhenSurfaceAttached = true" to all of the docking ports involved here but this still happens:

The problem is that the stock docking port on the hitchhiker module is not connecting to its space and the B9 CDP docking port (which I have properly added to the config) is not attaching to the B9 S2 2m Crew Module space.

Edited May 17, 2014 by TheSolty
Didn't work!

[codepoet]

If you add "passableWhenSurfaceAttached = true" to your docking ports then they will be passable, BUT... only when they are surface attached to a part that has "surfaceAttachmentsPassable = true". At the moment the only stock part that has this set is the structural fusalage, but you can add it to whatever part you want.

So, to repeat, a surface mounted part pass a passable connection only if both the parts have an appropriate flag set.

The reason I have restricted the parts you can surface mount onto by default, is that if in the future we do something with CLS and IVA, then it makes it a lot harder to draw the IVA model if Jeb has cut a hole in the side on the capsule with his angle grinder!

[TheSolty]

If you add "passableWhenSurfaceAttached = true" to your docking ports then they will be passable, BUT... only when they are surface attached to a part that has "surfaceAttachmentsPassable = true". At the moment the only stock part that has this set is the structural fusalage, but you can add it to whatever part you want.

So, to repeat, a surface mounted part pass a passable connection only if both the parts have an appropriate flag set.

The reason I have restricted the parts you can surface mount onto by default, is that if in the future we do something with CLS and IVA, then it makes it a lot harder to draw the IVA model if Jeb has cut a hole in the side on the capsule with his angle grinder!

Oh! alright, this makes a lot more sense now. Now I'm curious what will happen in my station when the IVA features are implemented. Will it perhaps be possible to see inside the inflatable module from habitat pack from the hitchhiker since the docking port is attached over the window, or vice versa? And what would you see when looking into parts with no IVA model?

[codepoet]

Oh! alright, this makes a lot more sense now. Now I'm curious what will happen in my station when the IVA features are implemented. Will it perhaps be possible to see inside the inflatable module from habitat pack from the hitchhiker since the docking port is attached over the window, or vice versa? And what would you see when looking into parts with no IVA model?

Those are the pertinent questions to ask with regard to such a feature. It is not a feature that would be added to CLS itself - CLS is just about working out which bits are connected to which other bits internally, and making that information available to other mods that want to do stuff with it. However other folks have talked about the possibility of an IVA mod that does the things you mention, and therefore would have to address these issues. I am not aware of anyone who is actively working on this at the moment.

[Haifi]

I have a problem here. All hatches are shown as closed, but there is no option showing up to actually open them… Im using version 1-0-4-1, with the last stable version ( the one without the bug ) everything worked fine. And the station i have built before version change still shows the option to open the hatches. Everything I build now does not. Any Ideas?

These are not working.

And these are still working despite the version change.

Best Regards

[codepoet]

Nevermind CLS - where did you get that awesome torus?!

In answer to your question - the docking ports on the first picture do not have the option to open the docking port hatches because the docking ports are not docked - they are attached. if you decouple them and then dock them, then you will be able to open the hatches. The difference is part of the game, not CLS, and you can tell the difference by the menu offering your the action "decouple node" rather than the action "undock".

You might have the view that this is dumb, and you should be able to open the hatches anyway, an opinion that you are welcome to. There are a few slightly tricking coding considerations to enable the player to open hatches for docking ports that are not docked, but attached to another docking port. It is not an impossible problem, but large enough that I could not be bother to make the effort to make it work - sorry. Perhaps you can think of it as the parts being bound together in a way that is structurally more secure for the launch phase, but that prevents the hatches from being opened. This stuff was all discussed earlier in this thread (or was it the other thread?).

I am not sure what the issue is with the second picture.

[Haifi]

Ahh, thats why they dont work. Sorry i did not know that this is counted as a different state for docking ports. As for that torus, its from a kind of abandoned parts pack i found. Had to modify the config a bit in order to get it to have the proper size and nodes. I can put together a zip and send it if youre willing to pm me with your e-mail or i can see if i can upload it somewhere. Theres some girder rings also, in 5, 10 and 20 meter size included in that pack.

Best regards.

[Papa_Joe]

Update:

I've just released Ship Manifest 0.23.5.3.3. This version of SM is now CLS optional. if you wish to use CLS with SM 0.23.5.3.3 or later, be sure to use CLS version 1.0.5.0 or later.

If you do not wish to use CLS, remove it from your gamedata folder.

Let me know what you think!

codepoet will be announcing the release of version 1.0.5.0 soon, but it is available now from his Github site. check out his op for the download details after he announces.

Edited May 30, 2014 by Papa_Joe

[sumghai]

codepoet, just a heads-up that the config you wrote for FusTek Station Parts Expansion X0.04-2 isn't needed anymore - the latest version is FusTek Station Parts* X0.04-3-1, which natively supports CLS. I'm not sure why people are still using the older dev builds.

*I've dropped the Expansion moniker now that fusty has officially handed his project over to me

[codepoet]

v1.0.5.0 now released and available from the front page of this thread.

This update provides a scheme to make it easier for other mods to not use CLS. If you update to this version of CLS you should update any other mods you have that use it (ie Ship Manifest / Kerbal Hot Seat)

[codepoet]

Good work - thanks. The config you refer to is not shipped with CLS v1.0.5.0