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

[codepoet]

I thought it was time to add some pretty:

In many ways this was all I ever really wanted from this mod - a way to let me role play transfering crew internally, and not "cheat" in my designs by forcing me to not assue I can move kerbels through fuel tanks.

I will work out what to do about providing config for stock parts, and then make a prerelease for people to play with, while I work on providing a sensible API.

A few other thoughts:

1) I am undecided on using ModuleManager. I see it is very powerful, but I want to give modders the final say withiut it being a hastle for them.

2) Currently you can ad config for a particular part by adding a "ConnectedLivingSpace" MODULE to a particular part. However if I go with that then it will be hard to encourage modders to provide their own config for their parts because not having this mod installed would then generate errors in the log.

3) I would really apprichiate some feedback on what functionality folks would like to see from the API. There is no point in me writing this mod if it does not provide the information people need to do whatever they are trying to do.

Edited February 11, 2014 by codepoet
spelling

[Fraz86]

Are you planning to include a built-in crew transfer capability (between contiguous modules), or do you plan to leave this to other modders utilizing your plugin? I certainly understand your desire to keep your plugin minimal, but transfer functionality seems pretty much intrinsic to the concept of your mod...

[regex]

3) I would really apprichiate some feedback on what functionality folks would like to see from the API. There is no point in me writing this mod if it does not provide the information people need to do whatever they are trying to do.

Some functions I'd like to see:

List<HabitableArea> getHabitableAreas()

List<Part> getHabitablePartsInArea(HabitableArea)

List<Kerbal> getKerbalsInArea(HabitableArea)

int maxPopulationInArea(HabitableArea)

bool moveKerbalToPart(Kerbal, Part)

I think those cover most of the functionality someone might need for a life support or crew manifest mod. At the very least, getting a list of HabitableAreas and a list of parts in them (or exposing the list of habitable parts) would allow any other modder to write the last three functions I defined (and pretty much anything else).

E: Something else that would be really nice for the API is to have some pre-built GUI elements for VAB/SPH and in-flight use for highlighting the areas.

Edited February 11, 2014 by regex

[a__gun]

I am undecided on using ModuleManager.

You can say 'add these config options unless they are already set' as you previously asked.

Example:

@PART[*]:HAS[~LivingSpaceSetting[]]    //Search for all parts without the variable 'LivingSpaceSetting'
{
    LivingSpaceSetting = defaultLivingSpaceSetting    //Set LivingSpaceSetting to whatever value you want
}

This comes from one of the examples in the second post on the MM thread

[codepoet]

Are you planning to include a built-in crew transfer capability (between contiguous modules), or do you plan to leave this to other modders utilizing your plugin? I certainly understand your desire to keep your plugin minimal, but transfer functionality seems pretty much intrinsic to the concept of your mod...

The point here is not that I do not want to add features to CLS, but that I do not want CLS to become an alternative to already well established mods with a large user base. I would much prefer to see existing mods make use of CLS than have CLS duplicate their features. If the maintainers of existing mods are not interested to use CLS, then I will probably write seperate a seperate mod to provide that functionality (ie crew transfer or whatever). However if I am going to spend my time writing a mod that makes use of CLS I would much prefer to do so writing a mod that adds a feature that is not currently available, rather than trying to steal users away from some other mod's userbase.

Once I have got to a point of making a proper release, I will approach the maintainers of appropriate mods.

[codepoet]

You can say 'add these config options unless they are already set' as you previously asked.

Example:

@PART[*]:HAS[~LivingSpaceSetting[]]    //Search for all parts without the variable 'LivingSpaceSetting'
{
    LivingSpaceSetting = defaultLivingSpaceSetting    //Set LivingSpaceSetting to whatever value you want
}

This comes from one of the examples in the second post on the MM thread

Back of the net! So presumably I can provide some MM config such as:

@PART[PorkJetsFunkyInflatableModule]:HAS[~LivingSpaceSetting[]]    //Search for all parts called 'PorkJetsFunkyInflatableModule' without the variable 'LivingSpaceSetting'
{
    LivingSpaceSetting = defaultLivingSpaceSetting    //Set LivingSpaceSetting to whatever value you want
}

Which will make PorkJets parts work, but allow PorkJet to provide his own settings if he feels so inclined?

[a__gun]

Back of the net!...

You could even:

@PART[PorkJet*]:HAS[~LivingSpaceSetting[]]    //Search for all parts who's names start with 'PorkJet' without the variable 'LivingSpaceSetting'
{
    LivingSpaceSetting = defaultLivingSpaceSetting    //Set LivingSpaceSetting to whatever value you want
}

This would apply the settings to all of porkjet's parts (as long as he follows that naming convention) that don't have LivingSpaceSetting set

[Crater]

Back of the net! So presumably I can provide some MM config such as:

@PART[PorkJetsFunkyInflatableModule]:HAS[~LivingSpaceSetting[]]    //Search for all parts called 'PorkJetsFunkyInflatableModule' without the variable 'LivingSpaceSetting'
{
    LivingSpaceSetting = defaultLivingSpaceSetting    //Set LivingSpaceSetting to whatever value you want
}

