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

[Crater]

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?

I think that would be a very useful extension, though it does also imply that it would be necessary to explicitly close the hatch before decoupling, or face a sudden shortness of breath for your crew. I'm not even sure if you can disable undocking from a mod, though...

[codepoet]

I think that would be a very useful extension, though it does also imply that it would be necessary to explicitly close the hatch before decoupling, or face a sudden shortness of breath for your crew. I'm not even sure if you can disable undocking from a mod, though...

I think that we would have to say that undocking implies closong the hatch. However a potential pressurisation mod may want to change that! But for now, and for CLS there is not much point worrying about what happens if you undock with the hatch open, while there ids not concept of pressurasion available!

[SnowyDuck]

I like the idea of opening and closing hatches. It adds some realism. One thing I was thinking of, would you want to weight the available seats? I understand you're making a small proof of concept mod and kerbals will randomly switch to different seats. However I was thinking if you could assign values to the seats. For example; unless the vessel is conducting a burn/rotation nobody really wants to sit in the pilots seat, they'd want to spend more time in the cupola. Different values for the seats, or even a GUI to assign them to a spot.

Just brainstorming here. I like this plugin a lot and I'm thinking of using it to make a mod, but I want to see what the other big named mods do first.

[codepoet]

.

.

.

One thing I was thinking of, would you want to weight the available seats? I understand you're making a small proof of concept mod and kerbals will randomly switch to different seats. However I was thinking if you could assign values to the seats. For example; unless the vessel is conducting a burn/rotation nobody really wants to sit in the pilots seat, they'd want to spend more time in the cupola. Different values for the seats, or even a GUI to assign them to a spot.

Just brainstorming here. I like this plugin a lot and I'm thinking of using it to make a mod, but I want to see what the other big named mods do first.

Yes I have been writing a proof of concert random seat swapping mod. I was up late last night trying to solve the problem of portraits disappearing, but I think I have cracked it now. That means I am in a position to make a formal release of that proof of concept mod which I am calling "KerbalHotSeats". Because it is dependent on CLS this means that I will be making a first formal release of CLS as well (once I have a spare moment, probably this evenign at the earliest.)

Writting a proof of concept mod was definately the right thing to do - I have a made a few changes to CLS having seen how a 3rd party mod would go about using it and what would be helpful.

The next step I think will be to add more features (open and closable hatches, and configurable support for radially attached parts, GUI hooks for 3rd party mods), and to get some sort of crew transfer functionaily available that uses it (either via one of the well known mods - the maintainer of ShipManifest has stated on its thread that he hopes to lok into adding support, or via a stand alone lightweight mod that does just that.)

On an unreleated note - I know that lots of people have downloaded this mod in pre-release (probably around 100). I would love to hear (see) what you have been doing to play around with it. Has it changed your approach to ship design. I found the first time I played with it installed, by experience in the VAB was dramatically changed, as a whole new set of considerations came into play.

[codepoet]

Ooops: double post.

Editied to say that the idea about prefered seating is obviously beyion dthe scope of CLS, but could be included into other mods - KerbalHotSeats would be a good place for it.

Edited February 19, 2014 by codepoet
double post!

[codepoet]

As promised I have formally released ConnectedLivingSpace, and also another mod called KerbalHotSeat that makes use of CLS.

Now to get some more exciting mods that use it released, and support for it built into some or the more mainstream offerings.

[Starstrider42]

First, thank you for creating this mod/API. The lack of any believability in which transfers don't require EVA is the main thing that's kept me from downloading any crew transfer mods -- hopefully they'll incorporate CLS soon!

However, I do have one question about the default settings. I noticed you've made the two lander cans passable from all directions, but I don't see anything that looks like a hatch on the bottom. Was there a reason for doing things that way?

[codepoet]

However, I do have one question about the default settings. I noticed you've made the two lander cans passable from all directions, but I don't see anything that looks like a hatch on the bottom. Was there a reason for doing things that way?

