Fix mouse control

No, I meant compounding, successive rotations about a vessel's own, fixed, cardinal axes from active torque input under the gyros, not passive switching between metastable orientations of minima of angular momentum formed by the mass distribution of a solid body that rotates inertially under its own rotational energy.

I don't think side-to-side is broken at all, at least not in the way I believe I understand you to be perceiving this. I think it's more an effect of your mouse control being organic, with your hand and wrist always making minute adjustments that lead to additional input that causes SE's truthful and unfiltered and uncompensated translation between your mouse movement and the character's (or ship's) rotation around its own, local axes.

Meaning, unless you move the mouse with protractor and ruler, unless you put the mouse in a perfectly aligned, controlled, robotic cradle with Cartesian locomotion that can guarantee the mouse is definitely moved in a straight line, and in a straight line only along its LR direction, unless you write some mouse control software that only generates movement purely in LR direction, some rotation is always going to creep into your input.

Of course, if you can show that you've seen to making your tests as reliable and repeatable as possible and the vessel or character is still rotating unreasonably and disproportionately, by all means, document and present as a bug. (Not feedback, hint, hint.)

FYI you can use the arrow keys instead of the mouse

It's definitely not the way I'm using my mouse. If it was, it would be a mix of pitch and yaw, not yaw and roll. There is zero pitch change when this happens. As far as repeatability, it's repeatable by anyone playing the game. Most have just gotten used to it as the way this game works.

I've seen others complain in the forums about it more than a few times, the answer is always to tap X to turn off your jetpack to auto-realign with gravity, but that only works if you're in gravity and only for the jetpack (not for fliers and not for anything in zero-G).

Yeah, well, but that's what happens when your up axis is no longer locked to remain aligned with the gravity vector. That's what happens when you come from the thousands of FPS games that have trained generations of players to blissfully accept an azimuth+elevation response to mouse XY that's firmly planted on the world surface, and that's what happens when this is no longer the case on account of your character now flying and hovering in 6DOF.

Unless you can present actual evidence, actual test results, that there is something not reacting truthfully to mouse input as it should be, then there is nothing actually broken that technically needs "fixing", your request there be some convenience function to actually switch such aforementioned alignment notwithstanding. It may not work as desired, but for all intents and purposes it would be working as designed.

Again: There is zero pitch change when this happens. The mouse controls pitch and yaw. Why is there no pitch change if what you're saying is true?

Aside from that, even if what you're saying made sense (it doesn't, see previous question), since when is this a 100% accurate physics simulator? (rofl) It's a game and saying that it shouldn't work like any/all other games makes no sense.

