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

[Taki117]

This looks awesome! Certainly better than Crew Manifest if you can manage to pull it off. I will be watching this to see how it develops. (And test if needed)

[nothke]

This looks awesome! Certainly better than Crew Manifest if you can manage to pull it off. I will be watching this to see how it develops. (And test if needed)

WOW! This is amazing. I would looooooove if you could make it alt+right click transfer like fuel =)

[codepoet]

This looks awesome! Certainly better than Crew Manifest if you can manage to pull it off. I will be watching this to see how it develops. (And test if needed)

The intention is not to be "better than crew manifest" but rather that crew manifest and other mods will have the opportunity to be improved in a compatible way, that means there will be consensus on the question of what is connected and what is not.

[Papa_Joe]

The intention is not to be "better than crew manifest" but rather that crew manifest and other mods will have the opportunity to be improved in a compatible way, that means there will be consensus on the question of what is connected and what is not.

I've been following this thread, and I've contacted codepoet concerning integration with ShipManifest. I thought I'd share a few thoughts.

First, what codepoet is offering is NOT a complete plugin with a user interface. He is offering a standard set of tools to be use across plugins. It offers a nice set of methods and objects to manage connected areas of living space. He is taking it a step further by persisting needed data to the gamesave, using Module Manager to support other mods and part packs

Second, I see value in what codepoet is doing, as I had considered creating a set of wrapper classes to add functionality to each of the entities he is working with. However, I didn't want to spend the time. Bravo to codepoet for doing the grunt work to create a standard set of classes.

Now, for what I think I might do with this:

- Add a new category of Resource called LivingSpace. In it would be all living spaces as defined by connectedlivingspaces.

- Using the same interface in SM, I would set up transfers between living spaces, IF they were connected.

- Further, I could add the ability to determine if one part is connected to another internally and enhance the existing Crew Transfer in Realism Mode. If they are not connected, then you are going to have to EVA. I had planned on working out the logic to do this, but codepoet "did it better".

So, expect better crew realism modes in Ship Manifest.

[SnowyDuck]

That sounds pretty awesome Papa_Joe. Do you think that crew degredation and insanity could benefit from this as well? You could take into account how much habitable space there is, how many kerbals are living together, etc. I imagine that would really add to the immersion of KSP.

[Papa_Joe]

That sounds pretty awesome Papa_Joe. Do you think that crew degredation and insanity could benefit from this as well? You could take into account how much habitable space there is, how many kerbals are living together, etc. I imagine that would really add to the immersion of KSP.

I've heard people talking about a sanity mod, but tbh, i've not been following closely the realism mods, as I'm largely a sandbox player, with lower realism needs than many. But the short answer is yes. With the ability to "extend" a part, vessel, etc, you can add attributes to codepoet's classes and persist a variety of data using MM. so a sanity Mod would likely look much like TAC Life support or Real Fuels. You could add a whole layer to Kerbals and manage their Mental health as well as their physical health.

Understand that ConnectedLivingSpaces provides a framework for this. Mod developers will have to build the functionality

[Papa_Joe]

A few more things that I have done to CLS:

1) There is a bug that CLS does not process living spaces when you go to a craft from the tracking station. It does work when you switch to a craft at close range - I have more testing to do for other scenarios. Obviously I will get these various problems ironed out.

...

I've been experiencing this issue as well, and it seems to be from part to part. I can make a seat to seat xfer refresh the internal view, but not from part to part. Obviously I'm missing something. So I have an ugly update portraits button until I solve this...

On second thought, these issues may not be related...

[codepoet]

I've been experiencing this issue as well, and it seems to be from part to part. I can make a seat to seat xfer refresh the internal view, but not from part to part. Obviously I'm missing something. So I have an ugly update portraits button until I solve this...

On second thought, these issues may not be related...

I think that this problem was fixed with the latest download. It now sinks the OnFlightReady event to rebuild the spaces and that seems to be working.

I am really grateful to Papa_Joe, both for understanding the spirit of what CLS is trying to do and expressing that on this thread. Just to back up what he has said - CLS is not about providing features, it is about allowing different mods to use the same framework for deciding what is connected and what is not. So far four different modders have got in touch with me to say that they are interested in using CLS from their mods (of which Papa_Joe is one). This is really good because it means that there may soon be several different features that use this concept of conected habitable spaces that will all be compatable. I think that the worst possible outcome would be for there to be four different mods each of them doing thier own work to figure out if the science lab is connected to the hitchhiker pod, based on whether or not kerbal can fit through a shielded docking port, and reach different conclusions about this question. If such mods are encouraged to use CLS then any required config only needs to be provided once, and such incompatabilities will not occur. It is for this reason that I do not intend to add any features such as crew transfer, presurisation, sanity or kerbal relationships to CLS itself, as I do not want to discourage other modders who might want to provide such features in their own mods from using CLS.

Having said all of that, I am really excitied about the interest that folks have shown in CLS and the encouagement I have recieved both on this thread, and also from those who have contacted me off the forums. There have also been some really good suggestions, and there is nothing to stop anyone from writing mods to implement those ideas, using CLS as part of their work. Two ideas that I particularly like are the suggestion on this thread for Alt+rightclick crew transfer, and also some of the discussions here about options for sanity, Kerbals interacting socially, and for Kerbals interacting in a "chain of command" sort of way. I am really tempted to start working on some of those ideas myself, but I want to wait a while to see what others come up with. If I did do any work on those ideas, they would be released as seperate mods, not as part of CLS itself. If you are intested in any of this stuff, then encourage your friendly local modder to write a mod that does it, and tell him or her to use CLS

Edited February 16, 2014 by codepoet

[codepoet]

A new pre-release (v0.3) that includes the CLSKerbal class is now available to download from the link on the first page of this thread.

[codepoet]

This is looking great. I added that module manager fix and my mods were recognized. It recognized a scaled cupola module and porkjet's centrifuge module (also my own science lab version of it). The only problem I noticed was that it doesn't track radial attachments. I think this setup should be allowed, but I don't know how difficult it will be. Otherwise this is great! Once it's complete we can integrate it with things like crew degradation or tac life support.

http://imgur.com/aNgoACI

I am intersted in what people think about this. Enablking radial attachments requires a code change (not a complex one, but a change all the same). So should it be allowed? I can see that the only stock part that you would realistically use it for would the be radial adapter thing, but then you could attach other passible / habitable parts to that.

However I can see there is an arguement that it is not on to just radiallt attach a big corridor into the side ot a command pod. Folk go to LOADS of effort to carefully design their command pod parts - it just seems rude to cut a great big hole in the side where the mod designer had not intended it!

But then on the other hand - why not?! I suppose for some parts it makes sense more than others: To radially attach a corridor to half way along a structural fusilage part makes sense, but to dothe same to the side of a Mk1 lander can seems a bit daft. Perhaps is would be possible to prvide config that says that a part will allow an attachment node into a surface attached part to be passable, withthe default setting being to disallow it. That way it can not be abused, but will be allowed in certain circumstances.

What do you all think?

[Ralathon]

I am intersted in what people think about this. Enablking radial attachments requires a code change (not a complex one, but a change all the same). So should it be allowed? I can see that the only stock part that you would realistically use it for would the be radial adapter thing, but then you could attach other passible / habitable parts to that.

However I can see there is an arguement that it is not on to just radiallt attach a big corridor into the side ot a command pod. Folk go to LOADS of effort to carefully design their command pod parts - it just seems rude to cut a great big hole in the side where the mod designer had not intended it!

I tend towards this side of the spectrum. Docking ports and holes are rather difficult engineering challenges, so radially attaching them on a whim is a difficult affair.

But then on the other hand - why not?! I suppose for some parts it makes sense more than others: To radially attach a corridor to half way along a structural fusilage part makes sense, but to dothe same to the side of a Mk1 lander can seems a bit daft.

Hmm, yea. Doing something like a T junction is a pain when you need to do it via a 6 way connector...

Perhaps is would be possible to prvide config that says that a part will allow an attachment node into a surface attached part to be passable, withthe default setting being to disallow it. That way it can not be abused, but will be allowed in certain circumstances.

What do you all think?

This would obviously be the best solution. Relatively simple parts would allow radial attachments (fuselage, adapters etc) could allow radial attachments but complex objects like command pods or hitchhiker cans cant.

[a__gun]

Perhaps is would be possible to prvide config that says that a part will allow an attachment node into a surface attached part to be passable, withthe default setting being to disallow it. That way it can not be abused, but will be allowed in certain circumstances.

What do you all think?

I like this idea, but would discourage a default setting - make it a configurable setting

[nothke]

I tend towards this side of the spectrum. Docking ports and holes are rather difficult engineering challenges, so radially attaching them on a whim is a difficult affair.

Um.. Ever seen ISS nodes?

The way I usually recreate the ISS nodes is that I put docking ports in 4 simmetry around the hitchhiker. That's basically the only way you can recreate it. I'm all for it.

[Papa_Joe]

I am intersted in what people think about this. Enablking radial attachments requires a code change (not a complex one, but a change all the same). So should it be allowed? I can see that the only stock part that you would realistically use it for would the be radial adapter thing, but then you could attach other passible / habitable parts to that.

However I can see there is an arguement that it is not on to just radiallt attach a big corridor into the side ot a command pod. Folk go to LOADS of effort to carefully design their command pod parts - it just seems rude to cut a great big hole in the side where the mod designer had not intended it!

But then on the other hand - why not?! I suppose for some parts it makes sense more than others: To radially attach a corridor to half way along a structural fusilage part makes sense, but to dothe same to the side of a Mk1 lander can seems a bit daft. Perhaps is would be possible to prvide config that says that a part will allow an attachment node into a surface attached part to be passable, withthe default setting being to disallow it. That way it can not be abused, but will be allowed in certain circumstances.

What do you all think?

As is evidenced with my mod, I tend to err on the side of choice. Some will grate against the ability to "cheat" and other will praise you for saving them the agony of EVA. SO make it a switchable thing, and the mod developer can either expose that to the player, or manage it themselves.

[Razorcane]

I'm going to cross my arms at this mod until you can combine IVAs and make them traversable. I'm not being rude, I'm presenting you with a challenge.

[codepoet]

I'm going to cross my arms at this mod until you can combine IVAs and make them traversable. I'm not being rude, I'm presenting you with a challenge.

OK. Well you might have your arms crossed for a while, as the feature you describe a beyond the scope of this mod, and will not be implimented as a part of CLS.

.

.

.

However, there is nothing to stop other modders from implimenting the feature you describe, and using CLS to decide which parts and attachments are passable and which are not. There may even be someone working on it as we speak - I am sure it would be well received.

[softweir]

But then on the other hand - why not?!

Indeed - it is a stock part and it has a hatch graphic on it which makes it appear that Squad intend that our Kerbals have, indeed, cut a great hole in the side of a capsule and welded a hatch over it.

If, that is, the code be made to work with reasonable effort!

[Crater]

I guess my difficulty when it comes to the idea that you can't radially attach a docking port or corridor to a hab or pod is that I now have an image of Jeb strolling across the VAB floor with an angle grinder dangling from one had, muttering something about wanting an easier route to the snack storage bay in the adjoining module. And I just can't imagine how you would stop him

[rhoark]

Eventually I'll want to extend my tank model (arbitrary stuff goes in or out, pressure is calculated) to cabin atmospheres as well. This API will be very helpful.

[nothke]

I'm going to cross my arms at this mod until you can combine IVAs and make them traversable. I'm not being rude, I'm presenting you with a challenge.

I am working on something right now that could end up as traversable IVAs

[SnowyDuck]

I am intersted in what people think about this. Enablking radial attachments requires a code change (not a complex one, but a change all the same). So should it be allowed? I can see that the only stock part that you would realistically use it for would the be radial adapter thing, but then you could attach other passible / habitable parts to that.

However I can see there is an arguement that it is not on to just radiallt attach a big corridor into the side ot a command pod. Folk go to LOADS of effort to carefully design their command pod parts - it just seems rude to cut a great big hole in the side where the mod designer had not intended it!

But then on the other hand - why not?! I suppose for some parts it makes sense more than others: To radially attach a corridor to half way along a structural fusilage part makes sense, but to dothe same to the side of a Mk1 lander can seems a bit daft. Perhaps is would be possible to prvide config that says that a part will allow an attachment node into a surface attached part to be passable, withthe default setting being to disallow it. That way it can not be abused, but will be allowed in certain circumstances.

What do you all think?

I think KSP has always had the spirit of allowing people to make their own game. I say give the developers and players the choice (a config option maybe). It goes along the same lines of how you want to play the game. It's only cheating if you're not having fun.

[codepoet]

I have been having a think about where to go with this mod now. There are a few things that need to be done:

1) Configs

2) Improve the GUI

3) Do something with radial attachments

However I also feel that I need to prove that this mod is providing what it claims to which is an API to make life for other modders easier. I do not want to start writting lots of mods that use it as I do not want to discourage the maintainers of existing mods form using CLS. Therefore I have decided to write a mod to uses CLS as a "proof of concept" providing a feature that no other mods are trying to provide. Taking an idea that was suggested on this thread a while back, that will be to make the kerbals in a Habitable Space occasionally swap seats, or move to empty seats. This would test all the things I am interested in, and provide a little fun too. Once it is working I intend to make a formal release of both mods (CLS and seperately KerbalHotSeats or whatever I call it).

I am hoping that some time soon there wil be a mod using CLS that allows for kerbal movement between parts.

[Razorcane]

OK. Well you might have your arms crossed for a while, as the feature you describe a beyond the scope of this mod, and will not be implimented as a part of CLS.

.

.

.

However, there is nothing to stop other modders from implimenting the feature you describe, and using CLS to decide which parts and attachments are passable and which are not. There may even be someone working on it as we speak - I am sure it would be well received.

I've actually been giving this a great deal of thought. Would it be possible to define a certain part in Unity to be recognized by the mod? You could then make the mod connect those two parts together in-game which would allow all IVAs to be seen from only one. Of course this means that you need to have some sort of detection system for docking nodes and whatnot, and it wouldn't work for docking nodes connected radially. What do you think?

[codepoet]

What do you think?

I think you ought to talk to nothke based on what he just said.

Of course this means that you need to have some sort of detection system for docking nodes and whatnot,

That is what CLS can do.

[codepoet]

I have had another thought - I would welcome feedback. Would it be helpful for CLS itself to impliment and "open hatch / close hatch" functionality for docking ports? The idea is that you could dock two craft together, but the docking ports would remain impassable until you rightclicked and chose "open hatch". Obviously you could repeart this and choose "close hatch" at which point the Habitable living spaces would become joined.

The reason that this can up was that I am writing the crew random movement mod, as a way of testing is CLD provides what it needs to, and I realise that there is the chance of two kerbals randomly swapping seat just before you undock, which would be really annoying. This way you can "close the hatch" and then you know who is on which side of the hatch before you undock. It could also be useful for other features that might use CLS, such as dealing with a hull breach in a pressuriation mod, or locking a kerbal "in the brig" if his goes crazy in a sanity mod to stop him from driving everyone else nuts.

Helpful?