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

[Captain Sierra]

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

Correct. It's the Mk 1 pod that lacks hatches (heat shield on bottom, and I'd like to see a kerbal get his big helmet through the node on top, which also lacks a visual hatch).

[Captain Sierra]

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

Fun fun! I see many possibilities for enhanced IVA plugins based off this (clicking hatches to jump to an empty seat in the next pod, etc.).

[codepoet]

Yep, that is what I am hoping. Once there is a standardised way of deciding if two parts are connected internally or not, then lots of other things become possible. (personal hygene mod anyone? - Oh, sorry - forget I mentioned it.)

[NathanKell]

regex: I do like that random-walkies idea.

[aeTIos]

Correct. It's the Mk 1 pod that lacks hatches (heat shield on bottom, and I'd like to see a kerbal get his big helmet through the node on top, which also lacks a visual hatch).

Only 1.25m+ stack nodes are traversable, as mentioned in the Clamp-O-Tron Jr. description.

regex: I do like that random-walkies idea.

I also like this. It might however be nice to have a visual indicator of moving kerbals. Maybe a dot on the pod displaying their position and when mouse-overed, their name?

[codepoet]

More baby steps, but in the right direction. Here is a picture:

What this shows is that the hitchhiker storage container and the small landing can are considered to be in the same living space, even though there are two docking ports inbetween them, which themselves can not house a kerbal. This has been done by assigning configuration to the docking port parts to mark them as being "passable". This can be done to any part, so parts such as the structural fusilage and 1.25m->2.5m adapters will also be able to be configured to allow kerbals to pass along them to get from one habitable part to another.

Next step is to make specific attachment nodes either passable or impassable.

[a__gun]

More baby steps, but in the right direction. Here is a picture:

http://s1.postimg.org/53yzuy027/screenshot101.png

What this shows is that the hitchhiker storage container and the small landing can are considered to be in the same living space, even though there are two docking ports inbetween them, which themselves can not house a kerbal. This has been done by assigning configuration to the docking port parts to mark them as being "passable". This can be done to any part, so parts such as the structural fusilage and 1.25m->2.5m adapters will also be able to be configured to allow kerbals to pass along them to get from one habitable part to another.

Next step is to make specific attachment nodes either passable or impassable.

You previously mentioned heuristically working out wether unsupported parts were passable or not. Can I suggest that the size of attachment nodes would be a easy way to do this. Of course it does assume attachment nodes are all set to sensible sizes, which they are not, but logically anything with a 1.25m node or above should fit a kerbal through. On second thoughts, I suppose you don't want kerbals passing through fuel tanks and batteries regardless of their size.....nevermind :/

[codepoet]

You previously mentioned heuristically working out wether unsupported parts were passable or not. Can I suggest that the size of attachment nodes would be a easy way to do this. Of course it does assume attachment nodes are all set to sensible sizes, which they are not, but logically anything with a 1.25m node or above should fit a kerbal through. On second thoughts, I suppose you don't want kerbals passing through fuel tanks and batteries regardless of their size.....nevermind :/

What you say is good thinking. Indeed I had pretty much that in mind already. The first test is "can a kerbal be inside this part?" If a kerbal can not be inside the part (ie a battery of a fuel tank) then obviously the attachment nodes on that part will not allow a kerbal in. However if a kerbal is allowed inside a part, how do we decide which of the attachment nodes will provide a sensible way in and out? So in rough outline, what I am planning is something like this:

1) Can a kerbal be inside this part? if not then its attachment nodes are impassable

2) Is there config provided with the part that tells us whcih nodes are passable and which are impassable? (This allows part makers to decide for themselves which of their attachment nodes they intended to be passable)

3) if there is not config provided with the part, is there some config provided by the ConnectedLivingSpace mod for that particular part (I hope to provide such config for populat part packs)

4) If none of the above help, then use some heuristics (ie attachment node size, does the name of the part include "docking port" etc) to make an educated guess.

Hopefully 2 & 3 will answer the question for most parts, but 4 will keep things working valuely sensibly. If 4) makes a bad choice then some config can be provided in a future release of either ConnectedLivingSpace or the part to set things straight.

[codepoet]

Another small step. Consider this image:

This is the same craft as the previous image I posted. However there are now 3 seperate living spaces. The reason is that I have configured the bottom node of the Mk1 Command Pod to be impassable (as someone suggested earlier on the thread that it was supposed to have a heat shield on the bottom.)

The point here is that the CLS mod is not only taking into account whether or not a part has been marked as passable, but also if the particular nodes that the parts are attached to each other on are passable.

