[1.12.x] Connected Living Space v2.0.2.0 (12 Feb 2022)

[Technologicat]

15 hours ago, Fraz86 said:

I don't like it, because it's incorrect. Attachable Surface doesn't force anything onto child parts. A passable radial attachment requires both a parent part that has an Attachable Surface and a child part that is Surface Attachable. Neither one alone is sufficient.

Thanks! This clears up at least my confusion

 

Likewise for the "Surface Attachable" flag, the idea is that most parts' passable nodes are specifically engineered to be joined with other passable nodes, not bolted to random uneven holes punched in a compartment's exterior.

There are some parts, where this is useful - e.g. in the Mk2 Stock-a-like Expansion, there is the Mk2 Mobile Processing Lab MPL-SM, which has a hatch at the top. The hatch is clearly meant for EVA, and it has no attachment node, but it could conceivably be kerbalized to bolt a passable part onto it instead (which may be useful if building a space station out of these parts).

The structural fuselages are also an example of a part where punching random holes may be useful for particular craft designs.

(But granted, such parts are in a minority.)

 

9 hours ago, Fraz86 said:

I'm not sure what you mean by "it works to 2/3" vs 1/3.

I agree that the terms could perhaps be more descriptive. Unfortunately the terms you proposed are just plain incorrect. I might suggest something like "Surface is suitable for passable attachments" for Attachable Surface, and "Passable when attached to a suitable surface" for Surface Attachable.

Humor, I take it

I also agree with Kerbal101's general point on user interface design.

Those suggestions are nicely descriptive, but at least in my opinion, a bit long for the right-click menu. This would force the whole window to become wider for the benefit of just one functionality.

Maybe we could make them shorter: "Surface allows passable attachments" and "Passable when surface-attached"? (Or something to that effect.)

 

[Kerbal101]

1 hour ago, Technologicat said:

Humor, I take it

I also agree with Kerbal101's general point on user interface design.

Those suggestions are nicely descriptive, but at least in my opinion, a bit long for the right-click menu. This would force the whole window to become wider for the benefit of just one functionality.

Maybe we could make them shorter: "Surface allows passable attachments" and "Passable when surface-attached"? (Or something to that effect.)

 

Lots of confusion, isn't humor the best way to deal with it?

Your options are also much nicer!

Option! : "Passable through", "Passable to surface attachment".

