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

[codepoet]

Current Version can be downloaded from the release thread

You will also need ModuleManager to load the config.

You can access the source code here. If you spot a bug please let me know. Ideally bugs should be raised in Github, but if that is too much to ask then post on this thread. More helpful than raising a bug report is to raise a bug report with lots of information about how to reproduce the problem, and with logs files, save files, craft files etc. Even more helpful is to write a fix by forking the code in Github, and then generating a pull request

Introduction

This mod is intended to identify areas within a vessel that can be crewed by Kerbals and through which kerbals can pass internally to reach other parts that can be crewed. It is envisioned that this information could be used for restricted crew manifest style movement of kerbals within a craft, and also a future sanity mod that takes into account who the kerbal's bunk mates are. (Other mod developpers have also contacted me privately to suggest other exciting uses for this mod, but it is for them, not me to announce their ideas.)

There are two key pieces of information that are needed by this mod:

1) Can a part house a kerbal or allow a kebal to pass through it?

2) Can an attachment node on a part allow a kerbal to pass through it?

Currently the config only allows us to know if a part can hold crew. Therefore it is envisioned that the config will be extended, and a set of configs for well known part packs written to ship with the mod. Heuristics will try to provide config for parts with no config available (such as the size of the node and whether or not it is a crewable part).

Progess report

A download is now available. It looks a bit like this:

A vessel with contain 1 continuous living space made up of 2 pods (green) that can house kerbals, some tubes (yellow) that kerbals can move through internally and two docking ports that have been joined docked together (cyan).

An image from my main save (yes I trust this code on my own main save). Here is a deep space transport vessel docked at an LKO transfer station with 3 crew shuttles also attached.

Helping to develop this mod

There are several ways in which you can help this project:

 

• Report bugs. Please do this on github if you can. If you can't then it is better to post to this thread than do nothing.
• Write a ModuleManager style set of config for a part pack that you use, adn then make that available to be included in this project.
• {DONE - thanks austizmo}Design a toolbar button. I am a coder really - I am no good at making things pretty!
• Offer ideas for how the API should work, so other modders can use this concept of connected spaces in their mods
• Offer ideas for mods where this functionaily would be useful.
• Write a mod that uses ConnectedLivingSpace. Do please let me know if you are doing, or even thinking of doing this, so I can ensure that CLS meets your needs.
• Post pictures to this thread of interesting things you do with this CLS to encourage me!

 

Ideas that have been suggested for mods using CLS

 

• Crew transfer
• Sanity mod
• IVA enhancements
• Pressurisation / airlocks

 

Roadmap

Other mods have started to get involved with the development of CLS which is greatly apprechiated. However this does mean that a roadmap is needed so we direct our efforts in the same direction! It is divided up into two sections - "Vision" (all the things that would be really cool, and we would love to see included) and "scope" (this things that we are realistically targeting for now.)

Vision

 

• Provide configuration for every part pack anyone has ever heard of.

 

Scope

 

• Provide configuration for Stock parts and the most popular part packs.
• Provide a default config that adds the CLSModule to all parts with that can house crew to enable the persistance of space names
• Impliment the concept of openable / closeable hathes on docking ports.

 

Already Implimented

 

• Be able to detect different habitable spaces within a craft, and dectect which one are joined together and hich are not.
• Allow the user to highlight the different spaces, to see which parts make up those spaces. Also display habitable and passable/navigable parts differently.
• Provide an well documented API that allows 3rd party modders to use the Connected Living Space information.

 

Config documentation - of interest to modders adding CLS support to existing mods.

There is a HOWTO to explains how the CLS config works.

API - of interest to modders using CLS in their own mods.

The API provided by CLS is in the form of five classes that can be used to get information about a Vessel, the Habitable Spaces with in it, the Parts that make up that Habitable Space, and the Kerbals in those parts. CLS therefore provides 5 classes:

CLSAddon

This class provides an entry point for other mods that are interested in the CLS information

CLSAddon Instance

A static property that can be used to get access to the CLSAddon

CLSVessel Vessel

A property that returns an instance of the CLSVessel object that represents CLS understanding of the active vessel.

