Kerbal Space Program

He meant to say target/anti-target, which has nothing to do with speed, and only with relative position, which shouldn't cause erratic behavior unless targets pass through each other. I understand what you're saying, Rex. The bottom picture is correct and reasonable behavior. Note the greyed out prograde/retrograde buttons. (Although I notice the speed is 0.3m/s, not at or under 0.2) There's no reason for the target/anti-target buttons to be greyed out like in the top picture, though.

The resetting of the SAS to Stability assist only at or around 0m/s was an introduced and intended feature to prevent wild automated control inputs for all modes. The feature is working as designed as mentioned in the related issues. However, if it causes undesirable, or unwanted effects, please raise a well reasoned and comprehensive feedback item so that can be appraised, and forwarded to the developers.

Spamming the tracker with duplicate issues, or in a confrontational manner does not help here. I refer you to the overview and the Bug reporting guide where the expected level of communication is outlined. Please frame your reports accordingly.

I agree this particular report is not well written and the follow-on (#5925) could have been put more politely, but with all due respect, you don't encourage users to cooperate with you when you ignore their comments pointing out that you've mishandled the issue (see my comment 6 in bug #5022).

With equal respect, the behaviour is according to design, so it is hard to justify this report as a bug.

It can be conceded that the behaviour is not necessarily helpful in this instance, and a modification to it may make docking and rendezvous that much easier, but that could also be seen as subjective, and may have impact on other scenarios where the converse would be as equally unhelpful.

We can only deal with factual and comprehensive reports here, not out of personal preference, but due to time constraints from the volunteer testers, and ultimately the developers perspectives. Clear cut repeatable bugs, reported completely and concisely, are the easiest to deal with of course. Subjective, gameplay issues can be complex, and need even more information and explanation. The better a case is presented, the easier it is to push forward. Suggestions for improvements in a balanced manner - weighing the benefits against the repercussions - are most welcome. Code changes need careful consideration for the time to implement and the impact or collateral damage that may occur.

I have hinted already that this may be better framed as feedback, and this is now a strong suggestion bearing in mind the further hints above. This issue has not been ignored deliberately, it simply has not fallen into scope during recent changes, so it would have been hard to push for what might seem an arbitrary change that would have taken time away from the other planned works. A concise and rationalised case for change can be dealt with and planned for more efficiently.