Boris-Barboris

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.

No such thing. It's 4x.

Fyi non-retracted gears affect the graph.

6. Do devs posess actual profiling data for the large vessel case? Can they publish it here? To the OP: 3). You would get another game, though it would indeed perform better. Joints are integral part of KSP from the very beginning, a lot of players like it, it will not change. What you propose is the path Space Engineers took btw. Space Engineers performance may be assessed by this meme (rather old though, but you get the idea, there is always trouble when game has any physics): https://imgur.com/PetIf9p 4). https://forum.kerbalspaceprogram.com/index.php?/topic/96670-14-253-2018-04-06-ubiozur-welding-ltd-continued/ 5). > Does the game separate calculations like lift from bending/breaking forces? yes. Before the integration step is made, KSP game code appends forces (drag, lift, gravity) and torques (SAS) to rigid bodies that will be accounted for by PhysX iterative solver. All that and joints and collisions on top of it are then calculated in said PhysX iterative solver under no direct control of KSP devs. > I can't help wonder if we (do/could do) frame-by-frame calculations for the bending forces, and the lift and the drag in separate threads, with the lift and drag's calc's taking the previous frame's bending outputs. yes, though Unity makes multithreading unreasonably hard. Measures that make it possible under Unity may well outslog the benefit of threading. Profiling is king here. Also, it implies devs caring at this point. Game's life cycle is far from it's zenith. > Yes the lift would be a frame behind, but would the player notice at 25+ fps that would result from threading it? Or even at 2 fps. yes. Such integration scheme is not physically correct and makes little sense. There will be planes that should fly and wich will not fly under such physical laws, they will become unstable. Control code will stop working as it is now. Manual control will feel unnatural with additional lag. It would be a nightmare.

If you have questions, PM me. PID peasants REEEEEEE

Batch-editing save files and vessel designs using text processing utilities. Windows Powershell should look something like (for the case when you have just uninstalled AA and didn't launch the game yet): $saves = Get-ChildItem -Recurse "C:\Steam\SteamApps\common\Kerbal Space Program\saves" -include *.sfs,*.craft ForEach ($file In $saves) { $file.toString() (Get-Content $file) | Foreach-Object {$_ -replace 'SyncModuleControlSurface', 'ModuleControlSurface'} | Out-File $file } Paste this code to some file, for example aa.ps1, insert your particular path to KSP in the first line and swap SyncModule... and ModuleControl... if you are installing AA instead of uninstalling. Run powershell, go to directory where you have the script and launch it by typing ".\aa.ps1" (without quotes). If you're on Linux, I'm sure you'll cope with the task on your own. upd: and you can restrict it to only one save by specifying it in the first line, like "...\saves\MySave"

dead the video is

Yes. But, please, test it.