Guardian_Gryphon

You could try 3D printing a Navball if you have access to a 3D printer in any way. That still leaves the question of paint though... If you 3D print it as two halves that can screw together, you could coat each half in an appropriate color, then mark-in the guide lines, etc by hand. If you're looking for 3D printer access, check local universities and colleges. Some have 3D printing labs now, and will often allow you to make use of them if you pay for the plastic to create your idea, and bring an appropriate model in the appropriate file-type.

Do you have a joystick, gamepad, or any sort of other control peripheral besides the mouse/keyboard plugged in? Even if you're not using it? If so; it can be sending input spikes, and an EVA would not reveal this since peripherals are usually not tied to EVA controls. Are you on a Steam install? Have you done a complete clean-out and re-install? Are you running on a clean/new profile?

It is also possible that the pattern aligns with people who use Joysticks, and have no deadzone set. Previously this was not an issue; SAS locked you out, and any random control input spikes from joysticks got lost in all the higglety-pigglety of existing problems with the RCS wobble and whatnot. Now that the new SAS tries to be input friendly? If you have input spikes it has no way whatsoever of distinguishing those from intended manuevers, and KSP's controls set deadzones to 0 by default... I know that while I dislike issues to do with the 'Spongyness' of the system, it is still currently usable for me; but I did a clean re-install, started a clean profile, and set 10-15% deadzones on all my flight axes. Before? I had far more serious veering issues. Now? It's just the annoying sponginess. So it's quite possible that this is the intersection of installation-based bugs, of the system still being unrefined, of Joystick deadzones not being set, *and* of either directly SAS related bugs, or behavior that is 'working as intended' but just so generally disliked that it deserves some small tweaking. Personally, in Squad's shoes? I'd push a patch tomorrow that sets a small default deadzone on flight axes, and; A; Tweaks the SAS to actually lock to selected headings rather than the velocity vector B; Tweaks the strength of compensation it uses at varying times and in varying situations, to eliminate sluggishness. I'd be willing to stake a pretty penny that doing just those would fix all issues for 90% of users.

AH! You jogged my memory; I completely forgot to mention that at someone's recommendation, I added a small dead-zone to my joystick's flight axes (they do not come set with one by default). This may have contributed to solving some of my problems. Stick is a Logitech Attack-3; properly calibrated. I added what I'd guess to be a 10-15% dead-zone for all flight axes. (EG *not* my throttle).

Apropos my earlier post; I stuck some Soviet Voskhod-style freaky antennae to the side of my Kerbal-X-i's CSM; it held perfectly to on-orbit headings with SAS engaged, even when I randomly extended the antennae. I then launched a probe with a communication dish tucked inside a capped docking port (my cheaty way of putting a faring over a probe comm dish); I know from experience that opening the comm dish, once the docking port covers have been cycled open, messes with the physics in spectacular fashion. I can report that with an Inline SAS attached, the probe very quickly returned to the original heading I had locked it to when I opened the comm dish. However, I should note that it was not under thrust at this time, and therefore the issue with the velocity vector vs heading wouldn't apply. After further RCS+SAS testing with Kerbal-X-i and planes; I've found that the SAS is indeed, as others have described, woefully 'wimpy' when it compensates, resulting in it doing a very slow-ballet of ping-ponging until it finally reaches a locked state. I've also noticed that continued and thrice-accursed tendency to pull towards the velocity vector, rather than the actual desire heading, requiring micromanagement of the craft until the velocity vector and pipper are both aligned to the desired heading or node simultaneously. This can be most easily seen when trying to yaw violently, or complete a 'combat turn' (roll 90 degrees left or right, then pull elevators-up to turn) in a plane.

[Operating System]: Windows 7 (64 bit) [Memory]: 6GB [ASAS Trouble (Y/N)]: Yes [Mods installed, pre-patch]: None [Mods installed, post-patch]: None [Description of problem (keep it short)]: ASAS is 'spongy' and tries to settle on velocity vector instead of selected heading; eventually ends up settling midway between old velocity vector, and desired heading, as velocity vector moves to catch up, and ASAS moves towards velocity vector, resulting in the 'snapback' people are describing.

First I should note that I use the Steam version, have done a clean re-install, and am working under a brand spanking new test profile. I think that there may be five distinct problems being talked about in this thread (and others); People who dislike the new SAS/Reaction Wheels System purely because they don't understand how it works A Bug or bugs that are causing inconsistency with how the SAS and control systems behave with respect to different craft A Bug or bugs that are causing the SAS and control systems to behave in a 'squishy' manner (bounceback, etc) A Bug or bugs that are causing the SAS and control systems to be nonfunctional resulting in extreme veering etc (Perhaps Steam Related?) A bug or bugs (or working as intended, but very poorly designed behavior) that cause slightly asymmetric craft to veer, and the SAS to fail to correct. I initially experienced #4 on my first pass with 0.21, but a clean re-install and remembering to place electrical systems on my craft has fixed this issue. I continue to experience #'s 2 & 3 at this time; I have done the 'Aeris test,' and done some flying with the Ravenspear and my own jet design and noted extreme inconsistency with the behavior of the SAS, as well as frequent 'spongy' or 'squishy' behavior. I have flown a Kerbal-X to orbit, as well as an 'improves' Kerbal-X with an added RCS system and Inline Advanced Stabilizer. Both exhibit the sponginess in the SAS, and severe under-compensation when trying to correct and hold a heading. I rebuilt this part-for-part based on your images and it flew straight up with no veering or wobbling in the slightest in my current clean-install/new profile. Someone else commented that you're using tailfins; that's incorrect, those are actually 'Standard Canards,' and do in fact articulate and can be used to control a craft. I added some asymmetrical parts to the craft to test for ascent issues, and found none. I do not know for sure how this would behave on-orbit in a maneuver however. I then proceeded to add a small asymmetrically placed engine to see if my SAS could correct; it absolutely could not. Thoughts in total? There are two main issues here; the one that certain users are having where SAS does not function period, and the one many more in total are having where SAS is just behaving poorly, while still technically 'functioning.' I really dislike the way the SAS seems to treat your velocity vector on the navball as your heading, rather than the spot at which you let off the controls; that is my main gripe with it at present. Secondarily, I'm concerned about the orbital issues people have described. I'll be taking my Kerbal-X-i up shortly to test some of these and will get back to you with results momentarily.