Just a lack of attention to detail I suppose. I have been concentrating on getting the code working and providing everythign that other modders will need to use it. I am rather hoping that the configuration needed for both stock and the hundreds of non-stock parts will emerge from interested players, or even the part designers themselves if CLS becomes widely enough used to get their attention.

However on the particular point you raise, athough there may not be anything looking like a hatch on those parts, if you were to add a docking port to the top ot bottom ot them, would that seem inapproriate? I don't know the answer, I am asking.

I am sure that there will always be some debate about which parts should be passable on which attachment nodes, and there will always be a balance of views ranging from "let me play my way" to "that is unrealistic". I do not really want to end up being the arbitrator of such debates - I am happy to go with the consensus.

I am also hoping that someone will be good enough to take the time to provide config for packs such as B9 that are widely used.

[Starstrider42]

However on the particular point you raise, athough there may not be anything looking like a hatch on those parts, if you were to add a docking port to the top ot bottom ot them, would that seem inapproriate? I don't know the answer, I am asking.

I am sure that there will always be some debate about which parts should be passable on which attachment nodes, and there will always be a balance of views ranging from "let me play my way" to "that is unrealistic". I do not really want to end up being the arbitrator of such debates - I am happy to go with the consensus.

I understand. I myself lie on the "let me play my way" end of the spectrum; I only posted my question about the landers because I thought those were a lot less debatable than any of my other tweaks.

I have no objections to a docking port on the top (given that many of the stock KSP parts seem Apollo-inspired, that was almost certainly the developers' intent), but a docking port on the otherwise featureless bottom would look pretty weird to me. On the other hand, I know my spaceship designs are a lot less original than some of the screenshots I've seen on the forums, so maybe people have designs with bottom-accessed lander cans that still look "natural". I'm quite happy to go along with it if the community agrees it's a feature, not a bug.

As for pack configs, I'd love to help, but the only part-heavy mods I have installed are Dmagic Orbital Science, Extraplanetary Launch Pads, Kethane, Procedural Fairings, and ScanSat. None of those really have anything that screams "crew space" to me.

[Fraz86]

However on the particular point you raise, athough there may not be anything looking like a hatch on those parts, if you were to add a docking port to the top ot bottom ot them, would that seem inapproriate? I don't know the answer, I am asking.

I can't speak for starstrider, but I support the idea that, if the model does not visibly depict a hatch at the node in question (such as the bottom nodes of the lander cans), the node should not be passable. I would extend this logic to prohibit the use of docking ports at any location other than passable nodes (including disallowing radial attacments). I understand other people may prefer more liberal parameters, but fortunately it's rather easy for me to create a ModuleManager file to configure everything as I see fit.

[softweir]

I feel Codepoet is right, and that it is a bit much for him to do the work of deciding which nodes are accessible and which are not. What might be a good idea is if players here were to work up their own .cfg's and submit them to be included in any future release. That way we can choose between liberal, middle-of-the-road and strict interpretations of these matters.

So long as the .cfg format is well explained then it won't be too hard for any person with strong preferences to work up their own version!

[Aedile]

This is a type of mod I have been waiting for a long time. I wanted to comment on the passable node issues. I wouldn't base my decision which node is passable on the visual appearance of a hatch. Structural fuselage does not appear to have a hatch but it makes good sense that it would be passable. So it is not illogical to think that when connecting two parts together, the caps might have been removed. (unless of course there is a decoupler).

[codepoet]

I am thinking that the approach I will eventually take with this will be to provide MM config files for the various part packs. For most park packs I will (if possible) get the views of the part pack author - I have already done this for some configs that will be in the next release. If the author does not have a view I will take a view myself. However for Squad parts I will most likely try to provide several config files - perhaps 1) freedom, 2) standard 3) realism, so the player to just copy in a different file depending on their required style of play.

Obviously there will always be different opinions on this stuff, so do keep offering the benefit of your opinion. However I think that ultimately it is more important to get config out there for the major part packs than to worry too much about if everyone agrees on what should be passable and what should not.

[Papa_Joe]