Edit: Real world examples where this does not happen: Aircraft (I've flown) and aquatic ROVs. I've never seen either of them roll when a yaw control is applied. Can you name a real-world situation where a rotation inducing control causes rotation in an unrelated axis? Also, it's a mouse that we're using to control a character and flying machines in a game. It's an input device that should have an expected output.

Yes, there is no pitch change, because you're compensating for it motorically and reflexively, without conscious thought, as a result of hand-eye coordination and FPS game UX training, and it's those compensations around your character's local coordinate system that make it rotate against the world's. You're still bound to human anatomy, not a robot's, that's why I said unless you can reproduce 100 % exact and true mouse motion along one axis and one axis only, you will still inevitably induce rotation around the forward axis in a UX system where a straight XY translation (the mouse's) is converted into rotation (the character's).

Yes, it is a mouse control we're using. And guess what fucking organic and inaccurate and obnoxiously full-of-themselves entity is moving that mouse: Yes, you, a human.

I don't care whether it makes sense to you. I don't care what you think the game "should" or "shouldn't" do. (At least not in this particular issue of contention.) I am happy to acknowledge that this is not how you or other players would like for the game to behave. However, this is how it is implemented and this is how it is working. (Unless you can demonstrate otherwise with hard evidence.) As such, it is not a bug and therefore does not warrant the choice of words in "Fix mouse control". Changed, improved, amended perhaps. But it's nothing that's broken in the sense there's a malfunction or unintended side function in the software.

Your so-called real-world experience doesn't apply, or at least doesn't transfer reliably. Aircraft (unless ludicrously inherently unstable but therefore highly agile combat planes) and aquatic ROVs tend to upright themselves passively, do they not? That's because they're (generally) constructed and ballasted, and when in operation trimmed, to be naturally stable around the high axis. Meaning, they naturally compensate for any induced rotation around the forward axis during yaw manoeuvres. (Besides, in aeroplanes, you actively go for a roll during a turn anyway … unless you have yet to progress to the lesson where they teach what a coordinated turn is? So, don't try to tell me you would even notice any unintended roll component in addition to the intended one. Worst case, you'd automatically lean the stick a bit more or a bit less long or far, but either way you return to the upright coming out of the turn anyway.) However, in SE in hover mode, there is no such self-righting effect, so don't try to skew this … discussion with anecdotes that at best sound impressive but conveniently lack other details necessary to prevent them from completely deflating in their value as applicable precedence. As you say, this is a game. Saying it should work like a real-life plane or aquatic ROV makes no sense. (See what I did there?)

You can wish for, and request, such an optional effect to be built into the jetpack or vehicle control, yes. (That's why I linked to an earlier suggestion (not a bug) of mine.) But making it sound like a bug report because you feel so strongly about it turns it into a (not really) veiled attempt at bullying the game designers and developers (and by extension all other players on the receiving end of any potentially resulting changes, including those who don't have a problem with that, at least not as big a problem as you have) into changing an implemented function just to suit your personal tastes.

And that's not something that is yours to do.

You are calling me full of myself? Dude, you need a mirror, apparently a really big one.

Enough with the tantrums about bugs. You are the only one who used that term (and used it repeatedly) in this thread. This is not filed under bug reports. It is filed under feedback, as in a suggestion or wish-list item.

As to my "so-called experience", yes, it absolutely applies. Aircrafts have ballasts? (rofl) Dude, you have no clue. As to "actively doing a roll", yes, manually, by pilot input. That's partly for efficiency and partly for comfort. It doesn't do it on its own. The rudder is for yaw, the elevators for pitch, and the ailerons for roll. You absolutely can use them independently, such as for compensating for very strong cross-winds while taking off and landing (something I've done). Did it cause me to roll? No, otherwise I wouldn't be typing this.

As to SE's hover mode, you obviously have the lack of comprehension that you accuse me of having, as I was not talking about hovering. There is no hover in space. The fact that it also does this in gravity wells does not make it about hovering.

The reason I brought up real-world examples is you keep trying to claim that the game is accurate to real-life. I asked you to give an example (I gave two), and yet you cannot.

The reason I brought up the fact that it's a game is... it is a game! For any system, real-life, simulated, or game, user input should be reflected by the expected output. That's a pretty simple concept.

As to bullying, there's only one person in this thread losing his mind, throwing insults, and acting like a bully, and it's not the person who started the thread.

I fail to see how you even come up with that line of thinking. I literally only have only one vote. How can I possibly be bullying the game devs when they won't see this unless there are 50 votes in 90 days (or whatever their threshold is)? Seriously, you have lost all credibility with that attack.

"I fail to see how you even come up with that line of thinking."

I can see that, Captain Obvious. Evidently even in the third iteration it seems to have eluded you that,

• user input is exactly and uncompromisingly reflected in the output, and it's the user input that is inaccurate and organic, not the reflection in the output
  
• a suggestion is nothing to fix, only bugs get fixed, no matter how much you filed it under suggestions

And the rest is just pure straw-manning.

Oh dear, I used the word hover, which you happily jumped at attacking by needlessly "correcting" how there's no hover in zero-g space … which is utterly irrelevant as, one, you yourself stated the phenomenon in question happens regardless of gravity, and two, there are only two relevant jetpack modes anyway, on and off, and the second one, surprise, also makes you not hover. Congratulations, you found an ambiguity in my choice of words, which I happily grant you. An acknowledged mistake. You know, acknowledged and mistake, something still foreign to your vocabulary on account of you either failing, or being unwilling, to tell the notional difference between "fix" and "improve".

Oh dear, I dared mislead anyone to infer planes always and by law need dead weight (as in, something that can qualify for a very conveniently narrow interpretation of the word ballast) and do so in the face of everyone in aircraft construction trying to save as much weight as possible to increase useful capacity. Yes, they do, and if not by said weight then by weight distribution within the design and construction. And yes, aircraft do use trim, too, where applicable. Gliders use adjustable ballast, and motor aircraft may shift fuel, or consume it at different rates, between tanks. Even a human packing cargo reasonably can count as trimming, if perhaps not as flexible during flight as other methods.

Oh dear, I got tempted into wasting more words on your so-called real-life experience than what was due on account of the hideously complex nature of aerodynamic flight and aircraft design and construction and emergent behaviour under the laws of physics in contrast with its relevance and applicability to a purely simulated, simplified, ideal, artificial and deterministic system. Is there aerodynamic flight in SE?? Is weight distribution a (functioning) thing in SE?? Are forces not aligned with CoM and resulting torques a (reliable) thing in SE?? No? Then why are you trying to argue with properties and behaviour from real nature and life in a system where they're not even applicable? Care to begin invoking things that are actually relevant? That's why I called them anecdotes. Congratulations, you got some fluff to tell at the campfire. Pat yourself on the back and bask in the gleam of the eyes of the unwashed PAX peasantry. In SE, it means something between fuck and all.

Oh dear, I got accused of not giving examples for something, while you got two. (Woohoo!) And why should that matter? One, on principle, I don't need to be a Michelin star chef to tell when the soup has too much salt. Two, examples for what again? For me allegedly claiming the game be true to real life? That's a lie, I never did such a thing at all. What I said (and keep saying) is that the game translates a real user's flawed and inaccurate and organic and constantly under the hand-eye feedback loop reflexively corrected, two-axis linear input unfilteredly (beyond technical necessity), and repeatably, reproducibly, and consistently (unless, again, proven otherwise with hard evidence) into three-axis rotational transformation, and that this inherently induces rotation in an axis not controlled by the mouse. Anything else is your irrational, impulsive, and who knows, maybe even intentional and malicious, misinterpretation.

So, what was that about credibility again?

I'm not even reading your responses anymore. You've lost all credibility with me and are now fully into harassment with your endless condescending insults. Go troll elsewhere.

If this is the level of toxicity in this forum, I can clearly see why people avoid coming to this forum to post ideas.

Yeah, sorry (not sorry) you can't handle being called out on your bullshitting.

glabifrons, I've tried this with a ball mouse (I'm old and I own one). I've removed the ball, and used the pickups to enter purely vertical and horizontal input. I cannot reproduce your issue. Yawing does not induce roll. Although pitching then yawing does put the engineer out of alignment with the horizon, that isn't due to roll, that's due to the pitch changing the yaw plane.

I admire your finding a platform that, one, runs SE and, two, has the peripheral support for the presumed PS/2 connector of a ball mouse. Or the outrageous luck to have access to the transitional curiosity of a ball mouse with USB connection.

See, that's how you do science. You examine the issue, remove, minimise, and/or control as many factors with a potentially disturbing influence on the test setup, and actually look what happens.

Not by shouting "but I saw it happen".

Let Dr. Neil deGrasse Tyson teach you about this.

My motherboard has PS/2 sockets. It's about five years old.