This allows four variants:
- passable through, but not from sides (can go through, but can't punch holes)
- not passable through, and passable from sides (if holes are punched, crew can go through it sideways)
- passable through, and passable from sides (can go through, can punch holes)
- not passable through, not from sides (can't go through, can't punch holes)
 

If something is "passable through", then it will always keep this if attached perpendicular to root part.
If something is "passable from sides", then it will always keep this if attached parallel to root part.

because, it then stays by ability to glue stuff together - and thats handled elsewhere (by part itself)
 

I am not sure a thing exists, which is: not "Passable", but "Surface allows passable attachments", yet not "passable when surface-attached".

Edited January 25, 2016 by Kerbal101

[Fraz86]

7 hours ago, Technologicat said:

There are some parts, where this is useful - e.g. in the Mk2 Stock-a-like Expansion, there is the Mk2 Mobile Processing Lab MPL-SM, which has a hatch at the top. The hatch is clearly meant for EVA, and it has no attachment node, but it could conceivably be kerbalized to bolt a passable part onto it instead (which may be useful if building a space station out of these parts).

The structural fuselages are also an example of a part where punching random holes may be useful for particular craft designs.

(But granted, such parts are in a minority.)

Structural fuselages should already allow surface attachment, when using a part appropriate for such purposes (Surface Attachable parts, e.g., the Radial Attachment Point, are meant to allow passable attachment on suitable curved surfaces).

In principle, I agree it would be reasonable to allow Surface Attachable parts to attach to EVA hatches. The problem is, there is no good way to allow attachment to EVA hatches without allowing attachment to the entirety of the part's surface. I suppose someone could write a ModuleManager config that adds passable nodes at the locations of EVA hatches, but then there wouldn't be a way to require Surface Attachable parts for these nodes (which would be ideal since EVA hatches are usually on curved surfaces), and not everyone wants extra nodes added to their parts anyway. I also question how important it really is from a design perspective, as there should generally be easy alternative solutions. For example, the Mk2 Clamp-O-Tron can fill the role you described.

Edited January 25, 2016 by Fraz86

[Technologicat]

Status:

• Reported the Mk4 cockpit issue to Nertea in the Mark IV thread. He said he'd add it to the issues page.
• Discussed Buffalo and CLS with Angel-125 in the Buffalo thread. He was receptive to the idea and actually made the configs before I had the time to do so myself. It was decided to do this the "easy" way, i.e., to assume that there is always a passable crew tube running through the Tundras and the Wagon, requiring no code changes to WBIResource Switcher.
• DSEV includes its own CLS configs! (Only the spindle parts need them.) There's a slight issue with the Rotating Hub, which does not currently set surfaceAttachmentsPassable. I have now posted in the DSEV thread about this.
• Currently I'm making the missing configs for Mk3 parts and the odd special case in NF and MRS. Shouldn't take long.

 

On 25.1.2016 at 4:05 PM, Kerbal101 said:

I am not sure a thing exists, which is: not "Passable", but "Surface allows passable attachments", yet not "passable when surface-attached".

As I understand it, the need for the whole "passable when surface-attached" thing comes from the technical design of KSP: each part, in addition to having node_stack_xxx (where xxx is one of front, back, left, right, top, bottom) nodes for axial attachment, may have a separate node_attach node if the part allows itself to be surface-attached to something. Because this node is technically completely independent from the others (i.e. its location on the part may be totally different), it must be handled as an independent node also in CLS.

Hence, "Passable" controls the passability of node_stack_xxx (optionally with blocking some of them using impassablenodes=...), whereas "passable when surface-attached" controls the passability of node_attach.

Hmm, I wonder what Editor Extensions does if you force-enable surface attachment with a part that doesn't have node_attach defined. Let's experiment! Judging visually, taking a Buffalo Crew Cabin and forcing surface attachment onto a Buffalo Command Cab:

...it seems to use the origin of the coordinate system of the part being attached, with negative y pointing inward. While the result is decidedly kerbal, maybe this attachment procedure should not be recommended for general use in spacecraft.

Now, "surface allows passable attachments" is a different thing, and as Fraz86 pointed out, it's hardly a precision tool: it makes the whole surface of the part passable, so that when a child part with a passable node_attach node is surface-attached anywhere on it, that connection becomes passable.

 

Based on the above, my answer to the question is that purely from a logical viewpoint, such a configuration is possible: the part has no hatches on its node_stack_* nodes (hence not "Passable"), but it has for example an EVA hatch somewhere on it that could be kerbalized to bolt something there (hence "Surface allows passable attachments"); and finally, it has no hatch at its node_attach node (hence not "passable when surface-attached").

There is one caveat, though: CLS might require a part to be Passable before accepting the other two options. However, I don't know if this is the case, or if the three options are treated as completely independent. Papa_Joe or codepoet may be able to better settle this part of the question, since it's related to the implementation.

 

On 25.1.2016 at 7:59 PM, Fraz86 said:

Structural fuselages should already allow surface attachment, when using a part appropriate for such purposes (Surface Attachable parts, e.g., the Radial Attachment Point, are meant to allow passable attachment on suitable curved surfaces).

In principle, I agree it would be reasonable to allow Surface Attachable parts to attach to EVA hatches. The problem is, there is no good way to allow attachment to EVA hatches without allowing attachment to the entirety of the part's surface. I suppose someone could write a ModuleManager config that adds passable nodes at the locations of EVA hatches, but then there wouldn't be a way to require Surface Attachable parts for these nodes (which would be ideal since EVA hatches are usually on curved surfaces), and not everyone wants extra nodes added to their parts anyway. I also question how important it really is from a design perspective, as there should generally be easy alternative solutions. For example, the Mk2 Clamp-O-Tron can fill the role you described.

True.

I think the main role of a switchable "Surface allows passable attachments" flag is to cater to different playstyles.

 

Edited January 29, 2016 by Technologicat
DSEV

[Technologicat]

CLS configs done. This was easy now that I actually got time for KSP this week

Here is a preliminary single-patch version that fixes all the parts that are currently known to have missing or wrong CLS configs, except the shielded docking port. (I'd like an opinion on that one.) If we want to match the behavior of the regular Clamp-O-Tron (dockingPort2), dockingPort1 just needs passableWhenSurfaceAttached = true.

Note that in the "realism" (default) version, the node on the nose of the Mk3 cockpit is impassable, because it does not explicitly have a hatch. For the "freedom" version, I plan to leave out the impassablenodes = ... setting.

The rest of the parts were trivial, needing just passable = true.

// CLSKIS.cfg
//
@PART[KIS_Container2]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[KIS_Container3]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

// CLSStock.cfg
//
@PART[MK1CrewCabin]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[mk3Cockpit_Shuttle]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = top  // for "realism" version
    }
}
@PART[mk3CrewCabin]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

