Kerbal Space Program

This is actually a manifestation of an issue as old as Control Surfaces in KSP. I've checked against KSP 1.2.2 and it behaves the same.
The issue is about the placement of Control Surfaces in relation to the CoM of a vesel. When they are backwards (in relation to the velocity vector) all is fine, control works correctly on all axes. But when placed forward of the CoM, Control Surfaces work to keep pitch and yaw, but do in reverse about roll.
In the attached picture, please notice how the forces around Control Surfaces at the front (circled in orange) go in one direction, but those at the back (circled in green) go in the opposite way. SAS is actually trying to stop the roll movement, but its orders are used backwards.

Attached some more screenshots that better show the problem. Showing a plane with 4 control surfaces mounted atop (numbered 1-4 in purple):
- 1 is back of CoM, rotated forward (in relation to the velocity vector)
- 2 is back of CoM, rotated backwards
- 3 is ahead of CoM, rotated forward
- 4 is ahead of CoM, rotated backwards

In shot1132, command is full Roll CCW (highlighted green). As visible, two control surfaces at the tip of the wings (L, R in yellow) are providing the actuating forces in the correct directions. As with the Control Surfaces 1-4 under test:
- 1 and 3 provide a CCW force (seen leftwards from the top of the plane), which is correct;
- 2 and 4 provide a CW force, in the wrong direction.

In shot1134, command is full Yaw left (highlighted green). All Control Surfaces 1-4 are providing a force to the left, which effects the plane as follows:
- 1 and 2 being back of the CoM, the force effectively yaws the plane to the left;
- 3 and 4 being forward of the CoM, the force yaws the plane to the right, wrong direction.

jclovis3 wrote:

So it would seem that even an option to reverse direction of controls with an action group would have the consequence of messing up pitch and yaw to fix the roll. The answer then would be a smarter SAS. We have to assume there will be navigation sensors that detect wind speed and direction, and that the programming in a stability system can use that data to make correct decisions about how to actuate the control surfaces. Either that, or make SAS refuse to engage if it detects unstable flying conditions like flying backwards, or a flat spin.

Is not a function of SAS to provide different input to the different actuators. This issue is specifically about Control Surfaces (CS): it is within ModuleControlSurface to compute, among all else, the vector of the airflow in relation to the CS and the displacement from CoM, then to transform based on those the required rotation (for the whole Vessel) computed by SAS into a deflection value. This for each single CS.

The question is rather, if this is to be considered a bug (in ModuleControlSurface), or the request for a feature able to autocorrect player errors in the use of CS (placing them backwards and expecting them to work in a retrograde attitude). As I wrote above, this is as old as CS were introduced: one may think it's time to improve, but is hardly a priority for developers until more important stuff is all dealt with.

Now let me provide also the analysis about pitch (screenshot1146):
- 1 and 3 (facing the airflow) are correct, their force rotates the plane to pitch up;
- 2 and 4 (backwards) provide a force in the opposite direction to what required.

The SAS control system was originally designed for orthodox flight conditions and not to automatically switch when conditions change.

This is clearly now a feature request. It is a good one, but is also complex and has many other consequences, so must be evaluated fully.

I have changed the tracker type and title to reflect this.