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

[S4qFBxkFFg]

This has been debated to death (in fact, one of my posts was the start of the most recent debate). Given how many different interpretations there are, the current standard is to let players use Module Manager to do what they want. The stock passability list is pretty minimal by design.

Fair enough, I'll probably put together an extended config file for the stock parts and if anyone wants to use it they can - anything to help whoever ends up coding kerbal first-person movement inside craft...

[codepoet]

Fair enough, I'll probably put together an extended config file for the stock parts and if anyone wants to use it they can - anything to help whoever ends up coding kerbal first-person movement inside craft...

I am hoping to also provide a couple of extra configs for stock parts in the release, so people can choose their style of play. If you would like to send me your "extended" config file I would be happy to use it as the basis for a set of config in the release for those who want a "freer style of play".

I am not sure about girders though in any circumstances - it seems to me that this is all about where kerbals can get to internally.

[codepoet]

Sorry to double post, I just wanted to add that I would really apprechiate more contributions of configs for other part packs. Rather that us spending energy debating what settings there should be of stock parts, I want to extend the list f mods that this is compatable with.

[Dix2lespace]

Do you mean you would like some config so that CLS works with TP's stock parts resized mod? Yes I can do that - I hope to support all major part packs eventually, it is just a matter of going through them all. I am not familiar with that particular part pack - would you like to suggest which parts in particular you think kerbals should be able to pass through?

It wiil be great to incorporate the HUB 2.5m, 3.75m and 0.625m. For the moment, only the 1.25m HUB works.

[Papa_Joe]

@codepoet,

I've found a behavior I'd like to tweak.

highlighting is hit or miss when you mouse over parts highlighted by CLS. Crew Manifest currently exhibits this behavior as well. I had the exact same issue in Ship Manifest, early in development. I solved it using a delegate function attached to the affected part's mouse out event.

This allows proper mouse behavior until you leave the part, and reverts the part to your desired highlighting. Very clean. Just remove the delegate function when you hide the control window or change the space(s) selected.

Also, I'd like to be able to control the colors for part types. I'm thinking static properties would due nicely.

Thoughts?

Edited March 8, 2014 by Papa_Joe

[codepoet]

@codepoet,

I've found a behavior I'd like to tweak.

highlighting is hit or miss when you mouse over parts highlighted by CLS. Crew Manifest currently exhibits this behavior as well. I had the exact same issue in Ship Manifest, early in development. I solved it using a delegate function attached to the affected part's mouse out event.

This allows proper mouse behavior until you leave the part, and reverts the part to your desired highlighting. Very clean. Just remove the delegate function when you hide the control window or change the space(s) selected.

Also, I'd like to be able to control the colors for part types. I'm thinking static properties would due nicely.

Thoughts?

I like it. I will look at the ShipManifest code, and see what you have done, and make some changes for the next release.

How is SM looking now? What else are you looking into implimenting before another release?

I may not be doing work on KSP modding very intensely ove rthe next few weeks, as I have a lot going on in real life, but I will be pottering about.

[Papa_Joe]

I like it. I will look at the ShipManifest code, and see what you have done, and make some changes for the next release.

How is SM looking now? What else are you looking into implimenting before another release?

I may not be doing work on KSP modding very intensely ove rthe next few weeks, as I have a lot going on in real life, but I will be pottering about.

Thanks!

I've been busy releasing a new version of some software at work , so I've not been able to do much the past week. however, time is getting better.

i have completed basic xfers from space to space. I'm incorporating part to part highlighting, which is when I discovered the issue above. So far the API is working well.

My goals for the next release include:

- Add space transfers.

- add move kerbals in a space. Currently, the the move only moves from seat to seat in a pert. This will allow seat to seat in a space.

- Update to crew transfers to be internal path aware, so you can't move a crew member to a part that is not connected internally.

- I also plan to add sounds to space transfers,

- Highlighting the parts in the path as the kerbal "moves" thru the ship. This would apply to both spaces and to crew xfers.

It seems a bit redundant to include space transfers and crew transfers, but it also give some flexibility. I've already included a switch to turn off crew transfers, so if you wanted you could use space transfers only.

Thanks for your efforts, and I'll keep you posted. I hope RL provides you a chance to play, and If there other changes I think of, I'll post. If I need something really bad, I'll likely do a pull and make the changes for you to examine when it is convenient, if that is okay with you.

Edited March 8, 2014 by Papa_Joe

[codepoet]

