Technologicat

I haven't used SVE - maybe someone else here can help? The SVE thread says just it's built off the development version of EVE (under the first picture in the OP). This could mean any new EVE version, or specifically the current dev version (I think 1.05-4 had some changes regarding texture mapping, don't know if that's needed for SVE or not). Don't know about EVE only, but EVE 1.05-3 and Scatterer 0.0235 together take about 400MB when compared to a stock KSP 1.0.5 on Linux 64-bit + OpenGL. (Using the GCMonitor mod, version 1.3.0.0 to measure. Note that it shows VIRT.) Even on 64-bit Linux, memory is a problem - there are just too many good mods available for KSP. Glad to have the problem that way around, though (Unity crashes when the virtual address space ("VIRT", not the actual physical RAM used) exceeds 16GB. This often happens at under 8GB of actual RAM usage (resident size, "RSS" - nothing to do with Real Solar System).) I'd say it's a safe bet to say that large part packs consume the most memory, but judging by the folder sizes under GameData, Scatterer and EVE also seem to be among the most memory-hungry mods. They look gorgeous, though.

I'm getting this, too. Rolling back to 1.05-3 solved it. No clouds in the main menu, but everything else seems to work. (Alternatively, you might want to try your luck with the dev version.)

Thanks for the feedback, I'll take a look once I get to the point where I can play with the JetWing again. You are correct though, the wing is intended to be assembled out in the field. Ok! One more question - any particular reason for using Atmosphere instead of IntakeAtm from Community Resource Pack? (Probably a technical reason I'm missing. Asking because Filter Extensions generates a separate category for the JetWing under Engines, due to the input resource combination not matching anything known by the config that comes with Filter Extensions (v2.4.1.3).)

Ok. Ah, ok. Fair enough. Only noticed KA this week when upgrading NF Makes sense. Thanks for the quick reply!

Ah, so this is the official return of the cool-looking hydrogen tanks! (Pun almost intended.) Found some minor bugs in v0.1.2: When Kerbal Atomics is present, the MRS Nuclear Quad Engine, 2.5m "Quad Nuke" (NB2mNuclearEngine) and LV-Nc "Mighty" Atomic Rocket Motor (RLA_small_ntr) remain as LqdHydrogen engines even if KerbalAtomicsLF.cfg from the Extras is installed. They are indeed converted to use LqdHydrogen by Kerbal Atomics; if KA is not installed, these engines use stock LF. A dummy KerbalAtomics/Patches/KerbalAtomicsNFE.cfg is enabled by default, with NEEDS[ADummyPack] and some blank configs. (The real one is correctly present in Extras.) As for mod compatibility, while many popular mods are already covered, noticed a gap: Mk2 Stock-a-like Expansion: AT-2 "Pluto" Atomic Rocket Motor (Mk2PLUTO, Mk2Expansion/Parts/Engines/PLUTO/part.cfg) is an NTR with stats similar to the stock LV-N, the main difference being that it comes in the Mk2 spaceplane form factor. There are some minor differences: it uses ModuleEnginesFX, and has maxThrust=80, heatProduction=332, fxOffset = 0, 0, 0, and a custom running effect (running_closed, defined in the same .cfg). I think this engine could use a hydrogen patch similar to the LV-N, and similarly for KerbalAtomicsLF.cfg for the hydrogen -> LF backconversion. Deep Space Exploration Vessels is another one, with the "Ace" ArcJet Rocket/motor (AJ5ArcJetEngine) and the Supernova Fusion Engine (WB8Supernova) always using LqdHydrogen (their default configuration), but this arguably makes sense - different technology not targeted by KA. The Supernova is obviously hydrogen-based, while the arcjet (judging by the Wikipedia description) could be either LqdHydrogen or LF, and the author has decided to go for LqdHydrogen. Overall, seems nice. Looking forward to employ these engines in new ship designs.

Hi, Is it just me imagining things, or has anyone else noticed that attached docking ports are not filtered out from the list that is cycled by the arrow buttons in the DPAI window? (Docked docking ports are filtered out correctly.) Attached means that the ports were docked right there in the VAB, and the ship launched that way. There is a technical difference in how KSP handles these cases, as was noted during the original dev thread for Connected Living Space. Noticed this after launching a two-section ship the lazy way using moar boosters (and in orbit, trying to dock another craft to it). DPAI 6.2 on KSP 1.0.5.

