Crzyrndm

I can't say for sure since I don't use KVV, but I'd be inclined to say that it will give very odd displays because of how the parts are retextured and reshaped.

Version 1.8.0 Added Radar altitude mode to vertical control Fixed craft trim being affected while Pilot Assistant systems engaged Removed [Modifier]+X action Some UI changes to make options faster to access (I need to make some proper icons for these...) - - - Updated - - - Already planned

Considering it (although it won't be exactly MJ's code if I do it, I have "issues" with how that is setup). It would be advantageous for some of my other mods if I could interact easier with the stock SAS system and creating it won't be that difficult

It's balanced if I fill up empty fuel tanks (Mk2 to 1.25m adapter and the bicoupler both have no LF in my version). For rockets, I find using the Mach sweep is often more helpful. You can see at which what speeds a certain AoA will be stable/unstable (instead of entering a speed, you enter an AoA, everything else is the same.). Increasing stability requires decreasing drag forward of the CoM and increasing it aft of the CoM (in this case, if you make your center stage extend further above your outer stages, it'll shift the drag they create back and increase vessel stability)

No, actually it doesn't "just" accelerate all 10 degrees (if it did that it'd always reach the same amplitude on the opposite end of it's swing), as you move faster it applies a counter torque and as you get closer it applies reduced torque (if your acceleration is high enough it will go control neutral/start decelerating a long way from it's target). It will overshoot slightly but under normal circumstances it will overshoot in a decaying fashion (ie. less each time). SAS instabilities are also contributed to by a flexing rocket because it uses the command pod facing to determine it's reaction (and that's typically one of the parts with the greatest amplitude of flex) The issue is one of sensitivity and the fact that stock SAS has a fixed setup. Adding a reaction delay to gimbals reduces their apparent sensitivity and alters the torque/MOI ratio that SAS can cope well with (slower = greater levels of torque required for the same effect). If you try the fix with one of the alternate SAS modes (eg. hold prograde) which just happens to be ~4x more aggressive than the stability assistance mode, you'll probably find that it works perfectly (whereas in stock it tends to be far too twitchy). This problem will continue to exist until someone decides that a constant sensitivity is wrong and writes something that changes with available torque and current MOI (or just copies it out of MJ )

Can you try with this version please

Sounds like I need to make keybindings my next development priority Maximum turn rate: Bank limit and/or add some Kp to the yaw control (by default it is holding the yaw to 0 degrees for maximum stability, changing Kp 0 => 0.2 on default settings will use up to 2 degrees of yaw depending on how far you are turning) The greater the bank angle you allow the faster it will turn, but the vertical controls will have significantly reduced authority. It defaults to a low value so that barely stable planes don't go into a nosedive when turning Turn in Rate: Increase "Easing" under the limits of the Heading controller Easing is "the rate of acceleration of the changing setpoint". The default 1.0 means after 1 second the setpoint will be changing 1 degree per second, 2 degrees per second after 2 seconds, etc. This allows the gradual roll in rather than a rather jerky movements that resulted when the change was instantaneous. Easing only has an effect on the controller receiving the setpoint, it is disabled for all controllers cascading off that one.

You can't use the categories in the part cfg to put them in a custom filter. KSP just doesn't know what "category = LifeSupport" means. The best way is to add an exclusion to Utility for the parts you want. @SUBCATEGORY[Utility]:FOR[FilterExtension]:NEEDS[<yourModHere>] { @FILTER,0 { ///--- copy your CHECKs here and add the line "invert = true" } }

1) That was me testing if it could "see" the KSC buildings (obviously not). That video was from the very first flight after I implemented the function so everything was a test 2) I think it's a necessary addition. Terrain following needs much more aggressive control than altitude control normally does (the default tuning is so passive it barely overshoots, that just doesn't work when you've only got a few meters of error) 3) Yup, although it won't "see" around the corner at this stage so it's slightly off. You also have to be somewhat careful about how aggressively you let it turn since any significant bank reduces vertical control and it needs a lot more excess authority than standard controls. Sounds like it's all functioning normally, but: 1) I used Mod+X because it shares the same purpose of returning to the base state (Stock: return to neutral controls, PA: return to straight and level flight) making it much easier to remember. That said, how much use does it actually get? if things get hairy, pausing control and using SAS to bring everything back to a reasonable state will often work better and small mistakes aren't that difficult to rectify by normal means. It exists for a state that doesn't seem likely to occur any more so maybe removal would be best. 2) Mod + Pitch/Yaw controls acting on stock while the relevant control system is engaged is a fairly serious oversight on my part. It doesn't get used often or for long so the result should normally be minor (which would explain why it's gone unnoticed for so long), but I will do something about it affecting the current trim state.

Because what that marker represents with FAR is not the same as what it represents in stock. Stability in stock mostly just means keeping the CoL behind CoM, stability in FAR means having a -ve slope on the yellow line at the speed/AoA you will be flying at (the CoL indicator doesn't tell you anything significantly useful)

It does work with FAR. I don't know what caused the NaN crash and the person reporting the issue hasn't replied with the information I need to narrow it down. EDIT: Well spotted on the inverted pitch trim, I'll get that fixed (and done, pitch forward/down is now trim nose down instead of up...)

The responsiveness of Stability Assist is significantly less than the other SAS Modes. For most vehicles, the complaint is that hold prograde etc. are too jittery, but in your case it seems the over responsiveness works better (probably because oscillations caused by Stability response happen to be close to a frequency your rocket wants to wobbles at). The easiest "fix" would be to stiffen your rocket up (ie. add lots of struts). If you can stop it wobbling, SAS will do its job.

nope, you can just change the name (example)

It no longer forcibly engages control, that was an unintentional effect of some changes I made which I quickly made updates to remove (that post was made after fixing the issue)

I have no idea, I just made the "0" not actually equal to zero (it's 100um ). If I had to guess, I'd be investigating some of the referenced material to see if they are x64 compatible before the code itself.

Well that's a new one. At least we know why I couldn't find it now. See if this fixes it

I need a copy of your output_log.txt (or Mac/Linux equivalent: player.log)

Can I get a copy of the craft please. For some reason I am unable to create this error just by reducing the tip to zero.

http://forum.kerbalspaceprogram.com/threads/100073-1-0-x-Pilot-Assistant-Atmospheric-piloting-aids-1-7-1-%28May-8%29

Another day, another update. I found the cause of the low control surface responsiveness with FAR (probably), and there's a good chance it was affecting all wing types and could have a significant affect on craft behaviour. You may want to double check craft stability before launching. Remember to thank Bac9 for doing all the hard work, I'm only repairing/polishing what was already there

New version on Github, resolves the CoL vector issue on the main wings. Can everyone other than funk who reported issues please verify they still exist because I'm not seeing them using this version (nullrefs for 0m wingtip, NaN wave drag area, odd analysis results) EDIT funk is right, the control surface doesn't appear to be doing anything in nuFAR, use other parts for now (all moving still works fine)

Version with Radar Altitude control now available on github. Just be aware that there are still some errors (oceans in particular need some special case handling, and I don't know what it'll do if you try it above a few km). It currently works fairly well for terrain like that around KSC, but I wouldn't trust it climbing a mountain just yet... I will add a button to lock keyboard input

Oh, so it's FAR that doesn't like it. Another thing for the list. Toggle them off with f10(?) if they appear. They're nice to have, but the amount of memory more than a few churns through is just not worth it :/

The memory leak is because of the temperature gauges, it's a known stock issue. I am investigating the FAR issues.

Why are you pointing at a mod he doesn't even have installed? (Unless you're pointing out the fact that it will probably match icons to most of those resources if he did use the .dll)