Crzyrndm

Na, if you want individual control surfaces to react differently at different times, that's way outside PA scope. I do have an idea how I could do it, but it'd definitely be a standalone plugin

The major recent change was to heading (to make it a direction lock). Which control axis thows a tantrum as you engage (I'm guessing yaw output is going to be stupid high)? How are you engaging SSAS control?

Thanks for the heads up. I'll have a look when I get back to dev PC (sounds like it could be a nasty one though :/) - - - Updated - - - Hang on, in the editor you say? Nothing even happens in the editor...

It has a gain and reference altitude to tweak how much it reduces inputs, but I don't use it so I have no idea how those work (once active it just applies a multiplier to all control inputs, nothing more) Changing the response of individual control surfaces according to speed and altitude sounds like an interesting mod to make though...

Hue/Saturation/Brightness control the colour (should be right under opacity if this image from the OP still applies) FAR has a control assistant labelled as DCA for this purpose (reducing control input when dynamic pressure is high). Your only other option is fine control (caps lock)

There is no way that I know of to disable control surfaces from reaction to input: stock, modded, or otherwise.

That would be a no (to my knowledge atleast)

It's not one with a default (defaults are indicated by [bool id = false] for example) so no it won't work (although if that bool does what it says it does, it makes the plugin all of about 2 lines...). (E: nvm, seems the git version is 0.90 updated) You make me feel better now

Oops, totally didn't even notice the dates... part.SetHighlight has a second boolean now so I doubt it'll run (part.SetHighlight(bool active, bool recursive))

Module manager patch to duplicate a part and change the propellant it's engine uses +PART[<originalPartName] // the '+' operator duplicates { @name = <newPartName> // each part needs a unique name field @title = <newPartTitle> // new name for the part in game @MODULE[ModuleEngines] { !PROPELLANT[<PropellantNameToRemove>] {} // remove the existing PROPELLANT node PROPELLANT // add a new one { name = <PropellantNameToAdd> ratio = 1 } } // etc. } You can add a MultiMode Engine if you only need two modes (take a look at how the Rapier is set up), for more you'll need a plugin I believe (EDIT: not MM)

previous page, ippo wrote a short plugin to forcibly remove it

1) Can't really be done in 0.90, but if it is more accessible post 1.0 I wouldn't expect to wait long before someone does this (packaged upgrades are stupid, the faster they become granular the better) 2) I think Kerbal Construction Time may already include this, and it's configurable enough you should be able to remove most of it's other functionality

