TranceaddicT

So, I'm gonna play dumb and ask how to use -mm-dump on a linux install

Maybe I'm blind but could someone explain the Difficulty/Performance Settings, what are "FlightData Multiplier" and "FlightData Engineer Multiplier"? The tooltip is a little obtuse (or maybe I am). EDIT: Nevermind, I spent the day reading up on everything.

If this is true (which I don't doubt), what did this do prior to update: @PART[*]:HAS[~name[RetroMk1inline],@MODULE[ModuleCommand],#CrewCapacity[*],~CrewCapacity[0],~author[*RoverDude*]]:NEEDS[TacLifeSupport]:AFTER[TacLifeSupport]:AFTER[SETIrebalance] { @RESOURCE[ElectricCharge] { @maxAmount = 205 @maxAmount *= #$/CrewCapacity$ @maxAmount += 310 @amount = #$maxAmount$ } } Does/Should it be split into multiple passes for each :AFTER?

Is there a way to force a cache? I used the cache to determine if my MMConfigs correct.

2 You can write a MMConfig that will move these anywhere you want them Something like: // Probodobodyne OKTO @PART[probeCoreOcto]:FINAL { %TechRequired = basicScience }

Bless you, sir and all you do. Thank you for the update.

What kind of movement has there been on the RT2 redevelopment and integration of CommNet Constellation v1.1.1 features?

1.3 so it should work on 1.1.3. I've found that sometimes if you wipe everything, reinstall KSP then add the mods things tends work.

So yeah, intuitively, you'd think `|` would work. Alas, the reality is a different beast. I bumped an (extremely old) issue on GitHub using this and my RF as examples. Also made note that the documentation is lacking in this regard.

YongeTech!! Holy crap is that old. Haven't seen that for about 2y. There must be something internal to YT that caused those to be put in an unused/able node.

So, for RealFuels' oxidizers (LOx, N2O4, HNO3, N2O, HTP, et al.), something like: @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[LqdOxygen|NTO|HNO3|NitrousOxide|HTP|N2F4|OF2|AK*|ClF*|FLOX*|IRFNA*|LF2],~useEngineResponseTime[True]]] and Monopropellents (Hydrazine, HTP, NitrousOxide, and N2) or Bipropellents (NTO/MMH): @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Hydrazine|HTP|NitrousOxide|Nitrogen|MON*|UDMH+NTO],~useEngineResponseTime[True]]]

Question: If you added :BEFORE[Squad] would this then add the useEngineResponseTime before any other mods (like RealFuels); thus making this usable in a heavily modded game?

If I'm reading correctly, for PARTS mk1pod|HeatShield1|parachuteLarge|radialDrogue|parachuteDrogue if these mods !CommunityTechTree,!SETIctt,!SETItechtree,!ETT,!OpenTree,!RP-0 are NOT (!) installed and UnmannedBeforeManned is installed make TechRequired = Those are techTree MMConfigs that create, shuffle and rename RnD nodes. So, basically, if you have any of those installed it will NOT change the tech required.

I'm not using RO/RSS and it works.

Yes. It is.

Noted. Changed BasePopulation.cfg Thank you.

Nice jog LinuxGuruGamer! The first thing that came to mind when I saw the name was Chekov saying 'Keptin". I know this is far far far out there but. after seeing the review, any plans for a slide show playback?

I happened to see this fly by in the log window. At the end of BasePopulation.log, I found this: Output log: [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'BasePopulation' [WARNING] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'BasePopulation' And, tracked it to BasePopulation.cfg @ ln 68 maxCrew = @/CrewSpace Is this an expected exception?

I have a question about SETIrebalance and (Semi)Saturable Reaction Wheels. In particular, I'm looking at the config of SXT375mProbe Here are the pertinent MMConfig codes: Here RW.cfg creates a new MODULE[RWSaturatable]. // RW.cfg @PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:FOR[RWSaturatable] { MODULE { name = RWSaturatable saturationScale = 10 // axis saturation limit is scale * avgTorque bleedRate { key = 0 0.025 0 0 // with 0% saturation, 2.5% of torque per second (0.25% total with the default scale of 10) key = 1 0.025 0 0 // with 100% saturation, 2.5% of torque per second (0.25% total with the default scale of 10) } torqueCurve { key = 0 1 -1 -1 // with 0% saturation, full torque key = 1 0 -1 -1 // with 100% saturation, no torque } } } Now, this is where I get confused. Here it seems SETI should either: 1) if RWSaturatable exists, SETI duplicates and renames MODULE[RWSaturatable] as MODULE[ModuleReactionWheel] or 2) if RWSaturatable DOES NOT (!MODULE[RWSaturatable]) exists, it just creates it. // SETI-GeneralSetting.cfg @PART[*]:HAS[@MODULE[RWSaturatable]]:NEEDS[RWSaturatable]:AFTER[RWSaturatable]:BEFORE[SETIrebalance] { @MODULE[RWSaturatable],* { @name = ModuleReactionWheel } } @PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:NEEDS[RWSaturatable]:AFTER[SETIrebalance] { @MODULE[ModuleReactionWheel] { @name = RWSaturatable %saturationScale = 10 !bleedRate,* {} bleedRate { key = 0 0.025 0 0 key = 1 0.025 0 0 } !torqueCurve,* {} torqueCurve { key = 0 1 -1 -1 key = 1 0 -1 -1 } } } These are creating the following entries in the respective config files. MODULE { name = RWSaturatable PitchTorque = 3 YawTorque = 3 RollTorque = 3 saturationScale = 10 RESOURCE { name = ElectricCharge rate = 0.25 } bleedRate { key = 0 0.025 0 0 key = 1 0.025 0 0 } torqueCurve { key = 0 1 -1 -1 key = 1 0 -1 -1 } } MODULE { name = ModuleReactionWheel saturationScale = 10 bleedRate { key = 0 0.025 0 0 key = 1 0.025 0 0 } torqueCurve { key = 0 1 -1 -1 key = 1 0 -1 -1 } } Is this the desired outcome? It seems that there is a duplication of MODULES. Again, I'm really confused about what is happening here.

So, you got me thinking. If you were right, there had to be something that created a workaround such that I do not experience your issue even though I have the exact same files for launchClamps. After digging, I think I found it. I created a MMConfig that added ModuleGenerator to command modules. @PART[*]:HAS[@MODULE[ModuleCommand]] { MODULE { name = ModuleGenerator isAlwaysActive = true OUTPUT_RESOURCE { name = ElectricCharge rate = 0.75 } } } Unfortunately, it also hits probe cores (fortunately, I designed for not having them) but, nevertheless, it's not something I desired. (This is what I initially tested your claim against knowing full well a command pod would have the generator.) Anyone have ideas how I can isolate this to only **manned** modules? I was thinking maybe working 'tag = unmanned' into it somehow.

Do you have a GitHub repository?

Neither makes a difference to the programming. They will be ignored.

You're right, I don't like how it deploys. So, yeah, I can accept there is no missing animation. Unfortunately, I don't know anything about graphics and animations. General Question: Would any one be able to alter that?

Is it me or is the Communitron HG-55 missing an animation? It seems to me that there should be an additional animation at the joint at the base of the antenna. This would allow the antenna to fold up for storage and extend out, away from the craft. In the spoiler there are three HG-55. On the right is the retracted state. At left-bottom is the current in-game extended state. At left-top is how I imagine it should look. (Note the square base would be lying flat; not 90-degree rotated)

I'm wondering if there is a way to incorporate creation of GroundStations into the TechTree. Much like MechJeb releases functionality SETI would "build" GroundStations. Here's my thought process: When we begin we have the KSC Mission Control. First, we research Tier 2 and build KSC Northern Control & KSC Mountains, since they're close-by and on the same continent. Next, we get build KSC NE Island at Tier 4. This is our first experience building something with more logistical requirements as it's not on our primary continent. With each successive even Tier (6,8,10) we build the next two stations further away in either direction (East&West). Would this be possible to do?