The SteeringManager tries to tune things based on what it knows of the torque of the vessel, from information it gets from the API call ITorqueProvider.GetPotentialTorque().
(Search the code for "GetPotentialTorque" to see where it's using it).

The problem is that KSP returns inconsistent results for this call depending on what kind of torque providing part it actually is, and this is messing with the SteeringManager in cases where the majority of the torque comes from RCS rather than other sources.

Through experimental testing, this seems to be what it does:

• If the ITorqueProvider is a reaction wheel
  • Position of part from Center of Mass doesn't matter. Torque provided is magically constant regardless of distance from center of mass. This might actually be "correct" in the game universe if reaction wheels really do work this way in game.
  • Because position doesn't matter, returns a constant amount in all X, Y, Z axes. i.e. the vector returned is V(10,10,10) for a reaction wheel that provides a torque of 10.
• If the ITorqueProvider is an engine with gimbal
  • Position of part from Center of Mass matters.
  • Vector returned is in the reference frame of the ship itself, with the usual swapping of Y and Z axes that controls seem to have.
  • Magnitude changes depending on engine thrust, which seems correct.
• If the ITorqueProvider is an areodynamic control surface
  • Position of part from Center of Mass matters.
  • Vector returned is in the reference frame of the ship itself, with the usual swapping of Y and Z axes that controls seem to have.
  • Magnitude changes depending on speed and air density, which seems correct.
• If the ITorqueProvider is an RCS part
  • Position of part from Center of Mass matters.
  • Vector returned is NOT IN the reference frame of the ship itself. It appears to be in the reference frame of Unity's global world coords. As the ship rotates in space around the world coords' x, y, z axes, it keeps providing a different answer. Pointing the ship directly along the world X, world Y, and world Z axes returns values that appear to swap the 3 numbers around in the tuple exactly as one would expect if it was in the reference frame of world.

That last one is the problem. The code in SteeringManager seems to presume that GetPotentialTorque() always returns values in the reference frame of the ship. And that's true ... in all cases except for ModuleRCS for some weird reason.

Possible fixes. Pick one:

1. Continue using the stock call, but check for the case where the ITorqueProvider happens to be a ModuleRCS, and if it is perform a reference frame transform to fix this problem and make it give the answer in ship relative coordinates. Pro: least code change to kOS. Con: It's designing it so two wrongs make a right, which isn't very future proof if KSP ever fixes this.

2. Throw away the use of ITorqueProvider and just make our own. Pro: future-proof against KSP ever fixing the problem. Con: Duplicating KSP's code and thus not future proofed against a new type of ITorqueProvider coming out later that our homemade call doesn't know about.