[WIP] "Connected Living Space"- API for connected habs (new download 9 June 14)

[Starstrider42]

It will be configurable on a per part basis (ie does this part allow living spaces to be connected to surace attached parts?"

Yay! Thanks a lot!

[curiousepic]

Any update on progress or 0.23.5 compatibility?

[Mecha Pants]

I'm using it in .23.5, it doesn't seem to have any issues on my end.

[codepoet]

Just an update.

I am sorry folks, I had hoped to have a new version for you all by now, and one that I could certify was compatible with 0.23.5. I am afraid that as I have been fiddling withthe code it has all turned to dust in my hands . In particular I am getting in a muddle over hatches / docking ports and parts. The fact that it is proving to be such a bore is a good indication that I am naot correctly modeling the problem. Indeed I am not. Currently CLS adds the cocept of a "hatch" to any part that has one or more docking nodes. However, really what I need is to add the concept of a hatch to each docking node.

I have decided that I will do this which means lots more code change and not release for a while. It will get there eventually, and be a better mod for it.

Sorry

[diomedea]

I am sorry folks, I had hoped to have a new version for you all by now, and one that I could certify was compatible with 0.23.5.

...

I have decided that I will do this which means lots more code change and not release for a while. It will get there eventually, and be a better mod for it.

Sorry

What, you say to be sorry for willing to provide us all with a better mod? Wish everybody was sorry, then .

You already have the concept about how to make this better, and in a most sensible way (IMHO). 0.24 won't take too long, so I would say you don't have to rush for 0.23.5 compatibility.

[icemonkey]

So how would you go about just making a single right-angle with this? I'm trying to make a T- Junction for a station, and the only way I can seem to do it is with one of the quad connector parts... Obviously radial attachments don't work, so any suggestions?

EDIT: Just realised what you said the most recent update does... Does this fix the problem? Or will it lead to a fix? The ability to use the Radial Attachment Port as a hatch would be useful...

Edited April 14, 2014 by icemonkey

[Starstrider42]

So how would you go about just making a single right-angle with this? I'm trying to make a T- Junction for a station, and the only way I can seem to do it is with one of the quad connector parts... Obviously radial attachments don't work, so any suggestions?

In the current version, the station hub is the only stock part that does what you want, but:

6) The refactoring excersise has resulted in support for surface attached parts. I have not tested this yet, but it just falls out naturally as a consequence of having tidies up the code. It will be configurable on a per part basis (ie does this part allow living spaces to be connected to surace attached parts?"

So yes, it's coming.

[codepoet]

I hope the next release will support radial attachments. However I am at a point at the moment where I have taken EVERYTHING to bits, and I am stuggling to put it back together (ooops!). I will get there - eventually.

[codepoet]

Just doing a little happy dance - I have finally managed to solve all the nasty spagettii problems, by moving the concept of hatches out of the CLS modue and into the docking port module. So now you can replace your docking ports with docking ports that have hatches. Lovely. Loads of the code just falls away, which is always fo sign of a more elegent solution, and one more likely to work as well. I can get on an fix up all the other fixes in CLS I have been working one now .

[codepoet]

OK, I have got control of my code again!

I am starting to think about making surface atached parts passable. I am considering 2 extra config options for a part:

1) Allow passage into surface attached parts

2) allow passage into parts I am surface attached to.

So only if both of these are enabled would the connection be passable. This means that even if the radial attachment part is configured to allow it to make passable surface attachments it would still be possible for a command pod to refuse to allow a a radial attachment part to create a passable connection. This resists the "cut a hole in anything and plug it in" approach to things.

Thoughts?

[Starstrider42]

OK, I have got control of my code again!

I am starting to think about making surface atached parts passable. I am considering 2 extra config options for a part:

1) Allow passage into surface attached parts

2) allow passage into parts I am surface attached to.

So only if both of these are enabled would the connection be passable. This means that even if the radial attachment part is configured to allow it to make passable surface attachments it would still be possible for a command pod to refuse to allow a a radial attachment part to create a passable connection. This resists the "cut a hole in anything and plug it in" approach to things.

Thoughts?

#1 seems pretty natural. Can you give an example of where flag #2 should be set/unset?

[Fraz86]

OK, I have got control of my code again!

I am starting to think about making surface atached parts passable. I am considering 2 extra config options for a part:

1) Allow passage into surface attached parts

2) allow passage into parts I am surface attached to.

So only if both of these are enabled would the connection be passable. This means that even if the radial attachment part is configured to allow it to make passable surface attachments it would still be possible for a command pod to refuse to allow a a radial attachment part to create a passable connection. This resists the "cut a hole in anything and plug it in" approach to things.

Thoughts?

Sounds like a logical approach. However, I would appreciate an option to globally disallow surface attachment for CLS. I like the idea that modules were engineered with hatches in certain locations, and I enjoy this as an important design consideration/challenge. Moreover, consistency with IVA is important to me, and IVA only depicts hatches existing at nodes.

