Crzyrndm

It's probably run into one of the integral output clamps if it can't quite make it, and I'd bet on it being the VSpeed controller. To fix it: 1) Under the options heading, toggle on show limits 2) Under the vertical speed heading, open the VSpeed controller and increase the "I Clamp Lower/Upper" from +/-5 to match the output limit Your cruising AoA is apparently slightly higher than 5 degrees (If you're flying stock, that's to be expected. If not, blame my habit of designing ultra-low AoA craft)

Not wrong, just not knowing everything there is to know (and there not being any thorough documentation of what there is to know...) To summarise: There are two ways of activating a control system 1) The toggle switches / key bindings. These reset the target to the current appropriate value to help keep engagement smooth and avoid the need to type anything in before activation. Best used when you are already close to your target, don't have a specific target in mind, or just prefer the ease of WASD target adjustment. 2) The Update Target buttons. These activate controls with the target set to whatever is currently in the target text box. Best used for activating when you have a specific target in mind and are a fair way away from it.

Er, kind of. It's a bug that it didn't activate when you clicked "Target Altitude", but using the toggles should always set the target to the current applicable value (makes switching from manual control a whole lot smoother). EDIT Quick glance through the relevant code says it should be working properly (I'll be a few hours before I can actually test things myself). In the meantime can I ask you to do two things: 1) Use the Update Target buttons on all three Pilot Assistant controls. Shouldn't matter what values (just quickly on the runway is fine). Do any of them activate? 2) Upload the output.log after running the above test if any of the three fail to activate again

It really should, but I didn't think about it at the time (obviously). I will do something about it so it doesn't happen again...

VanDisaster, it was the new throttle control module (which I totally forgot about...) Fixed version For anyone else wanting to import pre-1.1 Pilot Assistant presets you need to add the following in each PIDPreset in Presets.cfg ThrottleController { PGain = 0.2 IGain = 0.08 DGain = 0.1 MinOut = -1 MaxOut = 0 ClampLower = -1 ClampUpper = 0.4 Scalar = 1 }

Anything inheriting from Monobehaviour also gets print() which is the same thing as Debug.Log (Also, try typing it out manually with capitilisation and all. Sometimes VS autocomplete is silly about it) [COLOR=#333333][FONT=Consolas]Debug.Log([/FONT][/COLOR][COLOR=#333333][FONT=Consolas]o);

I *think* it could just be your capitalisation of OnGUI (all of GUI is capitalised). You do have Debug.Log() and print() for sticking things in the log as well so you can see that OnGui() is never entered but Awake() did run (massive red flag for OnGui). PS You dont need the GUILayout.Begin/End for just putting stuff in a window. By default, GUILayout places each object sequentially in a single column, Begin Horizontal is used to start a row, and then Begin Vertical makes a column inside a cell of that row.

Config nodes, generally no. const string asstPreset = "PIDPreset"; // this is actually elsewhere so I can use it in multiple locations foreach (ConfigNode node in GameDatabase.Instance.GetConfigNodes(asstPreset)) Loops through all nodes of type PIDPreset (snippet from Pilot Assistant) found inside GameData

KSP (and FAR by extension) has no winds at any altitude or position, so no there is no difference in surface relative speed flying east or west. In the space center scene you can change global FAR options. It should be in there

I believe that's because you have texture downsizing set in KSP settings. If you set texture resolution to full, it should appear as expected. EDIT: *facepalm* Didn't even check the image size... */facepalm*

I probably do need to change SSAS inputs to work like that. The reason I've never bothered is that changing the heading target any large amount will just cause it to jam the rudder full on (which planes don't particularly like...). Pilot Assistant heading control on the other hand is designed to turn through large angles properly and *should* be using the confirm button style input. EDIT To clarify, the intention of the inputs in the SSAS panel is for fine tuning (eg. making it hit exactly zero degrees of bank) because it is only designed to hold an attitude, not turn to one. The increment buttons give you +/- 1 degree (reasonable for about 10-15 degrees) and sub 1 degree input doesn't result in noticeable instability. For alterations of 15-20+ degrees, my recommendation is to turn it manually first such that SSAS is only doing it's job as an attitude hold mechanism.

