TranceaddicT

Nothing; bare file. Just thought you should know.

Yeah, I deserved that.

Here is a link to the log file. https://drive.google.com/file/d/0B7arxv3DfQDlcW44LU9GSmZhcGc/view?usp=sharing New Persistance file, the thing the game saves to. Literally, a brand new game with only slingshot installed will recreate. Edit: (Not trying to come off snotty.)

[EXC 20:58:08.262] NullReferenceException: Object reference not set to an instance of an object KerbalSlingshotter.SlingshotCore.WindowGUI (Int32 windowID) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) System: Linux Jupiter 4.10.0-33-generic #37-Ubuntu SMP Fri Aug 11 10:55:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Recreate: New persistance. Enter TrackingStation Click Slingshotter Exceptions with be thrown until exiting.

No, I was referencing attaching objects (antennae) to the surface of the research core. After reviewing the .cfg, I see that you have 'attachRules = 1,1,1,0,1'. A simple MMconfig can make that change for me. @PART[ResearchCore]:FOR[MissionController2] { %attachRules = 1,1,1,1,1 }

Has anyone run across surface attach problems with any of the cores, in particular, the research core?

ACE: The only draw back to this is that it does not modify the floatCurve of a part. I've confirmed with @sarbian that is is meant as an in-game version of FloatCurve editor 1.0. It doesn't actually implement any changes to a part. delayedSepratron: I was really looking for a possible solution to an 'real' delay. Unfortunately, thrustCurve does not allow for this possibility. Fortunately, I found [1.0.4] Smart Parts v1.6.6 for exactly what I want ... a true firing delay of 1s.

To be clear, this does not read any curve data from a part's configuration file. It's basically an in-game version of r4m0n's Unity plugin, right?

Thanks guys!!! Just an FYI, for those of us on linux it's RShift+F11 and the folder is _MMCfgOutput

@sarbian I've downloaded your latest version (1.1.1.0) and setup a KSP_testing install with only ACE installed. When I activate ACE [RightShft+P] in the VAB, I get the window as noted. Unfortunately, this is where the functionality ends in the VAB. I cannot 'Add Node', 'X-Remove', modify values. (Oh, I can drag it around the screen.) Yet, it does function in flight mode. Am I missing something? Is this not supposed to/cannot function in the VAB?

I'd like to see the configuration used for a part that I have added based on a MMConfig. Is there a way to view the active configuration file of a part while the game is running?

@Enceos Thanks for that. That's what I was thinking; went nuts trying to find something about ModuleSRBthrust. I even installed Unity and downloaded the FloatCurve editor 1.0 by @r4m0n At least after all that, I've learned more than enough about all the various floatCurves.

@Enceos Bravo. Bravo!! Well done, Sir. This is going on the list of must-haves; right there with MechJeb, KER, et al.

I figured it out!!! The MMconfig was doing everything correctly. The problem was in the persistent.sfs ResearchAndDevelopment scenario. Since I had already run KSP pre-config, the parts were already written to the generalRocketry node. Once I deleted them directly and restarted anything that had not been altered by the MMconfig was, once again, added back to generalRocketry; however, the parts (above) that were altered were placed correctly.

Tried that. No joy. Tried : TechRequired = [destination] @TechRequired = [destination] %TechRequired = [destination] even tried : !TechRequired = [destination] /@/%TechRequired = [destination] and : -TechRequired = [destination] /@/%TechRequired = [destination] Still, no joy.

Okay guys, I've been beating myself up trying to understand ModuleManager and I'm at my wits end. I'm simply trying to move the RN_US_Probes around and out of the generalRocketry node. Unfortunately, all I've done is duplicate the parts in the desired nodes, but I've not eliminated them from generalRocketry. Below is the MMconfig I'm using for the Galileo probe: From the literature, I was under the understanding simply that using a % would replace. Let the edumkating begin. //Galileo Satelite @PART[gdish_actual] { %TechRequired = largeCommunications } @PART[gdish_intended] { %TechRequired = largeCommunications } @PART[galileo_mb] { %TechRequired = advUnmanned } @PART[galileo_aprobe] { %TechRequired = advUnmanned } @PART[galileo_probe_parachute] { %TechRequired = advUnmanned } @PART[galileo_aprobe_bot] { %TechRequired = advUnmanned } @PART[galileo_hs_bot] { %TechRequired = advUnmanned } PART[galileo_hs_mid] { %TechRequired = advUnmanned } @PART[galileo_hs_top] { %TechRequired = advUnmanned } @PART[galileo_probe_hs_parachute] { %TechRequired = advUnmanned } @PART[rn_galileo_scanner] { %TechRequired = advUnmanned }

Fantastic. I look forward to breaking it.

I can run both a clean install and a heavily modded install for testing, if you like.

I don't know about the RD-191, but the SSMEs are throttleable to 109% not because they are over-driving the engines. It's because of design enhancements made over the course of the years. The original SSMEs are based on the RS-25. Over the years, there have been the RS-25A, B, C and (bloody) D. With the A upgrade, instead of re-writing everything for a new thrust value of 100%. NASA decided to keep the old everything the same and change the engine output to greater than 100%. Also, he D can actually be pushed to 111% in the event of an emergency. "Specifying power levels over 100% may seem nonsensical, but there was a logic behind it. The 100% level does not mean the maximum physical power level attainable, rather it was a specification decided on during engine development—the expected rated power level. When later studies indicated the engine could operate safely at levels above 100%, these higher levels became standard. Maintaining the original relationship of power level to physical thrust helps reduce confusion, as it created an unvarying fixed relationship so that test data (or operational data from past or future missions) can be easily compared. If the power level was increased, and that new value was said to be 100%, then all previous data and documentation would either require changing, or cross-checking against what physical thrust corresponded to 100% power level on that date." History of Liquid Rocket Engine Development in the United States 1955-1980 (California Liquid Rocket Propulsion History Colloquium, Aas Annual Meeting, Los Angeles, Astronautical Society Series, Vol 13) by Stephen E. Doyle

Malkuth, Love this idea with the repair panels. I do have one gripe, why are the panels not initially fully stocked? Is this a correct MM cfg for making that change? (I'm still new to using MM) // Fully stock Repair Panels by default. @PART[SmRepairPanel] } @RESOURCE[SpareParts] { %amount = 1 } } @PART[repairPanel] } @RESOURCE[SpareParts] { %amount = 1 } } Thank you for all you do. You make this game better.

One word: Tweakscale.

I'm having a little problem with TestFlight. It seems that information provided in the VAB is being repeated. This is happens in all my installs; including this clean install with ONLY TestFlight and ModuleManager installed. Also, did you remove the R&D functionality? I no longer have this option available within the VAB.

COMPATIBILITY • Kerbal Space Program : 1.0.5 (x86 only - x64 is not supported at all)

Any chance of a Linux port?