There is an inevitable debate that we will be able to have very soon - what is that list of stock parts that should be considered passable, and what is the list of stock parts that should be considered passable but only on certain nodes? I will post my own opinion in answer to this question soon, but if someone else wants to beat me to it, be my guest...

[nothke]

Nodes are more important than parts. Consider the free attach points as well. Note that you can attach clamp-o-trons anywhere, so even if you attach them to the side of the hitchhiker they should still be passable.

[codepoet]

Nodes are more important than parts. Consider the free attach points as well. Note that you can attach clamp-o-trons anywhere, so even if you attach them to the side of the hitchhiker they should still be passable.

Yep, I have got a big comment in my code at the moment that says "//TODO - work out what to do with surface attachements!"

As for nodes/parts, I suppose a part that can not have a kerbal in it is just a special case where all its attachment nodes are impassable.

[WillHop]

Just a suggestion I thought would be pretty cool (no idea if possible or not!) - building on from the idea that regex had a couple of pages back, as well as the randomisation of the position of Kerbals in crafts, maybe a little dot depicting where the Kerbal is in the craft, and when the position of the Kerbal changes, the dot could move around the station? No idea if possible, and quite pointless, but I think it would look pretty cool and actually make me feel like Kerbals were inside the station I spent 3 weeks building

[nothke]

There is an inevitable debate that we will be able to have very soon - what is that list of stock parts that should be considered passable, and what is the list of stock parts that should be considered passable but only on certain nodes? I will post my own opinion in answer to this question soon, but if someone else wants to beat me to it, be my guest...

Well, if you take out the controversial fuel tanks, batteries, (which IMO should not be passable even when they're empty), then you are left with pods, hitchhiker, lab, campotron1m, inline and senior, the 1m structural fuselage, the adapters and the 6-way node. That's basically it for the stock parts =)

[codepoet]

Just a suggestion I thought would be pretty cool (no idea if possible or not!) - building on from the idea that regex had a couple of pages back, as well as the randomisation of the position of Kerbals in crafts, maybe a little dot depicting where the Kerbal is in the craft, and when the position of the Kerbal changes, the dot could move around the station? No idea if possible, and quite pointless, but I think it would look pretty cool and actually make me feel like Kerbals were inside the station I spent 3 weeks building

I am sure that would be possible - I think it has already been suggested by someone else earlier on the thread. I think that the scope of this mod will be just identify how the living spaces are connected and then make that information as an API to other mods, or another modder (or even myself) could be moved to impliment the functionaily that you suggest.

What I am trying to achieve is to provide a way of ensuring that all the various different functionailties that are being suggested do not end up having to decide for themselves (possibly differently) which living spaces are connected to each other.

Edited February 10, 2014 by codepoet
spelling

[Fraz86]

I would suggest that surface attachments should not function as passable nodes by default behavior. Only a few specific parts should have that functionality, such as the BZ-62 Radial Attachment Point and the Clamp-O-Tron Docking Port.

[codepoet]

Well, if you take out the controversial fuel tanks, batteries, (which IMO should not be passable even when they're empty), then you are left with pods, hitchhiker, lab, campotron1m, inline and senior, the 1m structural fuselage, the adapters and the 6-way node. That's basically it for the stock parts =)

There is also the Cupola pod that has a special case window node on the top that in my opinion should be impassable, and also the small one-man pod (mk1) which it has been suggested should be not passable on the bottom node as it is a heatshield, and not be passable on the top as it is too small. I agree with the later of these, I am undecided about the heatshield arguement.

[Ralathon]

There is also the Cupola pod that has a special case window node on the top that in my opinion should be impassable, and also the small one-man pod (mk1) which it has been suggested should be not passable on the bottom node as it is a heatshield, and not be passable on the top as it is too small. I agree with the later of these, I am undecided about the heatshield arguement.

A specially modded Gemini had a flight proven heatshield that doubled as hatch. So it is certainly possible to pass through a heatshield without compromising its protection.

source

[Fraz86]

Upon further consideration, I'd like to argue in favor of completely disallowing surface attachments as passable nodes. It's simply too abusable, allowing players to slap on Radial Attachments to create passable nodes anywhere they desire, including clearly impassable parts of a module. Surface attachments would also be immersion-breaking in regard to consistency with the IVA view.

Along similar lines, when deciding which nodes are passable or not, it seems to me the most intuitive and immersive solution is simply: does the node visually appear intended to function as a passable hatch? I understand this is impossible to code as a heuristic, but I don't think it's necessary to have a perfect heuristic, given how easy it will be to add the needed config definitions via a ModuleManager file.

[codepoet]

