Crzyrndm

Unable to replicate errors caused by reducing any parameters to zero

No, there is something odd happening. FAR doesn't have any direction on the CoP indicator (because it doesn't show anything useful), yet a vector shows up when one of these wings is placed.

That's not breaking, it's what happens when there's no icon (and stock makes very little attempt to find an icon either...)

It's there for me. No reason for it not to be either Well that's interesting (ty for the heads up). Looks like it is probably not FAR it's conflicting with sadly which makes things a lot more difficult...

Changes causing the above issue and an issue reported earlier on github reverted. The exceptions they were preventing appear to be less harmful at this stage >.<

What can I say, I don't like leaving such obvious bugs hanging around

You're welcome (however you want ) Reducing overall sensitivity (2-3x scalar) and then a further reduction to Kd (2-4x) has seemed alright to me mostly. That is combined with dynamic deflection though (Q:%; 0:100, 40:50, 80:30, 160:25) You might want to have a look at Dynamic Deflection EDIT First test of the terrain follower is extremely promising (obviously the UI is in need of some changes but the functionality mostly works...) Although, if you're going to be flying that low, remember to dramatically increase the output limits in the altitude controller. Some of the mountains require some very steep climb's...

As part of a terrain following module for Pilot Assistant, I have been using the altitude of the terrain in front of the craft to predict the climb rate required to navigate that terrain. This is done via raycasting at an angle decided by the current altitude and speed. For the most part, this all works and has proven reasonably successful. However, every time the floating origin shifts, the raycast behaves as if it strikes a vertical boundary either just before or just after, which the control system interprets as an incoming obstacle and makes a rather abrupt effort to avoid. 1) The GameEvent "onFloatingOriginShift" isn't firing at all under conditions I would expect it to be (200m/s @ 500m over a period of 10 minutes), so while I can tell it happened (from the breaks in engine noise mostly), I can't tell exactly when it happens in code at this stage. I was planning on using this to just ignore the raycast for a few physics frames (if it occurred after rather than before the shift...) 2) If the error in the raycast appears before the floating origin shift (or in the case I'm in now where the event doesn't appear to work), how can I tell that I'm approaching the point where the shift occurs?

Probably steeringCurve { key = 0 10 key = 10 6 key = 30 2 } that looks like the format is: key = [speed (m/s)] [Turn Range (degrees)]

For the navball FlightUIModeController.Instance.navBall.expanded The other stuff is in PhysicsGlobals

Dynamic Deflection updated to v1.1.2 for FAR v0.15 compatibility I'm not seeing this?

Modifier + X is set up to be an "Stop what you're doing and go for level flight" button. In order to do that, it force sets the active mode. Prior to 1.7.0 this wouldn't matter if you weren't using a control system already, however I changed the way mode handling worked with 1.7.0 in order to make it more expandable (ie. coping with a third/fourth/+ mode). At that time, disabled was just another mode and so when the "level off" command switched the modes around, it caused all the control systems to activate. I can certainly do a quick activation command command, but "level off" isn't going to be it (and the actual problem to fix was making sure disabled stayed disabled while still allowing mode switching) Right clicking the toolbar button makes sense, I'll get that added.

Except the version CKAN is pointing to (2.1.1) is the latest version. What version are you referring to?

That one's my fault, v1.7.2 fixes the icon path being incorrect... I figured someone might (E: and just fyi, don't be surprised if it takes a while. I don't plan on it *just* being distance straight down...)

Updated Dynamic Deflection to v1.1.1: Fixes craft loaded from the runway/launchpad craft selection menu having 0 maximum deflection

Version 1.7.1 is a fix for the issue brought up by Gfurst. Control only activates when it is toggled on or the target is updated, mode switching no longer causes a deactivated control system to activate. No problem

Oh blast, I knew something like that would crop up. Will update shortly such that mode switches are independent of activation again (It's always used Modifier+x as a "level off", it just didn't cause it to activate before if it wasn't active) Your second comment, I don't understand? (well, I get the toolbar bit, but not the first part)

It's also highly unusual to need to use them as anything other than first stage engines. By the time they burn out the KR-2L already has probably 60+% of it's vacuum thrust if not more. Which combined with it's efficiency was absurd. Engines which are good at everything leave no place for many others. Use them for what they're intended for instead of complaining that you can't just use the same thing everywhere.

For all your longhaul aircraft needs: http://forum.kerbalspaceprogram.com/threads/100073-1-0-x-Pilot-Assistant-Atmospheric-piloting-aids-1-7-0-%28May-7%29 Edit: Seems I left the page open...

Each of the 4 numbers defines a point on a curve that is then used for interpolation. key = [situation] [thrustMult] [inTangent] [outTangent] velCurve uses Mach number for it's situation, atmCurve uses atmospheric density In/Out tangents are optional values that specify the gradient on each side of a point. Without these, Unity's interpolation can do some very strange things

Alternatively, use a mod to place an interface between your imprecise input and the output you require.

Increase the ASL ISP if you want to "denerf" the ASL thrust of the vacuum engines on Kerbin. Alternatively, use engines suited for the job at hand (4x24-77's in place of the 909, pairs of Mk-55's in place of a poodle, SRB's/Mainsails/quad cluster for bigger stuff) instead of just using the same old engines that could do everything.

Tweakscale needs to add this if they haven't already to notify FAR of changes in shape/size. PS: Overwrite the B9 Pwings with the files here to get them working in 1.0.x/FAR

Yes, because it is a MM patch

Version 1.7.0 Cascaded speed controller into an acceleration controller Added acceleration control mode Changed mode handling to improve expandability Disabled pause keybinding (tab) in map view due to conflict with a KSP binding And a very blunt hint as to what's coming next NOTE: Old Speed control presets will have some slight transition issues. Please check the set limits before coming to ask why it won't let you slow down any more