Fraz86

For the LifeBoat module, instead of ad hoc variables like "oxyAmount," why not use something like: MODULE { [INDENT]name = LifeBoat RESOURCE { [INDENT]name = Food amount = 1[/INDENT] } RESOURCE { [INDENT]name = Water amount = 12[/INDENT] } RESOURCE { [INDENT]name = Oxygen amount = 15[/INDENT] } RESOURCE { [INDENT]name = MonoPropellant amount = 4[/INDENT] }[/INDENT] } This would allow the LifeBoat module to be configured for life support mods that use a different set of resource names.

Ah, I see, my mistake. I understand, and I do think it's a neat feature, it's just that enforcing "passability" for non-EVA transfers is basically the only existing purpose for CLS, and I happen to enjoy that game mechanic.

Two comments: 1. The alternate textures you provided are .png whereas the originals are .tga. Thus, using them requires editing the models in a hex-editor. 2. CLS users (myself included) may consider the evacuation feature to be a "cheat", in that it allows instant non-EVA transfer regardless of the presence of CLS "passability" between the modules. I would appreciate an option to disable this feature, or (ideally) to make it "CLS aware" (i.e., if CLS is installed, evacuation is only possible if the escape pod shares a "Living Space" with the module being evacuated).

RoverDude, In RealChute.cfg, replace "@PART[uSI_PodEngine]:FOR[RealChute]" with "@PART[uSI_PodEngine]:NEEDS[RealChute]".

Wow, I love the alternate textures! Can't wait!

Any chance of configuring the Tesla recon rover to function with the new JSITransparentPod as an alternative to the sfr plugin?

Thanks for the update! I have no idea if this is even possible, but I would love to have "flowMode = CLS_ONLY" (i.e, the resource is transferable only within a connected living space) as an option for resource definitions. Such an option would be perfect for certain life support resources, such as food, which logically ought to follow the same transfer restrictions as Kerbals.

I have encountered a bug that can be recreated as follows: 1. In the config file of any part that is grabable and storable, set "stateless = false" in KASModuleGrab. 2. In the VAB, add an instance of this part to a container. 3. Spawn the craft, take a Kerbal EVA, open the "Container contents" dialogue, and click "Take" for the part in question. 4. Click "Store." 5. Click "Take" again. The 2nd time the part is taken from the container, it will drop to the ground, and there will be no option to grab the part. The option to "Attach" remains in the GUI, and functions as intended. An option to "Drop" is also listed, but appears to do nothing. There is no apparent means by which this part can be picked up by a Kerbal or returned to the container. Strangely, the part behaves completely normally the first time it is taken from the container; these problems emerge only after it has been stored and taken again. Also, making "stateless = true" completely resolves the problem. Any ideas?

I'd rather not make SolidFuel a pumpable resource; that would definitely feel like cheating to me. I like the requirement for an EVA Kerbal to manually refuel the landertrons, I just don't like dependencies on other plugins unless completely necessary. Ah, thank you! The duplicate Landertron.dll from HGR was the culprit.

For whatever reason, the landertron's animations don't seem to be working correctly for me. The larger radial engine starts deployed and remains deployed, while the other two start retracted and remain retracted. They all seem to function as intended (the retracted landertrons will actually fire despite appearing to be closed); it's solely an animation problem. Also, BahaD's standard (non-landertron) engines animate just fine, so it seems to be a problem specifically with the landertrons.

The update looks great! Any chance you could include a config option for non-KAS refueling? Similar to how refueling worked before the update (i.e., requiring EVA, but not actually moving any parts), for those of us who don't use KAS?

Do Landertrons work with RemoteTech2 in situations with signal delay?

RoverDude, Great mod, but I noticed the airbags have "PhysicsSignificance = 1." Is this necessary in order for them to function correctly? If so, that's quite unfortunate, as I prefer not to use magical massless, zero-drag parts.

XkaOnslaught, What am I looking at here? Are those nozzles of a quad engine? Or something else?

joed_, I certainly don't mean to be a nuisance, but I was wondering if you might comment on the feasibility of my earlier request, that the "Transfer [name]" button only appear when two parts are selected. Cluttering the context menu with useless buttons is the only thing holding me back from whole-heartedly embracing your mod. I believe several other commenters have endorsed this suggestion as well. Thank you very much for your work on this mod.

Excellent, I look forward to it! Will this update include passability for docking ports attached in the VAB?

I'd like to second this request!

Does anyone have a screenshot of the bunker's IVA?

I have a request: I use TacGenericConverter for a wide variety of custom modules, primarily because it handles resource consumption and production at high time warps far more reliably than the stock ModuleGenerator or generator modules found in other mods. In some cases, there is no conceivable reason to ever turn the generator off, and therefore the button just adds clutter to the part's context menu. I would love to be able to add "alwaysOn = true" in the config to remove the button.

Are there any config file edits I could make to allow passage through connected docking ports? Even if it involves removing the "hatches" functionality altogether, I'd much rather just have a functional connection. Un-docking and re-docking may sound like a trivial nuisance, but I've run into several situations in which it's been a substantial source of frustration. The game doesn't allow immediate re-docking; the docking ports are required to move a minimum distance apart before they can re-dock. In certain designs, such as with cargo bays or saddle truss payloads, there often isn't enough room to simply back up and then re-dock. Instead, I'm forced to maneuver all the way out of the bay and back in, consuming significant monopropellant and time.

joed_, Could you make it such that the "Transfer [name]" button doesn't appear on the context menu unless two parts are selected, similar to how the "In" and "Out" buttons don't show up with a single part selected? I like to keep the context menu clutter to a minimum.

CLS will affect existing craft, but you could either: 1. Don't install CLS, or 2. Install CLS and edit the CLS config files to make modules passable as necessary for the design of your station.

HeadHunter, Are you right-clicking the first pod, then hold-alt + right-clicking the second pod?

I noticed the OP was updated with the reason listed as "new version," and strikethrough of the text regarding CLS. What changed in the new version? Was support for CLS removed?

Just my opinion of course, but I dislike the hatch texture on the top of the Soy Juice. It's significantly smaller than other hatches (which are typically just under 1.25m in diameter). I believe it looks much better with a standard sized hatch, like below: