SAS overrides kOS raw input.

[allmhuran]

As things stand right now, raw input will have no effect on a craft if SAS is on.

This does not behave the same way as user input through a controller. When user input is provided, SAS disengages itself on the axis (or axes) receving user input, but stays enabled on axes where no user input is provided. In this way a user can still steer a ship with SAS on, while SAS maintains stability on the axes without user input.

The suggestion would be to either update the raw controls page on the doc site to reflect that this is the case, or alter the implementation so raw control does in fact act like pilot input.

The raw control page (http://ksp-kos.github.io/KOS_DOC/commands/flight/raw.html?highlight=raw%20control) currently states that control:yaw will (for example) "start pushing the ship to rotate a bit faster to the right, like pushing the D key".

Here is a quick gfy demonstration http://gfycat.com/ImportantDeadlyBushbaby

[hvacengi]

I've looked into this a little bit. It looks like we may be able to use a OnPostAutopilotUpdate event to update the flight controls. I haven't tested yet, but I'll add it to my list of modifications to be made with other steering updates I'm doing (see PR #1544). The entire system that manages vessel controls is going to be updated, including new event dispatching, so this would fit into that update nicely.

[GER-Space]

I tested it to replace all instances of OnPreAutopilotUpdate with OnPostAutopilotUpdate and it fixed the issue and I saw no more fighting of the steering_manager with SAS activated.
Should I create a Pull Request for it?

[hvacengi]

I had forgotten that this issue was in the queue of things that need to be fixed. I would rather not simply make a blanket replacement to use OnPostAutopilotUpdate on two counts: 1) in my connectivity update PR the method for subscribing to autopilot events changes, making it harder to simply swap out the event. 2) Changing all instances of this will cause lock steering which works with SAS to be one tick behind. That may be fine, I'm not sure. But no matter how we slice it, it should be addressed using our new subscription model. Perhaps I'll simply add a 2nd event subscription method, one for pre and one for post.