// CLSStock.cfg, cargo bays for "freedom" version
//
@PART[mk3CargoBayS]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[mk3CargoBayM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[mk3CargoBayL]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[mk3CargoRamp]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

// Near Future Construction
//
// Grip-O-Tron Large Docking Connector, passable for consistency with stock Clamp-O-Tron Sr. (dockingPortLarge).
@PART[docking-25]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}


// Modular Rocket Systems (MRS)
//
// This matches the config of the stock Rockomax decoupler.
@PART[NBdecouplerSlim2m]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
//
// cargo bays
//
@PART[NBcargoBay1m1]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[NBcargoBay2m1]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[NBcargoBay2m0]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}


// Axial Aerospace Cargo Bays mini mod
//
@PART[125cbsimple]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}
@PART[25cbsimple]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
  MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

Next up, I'll split this into appropriate files... now, where's the git for CLS...

[Technologicat]

Ok, so I forked the repo so that I can create a PR (stupid me, URL was right there in the OP ), and noticed something important: the actual default CLSStock.cfg and the "default" config in CLSStock Alternative Configs.zip are currently out of sync.

Driven by this observation, I fired up Meld and performed a three-way comparison between these two and the "freedom" config in CLSStock Alternative Configs.zip. Results:

• When compared to the default config, the "freedom" config, quite contrary to the name, makes the bottom nodes of landerCabinSmall and mk2LanderCabin impassable! In the other two configs they are passable. I assume this is a bug, but which config is correct? How do you guys want it? I'm fine with the bottom nodes of lander cans being impassable (no hatch and all that), and if it's up to me, in my PR I'll just copy this change to the default config, too. If "freedom", OTOH, is supposed to have the bottom nodes passable, I could also move this change to the default config in my PR.
• The default config has some entries, which are missing from both configs in the zip file, namely mk3Cockpit_Shuttle, mk3CrewCabin, batteryBankLarge, mk3CargoBay*. However, mk3Cockpit_Shuttle has the node on the nose passable; I think in a strict config it shouldn't be, as there is no visible hatch (and I'm not sure if the nose is reachable in the IVA space). Also, curiously, the configs for batteryBankLarge and mk3CargoBay* are patched in using :Final (which, if I understand correctly, is reserved for local overrides by the user) and the edit-or-create operator (%), instead of filtering for HAS[!MODULE[ModuleConnectedLivingSpace]] and just specifying a new module, as in all other entries in the .cfg. I'll fix this. (The use of the wildcard in the part name is better than my preliminary solution of listing all the parts individually. I'll adopt the wildcard approach where applicable.)
• "freedom" includes just one blank line before mk2CargoBayS, instead of three as in the other two configs. I think I'll fix this (either way) for consistency...
• Finally, exactly as it says on the tin, "freedom" adds passability to several parts. The full list is:  probeStackLarge, asasmodule1-2, decoupler1-2, stackDecoupler, stackSeparatorBig, stackSeparator, adapterLargeSmallTri, adapterLargeSmallBi, adapterLargeSmallQuad, batteryBankLarge.