If I need something really bad, I'll likely do a pull and make the changes for you to examine when it is convenient, if that is okay with you.

That is cool. If you need the fix to make progress and I am not getting on with it, then hack up my code and send me a pull request. Since we have talked a lot about where we are going in terms of CLS interation, I doubt you would take it off in some bizzare inappropriate direction!

[codepoet]

On the release thread CalculusWarior said:

A suggestion: perhaps you could make empty fuel tanks passable, to be something like NASA's wet workshop idea?

Hmmm. Interesting idea.

I suppose my immediate thought would be to reply to this sort of thing by saying "configure it yourself using module manager", but I recognise that a code change will be required to check the fuel level etc, so it is a bit more complicated.

My usual instinct in software is to try to make things more generic, so in this case perhaps what you are asking for is similar to problems to do with the porkworks inflatable habs, where the habitability/passability of a part depends on a dynamic aspect of its state. (it the part inflated or not? If the part full of fuel or not?)

I think I am uncomfortable with the idea of part just becoming passable because they are drained of fuel. However perhaps a better suggestion would be "can you make XYZ Corp's funky new wet workshop part passable / habitable?" That, I think would be well worth the effort so some how interface between the wet workshop conversion plugin that would be required and CLS. Perhaps CLS could define an interface and event / callback that other mods could support it they are capable of changing their habitable / navigable state dynamically.

Anyone got any thoughts on this?

[S4qFBxkFFg]

However perhaps a better suggestion would be "can you make XYZ Corp's funky new wet workshop part passable / habitable?" That, I think would be well worth the effort so some how interface between the wet workshop conversion plugin that would be required and CLS. Perhaps CLS could define an interface and event / callback that other mods could support it they are capable of changing their habitable / navigable state dynamically.

This sounds like the best way of doing it - it does bring up the question of what should happen to the kerbals involved if a part becomes uninhabitable though...

[codepoet]

This sounds like the best way of doing it - it does bring up the question of what should happen to the kerbals involved if a part becomes uninhabitable though...

I think it is the responsibility of the wetworkshop pluging, or the inflate/deflate plugin to ensure that the part is not deflated/filled with fuel while there are kerbals inside. CLS does not deal with stuff that happens, it just tells you where it is possible for kerbals to move to / stay.

[rhoark]

Jeb would totally design a ship where the crew hatch opens directly into a vat of nitric acid.

[Fraz86]

I've found a bug regarding the CLS module descriptions that show up in the VAB. Their descriptions in terms of which nodes are passable/impassable appear to reflect only the default settings. For instance, I changed the lander cans to be passable only through the top node, and this functions as intended in game, but the description still says they're passable through all nodes. Also, for whatever reason, the Hitchhiker module seems to lack a CLS description altogether (though it still function as intended).

[codepoet]

I've found a bug regarding the CLS module descriptions that show up in the VAB. Their descriptions in terms of which nodes are passable/impassable appear to reflect only the default settings. For instance, I changed the lander cans to be passable only through the top node, and this functions as intended in game, but the description still says they're passable through all nodes. Also, for whatever reason, the Hitchhiker module seems to lack a CLS description altogether (though it still function as intended).

Thanks for this. I have raised an issue in github for it. It would be helpful to have the following infomation:

1) What version of CLS are you using?

2) Could you provide a copy of you config file for you lander cans that are displaying the wrong descriptions.

[Fraz86]

I fixed my first issue by adding "@passable = false" to the ModuleManager config for the parts in question. I had previously assumed that setting impassablenodes as desired would be sufficient (and it was sufficient in terms of in-game function, but just not for the VAB tooltip thing). The Hitchhiker module, however, continues to lack a tooltip. Moreover, I can't seem to find a config for it in any of your included CLSStock ModuleManager file, and yet it functions correctly in game. I'm using CLS version 1.0.3.0.

Edited March 19, 2014 by Fraz86

[codepoet]

Thanks. I will get to it when I have a moment.

[CaptainKipard]

Will anything break if I add the module to a part cfg but not have the mod installed?

[softweir]

No, so long as you match opening and closing brackets properly. KSP ignores any .cfg entries it doesn't understand.

[Dix2lespace]

hi! I need help plz. My docking is not blue. It's yellow and I can"t open the hatch.

http://imgur.com/iOjQPrX

http://imgur.com/TyK0ajB

Edited March 26, 2014 by Dix2lespace

[codepoet]

That will be because the game dose not consider two adjecent docking ports that were assembled in the VAB to be docked, they are just joined like other parts are. To get them to be blur, you need to seperate them and then dock them together.