[diomedea]

May I inquire if the surface attached passage feature may imply a better working of such parts as the Rockomax HubMax Multi-Point Connector?

The HubMax has some issues about radial attachment. The only nodes it will get connected to another part, are the top and bottom ones (stack mounting). The lateral ones (left, right, front and back) can be used to connect another part to an already attached HubMax; but not to connect the HubMax to an existing part. To connect a HubMax to another part, it always must be rotated so to have top or bottom nodes facing the part. This is an issue of the stock game, not of CLS.

Also, I get the above is tied to the vessel structure, any part can be connected to only another (but can have many parts attached to it), therefore creating a tree-like structure; having a part able to attach to more than one, would create loops and some of KSP functionalities are not devised to deal with them (e.g. the tanks/engines association).

I would be real happy if CLS could in some way correct those "misbehaving" nodes, if only for crew passage (and, believe it is needed, structural joints), but not changing the vessel structure.

[cudern]

Sorry for my bad english

Why BZ-52 Radial Attachment Point Din't work?

I added in the configuration file:

@PART[stackPoint1]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

[codepoet]

Sorry for my bad english

Why BZ-52 Radial Attachment Point Din't work?

I added in the configuration file:

http://i.imgur.com/br2kL7m.png

http://i.imgur.com/Oz0rwmm.png

It does not work for you because CLS does not support radial / surface attachments .... yet.

I am working on that feature at the moment, and it will (hopefully) be supported in the next release.

[codepoet]

OK, here is a build of my current development branch. I am making this available mostly for the beneefit of folks like PapaJoe to ensure that there is nothing that is going to break mods that use CLS. This is not a supported build, please do not use it for playing the game!

[Papa_Joe]

OK, here is a build of my current development branch. I am making this available mostly for the beneefit of folks like PapaJoe to ensure that there is nothing that is going to break mods that use CLS. This is not a supported build, please do not use it for playing the game!

I got it.

I will look it over around 10:00 PM GMT

[codepoet]

The v1.0.4.0 release includes a HOWTO file that explains how to write config files to add CLS support to your favourite part packs. I thought it wise to post the text here as well:

HOWTO write configuration files for CLS

---------------------------------------

version 1 - 1 May 2014

Introduction

------------

Connected Living Space (CLS) creates an understanding of your vessels that considers which parts are connected to each other internally in such a way that a kerbal can move between parts without leaving a pressurised space. These spaces are refered to as "living spaces". In order to be able to create such an understanding, CLS needs to know extra information about each ot the parts, so that it can distinguish between a crew pod and a girder. This extra information can be provided in one of two ways:

1) By the part mod author including this extra configuration in their mod. This is ultimately the prefered method as it allows the part mod author to configure CLS to treat the part as the author intended, and allows the author to make changes as changes are made to the part.

2) By users who want to make a part compatible with CLS. It is great when players do this as it expands the range of mods that CLS can work with. If you write a CLS config fir for a particular mod, be sure to share it with the community by posting tot he CLS thread on the forums. Most likely your work will be included in a future release of CLS which benefits everyone, or may even be adopted by the part mod author.

Use of Module Manager

---------------------

All th examples show below show what the configration for a part should look like. However in practice config for CLS is usually shipped as a config file for Module Manager that patches the config for a part. Read the documentation on module manager, and look at the examples that ship with CLS to see how this works.

Configuration

-------------

configuration for CLS is added by adding a ModuleConnectedLivingSpace to the part that you want to provide configuration for in its .cfg file. Lets consider an example:

PART

{

// Fuselage Fuel Tank

// --- general parameters ---

name = Mk1FuselageStructural

// --- node definitions ---

node_stack_top = 0.0, 75.0, 0.0, 0.0, 1.0, 0.0

node_stack_bottom = 0.0, -76.0, 0.0, 0.0, 1.0, 0.0

node_attach = 0.0, 0.0, -51.0, 0.0, 0.0, 1.0, 1

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

surfaceAttachmentsPassable = true

}

}

In this example the part that has been added is a MODULE section which adds the ModuleConnectedLivingSpace to the part. All parts that are understood by CLS need to have a ModuleConnectedLivingSpace added to them. However any part that can house a kerbal (ie has a crew capacity greater than 0) will automatically get CLS support added to it which works for most scenerios - it would be better if they were explicitly configured though.

* The name value is required to indicate which Module to add to the part - for our purposes this will always be ModuleConnectedLivingSpace

* The passable value indicates if the part can generally be passed through. If this is set to true then it will be assumed that a kerbal can enter / exit the part via any of its attachement nodes.

* the Mk1 Structural Fuselage part has a special value set, which is surfaceAttachmentsPassable. This means that if another part is attached to the surface of the structural fuselage, CLS will allow kerbals to pass into it via that connection. If this is not set it is false by default.