I am thinking that the approach I will eventually take with this will be to provide MM config files for the various part packs. For most park packs I will (if possible) get the views of the part pack author - I have already done this for some configs that will be in the next release. If the author does not have a view I will take a view myself. However for Squad parts I will most likely try to provide several config files - perhaps 1) freedom, 2) standard 3) realism, so the player to just copy in a different file depending on their required style of play.

Obviously there will always be different opinions on this stuff, so do keep offering the benefit of your opinion. However I think that ultimately it is more important to get config out there for the major part packs than to worry too much about if everyone agrees on what should be passable and what should not.

Agreed. Create A standard first. Any standard. Then tweak it., break it, praise it, trash it, make it better.

BTW, the hatch idea is sweet. Consider this: I highlight parts as the kerbal passes. sounds queued to parts. maybe we Add some MM configs of my own, if I'm going to commit to requiring it with my mod. There is your Ow... I'm all right... hatch banging sound...

Time could be based on a standard time per part (likely same for all). Then with kerbalish sounds, kerbals "move" thru the vessel... Views from the inside do not work when moving, but I can give you a flavor of movement... some immersion.

Edited February 26, 2014 by Papa_Joe

[Aedile]

My opposition to the "does not appear to have a hatch", stems mostly from the fact that most parts, squad or otherwise (like fuselages) don't appear to have a hatch, but seem to be intended to be passable (like the LLL corridors for example).

Anyway, was wondering how to fit this with modular/real fuels which let you add fuel to structural elements. The realism mod uses real fuels, so it seems a mod which would most benefit, would run into a bit of a logical issue...

[codepoet]

For sheer entertainment value, I wanted to share an error that has appeared in my log:

Cannot parse Enum value: enumType is not an Enum type.

[a__gun]

For sheer entertainment value, I wanted to share an error that has appeared in my log:

Cannot parse Enum value: enumType is not an Enum type.

God I love hilarious coding fails!

[codepoet]

I have been having another bit of a fiddle, and have tried to impliment the concept of hatches on docking ports which can be opened of closed. Here are some pictures:

Here we are, back with my test vehicle. If I right click on one of the docking ports then a new option is presented - "Close Hatch". Note that this will only be offered for a part that is both a docking port (ModuleDockingNode) and has CLS support (ModuleConnectedLivingSpace). Information about whether or not the hatch is open or closed is saved in the ModuleConnectedLivingSpace persistance.

After closing the hatch you will notice that the CLS screen has been updated to show that there are now two seperate living spaces. The hightlighting has turned off as neither of them has been selected. For completeness we cna close the hatch on the matching docking port.

If we highlight the Living Spaces now, you can see that it ony extends as far as the docking port where we closed the hatch. Note that the docking port is highlighted in magenta to indicate that although it is docked (usually cyan) the hatch is closed.

For completeness here is the other Living Space. As you would expect its docking port is also coloured magenta as we closed the hatch on it too.

I am hoping that this new feature does not break the API in anyway. The API will have a new property on it - to allow 3rd party mods to check to see if a hatch is open or not on a part.

If you undock while a hatch is open, the hatch is automatically closed. There is no suggestion that CLS is going to simulate depressurisations and blowing kerbals out into space ("rapid unplanned EVA"?).

This feature should be useful for KerbalHotSeat to prevent Jeb changing seats just before you undock.

I will do some more testing and then make this available as a prerelease for a few days so interested parties can check it works before making a formal release.

In other news - I see that progress is being made in providing CLS support for Ship Manifest which will give us CLS compatable crew transfers (very exciting). I am also aware of another modder who has started a project that will eventually use CLS, but has not announced anything yet, so I will keep quite about it for now (that is also really exciting too!!)

[Dix2lespace]

Hi Codepoet! Can you make a plugin for this mod very useful? : http://forum.kerbalspaceprogram.com/threads/66525-0-23-TP-s-Stock-Parts-Resized-mod

thx for your works

[codepoet]

Hi Codepoet! Can you make a plugin for this mod very useful? : http://forum.kerbalspaceprogram.com/threads/66525-0-23-TP-s-Stock-Parts-Resized-mod

