mojira.dev
MC-15120

Very quick spinning of entire view

This is exactly like the MC-13024 "bug", which was closed for being "invalid". However the "invalid" verdict is in itself not valid at all. See below!

Yes, I can confirm that this is occuring "mostly" because of some optical mouses.

BUT!

The statement that "this is not a Minecraft issue" is invalid because: (please read fully, detailed bug behavior explained after why this should be fixed)

For any input type, wether it is keyboard or mouse, any software should definitely check for its desired "valid range" of input values, and accordingly adjust the input to let through only good data likely to produce desired results. Undesirable input, especially known sources of bad input from users or independent third-party, should in all cases either be prevented or modulated.

If Microsoft Windows was coded using the "this is a mouse input issue, not a Windows issue", then the same kind of thing would also occur, at the same kind of frequency, on the Windows desktop, and we'd get wild mouse pointer mouvements because Windows would stupidly "simply follow suit", believing that all input from the mouse hardware "is and should be perfect".

If all other freaking games were also coded using that same "philosophy", then all of those other games would ALSO give seizure-inducing wild spinning because of overly-sensitive hardware. Most games don't, which is proof enough that the professionnal game makers actually do see this as something that needs to be adressed.

If sound systems and cell phones were designed with the same "philosohy", then users would constantly hear constant noisy scratches and interference-like white noises coming from such devices, because the software designers thought that simply taking the input directly and for granted, without trying to filter it at all, and then put the fault of bad sound on the bad microphones hardware of the other cell phone companies, or a bad connection, was a sufficient reason.

If passenger airplanes and jet planes were designed in this manner, thousands would die each year because, when the pilot does a "bad manoeuver", instead of refusing or modulating the input to within the plane's tolerance levels, the plane would simply wildly try to "follow suit" doing impossible moves, and then of course something would break and the plane would crash and burn. And then trying to say "But it's not the fault of the plane, it was the fault of the pilot!" just wouldn't cut it, wouldnt it?

Forgetting to filter input to within playable levels is a bug, in the very same sense that "assuming" that a variable "should" fall within a range of values normally going from X to Y, and then seeing the game crash because, of course, the coders deliberately dismissed that there are in-game ways to make that variable go outside of that "valid" range anyway, will also end up causing bugs. This wild spin is just that: one more of those bugs caused by failing to predict and to deal with invalid input value ranges.

And this bug here occurs QUITE OFTEN ENOUGH. I suffer from it wildly and all the time, in fact every few minutes of play, major annoyance all around. Sometimes it lasts for several seconds or even FOREVER SPINNING UNTIL I MOVE MY MOUSE AGAIN.

It happens more to some mouses, especially optical mouses and other very sensitive input devices. In the case of an optical mouse it is caused by the mouse being moved ever so slightly "off the surface" on one side (front, back, or actual mouse sides), thus making the laser go "off" it's right range of values and maybe output "infinite or division by zero" values. Or something way beyond the normal range. Only the tiniest fraction of a millimeter is needed to cause this. and the way a user holds his mouse will have a great impact on the frequency of this happening, so it's not just the mouse hardware it's also the way the user holds his input device when playing games.

In short, this is simply a signal spike of some sort. SIMPLE TO DETECT. This is what causes all those input devices to send off wild input signals, and Minecraft stupidly chooses to simply "follow suit" with that grossly bad input data.

The game should EASILY be able to tell when the player movement is a wild spin for seemingly no reason at all, and prevent it altogether.

It happens a LOT more when moving the mouse towards looking up or down. In those directions, the tiniest mouse movement can generate a LOT of on-screen movement. Something feels just plain WRONG with the way Minecraft handles mouse movement in those directions.

Seemingly, Minecraft just forgets to poll the mouse again until the next "true" mouse movement event. That is why this glitch can occur for seemingly LONG times. If an input data "spike" occurs right before the mouse stops moving, then you're in it again for a wild spin again, ether looking straight up or down (but even sometimes at eye level too).

If Minecraft did this polling check (not a few times per second but actually tens of times per second - either as fast as the mouse hardware allows or at least tring to check twice as fast as a good human reaction time, because the mouse is a critical input stream and should be treated as such), then Minecraft would easily be able to take note of when such "wild input" becomes brief spikes that fall completely out of the mouse acceleration input value from "right before", flag it, and if in the next few instants the spike is confirmed as such (the acceleration not position values just as suddenly return to within near their previous range), then it would be able to correct what the hardware failed to do and return the view to what it would have been without the spike, with only a "normal" amound of rotation instead of always getting a super-fast wild spin.

And by polling frequently using mouse acceleration instead of position, Minecraft would also be able to STOP any spinning, too, as soon as the mouse would become immobile again. Currenty, it is unable to do so, how can you not see that as a bug is beyond me.