Typically a mod developper would use a line like:

 

CLSVessel clsData = CLSAddon.Instance.Vessel;

to get access to the CLS data.

CLSVessel

CLSVessel is used to describe the vessel from CLS's point of view. It can be used to access the Parts and Spaces that make up the Vessel. It has methods and properties as described below:

List<CLSSpace> Spaces

This property provides access to the list of Spaces that are contained withing the Vessel.

List<CLSPart> Parts

This property provides access to the list of Parts that make up the vessel from CLS's point ov view. The is a CLSPart that represents all of the Parts in the vessel even the ones that are neither Habitable nor Navigable (ie passable). This means that for any part in a vessel you can ask the question "Is this Navigable? Is this Habitable?"

void Highlight(bool)

The Highlight method allows modders to ask CLS to hightlight all the Habitable Spaces within a vessel, or to turn this highlighting of. It is anticipated that it will be most useful for turning the highlighting all off, so that other highlighting schemes can be employed. Note that CLS itself provides a simple GUI to allow a player to visually see which parts are in which spaces.

CLSSpace

CLSSpace is the heart of what CLS provides. While KSP already has the concept of Vessels, Parts and Kerbals, Habitable Spaces is a genuinely new concept, and is likely to be of most interest to modders. A CLSSpaces represents a group of one or more connected parts all of which a kerbal can pass through, and at least one of which a kerbel can live in. Note that one or more Naviagable but not Habitable Parts that are joined together to not make a Habitable Space.

The class has the following properties and methods:

List<CLSKerbal> Crew

The Crew property provides a list of CLSKerbals which represents CLS's understanding of which kerbals are in currently in that particular Habitable Space.

int MaxCrew

The MaxCrew property provides access to a single number that is the larest number of Kerbals that can be housed in the Habitable Space.

Name

The Name property returns the name that has been given to a particular Habitable Space. While the habitable space's default name it taken either from the first Part that makes up the Habitable Space (or if that part has no CLS configuration available then a generic name generate by CLS), CLS does provide a GUI that allows the user to change the name of a paricular space.

Note that the name of the Habitable space is associated with and stored in each Part that makes up that space. Therefore if parts from that Space a removed (undocked) and docked with other parts to create a new Habitable Space, then that new Habitable space night have the same name as the old one. (The name of the Space might also be taken from the other parts that make up the space, depending on which parts where docked to which.)

Also be aware that if a part does not have any CLS configuration it will not be able to store the name of the Space that it is part of, so this will be lost between save or between the VAB and flight. CLS does recognise parts with seats for at least one Kerbal as Habitable and Navigable, even if there is not config to say that they are so.

List<CLSPart> Parts

The Parts property returns list of CLSPart objects that represent the Parts that make up a particular Habitable Space.

CLSVessel Vessel

The Vessel property provides a reference back to the CLSVessel object that represents the Vessel of which this Space is a part. Via this it is possible to access the other Habitable Spaces.

void Highlight(bool)

The Highlight method allows a particular Habitable space to be Highlighted so that the user can see which parts make up the Space. Note that CLS provides a GUI that allows the player to highlight the different Spaces via this method.

CLSPart

The CLSPart class represents CLS's understanding of a particular Part in the Vessel. It can be cast into a Part in order to access the Part object that it is attached to. The contains the following properties and methods:

List<CLSKerbal> Crew

The Crew property returns a List of all the CLSKerbal objects that represents the kerbals that are currently housed in a particular part.

bool Docked

