Crzyrndm

*smacks head* <== forgot it has to be public tyvm sarbian

*Scratches head* Checks code *looks puzzled* Checks again *shug* tl;dr Why they stopped working out of the atmosphere I do not understand. It doesn't seem to be happening on my current dev version either so I'll just write it off as something I forgot yesterday. Once I work out how to load float curves (same system as engine ISP/atmo pressure), I'm going to push a lot of stuff onto that so how torque and bleed rates change with saturation will be completely configurable on a per part (and possibly per axis) basis. Probably not. I'm having more issues getting everything to initialise correctly than making the functionality work .

Yes, it is. (you can see an example of editing Strategy nodes here) Anything inside the GameData folder in a *.cfg file which follows the format below is a valid target for module manager patches nodeName { key = value ... }

Any config node is valid so long as it is loaded through GameDatabase (some mods may not do this. All stock functions use this).

Er, what on earth did I do... - - - Updated - - - *Smacks self in head* v1.4 Correctly initialised center location once more Added center location to settings Center now depends on trim

Easing is for the bumpless transfers I introduced with 1.3. If everything is 0.01, that 100% explains your first issue and *may* explain the second issue. I added a note about a temporary MM patch needed to update old presets in the v1.3 release post (otherwise existing presets get read as having 0) If you could get a video of the freezing thing with the top level controller having a reasonable value for easing (it only matters on the controller that your inputs are being passed to) it would be much appreciated

FloatCurve implements IConfigNode, which is what KSPField requires to function I'm beginning to doubt my config placement this is so persistent. Does this make sense to someone other than me?

Nada, KSPField works on it's default values if you just tag it like I have done (persistent = false, no GUI, etc.). You can see it higher up the source page I linked for saturationScale (which is 100% confirmed working as intended). Also, tagging things with persistent = true when you don't need to permanently track them is a bad idea (exactly because of cfg changes not taking effect on old parts) EDIT With persistent = true, I took a look in the save file just to make sure. torqueCurve had no keys

v1.1 Fixed Reaction wheels requiring staging to activate Removed logging

The only thing I can think of is that the easing parameter is very close to 0. Are you possibly using the update button when this happens as well? (A look at your default config will help here, it will atleast rule out easing)

Update is waiting on getting torque decay as a configurable curve rather than the current fixed linear decay. Once I get that sorted I'll push a release ASAP which will include a fix for wheels not being active until staged and remove the log spam. E: Scratch that. If I can't get the torque configuration working in the next half hour or so I'll just hardcode it back to what it is now.

The no/slow response may be due to the new Ease/Easing setting (which doesn't apply to key input). Compare the numbers in my release post to your default (or other as applicable) config Need a lot more information than just "stuck"

Oops. v1.3 Added deadzone and range settings If you're not getting 100% action at the screen edge with default settings (as of 1.3), something is wrong. It should reach max output 2/3rds of the way to an edge. Range setting is a percentage of screen width/height, deadzone is a % of range. The center texture will resize with alterations in range and deadzone to continue indicating the deadzone border. If you want to make a different center indication it needs a 500x500 px image and the deadzone is the center 200 pixels of each axis. I'm not averse to suggestions on how the texture can be improved

Initialising a floatCurve from a part config. Everything I've read indicates I can just tag it as a KSPField and it works the same as most any other config variable. However I'm having no luck with this approach. [KSPField] FloatCurve torqueCurve = new FloatCurve(); // inside FixedUpdate() torqueCurve.Evaluate(0.5); // returns zero The config for the module has this for the floatcurve torqueCurve { key = 0 1 key = 1 1 } but evaluate always returns zero. I checked the MM cache and the torquecurve is inside the partmodule where I would expect it to be. Full source here

Thanks for the detailed report, makes things much easier to resolve

Control "bounce" is fairly typical with FAR (stock maybe? Probably not but I haven't played with it in so long...). Basically you accelerate rapidly and gain enough rotational speed to significantly overshoot a maintainable angle of attack. Aerodynamic forces on your craft at high AoA fling you back the other way until your elevators gain enough control to overcome the righting moment again (repeat ad infinitum).

Analog Control v1.2 Added invert pitch axis option Added optional HUD target to indicate location of deadzones. Transparency configurable .version file No longer a part module (why it ever was, I don't know) Settings can be found in the pluginData folder after you exit the flight scene once. Transparency is <0-1>, other options are boolean 0 or 1

Ridiculously slow, but I finally stuck a landing after hitting 1m 16 parts, 1m altitude HUD cross is from dev version of this (which I'm about to release after thorough testing through this challenge ) Your challenge, your call . 8s penalty for getting myself setup isn't that bad (PA to altitude mode, camera to chase, analog control activated...)

This is a somewhat frustrating challenge... (I think that makes it a good one btw...) Low altitude control => No problem (Pilot Assistant is only up for the readouts which are somewhat useful ) Sticking the landing at the other end *without exceeding 140m* => Not having a whole lot of luck I shall keep trying... (oh, and that picture is somewhat misleading, I lost that stupid intake again right after taking the pic. Still got to the runway, but just popped over 140 on final approach >.<) EDIT And I totally just read the OP again and saw it was 150. A little frustrating considering I've thrown out several for 141m records... >.< EDIT2 Success! 2:05 and 21 parts in FAR (Debris warning is from my marker craft, current vessel is named the Aeris 3B) No low altitude stuff on this flight, just keeping +/- 10m is a struggle at 400 m/s

Thinking on it further: Set the output limit of the vertical speed block to desired AoA Set the desired vertical speed to 0 That *should* do what you want it to (helps to have a use case )

An angle of attack controller on it's own is next to useless for flying. You have to offload all vertical control to the throttle before it makes sense again and then you're right back where we are now. Pilot Assistant is continuously adjusting the desired AoA to attain a target vertical speed (the low level control *is* working on angle of attack and you can limit the AoA Pilot Assistant will try to use). If you meant pitch, just use SSAS. If you want it for re-entry purposes, SSAS pitch control is the closest thing available (even if I added an AoA control mode, you would still have to monitor it for when to switch back to something useful).

Probably is my best guess, but untested. From memory MJ abuses the "timewarp kills rotation" thing a bit which may not be the greatest idea with this running

Simple and interesting challenge. I might take a whack at this later. However, you *may* want to consider disallowing usage of mods which automate altitude control... It can be even better if all the control surfaces are present (water swiped the port ones when I tried turning too sharply) It can go lower than that (Aeris 3A is limited by it's underside air intake to ~1.00m. Without it can get down to ~0.75m) It can go faster (whack a turbojet on the 3A in FAR) without noticeably impacting precision

Which is somewhat amusing for me because the code doing the "heavy" lifting is rather simple and straight forward

AJE is entirely different from from the changes ferram makes. Turbojet just gets its max thrust and velocity curve cut down a bit so you can't go orbital on only the turbojet (0 thrust stock is 2400m/s surface speed, 0 thrust in FAR is 1800m/s IIRC). You're looking at just over a half hour flying (before warp) in stock (approx. low orbit period), FAR is probably more like 45 minutes since surface velocity is only going to be ~1300 m/s. ^^ Most fuel efficient option. Sub-orbital hops can cover enourmous distances for very little fuel. The higher your surface velocity, the better (orbital velocity is obviously the extreme here at 0 fuel per km covered). No need to build it as a spaceplane either, just nose up and go fast.