thx for your works

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?

[Papa_Joe]

Hey codepoet,

I've been testing Ship Manifest with CLS integration and have hit an issue.

You have compiled in .Net 4.0, and I've released in .Net 3.5. It seems it matters. I've been getting multiple errors with my code when using CLS. If I recompile CLS to 3.5, all errors go away.

Obviously, I have a problem in my code that is not compatible with 4.0. however, it seems, for maximum compatibility that 3.5 would be ok.

Would you be willing to release CLS in .Net 3.5?

I PM'd you about the issue, but thought it made sense to also post for everyone's benefit.

Thanks so much. In hopes that you are willing, I'm pushing forward. It it is an issue for you, then maybe you could glance at my code and see where I may be in error.

If you choose to look I can update github with some commits of my code.

[codepoet]

Sorry everyone. This is just me being a bit slapdash and careless. I will get a new release out asap.

[S4qFBxkFFg]

Apologies if this has already been pointed out, but assuming I'm reading the config files correctly, there seem to be a lot of parts that aren't marked as passable that nevertheless appear passable when viewing them.

Is this just because no-one has submitted data for them? If so, I'd be happy to work through the parts and provide the necessary text to go in the configs.

However, there are some cases where a decision isn't obvious - for example, decouplers appear hollow, so it should be fine for a Kerbal to physically pass through them but would they even be pressurised? I'm of the opinion that we should just ignore the concept of pressurisation until someone mods it into the game. (This could have an amusing result - if it does get implemented, and the decoupler isn't designed as a pressure vessel, we could see it "decoupling" laterally when Jeb opens a hatch in the next compartment...)

Other things that should probably be passable are the 2.5m battery (it's got a hatch in its texture) and the 2.5m probe core (which appears to just have a black circle in the middle that might just be a hole - presumably so a kerbal can crawl inside to deactivate it when it goes HAL 9000).

For two types of part in particular, I have no idea whether they should be passable or not so I'd like to hear what more people think before making any configs.

The first category would be the bi/tri/quad couplers - for some of them (where it's 1.25m nodes on both sides) I'm not sure there's enough space for a Kerbal to fit through, whether the part is hollow or not.

Also, should kerbals ever be able to be inside modular girder parts? If a docking port is connected to a modular girder adaptor, which then has more modular girders on its end, it's easy to imagine it being used as a type of corridor, albeit one that's open to space.

[Papa_Joe]

Sorry everyone. This is just me being a bit slapdash and careless. I will get a new release out asap.

You da man!

Back to plumbing features...

[Starstrider42]

Apologies if this has already been pointed out, but assuming I'm reading the config files correctly, there seem to be a lot of parts that aren't marked as passable that nevertheless appear passable when viewing them.

Is this just because no-one has submitted data for them? If so, I'd be happy to work through the parts and provide the necessary text to go in the configs.

However, there are some cases where a decision isn't obvious - for example, decouplers appear hollow, so it should be fine for a Kerbal to physically pass through them but would they even be pressurised? I'm of the opinion that we should just ignore the concept of pressurisation until someone mods it into the game. (This could have an amusing result - if it does get implemented, and the decoupler isn't designed as a pressure vessel, we could see it "decoupling" laterally when Jeb opens a hatch in the next compartment...)

Other things that should probably be passable are the 2.5m battery (it's got a hatch in its texture) and the 2.5m probe core (which appears to just have a black circle in the middle that might just be a hole - presumably so a kerbal can crawl inside to deactivate it when it goes HAL 9000).

For two types of part in particular, I have no idea whether they should be passable or not so I'd like to hear what more people think before making any configs.

The first category would be the bi/tri/quad couplers - for some of them (where it's 1.25m nodes on both sides) I'm not sure there's enough space for a Kerbal to fit through, whether the part is hollow or not.

Also, should kerbals ever be able to be inside modular girder parts? If a docking port is connected to a modular girder adaptor, which then has more modular girders on its end, it's easy to imagine it being used as a type of corridor, albeit one that's open to space.

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.