The Docked property returns a bool that indicates hether or not a particular Part has been identified as one half of a docked connection. When such Parts are highlighted via a call to the Highlight method they will be displayed as cyan (unless they are also Habitable in which case they will be displayed green). Be aware that when two docking ports are placed next to each other in a craft that is assembled in the VAB the two docking ports are not considered by the game to be docked, but instead are attached (this is reflected by the fact that right clicking on then displays the option to detach, rather than undock. It is only after they have been detached and then docked together again that they are considered to be docked by the game. CLS reflects this in the value of the Docked property.

bool Habitable

The Habitable property returns a bool that indicates if one or more Kerbals can be housed in a particular part. If a part is Habitable then it will be Highlighted in green when the Highlight method is called.

bool Navigable

The Navigable property returns a bool that indicates if a part can allow a kerbal to pass along it in order to get from one Habitable Part to another. Parts are considered to be Navigable if the "passable" option is set in the configuration for that part. Be aware though that even if a part is marked as being passable, each of the attachment nodes on the parts can also either be passable or not. If no configuration relating to the attachment nodes is provided in the configuration then all the attachment nodes are considered passable by default. However configuration can be provided to indicate that some attachment nodes are not passable while others are.

Parts that are consider by CLS to be Navigable are highlighted in yellow when the Highlight method is called.

CLSSpace Space

The Space property returns a CLSSpace object that reffers back ti the Habitable Space that this Part is a part of. This allows a mod writter to discover what other Parts are in the same Habitable Space as this particular Part.

HatchStatus

The property provides information about the hatch status of a part that is docked (ie a docking port). A hatch in a docking port can be either Open, Closed or marked as not a docking port. Closed hatches split one Connected Living Space into two.

void Highlight(bool)

The Highlight method allows a mod writter to ask CLS to highlight a particular Part with a colour to indicate what CLS knows about that part. They can be highlighted in one of the following colours:

Green - the part is Habitable, which means that kerbals can live in the part.

Yellow - the part is Navigable which means that kerbals can move through the part to access other habitable parts, but the part can not house a kerbal itself.

Cyan - the part is Docked which means that it is one of a pair of parts that have been docked together creating a Navigable passage. Note that is two non Navigable docking ports are docked together (ie the Jr Clampotrons) they will not create a Navigable passage and will not be highlighted in cyan.

Red - the part is not Naviagable and therefore is not part of any of the Habitable spaces in a vessel.

CLSKerbal

The CLSKerbal class represents CLS's understanding of a particular Kerbal. You can access instances of this object from the Crew properites on the CLSVessel, CLSSpace and CLSPart classes. A CLSKerbal object can be cast into a ProtoCrewMember class to access the ProtoCrewMember object that it is associated with.

Original thoughts (where this thread started):

Quote

 

So although I am busy working on one mod that is pre-release, my mind is wandering through all the possibilities that KSP offers for modding, and am already plotting the next project! I thought I would just ask for some thoughts on the idea, and see if anyone has any suggestions of where it might go.

So the idea is to identify habitable space in a craft that is contiguous, in order to create an extra consideration in the design of craft. So for example a command pod is habitable space, as is a Hitchhiker container. A docking port is not habitable, but it seems to me that all docking ports other than the junior size should be "kerbal-passable" meaning a kerbal could pass through one. So if you had a command pod attached to a docking port, docking with a hitchhiker container attached to a docking port, then that would create one contiguous habitable space. However if you had a fuel tank inbetween that docking port and the hitchhiker container, then the space would not be congituous, and so the conbined docked craft would have two seperate habitable spaces.

So what use is this? Well it occurs to me that it could be taken into consideration for various features. Top of my list are:

1) Crew transfer. If parts in components of the same contiguous living space then a mod could allow transfer of crew without the need for eva, but if they are not contiguous then this is not an option.

2) Sanity mods. I know that at least a couple of people have suggested sanity mods. It seems to me that a sanity mod could take into account the way in which kerbal's sharing living space affect each other's sanity. Of course if the kerbals are living in non-continuous living spaces then they are not going to have the same affect on each other as if they are living together.

My proposal is to write a very light weight mod that identifies the contiguous habitable spaces (taking into account other types of part such as adapters, dockingports etc that could be considered passable), and allows the user to visually see which parts of the vessel make up each habitable space. However the main purpose of the mod is to expose this infomation as an API so that other mods can easily use the infomation for whatever functionaiity is envisioned, without having to worry about working out which spaces are continguous. It would also allow players to easily see if living psaces where connected or not, and so role play whatever rules they wanted to impose on themselves.