Ok, fair enough. I think I may stay on 1.0.5 for some time, as I suspect it'll take a while for the modders to update their creations There are some nice little old ones, such as SpeedUnitChanger, which has been abandoned since KSP 0.24.2, but which still happens to work in KSP 1.0.5. Rockets I'm fine with m/s, but cars are supposed to go km/h! (I may need to cave in and install MonoDevelop if some small but important abandoned plugin stops working due to the upcoming UI overhaul in 1.1...) I meant that Unity crashes at 16GB VIRT (also noted here and here). In my experience, RSS at that point is typically less than 8GB. (Running with 100+ mods including some large ones such as Mark IV Spaceplane System, Scatterer, EVE, DSEV, Buffalo, Near Future, SpaceY, ASET, etc.)

Hi, Just a quick bug report: on Linux 64-bit KSP 1.0.5, GCMonitor 1.3.0 shows VIRT correctly, but RSS (if enabled in the options window) is stuck at 1 MB. GCMonitor 1.2.7, which used to report only RSS, reported it correctly. Also, thanks for the work! The new GCMonitor with its VIRT display is much more convenient for predicting Unity crashes than running htop in a background terminal window and switching back and forth. (The 16GB VIRT limit just makes me wonder where the Unity devs got the 34-bit pointers...)

Oh, right, forgot to mention - with 0.022, ocean confirmed working here, too. Linux 64-bit, OpenGL, Nvidia. Thanks blackrack! Now... working ocean shaders, some blue sky above the EVE clouds, and no artifacts. I have to say I concur with Val and Jeb's assessment (in the first image): What's left of the spaceplane after splashing into the ocean at runway speeds. The crew wanted to see the waves up close!

Congrats for the new release! By the way, the JetWing seems really nice for a low-partcount vertical exploration solution. I totally missed it in 0.2.5, just noticed now when downloading the new release. Might need to re-spec my manned Duna mission to pack a few of these... I'm running into some small issues with the JetWing, but that may be caused by mod interaction or PEBKAC. I'll perform some more testing and get back on this. EDIT: Testing done: Turned out this was maybe 1/3 mod compatibility, 1/3 a case of using it wrong, and possibly 1/3 genuine small issues. Findings below. General I think the JetWing could use a separate README with instructions, maybe in the first post. It was surprising to (eventually) find the instructions in the changelog Typo in endEventGUIName for the kickstand ("kiststand") VAB/SPH The correct mounting procedure of accessories (in the VAB/SPH) could use instructions. Is the JetWing intended to be field-assembly-only, or are the accessories intended to be attachable in the VAB/SPH? In the VAB/SPH, on the left/right nodes of the JetWing, most accessories (mini jet engine, drop tank, parachute, cargo pallet) attach onto the top of the wing, while on the middle node, they attach onto the bottom (blocking the pilot "seat"). In each case, compared to the other accessories, the Outback container attaches on the exact opposite side of the wing surface (which to me looks more correct). If the JetWing itself is attached to something, the middle node becomes reserved/blocked. (Although node_stack_back and node_attach share the same position, they have different "up" vectors; this doesn't seem to help?) Short of using surface attachment, in the VAB/SPH there seems to be no way to place anything (except the Outback) onto the surface labeled as "Accessory mount" in the texture (and that only if the JetWing itself is not attached to anything). Symmetry (mode: mirror) does not want to work for placing the drop tanks to the nodes; when hovering the tank over the left/right node so that it "clicks" into place, symmetry switches off. (I have EditorExtensions installed if that matters.) Symmetry works when using surface attachment. The engine mode cannot be toggled in the VAB/SPH (the mode listed in the right-click menu won't change even if the toggle button is clicked). Toggling this in the editor could be useful for burn time estimates by KER, especially in mixed mode (both fuels). In-flight The drop tank decouplers actually decouple the drop tanks only if the tanks are attached to the nodes. If the tanks are surface-attached, nothing happens. The Kickstand toggle, even if configured into a custom action group (e.g. group 1), seems to force-reconfigure itself to the landing gear button upon launch. Having the possibility to put it in a different group could be useful for flying craft which carry JetWings to be detached later. The Decouple action can be fired again and again, even when the JetWing is not attached to anything, producing the decoupling sound and a puff of smoke. I suppose this is a side effect of how decouplers are implemented, given that in most other situations, decouplers end up on uncontrollable craft sections (and disappear from the staging diagram). I think I can see the intended use case here, though... reattach by magnet, and then fire decoupler again for the next flight? As indeed suggested in the README, the drop tanks require a fuel balancer mod. I suppose KSP itself does not provide a way to make the drop tanks drain first, since they're on the side stacks, whereas the engines are part of the JetWing itself, on the center stack? (Short of having a smaller fuel line part just for this... and that wouldn't work with KAS.) What is the Release button in the right-click menu supposed to do? Judging by the .cfg, it seems related to ModuleKISPartMount? I suppose it ejects all KIS drag'n'drop attached accessories? Mod compatibility KER seems to miscalculate the amount of monopropellant when cycling through the fuel setups, as if there was an extra 10 units of monopropellant somewhere on the craft. Tested with a simple craft with a Mk1 command pod, a stock girder, and a JetWing. (Yes, this is after accounting for the monopropellant in the Mk1 pod.) Take Command: boarding JetWing at launch time causes a misaligned navball. The "nose marker" points down (where the pilot looks) insted of forward (where the craft goes). This causes also control misalignment; the controls do the intuitive thing on the navball, so considering the mismatch, yaw and roll controls become swapped, and the roll directions flip. Boarding normally after launch with the stock mechanism, the navball is aligned correctly, so Take Command must do something differently. TextureReplacer's helmet reflections seem incorrect; a sideways kerbal silhouette is always seen on the helmet when viewed from front. This does not occur with the stock EAS-1 external seat. Maybe something has a different transform?