In the VAB/SPH part info panels? NEAR and FAR don't use the stock lift rating system so they get removed.

I cannot replicate presets dissapearing (I did however find that SAS presets aren't being associated with a craft properly, so I'll fix that...) With the presets.cfg open in N++ or similar text editor that notifies you when the file changes (or you can just reopen it every time...). Create a new preset => alt+tab and check the preset shows in the file => Close KSP => reopen KSP and load a game => check file on entering space center and flight scenes => ... Basically, until I know when or what causes the presets to get wiped, I can't do much EDIT You may want to try with the latest build on github. I fixed a few minor issues with presets in it, may have caught yours by accident (can always hope...)

:mad::mad::mad: Not this again... I did switch around some loading logic for SAS presets so they got sent to the right controller in the latest version, but that shouldn't have broken the save/load routine at all. Can you check the presets.cfg file and make sure it's actually being created? (it should be refreshed when you make create one, update one, remove one, or leave the flight scene) Is it all presets or just one type? Any errors in the log? I can't test or fix this until much later tonight

IIRC, you can actually make all of the displays use the HUD style (or atleast any custom ones) so the number of available HUDs is not limited to just 2. I also agree that the extra information can be left to the likes of KER. This shows exactly what it needs to in a concise and useful manner. HUD1 and HUD2 I believe they're called by default. Configurable from the control window (I can't remember what it's called, but you can hide it and it has edit buttons next to each window as well as allowing you to open/close each display)

Ah, I thought the Instance.crew was a collection (hence the head scratching). My bad. And no, I can't seem to find a reference to the crew inside the editor anywhere either...

Ok, v1.1.2 Fixed SSAS axis activation issues where both pitch and heading had to be active. Pilot Assistant moved to post-Autopilot update event. Pilot assistant functions now override SAS or SSAS if they are active (so you can use the wing leveller and (S)SAS to hold pitch if you want). No more pause desynchs ever!!! Fixed Pilot Assistant targets being updated instantly when being typed in instead of requiring the update button to be clicked Fixed SAS presets being loaded from file in the incorrect order Removed all references to velocity from Pilot Assistant Throttle control (replaced with speed). Just a minor terminology issue. Fixed SSAS pitch being randomly clamped to +/- 80 degrees instead of +/- 90 degrees EDIT Forgot one Added Modifier (windows: LAlt) requirement to the Asst function toggles (eg. LAlt + numpad9 toggles heading control)

If you can get the information from the panel manager, I'm not sure what the issue is (you're not parsing the GUI, you're getting information from the class that controls the GUI). Crew is almost certainly added/associated with the vessel post-launch

