Fraz86

ModuleEnginesFX does exactly the same thing as ModuleEngines, except that it allows for fancier graphical effects. All engines added since 0.23 (i.e., RAPIER, both 3.75m engines, the new SRBs, and the Launch Escape System) use ModuleEnginesFX instead of ModuleEngines. Many mods use ModuleEnginesFX as well.

I have two issues to report: 1. Engines with ModuleEnginesFX instead of ModuleEngines are not currently supported. If I add ModuleEngineReliability to these parts, will it work as intended? Or will they need a separate (yet to be created) ModuleEngineFXReliability? 2. When I installed this mod, the dial at the top center of the screen (indicating vertical velocity) ceased to function, simply pointing to zero regardless of my velocity. Removing the mod fixed the problem.

Now that Spaceport is gone, is there anywhere else I can download this mod?

As I noted earlier, there were additional errors/omissions beyond the mismatched brackets.

SP+DRE.cfg has several errors: mk2Cockpit_Standard not supported (file uses deprecated name "mk2Cockpit") mk2Fuselage_L not supported (file uses deprecated name "mk2FuselageL_long") mk2Fuselage_Short_L not supported mk2Fuselage_Short_LFO not supported structuralWing2 not supported File has two entries for structuralWing1, adding a second (redundant) heat shield

I actually lean toward a single generic "Spare parts" resource. I think it's reasonable to assume that Kerbal engineers would fill the available storage space with an appropriate array of spare parts corresponding to the modules present on the craft. I'm not sure that making the player determine the ideal mixture of spare part sub-types really adds anything to gameplay. I also worry that having multiple spare part sub-types is ultimately just asking the player to slap on additional storage modules, leading to needless extra parts.

Outright disabling the command pod does seem like too catastrophic (and potentially irrecoverable) of a failure. Perhaps if just the SAS functionality could be disabled, that would be more reasonable.

Perfect, thank you!

Just to make sure I understand correctly: If I change the density, I will get more/less units of water (but the total mass will remain constant), or more/less mass of water (but the number of units will remain constant)?

If I use a different density for water, will the plugin automatically scale the number of units of water that are spawned when I "analyze" an asteroid, or will I end up with a total mass of water that is greater/less than what it's supposed to be?

I really like where this is going. In particular, I'm a big fan of the following: lack of catastrophic (i.e., immediately mission-ending) failures all failures are repairable via EVA (which has the added benefit of creating greater purpose for manned missions and EVAs) customizability via ModuleManager straitforward but realistic failure model in which there is some chance of failure at any time, and this chance increases with use

Thank you, it works perfectly! Would it be possible to remove the "Governor" button when "CalculateEfficiency = false", since it doesn't actually do anything in these modules?

I'll cast my vote against assumed passability; I like explicit, transparent configs.

Motokid is likely referring to the prior ShipManifest bug, in which TACLS resources would be duplicated when crew were transferred. I believe this issue is now resolved, and it was never related to CLS.

CLS is apparently checking whether or not a port is "docked", and then only displaying the "Open hatch" option if the port is docked. My proposal would be to disable this check, or to only check that the node is attached to something (not necessarily "docked").

If you attach 2 docking ports together in the VAB, the game does not recognize them as "docked" (they are instead viewed as 2 parts connected by an ordinary node/joint). As such, there is no option to open the hatches on these ports, and the connection thus remains impassable. The only solution is to decouple the ports and then re-dock them, which is obviously rather annoying.

Another bug report, not sure if this is new with v1.0.4.1 or an old issue: If I dispose of my root command module while the CLS window is open, the window basically freezes. It won't update when I select a new root part, nor can the window be moved or closed.

FYI, the tooltip descriptions in the SPH/VAB don't like modules defined as "passable = true, impassablenodes = top". The description says that the module is passable through all nodes, even though in-game it functions as intended (only the bottom node is passable). Defining the passable and impassable nodes explicitly (without "passable = true") seems to avoid this problem (i.e., "impassablenodes = top, passablenodes = bottom").

Version 1.0.4.1 breaks passability for any part in which at least one (but not all) nodes are meant to be impassable. For example, the copula module is meant to be passable through the bottom but not the top. With v1.0.4.1, it is not passable through either node. The same problem occurs for any similarly configured part. I have copied the pertinent excerpt from CLSStock.cfg below: @PART[cupola]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace impassablenodes = top } } UPDATE: Thankfully, it appears this problem can be fixed with a few simple config edits. Basically, previous versions of CLS assumed that "passable = true" for crewable modules, with the exception of any nodes explicitly defined as impassable. Version 1.0.4.1 no longer makes this assumption. Thus, parts like the copula now need to have their passable nodes explicitly defined. For example, the following correction will fix the copula: @PART[cupola]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace impassablenodes = top passablenodes = bottom } }

Yes, there's a new radial intake, but I think it may be a WIP that PorkJet accidentally released early. As you point out, there haven't been any pictures or mention of it, and as alephzorg said, the orientation is wrong to work for symmetry in the SPH. That said, it looks nice, and the orientation can be fixed with a MM config containing the following: @PART[IntakeRadialLong]:Final { !mesh = DELETE MODEL { model = SpaceplanePlus/Parts/RadialIntakeLong/model rotation = 0, 90, 90 } }

I agree. I realize BahamutoD merely threw it together as an example, but if he polished it up a bit, it would easily be my favorite landing leg.

I have a small request, if it isn't too much trouble. I play with TACLS, with extensive personal customizations via ModuleManager config files. I've been integrating elements of your mod, which I greatly enjoy, into my customized crew support system. In particular, your KolonyConverter module has been a great asset to my endeavors, due to it's very useful features (i.e., requiredResources, SurfaceOnly option, efficiency based on crew). However, in some situations, I'd like to be able to create a module with requiredResources or SurfaceOnly, but without efficiency based on crew. Thus, if this would be easy for you to implement, I would greatly appreciate an "EfficiencyBasedOnCrew" boolean as a variable of the KolonyConverter module.

I would recommend against requiring crewable parts to have an IVA model in order to function properly. Many mods add command modules with no IVA. It seems to me that CLS and ShipManifest should refer to the variable "CrewCapacity" to determine the number seats available, and that CLS should deem a part "crewable" if CrewCapacity > 0. If an IVA model is available, then the Kerbal portraits should be updated as appropriate, but I would recommend against any dependency on portraits or IVA models. However, if there's truly no other way around this issue, and all crewable parts need to have IVAs in order for CLS and ShipManifest to function properly, then I would recommend a MM config to add IVAs to all parts with CrewCapacity > 0. If it's important that the number of IVA seats match the intended capacity, then I suggest something like this: @PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[1]] { INTERNAL { name = landerCabinSmallInternal } } @PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[2]] { INTERNAL { name = landerCabinInternals } } @PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[3]] { INTERNAL { name = PodCockpit } } @PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[4]] { INTERNAL { name = crewCabinInternals } }

Could you elaborate on the above? Kerbals ought to be able to transfer to or from any crewable part regardless of whether or not it has an IVA. The lab in particular actually requires Kerbals in order to function, so I hope you're not saying that we won't be able to use ShipManifest to move crew into the lab.

So, while the resource consumption is updating at an accelerated rate of 24-hours-worth-of-consumption per tick, is the recycler activity accelerated to the same rate?