Ok! In case you want to add them, here, to save you some typing: // MRS Decoupler, 2.5m Stack, Slimline @PART[NBdecouplerSlim2m]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } // MRS Rocket Payload Bay, 1.25m @PART[NBcargoBay1m1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } // MRS Rocket Payload Bay, 2.5m Long @PART[NBcargoBay2m1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } // MRS Rocket Payload Bay, 2.5m Short @PART[NBcargoBay2m0]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Ah, I see. Thanks! Well, at least it's decidedly kerbal By its very presence in the part list, it also challenges the player to come up with a design that uses it. The monopropellant makes this a true challenge, since usually the RCS is in the last stage or two, which typically have the same size profile. Maybe it would make sense for a Mun rocket that may first need to dock with a space station (in case no one brought a screwdriver?) before firing the transfer stage...

Hi, A question - have you considered applying Take Command also to external seat parts added by mods? There's at least the EAS-2 Heavy Duty Command Seat in the classic Kerbonov pack, and the ATV Command Seat in Buffalo (0.2.5 and later). I think these could all be caught automatically by filtering for the KerbalSeat module in TakeCommand.cfg: @PART[*]:HAS[@MODULE[KerbalSeat]]:FOR[TakeCommand] { CrewCapacity = 1 MODULE { name = TakeCommand minimumCrew = 1 } INTERNAL { name = GenericSpace1 } } (At least by a quick test this seems to work.) EDIT: ah, I got beaten to it by ThatGuyWithALongUsername. Don't know how I missed that. Anyway, it would be nice to have the updated .cfg packaged officially, since at least two people have now come up with this improvement

Hi, Cargo bays with integrated ladders for laddering? Nice. I'm updating the configs that come with ConnectedLivingSpace for Papa_Joe, and I noticed Axial Aerospace Cargo Bays is not yet supported. What do you think, should the cargo bays be considered a passable space, or impassable? If passable, would you like to include a CLS config into this mod itself (I can make one, given below, it's just a short ModuleManager patch), or do you think it would be better to include it with CLS? // CLS config for Axial Aerospace Cargo Bays mini mod // 1.25M Cargo Bay @PART[125cbsimple]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } // 2.5M Cargo Bay @PART[25cbsimple]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } }

Hi, About the ConnectedLivingSpace config of MRS: Is the decoupler ("MRS Decoupler, 2.5m Stack, Slimline", NBdecouplerSlim2m) intended to be impassable, as it is? And how about the cargo bays? ("MRS Rocket Payload Bay, 1.25m", NBcargoBay1m1; "MRS Rocket Payload Bay, 2.5m Long", NBcargoBay2m1; "MRS Rocket Payload Bay, 2.5m Short", NBcargoBay2m0) The context for such a seemingly silly question is that I'm updating the configs that come with CLS for Papa_Joe. There is an optional "freedom" config provided in CLS, which makes some additional stock parts, such as decouplers, passable. Hence, if the MRS decoupler is intended as impassable by the MRS mod itself, then for consistency purposes, it could be a candidate for tweaking by the "freedom" config in CLS. As for the discussion above, are there replacements for the fractional jumbos in FTP? I've used them quite a lot, since in my opinion they look somehow cleaner than the stock 2.5m tanks. Maybe it's the wrinkly look of the Rockomax. If I had to pick one part in MRS I've never used, it would be the "MRS Decoupler, 3.75m to 2.5m Interstage Adapter" (NBinterstageDecoupler3m). Its combination of capabilities is pretty much unique, but I suppose I've never needed all three in the same place

I think it's EVE, it does this at least on OpenGL. This is related to Unity depth buffer precision being too low on OpenGL, requiring a workaround to avoid z-fighting. The workaround causes the black border around KSC. rbray mentioned something about this in November in his EVE thread. Can't find the original post now, but see e.g. [1] [2] [3]. (Relevant search terms: opengl, black, z fighting, offset)

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

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.

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

Hi, About the CLS config of DSEV - considering the part's usage, I think it would be useful to have surfaceAttachmentsPassable on WBI_SpinRing: MODULE { name = ModuleConnectedLivingSpace passable = true surfaceAttachmentsPassable = true } Currently the part is only axially passable. Also, both WBI_SpinRing and WBI_CounterTorqueRing have "Rotating Hub" as their title. It would be nicer to have no duplicate titles; may I suggest changing that of WBI_CounterTorqueRing to "Counter Torque Ring" or something similar?

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. 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. True. I think the main role of a switchable "Surface allows passable attachments" flag is to cater to different playstyles.

Wah?! Already done?! Seems you had more time for KSP this week than I did Excellent, this is pretty much what I had in mind. Some small things: WBI_BuffaloCab: for consistency with the stock cupola, I'd suggest making also "front" impassable (due to windshield). WBI_BuffaloCab: "bottom" and "top" behave the wrong way around: impassablenodes = bottom makes the roof impassable, but leaves the floor passable. The CLS config is correct; this behavior is caused by BuffaloCab.cfg. In BuffaloCab.cfg, the second (i.e. y?) coordinate for the "bottom" node is -0.626 (suggesting positive y = up), whereas in e.g. CrewCab.cfg and Wagon2u.cfg it is 0.626 (suggesting negative y = up). Switching around the names node_stack_bottom and node_stack_top in BuffaloCab.cfg should fix this. WBI_CrewCab does not have a "top" node, so impassablenodes = bottom is enough (unless you're going to add one later ). Tabs instead of spaces on the impassablenodes=... lines, whereas other lines are indented with spaces. One trailing whitespace after each PART line. Making these modifications (except the one that needs to be fixed in BuffaloCab.cfg), the config becomes: @PART[WBI_BuffaloCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom,front } } @PART[WBI_CrewCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom } } @PART[WBI_BuffaloAdapter]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[WBI_Tundra200]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = top,bottom } } @PART[WBI_Tundra400]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = top,bottom } } @PART[WBI_Wagon2u]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom } } EDIT: Tested these modifications and the one to BuffaloCab.cfg. Works correctly. Good point (implicit from configuration ) about the top hatch in WBI_BuffaloCab, I'd forgotten it had one in the IVA. Clearly I need to build more space trucks!