Obviously the crew manifest mod already allows players to move kerbals betwen parts without EVA, so that feeds into 1) in my list above. I did mention this idea on the crew manifest thread, and the idea was recieved like a fart on a bus, but then I suppose that is understandable as many players are using crew manifest in order to avoid EVA. However that does not mean that me writting this mod need create a problem for such users.

So I wanted to put the idea out there, and see if anyone had any further ideas for features that might benefit from the concept of connected living space.

 

 

Edited February 10, 2016 by codepoet
Adding information about the API

[Helix935]

uhh is this a suggestion or are you making this mod ? Because i am confused now

[codepoet]

I am considering writing the mod myself. However I would welcome ideas, and suggestions of how it might be used as an API , both in features that I might impliment myself and features that might be writen by other modders too.

[kiwiak]

I dont really have some usefull suggestions or comments.. just looking forward to this - immportant component of hypotetical sanity mod.

[Themorris]

Just for the open ports between the two vessels, this coud be archieved, by animating the hatch and set its size to zero to make it invisible(kind of), when two vessels are docked together.

[blackheart612]

You can make it like fuel. With "In" and "Out" events but for crews. If you want, you can make IVA anims for it.... I dunno if that's possible. Just a crazy idea

[Parkaboy]

You can make it like fuel. With "In" and "Out" events but for crews.

I second this. It could also include a highlighting of all the contiguous space to a part, when that part was clicked; an easy way to visualize all the space available.

