Crzyrndm

That's extremely wierd, Pilot Assistant uses no persistent data outside it's own directory (and 0.9.6.2 only used the presets) so wiping it's directory should be more than enough to set everything right. Is it only PA that's not working? Logs?

- - - Updated - - - v1.0.1 fixes flight scene reloading killing things

That's one way of putting it... The only real advice I have is using GUILayout over GUI unless you need to control placement in some way it won't allow, and to break it down into functions wherever possible (particularly anything that's repeated more than once like a label + textbox placed horizontally. I don't know how much frustration that particular change saved me, but it's a lot).

Pilot Assistant v1.0 released Large scale code overhaul SSAS now uses a sliding engagement Presets are now associated with a specific craft name A "defaults.cfg" will be created on entering the flight scene for the first time. Change the tuning values here to alter your default settings Fix for integral windup issues when craft is uncontrollable Fix for incorrect SAS preset assignments Craft Presets Whenever you load a non-default preset onto a craft, that particular craft name gets linked to the preset you just loaded. Anytime you load the craft after that it should automatically reload the specific preset. If there is no available preset, then the relevant default will be used. Defaults I would suggest using module manager rather than hand edits if you want to make changes to these. If things do get out of hand, deleting the defaults config will reset everything. SSAS With the new sliding engagement I feel like there is very little reason to use stock SAS inside the atmosphere. The slide time may need a bit of tweaking yet (feedback on this would be appreciated), but thats trivial now it functions.

Aight, fairly finalised dev build on Github. Functionally, SSAS now has it's nice sliding engagement (), presets are associated with a craft, and the PID defaults are available to change in a cfg (created after first run), plus a few other things that I can't remember. Now, the reason I'm not "releasing" this is because I have barely tested it, a good portion of the codebase has been restructured, and I need some sleep. If you're up for a (little) bit of risk, well here's v1.0 a day early

er, non-right angled trig says hello dist = sqrt (spot1:distance ^ 2 + spot2:distance ^ 2 - 2 * spot1:distance * spot2:distance * cos ( spot1:bearing - spot2:bearing) ) scuse the non-kOS syntax...

Not really that surprising. Most people don't use m/s much (if at all) and have no references against their "everyday" units (kph || mph). On top of that KSP lacks any feeling of speed (open road speed is less than 30 m/s, but would you be able to pick that in game?). So no, I wouldn't say it's surprising.

You could just check straight from the Flight UI as to what the displayed unit is if FAR doesn't expose the current setting.

FAR zeroes out the stock "lift" values, hence surfaces that don't have a lift rating. It also removes the arrow from the CoP(CoL) for reasons I can't remember at the moment. 150m/s takeoff's aren't particularly difficult, you just have to be rather light on the controls in the lower atmosphere (first 3-5km in particular). You could add some flaps to lower takeoff speed and you should be throttling back once you get into the air to keep the dynamic pressure in a manageable range.

I don't know whether to say it's a relief or a headache inducing annoyance (it's not the old bug, but it's still a bug with no repro case...) And a possibly interesting update, if you've used SSAS much, you'll probably have noticed that it locks it's target rather more quickly than stock SAS does (the instant you released the relevant input key for the axis to be exact...), which resulted in it always overshooting and then coming back after some control input. I had a bit of a lightbulb moment while I was cleaning that section of code and for once things worked perfectly straight out of the box. SSAS now uses a sliding engagement that feels almost exactly like the stock SAS system (a good thing in this case). My last major issue with SSAS functionality just dissapeared

So you're saying the calculated drag force from quoted drag equation is being directly applied as an acceleration (F = a)? (the acceleration is not computed directly in order to make it constant over all parts and avoid the complications to the player varying forces cause)

@Van Disaster I've been trying to squash that one ever since I introduced the "disable on SAS usage". If you ever find what makes it happen... @Wanderfound Can you just try one thing for me: Save a preset, load it, click update, and then load it again. If it flips back to what it originally was, I know exactly what's caused it (and I could have sworn I squashed that one...) Default stock SAS settings for FAR => Increase Scalar by 50% Assistant depends way too much on the plane SSAS defaults *should* be fairly FAR compatible since I do most of my testing with FAR. That does remind me though, I was going to move the defaults ot of the code...

Well technically, if the same acceleration is used for every part, the equivalent force does depend on mass (F = ma. Equivalent force being the force that would have been required to generate said acceleration) I could ofcourse be totally mis-understanding here

You probably want to tie into the flight control system rather than trying to move them in space directly (depending on what you're trying to do ofcourse). You can effectively emulate input to any loaded vessel which means there won't be any issues with animations and such. Add your function to the control event for each vessel you want to work on (you can do it without the event, but I don't have an example onhand) The event passes you the current control state of the vessel, and then you can modify/override that control state as you wish (to modify, you just need to add your value to what it already was eg. state.pitch = state.pitch + ...). So if you set the value corresponding to walk left == 0.05, the kerbal will walk left @ 5% speed I can't test anything right now, so hopefully thats not a wild goose chase...

I'm a good chunk of the way through setting up the preset loader to work on craft name, so barring any major disturbances that should be release ready by the end of the weekend. It's taking a while to get here because I've been slowly rebuilding the code to make things a little less hacked together. The result of this is that several subsystems should perform more reliably, some minor optimisation, and a significant decrease in headscratching on my end. If there are any issues/niggles lying around, now would be the time to be poking me with them I'm also considering writing/recording/drawing some comprehensive documentation/usage guidelines/PID tutorials. Past the obvious "this is what each number does", are there some systems that need more focus (I'm guessing KSP/PA tuning examples are going to be very high on that list, but past that I really don't know)

http://forum.kerbalspaceprogram.com/threads/104231-0-90-Filter-Extensions-1-16-%28Jan-17%29 Will change the "by Manufacturer" tab to list parts by mod folder instead. No need for a patch (not that what you're looking for is doable with MM AFAIK)

First line of code per physics update includes a check to make sure the craft is in the water. Nothing else is done if that isn't true.

You're running into pretty much the same problem Pilot Assistant does: nice PID tuning works really well for a very specific situation, but a flight situation changes significantly based on airspeed and altitude (or rather atmospheric density). If you take a look in FAR's readouts, you'll probably find that the instability occurs past a certain high/low level of dynamic pressure / 'Q' (I don't know which in your case, upper atmospheric flight can have either). High dynamic pressure results in excess control authority and the PID over-reacting (short, sharp oscillations. Typically followed by the plane shaking to pieces) Low dynamic pressure results in inadequate control authority and PID under-reacting (big, slow oscillations. Spins and other "fun" are the more likely result) Now, I don't really have much of an idea of what your script does (not a kOS user myself), but the easiest way to get around Q changes in my experience is to have a final scalar you can apply to the PID to change on the fly (if that's not feasible with kOS, maybe some form of lookup to do some mangement as you fly?). As Q increases, you scale down the output. As Q decreases, you scale up the output. It's not linear (that would just be too easy...) so don't try scaling it by dynamic pressure (that ends really badly). Hope that helps somewhat

Tried them, found them annoying, made a mod to do it (subjectively) better.

Derivative isn't used a whole lot outside of simulations because it suffers really badly from noise (measurement imperfections). That's probably why you won't find much on it. PA and SAS structure is so entirely different that exporting one to another is not going to happen. SAS is only a single controller per axis while all of Pilot Assistant's control systems are running in a two stage cascade.

GameData only

A log and list of mods might be useful here. That looks similar to the style leakage issue I had a while back where it picks up GUI styling from another mod. That said, there is a lot more wierdness this time...

For a version that is as light as you describe, I don't think the download needs to be seperated since it only requires a handful of extra clicks on your part. Taking a few seconds to delete the configs folder, only transferring the .dll from an update, or you could just not update until KSP does (Most update stuff is adding functionality to configs and the likelyhood of a major bug in Filter by Mod is almost nil)

You have to enable a control surface to act as a spoiler in the SPH (same for flaps)

Hehe, can you tell I didn't put any thought into that one till I was writing out the update post...