Windows does this filtering.
All other games do it too.
DVDs do it between reading the signal from the DVD and transmitting the image to a TV screen.
Sound systems and mobile phones do it between getting the sound from the airwaves before sending the sound to their speakers.
It is also done for plane control to avoid pilot errors.
etc.!

It is called [ Noise Filtering ] and is an elementary coding practice. Failing to do it is a buggy behavior, definitely not a feature "working as intended"!

Linked issues

Attachments

Comments 45

Can you please try with the latest snapshot http://mojang.com/2013/05/minecraft-snapshot-13w18a/ ?

Please force a crash by pressing F3 + C for 10 seconds while ingame and attach the crash report here.

Ok, sorry for that hothead flaming rant, that bug constantly making me go bat crazy isn't a real excuse to me having used such harsh accusating language. Anyway it seems like the Mojang team is becoming more and more professional-like each passing year. So thank you very much for keeping your cool.

Ok, the game never actually crashes because of this bug. However, I'll try to reproduce the "forever spinning" thing. It occurs way more often when I have to make frequent turns, especially turns going up and downward (like in the typical Minecraft maze of underground caves and tunnels).

Well, the spinning itself occurs often enough - and probably from a combination of the way I usually tend to handle my mouses + the way the optical mouse send their output signals when their lasers gets "oh-so-slightly" pulled off from the desk, especially if done at a very slight angle with the other side of the mouse still firmly pressed against the desk. Like when you turn somewhat rapidly.

The bug seems to occur much less often when I manoeuver because of outright panic (mobs or other danger nearby, in a hurry to get somewhere, etc.), again probably in these situations my nervousness probably causes me to put more pressure on the mouse, firmly "anchoring it" on the desk surface, by opposition to moving it with only very light pressure, by almost "holding" the mouse.

I'll make more regular backups of my world. When the bug happens again through normal gameplay (and it is sure to happen often enough) I'll try to suddenly "not touch the mouse anymore" when it happens, and if it falls in the "forever spinning" mode, then I'll have the 10 seconds needed to fully crash-report-grab it.

HOPEFULLY Minecraft stores more than 10 seconds of debug data, so that you'll ALSO get the entire event including the "before it happens" input data too. IF Minecraft does NOT store more than 10 seconds of crash report, please tell me. If it doesn't even store 10 seconds, and only provide a "snapshot" of things in it's crash report game data, then please tell me also. I'll adjust the way I try to grab the crash report accordingly in order to give you the best type of data possible.

However, since the 13w18a snapshot also requires the new launcher, and that it seems that this is not a bug shared by most players (meaning, not a priority-one bug for most players), can I wait until the next official release (1.5.3 or 1.6, I guess) in order to do and provide this crash report? That would simplify things a lot for me as I never play anything other than the official releases and having both launchers and an official release and a temporary update at the same time seem quite complicated for me. Strangely enough while I'm very good with algorithms I also am crappy with system configuration!). So even though the bug is making me go annoyed-crazy often enough, I'd prefer enduring it a little more and test properly using a true release. Is that okay?

Then I'll post the results here.

IF the bug stops happening completely, then I'll also post this information here.

Thank you.

That crash report doesn't store any historical data, it's just a snapshot, but quite handy to get information about your computer (versions etc), so it doesn't matter when you force the crash, but please do it.

The question if that issue is still in 13w18a because in that version the libraries behind Minecraft are updated (and those older libraries are quite error prone regarding input devices).
You can download the 13w18a, test it (e.g. with a newly created world) and delete it again until the next official release.

Ok, understood!

Man oh man, it would be just so wonderful if the new input device librairies solved this! I hope it's not a problem with Vista!

I'll definitely do the crash report thing test on the latest update and then post the full results here.

Thanks!

I can confirm for 13w18c.

35 more comments

This is not solved at all.. LOTS of ppl still got this issue.

Can confirm that this is still an issue. This should not be marked as Resolved.

notchplsfix?

Edit: If I remember correctly, this only became an issue when using Java 8.

Edit 2: Electric Boogaloo. Who would've guessed that cleansing my system of everything MC and java related and doing a fresh re-install would have fixed the problem. I had to use revo uninstaller, apparently the installer .msi packages have the same name regardless of version. Whole different issue.

If you have a legacy install (from before 1.2-ish or 2014-ish) try backing that up to a different location, preferrably in a .zip or other archive, nuking everything java and MC, and re-installing.

Is this fixed in 17w43a?

 I have this problem on Minecraft 1.16.5 / Java 1.8.0_51

An attachment with a disallowed file extension has been removed from this ticket.

Executable files and documents are not allowed as attachments.
Please attach crash reports, log files and screenshots as they are instead of pasting them into a document.
-- I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit

Patrick Rannou

(Unassigned)

Community Consensus

Minecraft 1.5.2, Snapshot 13w18c, Minecraft 1.6.1, Minecraft 1.6.4, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 1.7.4, Minecraft 14w02b, Minecraft 14w02c

Minecraft 1.7.9

Retrieved