Hi Angel-125, I was going through the list of Connected Living Space configs for the parts I have installed, and noticed that Buffalo does not currently support CLS. Some context: CLS is a mod that adds immersion during missions, and some additional challenge to craft design, by imposing requirements on what kind of crew spaces are considered connected, i.e. traversable without EVA. With CLS, all parts (parts meant here in the VAB sense) are divided into crewable (have crew seats, Kerbals can stay there), passable (can be moved through, but cannot stay), and impassable (which, roughly speaking, is the default if there is no config). Another mod called Ship Manifest then overrides the stock crew transfer system, calling into the CLS API to determine crew space connectivity, and imposing passability restrictions if configured to do so. I think this adds to the fun of designing especially large craft so that all the important crew spaces can be reached internally. Both CLS and SM are currently maintained by Papa_Joe. My role in this is that I've been looking into adding/fixing the last few missing/incorrect configs. Which gets me to my question: Have there been plans to add CLS support to Buffalo, and/or is there interest for this? Buffalo is of course not typically used for building large craft, but in a game save which has CLS and SM enabled, just having them causes (by default) the connection between the command cab and the crew cabin to be impassable internally. I took a quick preliminary look at what would need to be done. Adding CLS support to some of the parts is simple, while others are more involved. Yet other parts, actually a majority of them, have no internal crew space or hatches, requiring no CLS config at all. These are the easily configurable ones, which would benefit from CLS configs: Buffalo Command Cab (WBI_BuffaloCab). This just requires a simple MM patch to add ModuleConnectedLivingSpace and configure which attach nodes should be passable and which should not. I think that (rather obviously) the door at the back should be internally passable to other parts attached to that node, while the other nodes should not, since the cab is cupola-ish and there are no other hatches. To make a config for this, I just need the name of the attach node corresponding to the door (figuring it's either "back" or "bottom", depending on the neutral orientation of the model). Buffalo Crew Cabin (WBI_CrewCab). This is also simple: four visible hatches: front, back, left, right. Top and bottom impassable. Here too, just the node names are needed. Buffalo Adapter (WBI_BuffaloAdapter). Non-crewable part with hatches, should be passable axially. Since the only attach nodes are placed axially, this should need just passable=True. Now we get to the difficult part(s) (pun intended): Tundra 200 (WBI_Tundra200) Tundra 400 (WBI_Tundra400) Wagon (WBI_Wagon2u) First, I'd like to ask what the design intent is: is there always a solid crew tube running through these parts, or is the full volume of the part taken up by fuel if it is configured for use as a fuel tank? I'm assuming that the internally accessible KIS storage can always be walked through (internal access being suggested by the absence of hatches on the outside). If there is always a crew tube through these parts, this is simple: these parts can be simply tagged passable via the axial nodes marked by the 1.25m circles, similarly to the "easy" parts, and we're done. But if the passability depends on the configured state, let's first consider the Tundra containers. These would need a way to switch their CLS config on the fly, depending on whether each particular instance is configured as a fuel tank or as KIS storage. The only way I can see that this could be done would be for WBIResource Switcher to call into the CLS API, telling CLS whether the part is now passable or impassable when the state changes. So this would require some coding. Finally, the Wagon adds the additional complication of inflatability. In this case the rules would need to be whatever they are for the Tundra container, plus possibly a check on whether the part is currently inflated or not, depending on whether a passable crew tube can fit there when the storage is deflated. (I.e. if it won't fit, then the part must be in the "inflated" state to be passable, in addition to any other restrictions.) If CLS for Buffalo is desirable, I can create the MM patches, but I'd likely need your help if WBIResource Switcher needs to be modified. Thoughts/comments?

Hi, I was going through the Connected Living Space configs of the parts I have installed, and noticed that the Mk4 'Thunderhawk' Cockpit (mk4cockpit-1) is currently not CLS passable, while the other Mk4 cockpit is. This is caused by MarkIVSystem/Patches/MkIVCLS.cfg having an incorrect part name (just mk4cockpit instead of mk4cockpit-1).

Thanks! This clears up at least my confusion 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.) 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.)

Hmm, why not. CLS configs are simple to make, I have the list right here, and better configs out of the box sounds nice. It should also minimize the need for local maintenance Once I have the configs done, where do I make a pull request? By the way, I noticed that Near Future and MRS don't seem to have CLS configs. The fact that they happen to work (with only a couple misbehaving parts) implies that the heuristics detect most of the parts correctly. What do you think - should we keep the status quo, or is it better to create an explicit config for all passable NF and MRS parts? (I.e. listing all passable parts, not only those that currently need patching.) Yeah, hex edits are like that Would be nice to find compact descriptions. My question was, does option 3 force passability on children, or does it simply enable the possibility of passable surface connections on that part (requiring option 2 to be set on each child to make the connection to that child passable)? P.S. Some missing details to last night's testing. Using Filter Extensions, crewed command parts were checked first, then crewed passenger parts. Then all parts in each form factor were checked, with the exception of radially attachable parts (but with some special cases such as docking ports). Buffalo was checked by filtering for manufacturer. I have the following part mods installed, so these can be considered checked. (Put into a spoiler to avoid wall-of-texting.) I'll need to do a second pass on DSEV, though - now that I think of it, I'm not completely sure if the spindle was configured correctly.