Which will make PorkJets parts work, but allow PorkJet to provide his own settings if he feels so inclined?

Yes, exactly that. Also, what some part providers do, to mitigate against the log errors you mentioned above, is that they provide their parts with stock (or must-have mod) configurations, and then also provice ModuleManager configs of their own that a player can include if they have the appropriate mod, or remove if they don't want the log errors.

It also means that players can contribute a ModuleManager config for a parts pack for CLS, then other users can include that one.

Lastly, it also gathers all the appropriate defaults that you provide into a simple easy to edit place, so if anyone disagrees with your decisions, (reasons of immersion, etc.), they can trivially tweak the file to be just how they like, without having to worry that your thoughts on heatshield hatches have been hardcoded.

Edited February 11, 2014 by Crater

[codepoet]

So I have taken some advice and used Module Manager. It was so easy!!

Here are some pictures:

So I have included configuration for tructural adapter type parts and the 6way node.

Here you can see a sloppy spacecraft designer managed to put a battery that seperates this living compartment from the rest of the living space! Rookie mistake - at least it was spotted in the launch pad, rather than in orbit.

There is a problem though. If you attached several passable but not habitable parts together, they get identified as a habitable space. In this case two docking ports. I think the code will need a little more tweaking!

[DasBananenbrot]

So I have taken some advice and used Module Manager. It was so easy!!

Here are some pictures:

http://s28.postimg.org/oko5klfq5/screenshot106.png

So I have included configuration for tructural adapter type parts and the 6way node.

http://s28.postimg.org/9jlv3bx0d/screenshot107.png

Here you can see a sloppy spacecraft designer managed to put a battery that seperates this living compartment from the rest of the living space! Rookie mistake - at least it was spotted in the launch pad, rather than in orbit.

http://s28.postimg.org/ytl845t5p/screenshot109.png

There is a problem though. If you attached several passable but not habitable parts together, they get identified as a habitable space. In this case two docking ports. I think the code will need a little more tweaking!

That is a great

[codepoet]

Also works in the VAB

[DasBananenbrot]

http://s18.postimg.org/tkfln0k61/screenshot111.png

Also works in the VAB

Nice Good to see you make progress that fast

[codepoet]

One more picture for tonight:

So you can now rename the individual habitable spaces, and those names are persisted across saves. I have fixed the problem of it creating spaces that were not habitable, and it now calculates the Crew Capacity of each habitable space.

[CaptainKipard]

I'm not really sure what's going on here, but I've been quietly hoping for loss of pressure functionality and actual working airlocks for a while. Is this relevant/possible?

[landeTLS]

I'm not really sure what's going on here, but I've been quietly hoping for loss of pressure functionality and actual working airlocks for a while. Is this relevant/possible?

You can do all of that via a plugin. Tho there are degrees of how much simulation the plugin will do and an associated complexity in the code required to do so. In the most simple and basic way to do the pressure functionality would be to have a value that goes from 0 to 100 % in each module and if there is a break in the System (hole in the fusulage or other) the pressure would start to drain from that segement of connected modules and you would have to plug the hole in eva or move the crew and seal the module before the pressure gets too low and the crew dies. Tho there are lots of design conciderations with such a system and lots and lots of coding.

I believe it was asmi i said he was going to be looking into something like this in the future for his elcss mod. But more for internal atmosphere simulation rather than faliures.

Same with working airlocks. The best suggestion iwe seen for a basic implimentation of this is to add a clickable element inside the iva on the "airlock"(most ivas have some kind of airlock looking texture) that will jump the view to the connected module if there is a free seat.

The problem of making actual advanced iva via a plugin comes from that the iva dont really allow moving in the space.

Tho there is currently possible to add animations on parts in the iva. One could perhaps take it one step further and make a prop that is an animated openable airlock that leads to a small dark section (airlock connecting two modules together(?)), or perhaps somehow the code could even load the iva model of the connected module and connect that to the hole (no idea if this would be possible) but that would require a lot of configs placing it in every habitable space iva, the iva models would probably need to be changed in order to do this.

But for actual moving inside an iva view(without hacking it by using a hollow structural component instead of an internal) i dont know about that one. I think we would probably need to wait for squad to impliment that.

Edited February 12, 2014 by landeTLS

[CaptainKipard]

But for actual moving inside an iva view(...)

That's not what I'm talking about. I think you're confusing airlocks with hatches. An airlock is a separate structure that allows for depressurisation before EVA, while keeping the rest of the inner atmosphere intact. A hatch is basically a door that leads to the next section or out into space like we have right now.

[landeTLS]

That's not what I'm talking about. I think you're confusing airlocks with hatches. An airlock is a separate structure that allows for depressurisation before EVA, while keeping the rest of the inner atmosphere intact. A hatch is basically a door that leads to the next section or out into space like we have right now.

