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

[codepoet]

Good stuff. I would be interested in whether the way the highlighting of spaces is now working, and if it makes things easier or harder for Ship Manifest.

Next up to do

• the reflection wrapper,
  
• improvements to the GUI
  
• hooks that can be used by mods such as Porkjet to change the passability / habitability of parts in flight.
  
• Better VAB/SPH descriptions
  
• support for more part packs!
  

[Papa_Joe]

Good stuff. I would be interested in whether the way the highlighting of spaces is now working, and if it makes things easier or harder for Ship Manifest.

Next up to do

• the reflection wrapper,
  
• improvements to the GUI
  
• hooks that can be used by mods such as Porkjet to change the passability / habitability of parts in flight.
  
• Better VAB/SPH descriptions
  
• support for more part packs!
  

Ran into an incompatability last night. loading SM without recompiling and it fails miserably with the new version of CLS. I recompiled with the new dll referenced, and lost one of my test game saves (20 + ships) similar behavior to the last "event"... docking ports?

anyway, I had to revert to get it working. Right now the button does not show up in the latest release version, and in the compiled version under test, I cannot see a ship when I load it to the launch pad... very weird.. not sure if it is me or CLS...

I will do some more testing tonite, to determine if I can find the root cause.

[Fraz86]

Version 1.0.4.1 breaks passability for any part in which at least one (but not all) nodes are meant to be impassable. For example, the copula module is meant to be passable through the bottom but not the top. With v1.0.4.1, it is not passable through either node. The same problem occurs for any similarly configured part. I have copied the pertinent excerpt from CLSStock.cfg below:

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

UPDATE: Thankfully, it appears this problem can be fixed with a few simple config edits. Basically, previous versions of CLS assumed that "passable = true" for crewable modules, with the exception of any nodes explicitly defined as impassable. Version 1.0.4.1 no longer makes this assumption. Thus, parts like the copula now need to have their passable nodes explicitly defined. For example, the following correction will fix the copula:

@PART[cupola]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		impassablenodes = top 
		passablenodes = bottom
	}
}

Edited May 9, 2014 by Fraz86

[codepoet]

Version 1.0.4.1 breaks passability for any part in which at least one (but not all) nodes are meant to be impassable. For example, the copula module is meant to be passable through the bottom but not the top. With v1.0.4.1, it is not passable through either node. The same problem occurs for any similarly configured part. I have copied the pertinent excerpt from CLSStock.cfg below:

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

Thanks for this. I think the way ahead is to keep the current scheme, but change the configs. The example you give will become:

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

It is longer, but it more explicit.

I will make the necasery changes to the configs that are shipped with CLS.

Edited May 9, 2014 by codepoet

[codepoet]

Ran into an incompatability last night. loading SM without recompiling and it fails miserably with the new version of CLS. I recompiled with the new dll referenced, and lost one of my test game saves (20 + ships) similar behavior to the last "event"... docking ports?

anyway, I had to revert to get it working. Right now the button does not show up in the latest release version, and in the compiled version under test, I cannot see a ship when I load it to the launch pad... very weird.. not sure if it is me or CLS...

I will do some more testing tonite, to determine if I can find the root cause.

Can you provide some more details - logs or something? The things you describe really should not be happening following a rebuild.

[Fraz86]

Thanks for this. I think the way ahead is to keep the current scheme, but change the configs. The example you give will become:

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

It is longer, but it more explicit.

I will make the necasery changes to the configs that are shipped with CLS.

FYI, the tooltip descriptions in the SPH/VAB don't like modules defined as "passable = true, impassablenodes = top". The description says that the module is passable through all nodes, even though in-game it functions as intended (only the bottom node is passable). Defining the passable and impassable nodes explicitly (without "passable = true") seems to avoid this problem (i.e., "impassablenodes = top, passablenodes = bottom").

[softweir]

I have some logs, download them from: HERE.

Minimum mods for the test, just CLS, SM and buttonbar.

[Fraz86]

Another bug report, not sure if this is new with v1.0.4.1 or an old issue: If I dispose of my root command module while the CLS window is open, the window basically freezes. It won't update when I select a new root part, nor can the window be moved or closed.

[Papa_Joe]

I have some logs, download them from: HERE.

Minimum mods for the test, just CLS, SM and buttonbar.

Thanks! codepoet and i discussed it on the SM thread, and it turns out the be an assembly version issue.

New Version of SM out. Hot fix. to make it compatible with CLS 1.0.4.1.

Edited May 10, 2014 by Papa_Joe

[sumghai]

Just here to report that Ship Manifest 0.23.5.3.2.2a and CLS 1.0.4.1 work perfectly, both with stock ports and my FusTek IACBMs - the hatches now open/close properly too, dividing the living spaces as intended.

Thanks so much, guys

[Fraz86]

If you attach 2 docking ports together in the VAB, the game does not recognize them as "docked" (they are instead viewed as 2 parts connected by an ordinary node/joint). As such, there is no option to open the hatches on these ports, and the connection thus remains impassable. The only solution is to decouple the ports and then re-dock them, which is obviously rather annoying.