To clean up the situation, my suggestion is to:

• Have only one default CLS config for stock parts and delete the extra copy, since it is almost guaranteed that even if we sync it now, it will again go out of sync (OnceAndOnlyOnce is the maintainer's friend). If needed, a fresh copy of the default config is always available in the release zip of the mod itself. I'd expect the people who install mods to be the type that archives the zips, and failing that, there's KerbalStuff and Github to download it again.
• Take the alternative configs out of the zip file to make them easier to work with (so that there is no need to extract the zip in order to e.g. compare them). Remove the zip file.
• Name the configs e.g. CLSStockStrict.cfg and CLSStockFreedom.txt (note file extension). Mention the alternative configs in the README. Players familiar with installing mods will know what to do with .cfg and .txt files, if they are just alerted to the fact that alternative configs are supplied.

I haven't yet asked NecroBones about whether he wants to include the config for the single part (a decoupler) that needs to be passable into MRS itself, or whether he prefers that we handle it here. Likewise for Nertea and the large docking port in Near Future Construction. I'll do this in the near future (pun not intended).

Finally, by the way, is there a dev thread for CLS? Even though this is just about modifying default configs, I feel like I'm starting to spam up the release thread with technical details that would feel more at home in a dev thread.

[Technologicat]

PR sent on Github, containing the fixes to stock and KIS configs. Details at the link.

I have MRS and NF configs for the couple of misbehaving parts, too, but I'll hold off on those until I have talked with NecroBones and Nertea.

 

EDIT: just to be sure, I searched again for mods providing CLS configs and actually, MRS and NF (Construction, Electrical and Spacecraft) are already among them. I have no idea what went wrong last time I was looking for configs, but:

find . -name "*.cfg" -exec grep -HiIrl "ModuleConnectedLivingSpace" \{\} \; | sort

when run inside GameData (on Linux), returned a much more complete list. Below is the corrected result.

 

Mods providing their own CLS configs (updated list)

• ALCOR (by alexustas)

• Buffalo (by angel-125) (added in version 0.2.7, just released)

• Deep Space Exploration Vessels (by angel-125)

• Filter Extensions (by Crzyrndm) - provides a meta-config to filter for parts which are CLS passable

• Kerbal Planetary Base Systems (by Nils277)

• Mark IV Spaceplane System (by Nertea)

• Mk2 Stock-a-like Expansion (by SuicidalInsanity)

• Modular Rocket Systems (by NecroBones)

• Near Future (by Nertea)

  • Construction

  • Electrical

  • Spacecraft

• SpaceY Heavy Lifters (by NecroBones)

• SpaceY Expanded (by NecroBones)

 

So, right now I'm thinking that the omission of CLS for the decoupler in MRS is probably intentional - considering that even for the stock parts, it's the "freedom" config that makes decouplers passable. If this is the case, maybe it would make the most sense to rename the "freedom" config (so that it's no longer stock only), and tweak the decoupler here using :NEEDS[ModRocketSys]:AFTER[ModRocketSys].

As for the large docking port in NFC, it's less clear-cut - it may have been omitted either intentionally or unintentionally.

I'll keep you guys updated when I know more...

 

EDIT2: Posted in the threads for MRS, NF and Axial Aerospace Cargo Bays. Will report here when I have information.

Also, currently thinking that as for cargo bays in general, the most logical option would be to have them impassable (since they open to space; even if they had the equipment to re-pressurize, the passability would need to depend on the open/closed state), and enable passability in the "freedom" config, or maybe even a separate "PassableCargoBays" config. On the other hand, the Mark IV Spaceplane System marks its cargo bays as passable, so if we don't, this will make cargo bays inconsistent unless Nertea changes his configs, too. So from that point of view, I should probably either go bother Nertea again, or attempt to make all cargo bays passable.

(I wonder whether the passability of MkIV's cargo bays was an independent design decision, or made for consistency with the handling of stock cargo bays in CLS.)

 

Edited February 2, 2016 by Technologicat
status update

[Papa_Joe]

Wow, lots to catch up on.    I've just overcome a hurdle with SM and will be releasing soon. (really, I know if said it before.)..

I'll look over this stuff and provide some concrete feedback and an update that I promised.

 

[GreenWolf]

Any chance of getting some CLS configs for Ven's Stock Part Revamp and the community fixes version of Home Grown Rockets? I've already run into a few instances of having crew trapped inside parts because they can't transfer out and can't EVA because the part is missing configs.

[Kerbas_ad_astra]

4 hours ago, GreenWolf said:

Any chance of getting some CLS configs for Ven's Stock Part Revamp and the community fixes version of Home Grown Rockets? I've already run into a few instances of having crew trapped inside parts because they can't transfer out and can't EVA because the part is missing configs.

I don't know about VSR, but I've made a pull request to update the HGR config.

[Stone Blue]

@Papa_Joe  SO I figured out the purple Blizzy's Toolbar icon that some people reported back, around the last update release...
I guess the issue got lost in the heated discussion about the semantics of the "Surface Attachable"/"Attachable Surface" debate... LOL... and the later, more important, in-depth feature discussions...

Unless it was an intended change, it looks like the two smaller textures, with the "_b_" filenames were not included in the v1.2.0.1 update...

I copied them from the 1.1.3.1 version (I didnt hve the 1.2.0.0 on hand,, but see it DOES include them), and added them to my 1.2.0.1 folder, and the icons now work properly in Blizzy's Toolbar...

I dont know how to add a PR to Github, and couldnt even if i did, since I cant access Github domain from my home network...
Could someone please throw one up quick?

Thanx!

Edited March 15, 2016 by Stone Blue

[Papa_Joe]

Hey all,

Back in action.  SM had been released and nominally debugged,   Roster Manager has been updated.

Now to address CLS...

I have some existing bugs to fix.  I will be posting them in the Git Repository Issues area.  If you have bugs that are not in the list, please add an issue for it.

This way, I will stay on top of them and they won't get forgottten.

I'll begin going over the various conversations governing the configuration files, and get a quick release out to resolve any glaring bugs.  JPLRepo and I also found some bugs when testing between DeepFreeze and ShipManifest.  The big one is a cls bug in a failed crew swap that causes dup or missing kerbals.  This may be the one that has been haunting SM and CLS for months...

I'll also lookover the proposed changes to the configs and build that PR being discussed.

 

Thanks for all the feedback!  

Edited March 15, 2016 by Papa_Joe

[Papa_Joe]

On 3/12/2016 at 3:23 PM, Stone Blue said:

@Papa_Joe  SO I figured out the purple Blizzy's Toolbar icon that some people reported back, around the last update release...
I guess the issue got lost in the heated discussion about the semantics of the "Surface Attachable"/"Attachable Surface" debate... LOL... and the later, more important, in-depth feature discussions...

Unless it was an intended change, it looks like the two smaller textures, with the "_b_" filenames were not included in the v1.2.0.1 update...

I copied them from the 1.1.3.1 version (I didnt hve the 1.2.0.0 on hand,, but see it DOES include them), and added them to my 1.2.0.1 folder, and the icons now work properly in Blizzy's Toolbar...

I dont know how to add a PR to Github, and couldnt even if i did, since I cant access Github domain from my home network...
Could someone please throw one up quick?

Thanx!

Awesome!   I'll be sure to correct that with the next release.  Thanks!

[Papa_Joe]

On 1/31/2016 at 0:08 PM, Technologicat said:

PR sent on Github, containing the fixes to stock and KIS configs. Details at the link.

I have MRS and NF configs for the couple of misbehaving parts, too, but I'll hold off on those until I have talked with NecroBones and Nertea.

 

EDIT: just to be sure, I searched again for mods providing CLS configs and actually, MRS and NF (Construction, Electrical and Spacecraft) are already among them. I have no idea what went wrong last time I was looking for configs, but:

find . -name "*.cfg" -exec grep -HiIrl "ModuleConnectedLivingSpace" \{\} \; | sort

when run inside GameData (on Linux), returned a much more complete list. Below is the corrected result.

 

Mods providing their own CLS configs (updated list)

• ALCOR (by alexustas)

• Buffalo (by angel-125) (added in version 0.2.7, just released)

• Deep Space Exploration Vessels (by angel-125)

• Filter Extensions (by Crzyrndm) - provides a meta-config to filter for parts which are CLS passable

• Kerbal Planetary Base Systems (by Nils277)

• Mark IV Spaceplane System (by Nertea)

• Mk2 Stock-a-like Expansion (by SuicidalInsanity)

• Modular Rocket Systems (by NecroBones)

• Near Future (by Nertea)

  • Construction

  • Electrical

  • Spacecraft

• SpaceY Heavy Lifters (by NecroBones)

• SpaceY Expanded (by NecroBones)

 

So, right now I'm thinking that the omission of CLS for the decoupler in MRS is probably intentional - considering that even for the stock parts, it's the "freedom" config that makes decouplers passable. If this is the case, maybe it would make the most sense to rename the "freedom" config (so that it's no longer stock only), and tweak the decoupler here using :NEEDS[ModRocketSys]:AFTER[ModRocketSys].

As for the large docking port in NFC, it's less clear-cut - it may have been omitted either intentionally or unintentionally.

I'll keep you guys updated when I know more...

 

EDIT2: Posted in the threads for MRS, NF and Axial Aerospace Cargo Bays. Will report here when I have information.

Also, currently thinking that as for cargo bays in general, the most logical option would be to have them impassable (since they open to space; even if they had the equipment to re-pressurize, the passability would need to depend on the open/closed state), and enable passability in the "freedom" config, or maybe even a separate "PassableCargoBays" config. On the other hand, the Mark IV Spaceplane System marks its cargo bays as passable, so if we don't, this will make cargo bays inconsistent unless Nertea changes his configs, too. So from that point of view, I should probably either go bother Nertea again, or attempt to make all cargo bays passable.

(I wonder whether the passability of MkIV's cargo bays was an independent design decision, or made for consistency with the handling of stock cargo bays in CLS.)

Thanks Technologicat for all your efforts here!  

I've merged this into the CLS Repository.   I'm now going thru a couple of other pull requests from Kerbas_ad_astra & mwerle  (back in 2015).

No date yet, but soon.

Edited March 18, 2016 by Papa_Joe

[Noobton]

EDIT: I found the answer a minute after posting this (I had been looking for a while before), in the right click info the MKI cockpit states that top and bottom are impassable.

I'm trying to connect a mk1 commnad pod to a crew cabin, but I get the "Jebediah is unable to reach Mk1 Cabin message", I'm not sure if what I want to do is possible or if I'm doing something wrong, Here's some screenshots of how I'm configuring the objects, I enabled everything to try to make it work, but I try a few other combinations before and nothing worked.

Thanks

Edited March 19, 2016 by Noobton

[Papa_Joe]

3 hours ago, Noobton said:

EDIT: I found the answer a minute after posting this (I had been looking for a while before), in the right click info the MKI cockpit states that top and bottom are impassable.

I'm trying to connect a mk1 commnad pod to a crew cabin, but I get the "Jebediah is unable to reach Mk1 Cabin message", I'm not sure if what I want to do is possible or if I'm doing something wrong, Here's some screenshots of how I'm configuring the objects, I enabled everything to try to make it work, but I try a few other combinations before and nothing worked.

Thanks

Indeed the mk 1 pod is impassable... there is a heatshield on the back... cant walk thru that... However, if you realy want this, then I'm guessing that if you enable Custom CLS configs, you can modify the design in the editor and enable passability for the pod.   Check it out.   this is explained in the wiki as well.  Check out my sig.

Additionally, in the CLS options menu, you can turn off cls and that will allow the stock transfer to work.

Edited March 19, 2016 by Papa_Joe

[Deimos Rast]

Out of curiosity, does CLS have a blizzy toolbar button? I've always had just a purple box and I always get "button missing" messages in my log. An issue of Kerbin shattering importance to be sure. It also seems I'm a version behind, so that might resolve the issue.

Also, to insert myself in the conversation above without invitation (sorry), the CLS Options Menu has the "Allow Unrestricted Crew Transfer" which might be the same thing as what you mean by "turning off cls."

[Stone Blue]

2 hours ago, Deimos Rast said:

Out of curiosity, does CLS have a blizzy toolbar button?

My post, a few posts up the page:
 

 

[Papa_Joe]

6 hours ago, Deimos Rast said:

Out of curiosity, does CLS have a blizzy toolbar button? I've always had just a purple box and I always get "button missing" messages in my log. An issue of Kerbin shattering importance to be sure. It also seems I'm a version behind, so that might resolve the issue.

Also, to insert myself in the conversation above without invitation (sorry), the CLS Options Menu has the "Allow Unrestricted Crew Transfer" which might be the same thing as what you mean by "turning off cls."

yes.  allow unrestricted is the setting I'm referring to crudely.

[Deimos Rast]

4 hours ago, Stone Blue said:

My post, a few posts up the page:
 

 

The plot thickens! Many thanks.

[Papa_Joe]

Ok, new release.

release v1.2.0.2
* New:  Added Changes to configurations based on conversations in forums and a Pull Requests by Technologicat, khr15714n &  Kerbas-ad-astra.
* Fixed:  Correct build deploy automation to project (missing icons for blizzy). 
* Fixed:  CLS tweakables incorrectly visible when custom passability is disabled.
 

On SpaceDock and Github

Looking forward to KSP 1.1.  Soon now...

[Kerbas_ad_astra]

I'm not seeing the TaurusHCV.cfg file in the 1.2.0.2 download (looking in GameData/ConnectedLivingSpace/Config).  Also, there's still the "CLS Stock Alternative Configs.zip" and "ASETStackableInlineLights .cfg" (with a space, in addition to the space-less "ASETStackableInlineLights.cfg"), even though Technologicat's PR removed those files.  Maybe there's still a bug with the build deployment?

[Papa_Joe]

16 minutes ago, Kerbas_ad_astra said:

I'm not seeing the TaurusHCV.cfg file in the 1.2.0.2 download (looking in GameData/ConnectedLivingSpace/Config).  Also, there's still the "CLS Stock Alternative Configs.zip" and "ASETStackableInlineLights .cfg" (with a space, in addition to the space-less "ASETStackableInlineLights.cfg"), even though Technologicat's PR removed those files.  Maybe there's still a bug with the build deployment?

Certainly Possible.    I'll check it out. Thanks!

[Stone Blue]

19 minutes ago, Kerbas_ad_astra said:

 Also, there's still the "CLS Stock Alternative Configs.zip" and "ASETStackableInlineLights .cfg" (with a space, in addition to the space-less "ASETStackableInlineLights.cfg"), even though Technologicat's PR removed those files.

Why was that removed?...I still use those parts quite a bit, especially on stations...

[Kerbas_ad_astra]

10 minutes ago, Stone Blue said:

Why was that removed?...I still use those parts quite a bit, especially on stations...

The file was removed because it was renamed.  (Git has a few idiosyncrasies with how it handles files.  For example, renaming a file is stored in Git as a "delete-and-recreate" operation.)  So, the old file with a space in its name was removed from the repo, and the new file sans space was created.  Except, in the download, both files are present when there should only be the latter.