... I understand this is impossible to code as a heuristic, but I don't think it's necessary to have a perfect heuristic, given how easy it will be to add the needed config definitions via a ModuleManager file.

I am not familiar with ModuleManager, but several people have posted on this thread suggesting that it is going to make my life easier. Could someone explain very simplky what it does and how it can help with this project?

[Ralathon]

I am not familiar with ModuleManager, but several people have posted on this thread suggesting that it is going to make my life easier. Could someone explain very simplky what it does and how it can help with this project?

ModuleManager is a tiny DLL that allows you to adjust anything about any part.cfg file. For example, say you want to add a module to the small fueltank and remove its fuel content. All you need to do is add a .cfg file that contains this:

@PART[fuelTank]{
    !RESOURCE[LiquidFuel] {}
    !RESOURCE[Oxidizer] {}
    MODULE
    {
        name = Module_of_awesome
        awesomeness = 2003921337
        modifier = epic
    }
}

and Modulemanager will automatically apply it to the stock fuel tank. It keeps everything tidy and is very powerful.

[Fraz86]

Basically, it allows you to easily edit the content of part cfg files (from stock or mods), without actually messing around with the individual files. So, you could use a single cfg file to add all of your node definitions. It would look like this:

@PART[mk1pod]

{

[passable node definition here]

}

@PART[mk1-2pod]

{

[passable node definition here]

}

etc.

[codepoet]

ModuleManager is a tiny DLL that allows you to adjust anything about any part.cfg file. For example, say you want to add a module to the small fueltank and remove its fuel content. All you need to do is add a .cfg file that contains this:

@PART[fuelTank]{
    !RESOURCE[LiquidFuel] {}
    !RESOURCE[Oxidizer] {}
    MODULE
    {
        name = Module_of_awesome
        awesomeness = 2003921337
        modifier = epic
    }
}

and Modulemanager will automatically apply it to the stock fuel tank. It keeps everything tidy and is very powerful.

So I could use it to ship default settings for stock / other modders parts (unless others modders choose to support CLS themselves)? I can see how that would be very handy!

Can it be used to say "add these config options unless they are already set"? I would like to give first preference to any setting that modders add to their own parts. I think that it is the modder who should be the authority on which attachment nodes they wanted to be passable/impassable.

[Ralathon]

So I could use it to ship default settings for stock / other modders parts (unless others modders choose to support CLS themselves)? I can see how that would be very handy!

Can it be used to say "add these config options unless they are already set"? I would like to give first preference to any setting that modders add to their own parts. I think that it is the modder who should be the authority on which attachment nodes they wanted to be passable/impassable.

I'm not an expert on Module Manager code. But I know that it has a [final] command which means it makes that pass last. If modders want their own definitions over yours they can just add their own Module Manager file with a [final] so it executes after yours. This means that it will default to your settings but can be overwritten if the modder desires it.

Here's the thread on Modulemanager. If there is a more elegant solution I suggest looking here.

[regex]

Upon further consideration, I'd like to argue in favor of completely disallowing surface attachments as passable nodes. It's simply too abusable, allowing players to slap on Radial Attachments to create passable nodes anywhere they desire, including clearly impassable parts of a module. Surface attachments would also be immersion-breaking in regard to consistency with the IVA view.

I don't see how surface attachments or other parts being passable would be "abusable" in any sense, since moving Kerbals around doesn't give the player any real advantage in gameplay. I mean, you're basically arguing that people would be "cheating" by moving Kerbals through surface attachable nodes. Most of this is "quality of life" improvements anyway; if it needs to be refined for a life support mod that is easily done through ModuleManager. Besides, ruling out surface attach parts kills certain things like the radial attachment node being used for an impromptu corner which ruins creativity.

E: Crap, sorry for ****ting up this thread after you just made a mention of using ModuleManager and having modders override your config if needed...

Edited February 10, 2014 by regex

[Fraz86]

I don't see how surface attachments or other parts being passable would be "abusable" in any sense, since moving Kerbals around doesn't give the player any real advantage in gameplay. I mean, you're basically arguing that people would be "cheating" by moving Kerbals through surface attachable nodes. Most of this is "quality of life" improvements anyway; if it needs to be refined for a life support mod that is easily done through ModuleManager. Besides, ruling out surface attach parts kills certain things like the radial attachment node being used for an impromptu corner which ruins creativity.

I'd argue that this whole plugin serves to increase immersiveness, because, as you point out, defining a contiguous habitable area has minimal implications for gameplay. So, my proposal is based on what seems most immersive to me, which would be only allowing habitable areas to connect in places where they appear to have been designed to do so.