Fraz86

I use the latest MJ dev build (240) along with OrbitalDebris' corresponding recompile of RPM and MechJeb2RPM, and ProbeControlRoom works perfectly fine for me.

Would you mind elaborating on this? Does this mean that resource production/recycling is or is not calculated for unloaded vessels?

You're missing a "}" in the config for dockingkso.

I do not use Hotrockets, nor do I use this mod yet. However, after taking a look at the config files, I do not believe this mod is compatible with Hotrockets or any other parts that use the ModuleEnginesFX module. I presume this would be easy enough for IRnifty to fix; he just needs to create a corresponding ModuleEngineFXReliability module. EDIT: I would also like to point out that, while this mod would have substantially better compatibility with other mods if it added a ModuleEngineFXReliability module and used MM as I outlined above, anything that renames stock modules (ModuleDecouple, ModuleLight, ModuleEngines, ModuleEnginesFX) is inherently going to have some compatibility limitations because once those modules are renamed, any other mod attempting to find those modules won't be able to do so. This problem could be somewhat mitigated by making sure that renaming the modules takes place last (by adding the ":FINAL" flag) so that other mods have the opportunity to make their changes first.

I hope I'm not just stating the obvious, but wouldn't it be trivially easy to use a ModuleManager file to replace the relevant module names without needing to replace the entire part? See below: @PART[*]:HAS[@MODULE[ModuleDecouple]] { @MODULE[*]:HAS[#name[ModuleDecouple]] { @name = ModuleDecouplerReliability } } @PART[*]:HAS[@MODULE[ModuleLight]] { @MODULE[*]:HAS[#name[ModuleLight]] { @name = ModuleLightReliability } } @PART[*]:HAS[@MODULE[ModuleEngines]] { @MODULE[*]:HAS[#name[ModuleEngines]] { @name = ModuleEngineReliability runningChanceToFailPerfect = 0.00001 startingChanceToFailPerfect = 0.01 runningChanceToFailTerrible = 0.025 startingChanceToFailTerrible = 0.875 reliabilityDrainPerfect = 0.001 reliabilityDrainTerrible = 0.025 } } @PART[specific_engines_to_be_given_nondefault_values] { @MODULE[ModuleEngineReliability] { @runningChanceToFailPerfect = nondefault_value @startingChanceToFailPerfect = nondefault_value @runningChanceToFailTerrible = nondefault_value @startingChanceToFailTerrible = nondefault_value @reliabilityDrainPerfect = nondefault_value @reliabilityDrainTerrible = nondefault_value } }

I think that's an excellent decision. Outright replacing the stock docking port module would likely continue to cause a variety of unexpected problems, as well as creating incompatibility with other mods that interact with docking ports.

The "#" preceding "name" signifies to ModuleManager that I'm looking for the value of a variable named "name". This accomplishes almost the same thing as: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode] { @name = ModuleDockingNodeHatch } } Except that the above will only look for the first module named ModuleDockingNode, rename it to ModuleDockingNodeHatch, and then move on to a different part. @MODULE[*]:HAS[#name[ModuleDockingNode]] should (I think) find all modules named ModuleDockingNode within a given part. Also, just to help with troubleshooting, the change in behavior that you observed relative to your development version is not caused by the ModuleManager update. Every version of ModuleManager going all the way back to when wildcards were first introduced would have interpreted that file the same way: find all parts containing a module named ModuleDockingNode, and rename the entire part (not the module) to ModuleDockingNodeHatch.

My aforementioned fix (see below) appears to work as intended, except that I don't see any option to open the hatch in game. @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[*]:HAS[#name[ModuleDockingNode]] { @name = ModuleDockingNodeHatch } }

Will this release fix the non-updating inflatable habs problem?

As I posted in your development thread, the problem is your "CLSAddHatchesToDockingNodes" file, which renames the docking parts themselves instead of replacing the docking module. This essentially breaks docking ports. See below: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @name=ModuleDockingNodeHatch } I believe the following replacement should work as intended: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[*]:HAS[#name[ModuleDockingNode]] { @name = ModuleDockingNodeHatch } } However, this change does not seem to entirely fix the problem. Right-clicking a docking port reveals "Hatch: closed", but I don't see any option to open the hatch. Unrelatedly, I also noticed that you do not appear to have included any configs for radial attachments.

@PART[*]:HAS[@MODULE[ModuleDockingNode]] { @name=ModuleDockingNodeHatch } The above code renames the part itself to "ModuleDockingNodeHatch" (which is very bad) rather than replacing the ModuleDockingNode as you intended. Instead, it should read: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[ModuleDockingNode] { @name = ModuleDockingNodeHatch } } EDIT: My above replacement still won't work properly for parts that have multiple docking nodes, such as Porkjet's Flat Hab. Perhaps the following will work, but I need to test it: @PART[*]:HAS[@MODULE[ModuleDockingNode]] { @MODULE[*]:HAS[#name[ModuleDockingNode]] { @name = ModuleDockingNodeHatch } }

No problem, I'm happy to help. Let me know if there are any other tests I could attempt that would be of value to you.

This version does not allow transfer to inflated habs. Also, I tried exiting the scene to the Space Center and then returning to the craft. The inflated habs were still not available for transfer, and the following message popped up in the debug window upon entering the scene: Error: in SetResourceHighlighting. Error: at (wrapper managed-to-native) UnityEngine.Transform:Find (string) at UnityEngine.Transform.FindChild (System.String name) [0x00000] in <filename unknown>:0 at Part.FindModelComponents[Renderer] () [0x00000] in <filename unknown>:0 at Part.highlight (Color highlightColor) [0x00000] in <filename unknown>:0 at Part.SetHighlight (Boolean active) [0x00000] in <filename unknown>:0 at Part.SetHighlightDefault () [0x00000] in <filename unknown>:0 at ConnectedLivingSpace.CLSPart.SetHighlighting () [0x00000] in <filename unknown>:0 at ConnectedLivingSpace.CLSPart.Highlight (Boolean val) [0x00000] in <filename unknown>:0 at ConnectedLivingSpace.CLSSpace.Highlight (Boolean val) [0x00000] in <filename unknown>:0 at ShipManifest.ShipManifestBehaviour.SetResourceHighlighting () [0x00000] in <filename unknown>:0

Yes, see below: @PART[mk2Cockpit_Standard] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2Cockpit_Inline] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CrewCabin] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_Adapter] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_AdapterLong] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_Bicoupler] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2FuselageL_long] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2Fuselage_LFO] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CargoBayS] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CargoBayL] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[deltaWingX] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 26 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[structuralWing1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 44 //Angle of line from mid root chord to mid tip chord b_2 = 1.88 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[wingStrake] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 62 //Angle of line from mid root chord to mid tip chord b_2 = 0.94 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[structuralWing2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 1.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 13 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 0.16 //Ratio of tip chord to root chord } } @PART[wingConnector1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 4 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 0 //Angle of line from mid root chord to mid tip chord b_2 = 1.88 //Root to tip in meters TaperRatio = 1 //Ratio of tip chord to root chord } } @PART[wingConnector2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 0 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 1 //Ratio of tip chord to root chord } } @PART[elevon1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.5 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = 0 b_2 = 1.8 TaperRatio = 1 } } @PART[elevon2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.62 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = -4 b_2 = 1.8 TaperRatio = 0.67 } } @PART[elevon3] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.86 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = -4 b_2 = 1.8 TaperRatio = 0.75 } }

That very well may be the case, but I'm simply following instructions. To quote from ModuleManager's opening post: !foo = DELETE deletes foo completely.

I just checked, and 3.1.5 immediately adds newly inflated habs to its transfer locations list.

FAR support: @PART[mk2Cockpit_Standard] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2Cockpit_Inline] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CrewCabin] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_Adapter] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_AdapterLong] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2_1m_Bicoupler] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2FuselageL_long] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2Fuselage_LFO] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CargoBayS] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[mk2CargoBayL] { @module = Part !dragCoeff = DELETE !deflectionLiftCoeff = DELETE } @PART[deltaWingX] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 26 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[structuralWing1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 44 //Angle of line from mid root chord to mid tip chord b_2 = 1.88 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[wingStrake] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 62 //Angle of line from mid root chord to mid tip chord b_2 = 0.94 //Root to tip in meters TaperRatio = 0.08 //Ratio of tip chord to root chord } } @PART[structuralWing2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 1.16 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 13 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 0.16 //Ratio of tip chord to root chord } } @PART[wingConnector1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 4 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 0 //Angle of line from mid root chord to mid tip chord b_2 = 1.88 //Root to tip in meters TaperRatio = 1 //Ratio of tip chord to root chord } } @PART[wingConnector2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 MODULE { name = FARWingAerodynamicModel MAC = 2 //Mean chord length in meters e = 0.75 //Drag per lift, lower equals more drag MidChordSweep = 0 //Angle of line from mid root chord to mid tip chord b_2 = 3.76 //Root to tip in meters TaperRatio = 1 //Ratio of tip chord to root chord } } @PART[elevon1] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.5 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = 0 b_2 = 1.8 TaperRatio = 1 } } @PART[elevon2] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.62 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = -4 b_2 = 1.8 TaperRatio = 0.67 } } @PART[elevon3] { @module = Part @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 MODULE { name = FARControllableSurface MAC = 0.86 e = 0.9 nonSideAttach = 1 maxdeflect = 20 MidChordSweep = -4 b_2 = 1.8 TaperRatio = 0.75 } }

I'm writing a ModuleManager file to provide FAR support for Porkjet's wings, and I have a config question. Two of Porkjet's control surfaces are angled, as seen here (bottom right): I'm wondering how FAR handles non-zero MidChordSweep and TaperRatio other than 1 for parts that are "nonSideAttach = 1". In plain English, I'm curious if/how the plugin knows which end of the control surface is the "root chord" versus the "tip chord" when, unlike wings, the root chord is not the attachment site. Does it even matter? Should I just pretend the parts are flat across the back?

If you turn off CLS integration in the config, ShipManifest will work exactly as you describe. CLS itself doesn't actually do anything, so if remove its icon from your toolbar, it's basically as if CLD isn't even installed. Technically it continues running in the background, but has no effect on gameplay other than consuming some small amount of memory.

I'll test it when I get home. Also, I'm curious, what do you mean by scope for parts? My programming knowledge is limited, but given that CLS is already adding the module to a living space in real time, shouldn't there be some way for ShipManifest to simply refer to or "mirror" the CLS list of connected habitable modules with minimal burden on memory? In other words, the necessary monitoring of dynamic parts is obviously already taking place within CLS, and I would imagine there must be a way for ShipManifest to utilize this efficiently, without a need for redundant memory-intensive updating, right?

Has anyone managed to put together a ModuleManager file to configure Porkjet's wings for FAR?

Sounds like a logical approach. However, I would appreciate an option to globally disallow surface attachment for CLS. I like the idea that modules were engineered with hatches in certain locations, and I enjoy this as an important design consideration/challenge. Moreover, consistency with IVA is important to me, and IVA only depicts hatches existing at nodes.

The TACLS resource duplication bug appears to be fixed in this version. However, in the course of my testing I identified a different, equally problematic bug. ShipManifest does not seem to recognize the change in status of "deployable" living space modules, such as PorkJet's inflatable habs. In CLS terms, these habs begin as "passable" but without room for Kerbals to stay. Once inflated, the habs have space for Kerbals. CLS correctly identifies this change, with the habs immediately changing from yellow (passable) to green (habitable) when inflated. Unfortunately, though, the newly inflated hab is not added to ShipManifest's list of crew transfer locations.

Absolutely, I'd be happy to help with troubleshooting.

Until you find a permanent solution, would you consider releasing an alternate version without the EVA & board actions for those of us who use TACLS but not texture replacer?