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

[codepoet]

Good stuff. When do we get to play?

[ParasiteX]

I created a cfg for KOSMOS parts

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

{

MODULE

{

name = ModuleConnectedLivingSpace

impassablenodes = top02

}

}

@PART[Kosmos_Salyut_1.5_Propulsion_Unit]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

impassablenodes = side00 ,side01, side02, side03, side04, side05

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

@PART[Kosmos_Salyut_1.5-1_Taper]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

@PART[Kosmos_Salyut_2-1.5_Taper]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

@PART[Kosmos_Salyut_3-2_Taper]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

@PART[Kosmos_Salyut_body_1.5]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

@PART[Kosmos_TKS_2-1_Flared_Taper]:HAS[!MODULE[ModuleConnectedLivingSpace]]

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

[codepoet]

Thanks so much for this ParasiteX. I will give this a go and then get it ready for the next release.

BTW I tried to do a config file for b9, but my rubbishie little laptop could not handle it and keeps crashing when I load b9. I would be really grateful if someone else could look into doing that for me.

Also, a general point on writing configs - it is important to provide config for pods etc, even if they seem to be "working" anyway. The reason is that if a part does not have a CLSModule on it then it can not persist its state into saves, and so infomation like the name of the living space that the part in a part of gets lost between saves. This may not matter but it would be better to correct it.

I could do a fancy thing such as just add a CLSModule to a part in the code, rather than in the config, but that is the sort of thing that might lead to compatability bugs, or other unexpected scenarios. I may well get CLS to log a warning if it finds a part with crewcapacity>0 nut no CLSModule, so tha t the issue does not go unnoticed.

[Legendary Emu]

Super excited for Ship Manifest integration. Finally the end of the old fashioned EVA transfer.

Is there a possibility of making Junior docking ports impossible to travel through or is that already done?

[codepoet]

Super excited for Ship Manifest integration. Finally the end of the old fashioned EVA transfer.

Is there a possibility of making Junior docking ports impossible to travel through or is that already done?

Junior docking ports should allready be impassable. If you discover that they are passable, let me know and I will fix it.

[CalculusWarrior]

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

[codepoet]

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? I will copy this post to the development thread where such a discusion it better located.

[Unteknikal]

Super excited for Ship Manifest integration. Finally the end of the old fashioned EVA transfer.

Is there a possibility of making Junior docking ports impossible to travel through or is that already done?

When this is going to happen?

[codepoet]

When this is going to happen?

Do you mean ship manifest? As I understand it, it is in development. Try asking on the ship manifest thread.

[codepoet]

Version 1.0.3.0 is now available

[Zero One]

I have an issue with your mod (its a nice mod)

When you have a non-docked docking port you can open the hatch. imo this should not be possible.

After you have opened it nothing special happens ofcourse but you can not close it again. So at that moment the situation is as it should be.

If you go away to the space centre and come back to your vessel the situation is back as before, allowed to open the hatch again.

[codepoet]

I have an issue with your mod (its a nice mod)

When you have a non-docked docking port you can open the hatch. imo this should not be possible.

After you have opened it nothing special happens ofcourse but you can not close it again. So at that moment the situation is as it should be.

If you go away to the space centre and come back to your vessel the situation is back as before, allowed to open the hatch again.

Thanks for raising this. I have noticed this myself as well. It is caused because at the point that the ship is loaded up there is some uncertainty about the state of soem thing in some situations (I can't remember the detals off hand). If you try to open the hatch then the mod notices that the port is not docked and just removed the Open/Close hatch option. Obviously it would be better to provide a proper fix - I will look into it. I will add your post to github for now to keep track of the issue.

[Zero One]

I have an other problem with your mod

Your mod does not recognize parallel docking points.

When your vessel uses 2 docking ports at the same time to dock to an other vessel with 2 docking ports it gets docked at 2 points at the same time.

Your mod only sees 1 point docked, the other not.

This type of docking does not stop at 2 points but can even have more.

[Starstrider42]

I have an other problem with your mod

Your mod does not recognize parallel docking points.

When your vessel uses 2 docking ports at the same time to dock to an other vessel with 2 docking ports it gets docked at 2 points at the same time.

Your mod only sees 1 point docked, the other not.

This type of docking does not stop at 2 points but can even have more.

I'm pretty sure this is actually an issue with stock KSP -- whenever you multidock, the game only docks you at one point even if it *looks* like they're all aligned.

[Zero One]

I'm pretty sure this is actually an issue with stock KSP -- whenever you multidock, the game only docks you at one point even if it *looks* like they're all aligned.

If you were right why do I have to give an undock command to both points to get undocked?

Answer: Multidocking is working. At least for me. And I have seen many videos where it was working too.

[ParasiteX]

A lil suggestion: Could you add support for surface attached parts to allow passability to any parts they are connected between? Like the stock Radial Attachment point. Or docking ports attached to the surface.

[NathanKell]

If you were right why do I have to give an undock command to both points to get undocked?

Answer: Multidocking is working. At least for me. And I have seen many videos where it was working too.

Not actually true. Both ports will have their "is docked" magnetics enbabled, but the actual part tree of the vessel will be via only one of the ports. Recall, all vessels in KSP are trees of parts; there cannot be multiple routes from one part to another. So for two pod+2docks vessels, the tree will be:

pod1(root)
/      \
dock1A  dock1B
|
dock2A
\
 pod2
   \
    dock2B

Even though dock1B and dock2B both consider themselves docked, and have the magnetic "stick-together" force applied, they're not actually a bridge in the part tree.

[Papa_Joe]

Please add the following to the stock.cfg:

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

Thanks!

[codepoet]

Please add the following to the stock.cfg:

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

{

MODULE

{

name = ModuleConnectedLivingSpace

passable = true

}

}

Thanks!

Ok I will look into that.

Are you using the latest release of CLS? The latest release will automatically add the CLS module to any part with crewcapacity >0 that does not already have it.

On an unrelated note, I am writing a set of wrapper classes that use .net reflection to make it possible to easily only use CLS if it is installed. I am using the toolbar equivelent for inspiration, but am a little unsure how to wrap an enum type - suggestions would be welcome.

Papa Joe, you many wish to consider this for ship manifest, but it sounds like you are already set to go with a hard dependancy which is also great.

[codepoet]

Not actually true. Both ports will have their "is docked" magnetics enbabled, but the actual part tree of the vessel will be via only one of the ports. Recall, all vessels in KSP are trees of parts; there cannot be multiple routes from one part to another. So for two pod+2docks vessels, the tree will be:

pod1(root)
/      \
dock1A  dock1B
|
dock2A
\
 pod2
   \
    dock2B

Even though dock1B and dock2B both consider themselves docked, and have the magnetic "stick-together" force applied, they're not actually a bridge in the part tree.

CLS's algorithm for selecting the living spaces depends on the ship being a tree structure, rather than a cyclic graph, and for this reason, even if Nathan was wrong (which he is not) I am afraid, CLS will not be addressing the multidock issue.

In some ways this is a bit of a shame as in theory it should be possible to construct a craft where two living spaces should be joined into one, but they are not because the are actually joind through a different docking port where the path is blocked by a non passable part.

However I consider this to be a nontypical situation that can easily be avoided by craft design.

As an aside I am no fan at all of multiple dockings. It seems to me that they are a cludgy attempt to fix the wobbly rocket problem that is better addresses by KJR, or even needs to be addressed in the base game. This is another reason I am not inclined to spend time worrying about it in CLS.

Edited March 26, 2014 by codepoet

[Papa_Joe]

Ok I will look into that.

Are you using the latest release of CLS? The latest release will automatically add the CLS module to any part with crewcapacity >0 that does not already have it.

On an unrelated note, I am writing a set of wrapper classes that use .net reflection to make it possible to easily only use CLS if it is installed. I am using the toolbar equivelent for inspiration, but am a little unsure how to wrap an enum type - suggestions would be welcome.

Papa Joe, you many wish to consider this for ship manifest, but it sounds like you are already set to go with a hard dependancy which is also great.

Good to know. I was using the version you compiled for me with the highlighting event handlers. I recently went to 1.0.3.0 and added the config without thinking. I will test without the Config entry.

[Fraz86]

Are you using the latest release of CLS? The latest release will automatically add the CLS module to any part with crewcapacity >0 that does not already have it.

As I previously reported, this function seems to work fine, except that parts for which CLS is added in this manner are missing the CLS text box on the parts' tooltip in the VAB.

[codepoet]

As I previously reported, this function seems to work fine, except that parts for which CLS is added in this manner are missing the CLS text box on the parts' tooltip in the VAB.

Yep, thanks for reporting that, I am yet to look into it.

[Starstrider42]

Any word on compatibility with 0.23.5?

[codepoet]

I have just got back from holiday, and so have not looked into this yet. I know that Papa-Joe is working on CLS support for shipmanifest and also supporting 0.23.5, so he might know if it works.

I am halfway through quite a large overhaul of CLS at the moment, so I will probably aim to support 0.23.5 in the new release.

(as an aside I have not heard of any features in 0.23.5 that make me interested in playing it. - Just a personal opinion.)