But it would be great to have an interface that allowed you to move the kerbal between spots, even inside the same cockpit. That way you could have your guy on the pilot seat while driving, and then switch him to a bed or a table when idle (Porkjet's habitats, for instance, have beds and tables).

[codepoet]

OK, I was starting to wonder if it was an idea without merit, but it seems that some folks might be interested in this sort of functionality. I will look into starting this once I have got my other current project to a stable position that I can make a release.

Is there anyone who is currently working on a sanity mod at the moment? I am full of ideas of how it could work, but I do not want spend time on it if someone else has a project that is making progress.

[SkyHook]

Moving around in IVA is one of the most wanted features for me. Having a truly interconnected base is one of the things that would greatly increase the enjoyment of the game for me. Hope this gets off the ground (pun very much intended)!

[NathanKell]

This sounds good to me!

How will you handle the use of, say, stretchy conics as adapters between a hitchhiker and a docking port? (or either rockomax adapter).

[softweir]

It's a great idea!

I would suggest that the best way to decide which parts are navigable is to declare this to be the case in configs. For instance, you could create a new module...

MODULE {
    MODULE = Navigability (or whatever name you choose for the module)
    navigablenode = nodename1
    navigablenode = nodename2
    ...
}

Add an entry such as this to a part so as to declare which nodes can be used as entrances and exits from a part. Parts without such listings are un-navigable, so parts which have obviously not-hatch-like nodes (such as the top stack node on the cupola) won't be free to be misused.

Advantages:

• It simplifies your code enormously
  
• It prevents Kerbals teleporting through solid walls!
  
• It allows Kerbals to use fuselage parts and other parts without IVAs as access corridors
  

Disadvantages:

• A config entry has to be created for each part
  

[codepoet]

It's a great idea!

I would suggest that the best way to decide which parts are navigable is to declare this to be the case in configs. For instance, you could create a new module...

MODULE {
    MODULE = Navigability (or whatever name you choose for the module)
    navigablenode = nodename1
    navigablenode = nodename2
    ...
}

Add an entry such as this to a part so as to declare which nodes can be used as entrances and exits from a part. Parts without such listings are un-navigable, so parts which have obviously not-hatch-like nodes (such as the top stack node on the cupola) won't be free to be misused.

Advantages:

• It simplifies your code enormously
  
• It prevents Kerbals teleporting through solid walls!
  
• It allows Kerbals to use fuselage parts and other parts without IVAs as access corridors
  

Disadvantages:

• A config entry has to be created for each part
  

This is pretty much what I had in mind. I was considering marking parts as passable/navigable in the config, and for parts where then config was absent, using a few hueristics to make a guess. I was also thinking of the mod having a list of predefined config list for all the major part packs, so that it mostly worked "out of the box", but part makers could specify their own config if they were interested to.

I like the idea of defining passablity/navigability on attachment nodes rather than parts though - like you say it stops people doing cheeky things like trying to break out through the cupla windows.

Edited February 7, 2014 by codepoet
spelling

[Garek]

like trying to break out through the cupla windows.

Now I imagine Jebediah breaking one of those windows with a hammer to get into SPAAACEEE

But seriously, I like this concept. It would propably be nice to have more area-types than habitable and navigable, e.g.

• Navigable (can go through, but not stay)
  
• Corridor (can stay, but doesn't do anything)
  
• Habitat (can stay and regenerates sanity/required for Life Support/....)
  
• ... (Command, Lab, ... but I don't know what those would actually do)
  

That would allow us to differentiate between actual habitat units and stuff like the FusTek nodes, where Kerbals could stay and have IVA (e.g. RPMs walkthrough feature), but shouldn't for a long time.

[Crater]

Nothing much to add from a suggestion perspective, since everything I thought up as I read through the thread has already been said, but I definitely want to add another voice in support of this being an excellent idea for a mod!

[codepoet]

Well I have been sufficently encouraged to start coding. Keep the encouragement coming

[boberts314]

I feel like I've been seeing more and more IVA related mods and IVA-only missions lately. I kind of like the thought that you might eventually be able to do everything in the game from a first person perspective. Something like this would obviously be an important step in that direction, certainly.

[codepoet]

The tiniest amount of progress to report, but I have started coding. It really is not much to look at, but here is a picture:

What this shows is that in the "Connected Living Space" window the mod is displaying its understanding of the living spaces in the craft on the pad. It has identified that there is a living space made up of the Mark1-2 pod and the mk1pod, and there is another, seperate living space made up of the Mk2LanderCabin and the landerCabinSmall.

Like I say not terribly exciting, but the information it is displaying will be the heart of this mod - the ability to work out which habitable parts are connected to which other habitable parts, and which habitable parts are cut off from others.

Edited February 9, 2014 by codepoet
typo

[aeTIos]

That looks like a great start already!

[Captain Sierra]

That's really awesome. I'm curious to see where this goes. Though, the one flaw I see is that the Mk1 pod has a heat shield on it's bottom, not a port, like all the other pods do, so it would logically not be able to transfer crew.

[codepoet]

That's really awesome. I'm curious to see where this goes. Though, the one flaw I see is that the Mk1 pod has a heat shield on it's bottom, not a port, like all the other pods do, so it would logically not be able to transfer crew.

We will be able to take that into account by providing config for the various attachment nodes for each part - so we will be albe to say that the tope node for a mk1-2pod is navigable, but the bottom node (heatshield) is not. I have not yet written the code to read in that config, so at the moment you can transfer through the heatshield.

[Fraz86]

The mk1-2 pod actually does visually have hatches on both the top and bottom nodes (and it does not have a heatshield).

[regex]

This is a really cool idea and using PartModules with ModuleManager will make things a lot easier to code, good to see you're heading that way.

A suggestion, if I may? Provide an automatic means for Kerbals to move through the living area. As in, have them move around the craft randomly. This could be done via a random check every hour or so while the vessel is focused and a random "scrambling" of the Kerbals when switching to a vessel (if the time delta is enough) or after timewarping. Have the moving time delta reset when engines are ignited or some sort of human input has been done. Just an idea, but I feel it will increase the immersion this mod will provide.

Looking forward to seeing where you take this!

[CaptainBlue]

Hmm, what about adding a time required for a kerbal to move from one area to another feature? Also, the more parts between one living space to another the longer it takes?

[aeTIos]

Great work. What about coloring the different living spaces with a kind of glow, just like the hover glow?

[codepoet]

Great work. What about coloring the different living spaces with a kind of glow, just like the hover glow?

Yep, that is what I am planning. At the moment I am just writing the code to wall the part tree, identifying which part in in which space, reading the config to take into account which parts are habitable / navigable / passable which attachment nodes are navigable / passable etc etc.

But once I have done all that boring sort of work, I hope to be able to add some pretty as well