Boris-Barboris

What is center of drag?

No, a couple of people reached out but got scared away when dived deeper into code base. I'll keep it alive for now. Squad slowed it's update pace, that shouldn't be a big hassle.

Bank angle: No direct limit for vertical speed, but you can limit climb angle in CF advanced options. Or you can just use vertical speed mode until target height.

It will turn out to be either a bug, useless unity shader or a bitcoin miner, won't it?

There is no official temp for mods outside of OS-provided temp (pita on windows), so I picked empty unused directory. No, this data does not belong to gamedata mod folder.

I unironically use Resources for dumping telemetry from the mod. Emty folders don't take much space, so let them be, there'll always be someone with his workflow broken.

... and a shader.

https://github.com/Boris-Barboris/AtmosphereAutopilot/commit/686c0bb18db6b474517b6394b4a2c15eca6f5f14#diff-575ab59de22989b9d040dace3c57e006

switch navball to "Surface" mode.

yeah, I meant reaction wheels, bad wording.

Control surfaces move to the set value with constant angular velocity. Reaction wheels, RCS and some gimbals (with small max angle) instantly assume set value. Most gimbals exponentially approach set value until small error when they snap to it.

1.5.11: https://github.com/Boris-Barboris/AtmosphereAutopilot/releases/tag/v1.5.11 Gimbal fix @Hotel26 made cruise controller waypoint control textual (coordinates), mouse picking now has a button. director strength is now part of craft settings window. @SkyKaptn Pepperidge farm remembers.

Ok, solved it. DLC added new LoadingSystem - Expansions.ExpansionsLoader. That's why I had to properly inject my loaders right before PartLoader, and not in the second from the tail position in loader list.

Gentlemen, my old nemesis is haunting me again after a couple of KSP patches. ModuleGimbal was tap-delayed in KSP at least as long as I can remember. That happens because it is a separate module and not part of the ModuleEngine(FX). Standard situation for engines: physx update -> user alters joystick position -> vessel control state updated -> engines FixedUpdate() (thrust applied) -> gimbal FixedUpdate() (here thrust is rotated, but it's too late, so it goes to the next frame) -> physx update Compare it to control surfaces that do not suffer from this: physx update -> user alters joystick position -> vessel control state updated -> controlSurface FixedUpdate() that first reacts to control state and then applies aero forces -> physx update Thanks to the advice of The One I circumvented this in previous versions of KSP by moving ModuleGimbal to the very beginning of part config node. This way gimbal's FixedUpdate was called before engine's. How exactly did that work is still unknown to me, but it worked. Old code that did reordering: https://github.com/Boris-Barboris/AtmosphereAutopilot/blob/master/AtmosphereAutopilot/GimbalRearranger.cs#L52 Now it does not. Rearrangement of nodes does complete, but it is not reflected in the actual module instantiation order or module node order in save or craft files. I can only assume that the config I'm modifying is no longer the source of truth. I am once again seeking public council. Remember that the end goal is to make ModuleGimbal FixedUpdate be called strictly before ModuleEngine. I would gladly throw config node manipulation out of the window if there is a more elegant way.

One of the recent patches broke gimbal module rearrangement, so gimbals are once again tap-delayed one frame relative to player and autopilot input. This will cause oscillations under AA control. I'll see what I can do.