Yea i guess i confused the two. It was late:P working airlocks would be cool. Youre thinking seperate parts for the airlock then right? Nothke made a hollow structural component lab with an integrated animated airlock but he never released it. It would be really cool if you had to depressurize the airlock before you where allowed to eva. Now we just need to wait for someone to impliment this and simulate atmosphere inside the ship etc. would really give a whole new level of immersion

Edited February 12, 2014 by landeTLS

[codepoet]

I have made a download available on the first page. It does not do very much, but should allow you to view and rename the various living spaces in your craft. You will need ModuleManager in order to load the config for stock parts.

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

1) 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.

2) 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.

3) Offer ideas for how the API should work, so other modders can use this concept of connected spaces in their mods

4) Offer ideas for mods where this functionaily would be useful.

5) 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.

6) Post pictures to this thread of interesting things you do with this CLS to encourage me!

[a__gun]

Good job on first release! Not had a chance to do any testing yet but a few things:

Not sure your MM patch will work as intended. You have used 'HAS[~MODULE' when 'HAS[!MODULE' appears to be the correct syntax (The example I gave you was checking against a variable not a module, this does seem to use ~ rather than !, no idea why). If you look at this post it gives some good examples that cover most things.

Also, I have started a basic MM patch to add your module to ALL parts meeting certain criteria:

@PART[*]:HAS[!MODULE[ModuleConnectedLivingSpace], !MODULE[ModuleParachute], ~category[Aero], ~category[Propulsion], 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

////All parts with:
//No CLS module already
//No parachute module
//Not an aero part
//Not a engine/tank

I think other checks it would be good to make are the mass of the part, its attachment rules and the size of its nodes. To do this however, you would need code along these lines:

@PART[*]:HAS[#mass[>1], #attachrules[1*], #node*[*,*,*,*,*,>0]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

and I have no idea if MM can handle comparisons (<,>, etc) or partial variable names using wildcards (node*).

[codepoet]

Good job on first release! Not had a chance to do any testing yet but a few things:

Not sure your MM patch will work as intended. You have used 'HAS[~MODULE' when 'HAS[!MODULE' appears to be the correct syntax (The example I gave you was checking against a variable not a module, this does seem to use ~ rather than !, no idea why). If you look at this post it gives some good examples that cover most things.

Also, I have started a basic MM patch to add your module to ALL parts meeting certain criteria:

@PART[*]:HAS[!MODULE[ModuleConnectedLivingSpace], !MODULE[ModuleParachute], ~category[Aero], ~category[Propulsion], 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

////All parts with:
//No CLS module already
//No parachute module
//Not an aero part
//Not a engine/tank

I think other checks it would be good to make are the mass of the part, its attachment rules and the size of its nodes. To do this however, you would need code along these lines:

@PART[*]:HAS[#mass[>1], #attachrules[1*], #node*[*,*,*,*,*,>0]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

and I have no idea if MM can handle comparisons (<,>, etc) or partial variable names using wildcards (node*).

Thanks so much for providing some input on this - as you can tell I know nothing about MM and its possibilities, so it is great to have others who know better showing the way forward

As it "works" with stock for now, I want to be able to concentrate on things such as:

1) Support for blitzy Toolbar

2) Improve the UI

3) Provide a documented API

So I am really pleased that soemone else is worrying about how to make it work with all the hundreds of mod parts that are available.

Edited February 14, 2014 by codepoet

[a__gun]

No problems - nice to have something I actually feel I can help on!

[SnowyDuck]

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

Edited February 14, 2014 by SnowyDuck
Formatting

[codepoet]

I have done a bit more work on CLS, and will update the download in a moment. Changes include:

1) Added support for (dependancy on) blitzy's Toolbar.

2) Refactored some of the code with an eye to the API.

3) Made some changes to the stock config. (Note that parts that can house crew but are not configured will still be identified as habitable by CLS, however CLS will not be able to save any change in the name of the Space, as that is saved in the PartModule for each configured part.)

4) Added support for highlighting habitable and passable parts differently. Here are some pictures:

Also in other news I have had more maintainers of other mods get in contact to express an interest in integrating with CLS. It is not for me to reveal their plans, or who they are, but it is obviously great to have people want to do this.

Edited February 14, 2014 by codepoet

[codepoet]

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.

2) CLS now correctly navigates docked attachments. Docked craft are very different to attached parts as the AttachNodes between the docked parts are not set up, so CLS was not identifying them as being passable. I have made some changes so CLS works out whether or not docked parts are passable.

3) Having done 2) above it is now able to display docked parts diferently to other parts, so they get highlighted in cyan.

4) The shape of the API is not much clearer in my mind as well, so I hope to document it in the next few days.

Here are some pictures:

This was all launched as one piece. Notice that the docking ports all show up as yellow to indicate that they are passable/naviagable.

One of the capsules has detatched and docked onto one of the other docking ports. Notice how the docking ports now display as cyan, to indicate that they are now docked. Previously they were not docked, they were attached (but still considered to be passable by CLS)

Here the other capsule has detatched and then redocked.

I have updated the download on the first page.

Edited February 15, 2014 by codepoet

[codepoet]

I have started to write a roadmap for this mod on the first post, for the benefit of modders who are interested in contributing to its development.