Thanks to a tip from ferram4, this is now "working as expected" (the numbers are a bit fudged at the moment so it isn't perfect but things atleast move in the correct direction ) NOTE This can have a serious impact on stability of existing craft. You may want to deorbit any existing designs before changing, and double check stability of existing design afterwards

That sounds like the missing element. So it needs to update this as well as the shape parameters I assume. Thanks for the help

@ferram4 Attempting to debug this issue with B9 PWings and FAR (increasing the size of the trailing edge moves the CoP indicator towards the leading edge (compared to a stock wing of the same dimensions as well)). From what I can tell, the parameters being passed to FAR (MAC and surface area being the relevant ones, semispan, sweep, and taper ratio don't change with a rectangular section) are all correct. That leaves me wondering how FAR determines where the wing is located (ie. how does it determine only the back/front edge is changing instead of a symmetric change around the attachment point).

You probably have some trim active. Modifier + X will clear all trim (Modifier is RShift on Linux IIRC)

The config node that's passed to OnLoad isn't invalid (or atleast, it has nothing to do with the error). It errors when you call: KSP.IO.PluginConfiguration.load () which is the second line of OnLoad (config.load(); ) There's nothing out of the ordinary with your method, so that leaves either a corrupt file (delete this file: C:/TestEnvironments/KSP/Kerbal Space Program/Plugins/PluginData/GuiWindowPlugin/config.xml and see if things get resolved), or maybe a permission error.

You're missing the open brace ({) for the PART node @PART[Large.Crewed.Lab] [B][COLOR=#ff0000]{[/COLOR][/B] MODULE { name=ModuleCommand } } You probably also want to have minimumCrew = 1 otherwise it'll function as a drone with no power drain

http://forum.kerbalspaceprogram.com/threads/92230-!!!-PLEASE-READ-BEFORE-POSTING-!!!-Stock-Support-Bug-Reporting-Guide Scroll down to the bit about output logs. Search that file for exception and you'll find what you need - - - Updated - - - It's onload that's running GuiWindowPlugin.GuiWindowPlugin.OnLoad (.ConfigNode node) Something wrong with the config read

Sections of code are generally worthless unless you know what all the inputs/outputs are (and that they are valid). You also haven't mentioned any exceptions being logged that you could follow the stack trace for to narrow it down. My bet would be that it's throwing a lot of errors during the initial loading process, but it's impossible to tell without any information from the logs PS An easier way to handle default window positions _windowPosition = config.GetValue<Rect>("Window Position"); // defaults to 0,0,0,0 if no value is found (current implementation) _windowPosition = config.GetValue("Window Position", new Rect(10,10,0,0)); // defaults to 10,10,0,0 if no value can be found EDIT Your problem is probably going to be OnStart. It could get called during the part compilation process and the != editor check wont catch that (HighLogic.LoadedSceneIsFlight is probably the check you want)

Note that you're running the mach sweep between 0 and Mach 25 (in steps of 0.5) with an AoA of 0.2. If you want useful information, you should keep the sweep below Mach 6/7 and give it a few degrees of AoA (you can find your level flight AoA for a given speed/altitude in the static analysis tab)

@PART[<partName>]:AFTER[NEAR]:NEEDS[!AJE] { @MODULE[ModuleEngines*] { @maxThrust *= 2 } } @PART [*]:HAS[#manufacturer[aManufacturer]]:AFTER[NEAR]:NEEDS[!AJE] { @MODULE[ModuleEngines*] { @maxThrust *= 2 } }

I haven't actually checked, but his description and code says that 1) It isn't using the stock brakes key 2) It may not have a default binding (right click on the brakes button to open set binding window)

Oh, functionally it'll be fine (and it can do a lot more than just check modules btw ). It's more whether the groupings are useful given parts being removed. If someone (Yemo or otherwise) wants to put together an alternate/SETI setup, I have zero issues with that. This will give you a category with: wings, control surfaces, Mk1/2/3 fuselage, jet engines, and intakes as subcategories. The Mk* subcats will probably need a bit of tweaking to be fully reliable CATEGORY { name = Spaceplane Parts icon = AeroParts colour = #FF0000 // red, colour is in hex (A)RGB, # and 0x are recognised hex prefixes (usage optional) all = true // first subcategory includes all the parts in the subcategories SUBCATEGORIES { list = 0, Wings // number is order of appearance from top, followed by subcategory name list = 1, Control Surface list = 2, Mk1 Fuselage list = 3, Mk2 Fuselage list = 4, Mk3 Fuselage list = 5, Jets list = 6, Air Intake } } // Wings, Control surface, Jets, and Air Intake already defined, just need Mk1/2/3 SUBCATEGORY { name = Mk1 Fuselage icon = number1 // needs a proper icon // parts from mods FILTER { CHECK { type = title value = Mk1 } CHECK { type = size value = 1 // has to use atleast 1xsize 1 (1.25m) attach node. Trying to filter out parts that might incorrectly be picked up by the title filter } CHECK { type = folder value = Squad invert = true } } // Squad's Mk1 parts FILTER { CHECK { type = path value = Squad/Parts/Mk1 // mk1 fuselage sections } } FILTER { CHECK { type = name value = Mark1Cockpit, Mark2Cockpit, nacelleBody // Mk1/Mk1 inline cockpits, and engine nacelle } } } SUBCATEGORY { name = Mk2 Fuselage icon = number2 FILTER { CHECK { type = title value = Mk2 // has Mk2 (case insensitive) in the part title } CHECK { type = size value = 1 // has to use atleast 1xsize 1 (1.25m) attach node } CHECK { type = folder value = Squad invert = true } } FILTER { CHECK { type = path value = Squad/SPP } CHECK { type = path value = Squad/SPP/Wings invert = true } CHECK { type = moduleName value = ModuleResourceIntake invert = true } } } SUBCATEGORY { name = Mk3 Fuselage icon = number3 FILTER { CHECK { type = title value = Mk3 // has Mk3 (case insensitive) in the part title } CHECK { type = size value = 3 // has to use atleast 1xsize 3 (3.75m) attach node } CHECK { type = folder value = Squad invert = true } } FILTER { CHECK { type = path value = Squad/Parts/Mk3 } } } EDIT Updated to handle stock parts properly, mods will still be hit and miss since there isn't a real identifier for Mk1/2/3 parts other than the name

http://forum.kerbalspaceprogram.com/threads/104231-0-90-Filter-Extensions-2-0-4-%28Apr-8%29 I have no idea how well the distributed configs will work with SETI given it's liberal parts pruning, but that's what MM is for (PS: I struggle with just the stock parts sometimes, I've no idea how you cope with that mammoth list without extra filters).