Pilot Assistant cannot be used with SAS/SSAS (*right now* I may have finally found a fix for that) as it's output gets overridden (which causes all sorts of wierd "fun"). That's why it pauses when you activate anything in the SAS module. Using the other SAS window (click "Mode: SSAS" => Changes to "Mode: Stock") and SAS as normal will likely be easier for you. You might have to retrim a bit, but functionally there's less to worry about. RE: You do have it mostly right (other than the conflicting activities). The reason the nose drooped when you activated pitch controls is that: A) the scale on the outputs was too low (Scalar probably too high). Tick that down a bit and it should drift much less default settings have no integral term. If you open the pitch tuning controls (under the targets), you'll see the value labelled as Ki is currently zero. Press the increment button just once and while the nose will initially droop, it should come back up to the specified target. EDIT Ofcourse, it's always possible I broke something . Pitch control can't activate on it's own at the moment for some reason, so you can ignore what I just said RE: the scalar being too low. If you use "T" or the button by the navball to activate it everything will work much more as expected. Meanwhile, I'll go fix that... Also, activate before entering targets. To make activation as smooth as possible, it updates to the current heading/pitch/roll on activation. You can then use the increment buttons to shift that to your desired target (so if it says 7.41, tick it up till it shows 15.41, then backspace the fractional part to get just 15.00 degrees. Changing it iarge amounts in one go (eg. 7 => 17) isn't good for stability because it'll try make that movement at full power EDIT2 And just for completeness

I may put a toggle in the options to allow/disallow use of the activation keys and/or change them to be bound as "Alt + ...". In hindsight I agree that the numpad is a terrible location, but I do prefer having the keyboard shortcuts available. Basically, I'll think of something

Those ones aren't currently. There isn't a stock keybind I can over-ride for that and I have no rebinding functions of my own setup. Seems I need to find some better bindings

Somehow I doubt it. To put it bluntly: At the end of the day I wrote this to make my life easier, making it useful for others has always been a somewhat secondary concern. If it wasn't for the need to find space in the GUI, I'd probably have even more numbers showing up The shorthand of it is actually rather simple (using the stock SAS tuner). Open the axis which is giving you issues If the issue is rapid oscillations/vibrations, increase the value marked as Scalar (just slowly tick it up with the increment buttons, sometimes it doesn't take much for it to dissapear) If the issue is a large slow wobble (Imagine the stereotypical cartoon drunk sway) decrease the value marked as Scalar Increasing speed brings you get closer to the rapid oscillations, while increasing altitude gets closer to the drunken flailing The Asst is pretty much the same thing, however identifying the controller to change the scalar is slightly less straight forward and some messing with the tuning constants will be required (except the throttle control, that's nice and straight forward) . If you want to keep it light on the unmbers, just stick with stock SAS and the scalars.

So in other words, how to tune the Assistant controllers for stable flight? Some tips http://forum.kerbalspaceprogram.com/threads/100073-0-90-Pilot-Assistant-Atmospheric-piloting-aids-1-1-1-%28Jan-30%29?p=1631919&viewfull=1#post1631919 http://forum.kerbalspaceprogram.com/threads/100073-0-90-Pilot-Assistant-Atmospheric-piloting-aids-1-1-1-%28Jan-30%29?p=1588253&viewfull=1#post1588253 PID in a spreadsheet: https://docs.google.com/spreadsheets/d/14HopZx8l7g4gGfQU0BZhxjjyEOzr5fQ8puNg8_44b1g/edit#gid=0 (make a copy of it and you can change numbers and see what sort of effect they have) You can also use the throttle control to safetly experiment (since speed oscillations won't make you fall out of the sky unless you're going really slow) I'll get to writing a full tutorial here, but it's going to take a while It's best if you can describe your issue since otherwise I can only start with the common issues and work down the list EDIT *angry muttering about forgetting to update my own mods on full install*...

If a few people could enter and exit the editor scenes 3-4 times with this version and then upload the log. I'm testing changes to the way initialisation occurs and need to check there isn't any variation between installs. Particularly interested in logs from slower PC's with lots of mod parts.

Version 1.1.1 Fixed GUI style leakage Added Throttle controller to presets Added SAS mode to craft presets Added AoA default override patch for non-FAR users Added new keybindings for toggling Pilot Assistant functions I finally caught something like this consistently on a local install (no idea which mod it was...), so I can now say that it should definitely be fixed. SAS mode in the presets means you can choose which SAS tuner pops out by changing the default. "SASmode = true" => stock tuner, false is the SSAS GUI. If will also override for any craft preset (so some craft can load SSAS by default and others can load the Stock tuner. Key bindings (If you have a bettter suggestion for the Asst toggles, I'm all ears...) Modifier + SAS Toggle now toggle SAS mode as appropriate SAS Hold (default: F) refreshes the SSAS target numpad 9 toggle Pilot Assistant Heading Controls numpad 6 Toggles Vertical controls numpad 3 Toggles Throttle controls Stock AoA Patch sets the default angle of attack maxima to +/- 30 degrees if you don't have FAR installed.