Crzyrndm

All I can say is there may be some form of integration, particularly with the SSAS module. I'll look into it properly once 0.90 is actually out, anything before that is pure specualtion.

You need to check for the blank string before trying to use int32.Parse (edit, convert...) and then encode that as an unusable value is what I was trying to say (and a conversion doing the reverse on the way in). string masterActivateGroupAString; // If value is negative, string is blank if (masterActivateGroupA >= 0) masterActivateGroupAString = masterActivateGroupA.ToString(); else masterActivateGroupAString = ""; masterActivateGroupAString = GUI.TextField(new Rect(5, 63, 30, 20), masterActivateGroupAString, 4, AAFldStyle); // If string is blank, set value negative if (masterActivateGroupAString == "") masterActivateGroupA = -1; else { // otherwise proceed as normal try { masterActivateGroupA = Convert.ToInt32(masterActivateGroupAString); //convert string to number } catch { masterActivateGroupAString = masterActivateGroupA.ToString(); //conversion failed, reset change } } This should catch the blank string and store it as -1, returning it to a blank string for subsequent iterations. As an added bonus, anyone trying to enter negative numbers will have it rejected and turned into a blank screen (I don't believe -ve action group numbers are particularly sane...)

Open Pilot Assistant and open the vertical control tab (if it isn't already open). By default, vertical control maintains a set vertical speed/climb rate, click the little toggle to change it to altitude control. With SAS off (There's a small bug with the SAS interaction that makes things a bit *interesting* if you dont turn it off first), toggle on the vertical control using the toggle or by entering the desired altitude and clicking the button that says "Target Altitude". The Vertical control toggle will turn Orange when the system is active IIRC. If your craft oscillates, open the tab labelled as "Vertical Speed" (under "Altitude") and use the +/- buttons to increase/decrease the scalar term you find there. Increase it to remove rapid oscillations (caused by high dynamic pressure / transonic effects), decrease it as you slow down again (otherwise it can't react fast enough and you get some really slow oscillations that can lead to a stall pretty quick) If you still have problems I can make a video or some pictures tonight

To expand on this a little: If you experience wobble, open the relevant axis control (for pitch/altitude hold it is thel vertical speed tab) and increase the value labelled "Scalar" until the oscillation stops. You may have to do this several times as Dynamic Pressure increases (with FAR, the transsonic region (Mach 0.75-1.25) causes temporary oscillations so if your oscillations occur around 330m/s, you can actually bring the scalar down a little after passing into the supersonic region). You can tune everything a whole lot better using the PID gains, but then you really need to understand what's happening and it takes a bit of time.

This sounds so very familiar In this case, you could use a negative number to indicate that the string should be blank space (ie. if (textField.Text == "") then { val = -1 }, and ofcourse the reverse when printing to the screen)

Another bug report: The stability derivates are changing depending on the flap settings of the previous calculation Test Craft (all stock parts)

I may have forgotten to recompile it 0.9.1.2 has the actual fix in it EDIT I'm going to be taking some time to actually get to play KSP over the next few days (first time in weeks...) so in the meantime this post is going to be my memory of all the bugs/improvements/features that I come up with for when I get back into this. Bugs: Pilot Assistant engaged but no control activity (typically followed by frantic keyboard mashing and a dive into the sea). Repro: With no control systems active, activate SAS, later activate a pilot assistant module using the toggle. SAS will disable and control inputs will be captured, but control systems will fail to function. Capturing keyboard input or outputting messages when no relevant modules are enabled (should make a proper messaging system...) Hide/unhide UI based on stock KSP UI visibility so seeing the debug window isn't mutually exclusive to seeing Pilot Assistant's GUI Improvements: Overhaul attitude logic using 3D vectors inplace of euler angles. This will resolve the problems associated with reference axes (craft vertical, planet poles) and allow pitch and yaw to be decoupled in the SAS module. Pre-requisite for development of a terrain follower. Heading control should scale with the cosine (or similar) of pitch angle Heading control should be based off prograde heading, not craft heading. This will resolve craft direction of travel not quite reaching the desired heading and some instabilities. Roll angle hold logic revised for SAS. Pitching up currently leads to craft spiralling due to non-linearities and trying to flip 180 if passing through vertical. Individual activation/deactivation of SAS axes (ie. having roll or yaw SAS, free control on deactivated axes) Features Low altitude predictive terrain following module (ie. 3-5km alt maximum, using data from infront of the vessel) Another look at the input moderation module (see this for an idea) Non-linear background control authority scaling to make settings stable over a wider range of flight conditions Expanded preset manager

Version 0.9.1.1 has just one change, a fix for a divide by zero that would kill the current flight I also replicated the "this mod just nose dived me into the sea" bug, seems to be an issue with taking control from SAS.

Tab (pause all control) and Alt+X (aim for level flight: wings level, vert speed == 0) are there for a reason. Activating SAS will also give you some control. I may shift to a slightly larger button though, mostly because I need the functionality The major issue here is that I have Bank/Yaw and Pitch mostly seperated so it doesn't even know the other control is having issues. WIll have a look at a work around. Repro steps please. It's hard to find the problem unless I know how it happened Already intended to be in a future version. I was thinking maybe having both always visible, but the lower limit changes to match the upper when the upper is edited. PS I'm almost surprised you didn't make a note of the new messaging system having a little fit (I forgot to remove messages when PA isn't active)

Updated to version 0.9.1 GUI overhaul phase 2 - Colours, onscreen messages, more layout changes GUI now stays open between reverts, changing scenes and the like Added single sided output limits (one value for both +ve and -ve limits) for Pilot Assistant, most controllers now use them Fixed the heading/yaw interaction for co-ordinated turns. Yaw now chains off the main heading/bank controller to enforce a single solution for zero heading error (previously it could end up banked one way and yawing the other )

Small bug report with the aero tinting window. If you enter a very small Cl (probably Cd as well) factor such as 0.000005 the tinting GUI window breaks down. Log It also seems strange that I needed to make the Cl that small or smaller to see any tinting NOTE: To get any tinting I had to get the AoA up to about 1 degree (craft cruises at ~0.4)

So basically Unity GUI is as awkward as ever... Thanks for the answer, but it looks like thats going on the shelf for a while...

With the Unity default GUI skin, how to decrease the transparency of objects using it? Background alpha channel is maxmised (1/opaque) by default, so I'm a little lost as to where the transparency is originating from

Thats good to hear since I have no idea what caused it I don't think I'll be moving it out to the standard PID display. Everything in the primary display area is things that need to be tweaked in real-time. 99% of the time, limits can just be setup and then left alone for long periods which is why they can be minimised away. A single value on the other hand sounds very sensible. The difficulties entering text are because all the tuning is applied in real-time as you enter it, which I find to be really nice for tuning, but it does have it's annoying moments. I'll see what I can do about negative inputs.

Standard C# string escape sequences work fine for the most part. For a newline, you typically want "\r\n"

Version 0.9.0 is stage one of the GUI overhaul, gives the ability to minimise screen space down to a very small area if required, with only the wanted information being displayed. GUI resizing logic is significantly improved

It's on the list EDIT As a sneak peak at what I'm doing with the GUI... Most of the GUI displays are now individually collapsible so once I finish overhauling the resizing logic, the use of screen real-estate will be easily managable (that not all of course, whole lot of GUI improvements in the pipeline

I'm somewhere in the middle of a GUI rewrite on my development version so I can't exactly replicate either of these in a useful fashion. That said, what did you right click on Ph3rb0t that caused the windows to close? I don't recall anything that would have closed the windows other than closing them via. the toolbar window selector (well, in the current release version ). Van Disaster's bug on the other hand is a rather simple case of a faulty boolean check that I believe I have already fixed. EDIT You can always disengage AP funtions with the tab key (pause). If they were still running it was a GUI malfunction instead of a complete crash and all the hotkeys should still have been working.

Uh, that's the operating system being used. Read the rest of his post, talking about issues unzipping files... (100% unrelated to KSP.exe, x64 or x86)

I'm having some trouble just imagining how it would work with IVA stuff, so you're going to have to elaborate a little more. My leaning would be to say no though. And another update (no more today I promise ) Version 0.8.3 Corrected behavious of Surface SAS around 0/360 degrees heading and 180/-180 degrees of bank (it doesn't take the long way around any more...) Surface SAS engagement smoothing Surface SAS defaults are less forceful to help with smoother engagement Surface SAS activity indicator is now a button (with pretty colours no less ) Surface SAS attitude +/- buttons behave better around the 0/360 and 180/-180 crossings Surface SAS attitude inputs are now clamped within sane ranges (no more of this) I think that pretty much clears the backlog of bugs and annoyances

Updating to 0.8.2 SAS Presets are now functional Default tuning update The presets remember if they are for the stock module or the surface module, so you can't accidentally load one into the other. Switching from one SAS module to the other will revert to the last loaded preset for now (not the previous values that may have been modified from that preset)

Can you not just use the mouse enter/exit events to set an internal Part reference (on enter set refPart = p, on exit set refPart = null), and then run w/e you need to in in Update() triggered by the key presses? Part partRef = null; ... somewhere in monobehaviour Start()... GameEvents.onPartAttach.Add( OnPartAttach ); public void OnPartAttach( GameEvents.HostTargetAction<Part, Part> eventData ) { eventData.host.AddOnMouseEnter(OnMouseEnter); eventData.host.AddOnMouseExit(OnMouseExit ); } private void OnMouseEnter( Part p ) { partRef = p; } private void OnMouseExit( Part p ) { partRef = null; } private void Update() { if ( keyPressed() && refPart != null ) { // do stuff } }

That'll work for tuning stock SAS (and the ratio's of kp/ki/kd will likely work for the surface SAS tuning as well), but it's pretty much irrelevant for Pilot Assistant's aids (heading/altitude/vertical speed control) I have had problems linking the stock PID modules to my custom ones even when doing the same job. The functionality is all present (and then some ), but the outputs are at a totally different scale and stable tuning constants from one are wildly unstable or totally ineffectual in the other (it's approximately a factor of 100 different, but it never quite works even with that)

Part of the tuning overhaul has been to make it less likely to just try and jump right to an output clamp. What I'm finding is that often the control surface response is very low and it's causing the outer loop controls to have to do more work than they should be doing. The interactions are complex... You're the second person to report this in as many days. I'm not sure what's happening, but it sounds like I need to find out

Generally, if you find you need to change the integral limits to hit the output clamps, you can increase Kp and achieve the same result. Proportional for large scale changes, Integral for bringing the error to zero. That said, some of the default integral limits are just a little bizzare (I'm right in the middle of reviewing all the PID defaults to correct that among other things).