Jump to content

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


codepoet

Recommended Posts

Does this mod allow compatibility with all mods that has crew stuff?

If a part can hold crew then it will automatically be marked as habitable by CLS. However other parts, such as docking nodes, and structural parts that you might want to use a corridor will need some config added. Having said that it is not hard to add config for a part for CLS,and once you have done it you can share it with the community so it can be shipped with future verisons. Also some part packs are starting to be released with config for CLS already written.

I hope that answers your question, I was not entirely sure what "crew stuff" was!

Link to comment
Share on other sites

If a part can hold crew then it will automatically be marked as habitable by CLS. However other parts, such as docking nodes, and structural parts that you might want to use a corridor will need some config added. Having said that it is not hard to add config for a part for CLS,and once you have done it you can share it with the community so it can be shipped with future verisons. Also some part packs are starting to be released with config for CLS already written.

I hope that answers your question, I was not entirely sure what "crew stuff" was!

Yes that is what I was asking. I will try adding some configs for some mods I use that don't already have them when I get some time and maybe share them here. :)

Link to comment
Share on other sites

Hi,

I think I might be having an issue with CLS. I've constructed a space station using the stock node for docking ports (the Rockomax HubMax Multi-point Connector). One side of the node is attached to a stock habitat module (the PPD-10 Hitchhiker Storage Container) and the other five have docking ports attached to them and those are docked to various other parts of the station (all docking ports are open). For some reason, CLS isn't recognizing the node as a passable part (it's not highlighted in yellow like it is in the picture on the first page of this thread). I can use Ship Manifest to move kerbals in the station from, say, one of the science labs to the other or from one of the habitat modules to the other, but I can't get them to cross the docking node to go from habitat to lab or vice versa. Did I do something wrong somewhere? Thanks!

Link to comment
Share on other sites

Made a small cfg to the B9 adapters.

I`ll just leave it here and maybe add some more details from this pack later.

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

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

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

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

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

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

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

Edited by Riverey
Link to comment
Share on other sites

Have you opened the hatches in the docing ports? Right click on them, and choose "Open Hatch", then you should be able to pass through them.

Yes, I made doubly sure of that. All hatches show the 'Close Hatch' option when I right click them. I still can't pass through the node, oddly enough.

Link to comment
Share on other sites

Hey!

Noticed some more bugs=/

First of all, then i use ship manifest, sometimes the highlight doesn't switch off then i close SM window. And it continues to glow even then i switch to another near-by vessel=/ (maybe it's problem of ship manifest, but i'll leave it here too).

And another one - after opening/closing hatches and merging/separating living spaces they all have the same name (maybe it's because i use russian letters?).

And finally some ideas - maybe you can coop CCL with Modular Fuel Tanks to track free space in the tanks? For example if it's more than 200, fuel tank can became crew-passable (same for batteries).

Link to comment
Share on other sites

Hey!

Noticed some more bugs=/

First of all, then i use ship manifest, sometimes the highlight doesn't switch off then i close SM window. And it continues to glow even then i switch to another near-by vessel=/ (maybe it's problem of ship manifest, but i'll leave it here too).

There are bugs with the highlighting. I have made changes to the code related to this ready for the next release that will hopefully make the highlighting work much better.

And another one - after opening/closing hatches and merging/separating living spaces they all have the same name (maybe it's because i use russian letters?).

I think the way it works is that when you renamed a space, all the parts in that space get assigned that spacename. However the actual name of a space is plucked from one of the parts in the space. When spaces merge (because you opened a hatch) the new joined up space will have a name that has been taken from the stored space name for one of the parts in the space, but the different parts will still have their own stored space name (unless you manually renamed the space), so when the hatches are closed, the names of the spaces should be restored.

I have not paid much atention to this recently. I will do some testing on this with the forcoming release and see if it is working as it should be.

And finally some ideas - maybe you can coop CCL with Modular Fuel Tanks to track free space in the tanks? For example if it's more than 200, fuel tank can became crew-passable (same for batteries).

Someone was suggesting a while back that CLS somehow support the "wet workshop" concept, and there was a discussion on how to achieve it.

Link to comment
Share on other sites

I'm pretty sure that i have not changed name of space after docking and opening the hatches... Anyway, it's not very important and i'll also try again later. Problem with highlighting is much more frustrating=) With it big ship looks like a christmas tree.

Sorry=) i read some previous pages but looks like it was much earlier. I'll try to find. Can you please describe what "wet workshop" means?)

Link to comment
Share on other sites

I'm pretty sure that i have not changed name of space after docking and opening the hatches...

I have tested for this in the development build for the new version and it is not working as I described it should. I will open an issue in github to keep track of this issue. Thanks for raising it.

Link to comment
Share on other sites

Oh, yeah, i read about this but in russian, so i missed the name.

No my idea is slightly different. I'm talking about adding a possability to be crew-possable to the tanks from the start. It can be like a resource type for the tanks but with fixed room for it - so then you customize your tank in VAB you can chooze it and make tank passable and then fill remaining space with whatever you whant.

Link to comment
Share on other sites

Here is a picture:

screenshot0.png

This shows two surface attachments within a craft. One if between a structural fusilage and a radial stack adapter. The structural fusilage is configured to allow surface attached parts to be passed into. The radial stack adapter is configured to allow it to make passable connections into thesurface of other parts. As a result they create a passable connection.

However the other surface attachment (the radial stack adapter onto the side of a mark3 pod) does not createa passable connection. this is because the pod does not allow surface mounted parts to be passable in this way.

I will document the new config options when it becomes available in the next release (which should be soon :) )

Link to comment
Share on other sites

The v.1.0.4.0 release includes a HOWTO file that explains how to write config files to get CLS support for your favourite part packs. I thought it wise to post it here:

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 separated into 2 living spaces before undocking so the player can double check which kerbals are in which vessel. The functionality 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.

Link to comment
Share on other sites

Just patched 1.0.4.0 and nothing else and now in career mode all my vessels which had docking ports are gone. I can research every one of the docking ports each in 3 separate technologies but every time I enter SPH or VAB I still can't select them as if they're unresearched. After that if I go back to research them, they're all available for research again. If I research them and go out to space center and back in they're still researched but as soon as I enter VAB or SPH or try and load a craft they're all unresearched.

I deleted CLS and now all docking ports are in the correct technologies and only once and after reresearching them they're all available in SPH and VAB

Link to comment
Share on other sites

I am seeing something similar - everything has gone weird when I try to use the release build (dev builds were all fine!). Best to suggest folks do not use this for now :( Sorry everyone!

Link to comment
Share on other sites

Just patched 1.0.4.0 and nothing else and now in career mode all my vessels which had docking ports are gone. I can research every one of the docking ports each in 3 separate technologies but every time I enter SPH or VAB I still can't select them as if they're unresearched. After that if I go back to research them, they're all available for research again. If I research them and go out to space center and back in they're still researched but as soon as I enter VAB or SPH or try and load a craft they're all unresearched.

I deleted CLS and now all docking ports are in the correct technologies and only once and after reresearching them they're all available in SPH and VAB

Out of interest - what other mods are you using?

Link to comment
Share on other sites

As I posted in your development thread, the problem is your "CLSAddHatchesToDockingNodes" file, which renames the docking parts themselves instead of replacing the docking module. This essentially breaks docking ports. See below:

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

I believe the following replacement should work as intended:

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

However, this change does not seem to entirely fix the problem. Right-clicking a docking port reveals "Hatch: closed", but I don't see any option to open the hatch.

Unrelatedly, I also noticed that you do not appear to have included any configs for radial attachments.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...