Boris-Barboris

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.

As always, throw in some logs. upd: make sure you have installed ModuleManager

I'm afraid that won't do, you'll need to at least add grabber unit or a docking port - both make the vessel one.

Both problems sound like craft that is too unstable. Try reducing com shift after munition dispatch and generally move com backwards. No, there is no gui option to advise with the information you've given.

My bad. On the topic: I took a timer and sat through the start of your video (where you claim to be in 5x rails warp) and sat watching the TimeToPeriapsis. 60 in-game seconds passed while ~6 seconds were measured by my timer.