There are several other values that can be set:

* impassablenodes

* passablenodes

These two values allow a list of attachment node names to be specified where the passablity of those nodes is different from the passable for the whole part. This allows parts to be entered via some nodes by not others. The names of the nodes are the names specified in the Node Definitions section of the .cfg file, but without the "node_stack_" prefix. In the example above there are two node that are defined "top" and "bottom". (note that node_attach is used to surface attach the part and can not be specified).

* passableDockingNodeTypes

* impassableDockingNodeTypes

Some Docking Nodes in a part are specified by reference to a transform in the 3D model, rather than an attachment node in the .cfg file. In order to override if these docking nodes are to be passable, you can specify a list of passable or impassable docking node types. These values ned to match up with "nodeType" specified in the ModuleDockingNode for the part.

*surfaceAttachmentsPassable

Setting surfaceAttachmentsPassable to true (as shown in the example above) means that kerbals can pass into a part that has been attached to the surface of this part. It is false by default, and its use is discouraged as using it for a part with an internal model will not make sense visually.

* passableWhenSurfaceAttached

Setting passableWhenSurfaceAttached to be true means that it is possible for a kerbal to pass into another part that this part has been surface attached to. Effectively it allows kerbals to pass through the "node_attach" node. Be aware that a kerbal can only pass through a surface connection is both passableWhenSurfaceAttached and surfaceAttachmentsPassable are set to be true for the respective parts.

In practice setting passable=true is all that is required for most parts forthem to work with CLS, however the config does allow for more subtle configurations.

Hatches in docking ports

-------------------------

CLS provides an update to the stock docking port functionality to allow docking ports to have hatches in them the can be closed. This allows docked vessels to be seperated into 2 living spaces before undocking so the player can double check which kerbals are in which vessel. The fuctionailty is provided by adding ModuleDockingPortHatch to a part INSTEAD of ModuleDockingNode. The default config files that come with CLS will replace all the ModuleDockingNode modules with ModuleDockingNodeHatch modules, however if a part mod provides a new docking port part, then it would be best for it to be explicitly configured with a ModuleDockingNodeHatch.

[Fraz86]

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
     @name=ModuleDockingNodeHatch
}

The above code renames the part itself to "ModuleDockingNodeHatch" (which is very bad) rather than replacing the ModuleDockingNode as you intended. Instead, it should read:

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[ModuleDockingNode]
	{
		@name = ModuleDockingNodeHatch
	}
}

EDIT: My above replacement still won't work properly for parts that have multiple docking nodes, such as Porkjet's Flat Hab. Perhaps the following will work, but I need to test it:

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[*]:HAS[#name[ModuleDockingNode]] 
	{
		@name = ModuleDockingNodeHatch
	}
}

Edited May 1, 2014 by Fraz86

[codepoet]

Thanks for this. I figured out that this was the cause of the problem lastnight in my sleep, but you have offered a solution. Brilliant. I will do some testing and get a proper fixed release out.

Interestingly the version that I released worked as I intended it to all throughout my development for which I used a slightly older version of module manager. I guess the recent work on MM was tightened things up.

[codepoet]

Just to report that I think (hope) I have finally cracked the problem of how to do the hatches - adding them to parts with docking ports at "run time" as it were rather than fiddling with the prefabs which I was previously doing. I think this is now going to work, but I need to do lots of testing to ensure that all is well.

I have a nightmarishly busy day tomorrow, so it might be Tuesday before I can share anything. I will probably offer a development release first as I do not want to fumble it like last time! One it is out I will sort out a soft linking reflection wrapper so Ship Manifest can use CLS without forcing users to do so.

[codepoet]

Here is a picture:

What this shows is a 3 man pod docked to one of the docking ports on a Porkworks flathab. CLS recognises that they are both part of the same living space. Also note that right clicking on the flathab provide the open to close the hatch on the one docked docking port on the flathab (and not the two that are not docked). Closing the hatch on the flathab splits the living space into two.

[CatastrophicFailure]

Forgive me for not trudging thru all 18 pages here...

I've got a docking port with a bad hatch... I click "open" but nothing happens, the GUI doesn't even change. All the other docking ports on the same vessel work just fine. Even tried editing it open in the quicksave and the game still ignores it. Is this a known issue or do I have more troubleshooting?

[codepoet]

I am not sure what you mean by "bad hatch". Is the docking port docked when you try to open the hatch? Did you also open the hatch in the docking port that it is to? What version of CLS are you using?

[CatastrophicFailure]

Assuming I'm using the most current version, just downloaded it the other day. Yes, the bad hatch is docked to another port, that hatch is open and recognized as such by the overlay, but this one hatch doesn't react. Clicking "open" in the GUI does nothing, and the overlay just shows it purple.