[sumghai]

If you attach 2 docking ports together in the VAB, the game does not recognize them as "docked" (they are instead viewed as 2 parts connected by an ordinary node/joint). As such, there is no option to open the hatches on these ports, and the connection thus remains impassable. The only solution is to decouple the ports and then re-dock them, which is obviously rather annoying.

I've noticed that as well, although to be honest, that's a limitation of the stock game itself, not anything specific to CLS.

[Fraz86]

I've noticed that as well, although to be honest, that's a limitation of the stock game itself, not anything specific to CLS.

CLS is apparently checking whether or not a port is "docked", and then only displaying the "Open hatch" option if the port is docked. My proposal would be to disable this check, or to only check that the node is attached to something (not necessarily "docked").

[codepoet]

Thanks for this. I think the way ahead is to keep the current scheme, but change the configs. The example you give will become:

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

It is longer, but it more explicit.

I will make the necasery changes to the configs that are shipped with CLS.

I have woken up with a bit of a change of heart. I think what is also missing is the recognition that if a part is habitable it is also passable by implication. I will fix this for a future release.

[codepoet]

If you attach 2 docking ports together in the VAB, the game does not recognize them as "docked" (they are instead viewed as 2 parts connected by an ordinary node/joint). As such, there is no option to open the hatches on these ports, and the connection thus remains impassable. The only solution is to decouple the ports and then re-dock them, which is obviously rather annoying.

Yes, annoying, but maybe a feature (docking ports need to be docked to be docked)

Anyway, behind the scenes I was aware of the issue. I the latest release the code changes mean that if the hatches were opened then the joint would become passable (previously this was not the case). However, as you say the problem is that it is not possible to open the hatches when parts are attached and not docked. In the end I decided to ship and fix it later, as it was not a step backwards from.the previous release.

[softweir]

Oh! So that's why I can't launch a KSO with tug in the cargo bay and transfer a crewman to the tug before deployment!

Fair enough, I just need to undock it then redock it again - but a fix will be nice some time along the line.

Thanks for this, it's a neat mod and very useful!

[Krevsin]

Does this work with Bobcat's soviet pack?

[codepoet]

Oh! So that's why I can't launch a KSO with tug in the cargo bay and transfer a crewman to the tug before deployment!

Fair enough, I just need to undock it then redock it again - but a fix will be nice some time along the line.

Thanks for this, it's a neat mod and very useful!

Well technically you needs to decouple it, and then dock to it (notice the text when you right click).

I will try to look into this as it is obviously annoying.

[codepoet]

Does this work with Bobcat's soviet pack?

I do not think that there is a config for that pack. However it is easy to write one - there is even a HOWTO guide in the plugin folder for the mod. If you do get it working - please share so it can be added for the next release.

[jinks]

I have woken up with a bit of a change of heart. I think what is also missing is the recognition that if a part is habitable it is also passable by implication. I will fix this for a future release.

Isn't that how it was before?

To be honest, I believe the version suggested by Fraz86 (no implicit passability / every passable node configured explicitly) looks the most correct / intuitive. It requires a bit more work up front, but adding CLS configs for mods is quite simple in itself.

[TerrificToby]

Hello fellow kerbonaughts,

I have run into a slight problem.

due to an inconviniently placed bulkhead and probe core, I can't move my kerbals from one pod to another using the connected living space mod.

This presents a large problem as without access i can't effectively do science.

i know there is a workaround of using an EVA transfer, but i feel this takes the realism away.

cheers,

Toby

[codepoet]

Isn't that how it was before?

To be honest, I believe the version suggested by Fraz86 (no implicit passability / every passable node configured explicitly) looks the most correct / intuitive. It requires a bit more work up front, but adding CLS configs for mods is quite simple in itself.

A couple of things on this:

1) I have gone through all the configs that CLS ships and explicitly added the passability config, so that will be out in the next release.

2) The reason that CLS tried to make good guesses (ie if crewcapacity>0 then make it passable) was in order to make CLS work with as much stuff as possible while configs were not available. Perhaps we are at the stage now when we can start saying that config needs to be explicit. I looked at the code today, and it is not easy to tell is passability has been set or not as it is treated as a bool type, so there is no unset state. I keep changing my mind on this....

[TerrificToby]

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.

please help,

Toby

Edited May 10, 2014 by TerrificToby

[softweir]

Not sure what you mean. It would help if you saved a piccy to imagr or photobucket and linked to it here.

[Fraz86]

A couple of things on this:

1) I have gone through all the configs that CLS ships and explicitly added the passability config, so that will be out in the next release.

2) The reason that CLS tried to make good guesses (ie if crewcapacity>0 then make it passable) was in order to make CLS work with as much stuff as possible while configs were not available. Perhaps we are at the stage now when we can start saying that config needs to be explicit. I looked at the code today, and it is not easy to tell is passability has been set or not as it is treated as a bool type, so there is no unset state. I keep changing my mind on this....

I'll cast my vote against assumed passability; I like explicit, transparent configs.