[codepoet]

hi! I need help plz. My docking is not blue. It's yellow and I can"t open the hatch.

http://imgur.com/iOjQPrX

http://imgur.com/TyK0ajB

A bit of an update folks:

It seems mu first reaction to this was incorrect. I believe that the problem is because the sheilded docking ports are not correctly handled by CLS. Looking into it I believe that the lateral ones are also not handled correctly, and that this issue will also be related to the Porkjet Flathab. Let me explain:

When two parts are docked, they are not "conected" in the wayn that other parts are, and so the CLS code that walks the part tree does not work for docked connections. However that does nat matter, because I have handed docked connections as a special case, which works for the dock-o-tron / junior / large. It does this by taking acount of the referenceAttachNode in the config for the ModuleDockingNode on the part. However for the shielded and lateral docking parts, there is no referenceAttachNode, hence CLS barfs!

I am trying to figure out how I can detect a docked connection in the scenario where referenceAttachNode is not set, but for now I am struggling a little. If anyone knows more about this that I do (perhaps Porkjet or whoever do the work with him on getting his flathab docking ports docking) might be able to assist me with this.)

[S4qFBxkFFg]

codepoet: Firstly, the config file for the KSOS I sent isn't correct - I've sent the better version.

However, I'm struggling with a particular part in that mod - I can't seem to set the bottom node of the SST (the space station construction tug) as passable while also making the middle node impassable.

Could it be something to do with the fact that they have very similar names?

The relevant code from the tug's config file is:

node_stack_bottom01 = 0, 0.0, -0.6525, 0, 1, 0, 1
node_stack_top = 0, 1.332, 0, 0, 1, 0, 1
node_stack_bottom = 0, -1.332, 0, 0, -1, 0, 1

(note that the node in the middle is the first in the list, bottom and top appear to be named as would be obvious when viewing in the VAB)

What I have in the CLS config is:

@PART[KSO_SST]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		impassablenodes = node_stack_bottom01
	}
}

However this makes both the middle and bottom nodes impassable and I'm not sure where to go from here.

(Just using "passable = true" makes every node passable, as expected, but that's not perfectly desirable behaviour either.)

[codepoet]

A couple of thoughts:

1) the names of the nodes are "top" , "bottom" etc. the "node_stack" bit gets stripped off when the game reads the config.

2) the have you tried setting "passablenodes"? It may well work as follows:

@PART[KSO_SST]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		impassablenodes = bottom01
	}
}

Note that specifying a node as impassable implies that all the others are passable. Perhaps the reason it was not working for you was that node_stack_bottom01 was not being recognised, hence nothing was impassable, and hence nothing was passable by implication!

You could also try:

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

The suggestion here is that by specifying some nodes as passable implies that those not oin the list are impassable. I am not sure if this will work as I have not tried anything like this myself.

You could also try:

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

Thanks for all your work on this. If any of these fix the problem, do please send me a new config file, and I will ship it in the next release, once I have fixed some bugs.

Also a heads up for anyone hoping for support on CLS - I am going skiing next week , so sorry, it might have to wait!

[S4qFBxkFFg]

A couple of thoughts:

1) the names of the nodes are "top" , "bottom" etc. the "node_stack" bit gets stripped off when the game reads the config.

2) the have you tried setting "passablenodes"? It may well work as follows:

-snip-

You could also try:

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

Thanks for all your work on this. If any of these fix the problem, do please send me a new config file, and I will ship it in the next release, once I have fixed some bugs.

Also a heads up for anyone hoping for support on CLS - I am going skiing next week , so sorry, it might have to wait!

Yes - all working now (I didn't even know the "passablenodes" syntax was acceptable...), just about to send the updated file.

[codepoet]

A quick update before I go offline for a while:

1) I have been working oin making shielded and lateral docking ports works properly with CLS. Shielded seems to work. There is a quirk with the lateral one that I need to work out.

2) Doing the above work involved refactoring the code, and a lot of things are much clearer now:

3) The passable/impassable node config is better implemented

4) passable/impassable docking node types has been added to the config. This was needed for the shielded docking node and others where there is no referenceAttachNode in the config. However it will be generally useful.

5) All of the above should make CLS work with the PorkJet flathab

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?"

7) Folks have been sending me config for more part packs, so expect that in the next release.

8) I have also been trying to provide a .net reflaction style wrapper for CLS so other mods can use it wothout having a hard dependency on it.

So lots to come, but I am going skiing first