View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0028412 | Heart Of The Machine | Bug - Gameplay | May 25, 2024 11:22 pm | May 27, 2024 10:32 pm | |
| Reporter | Bobtree | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.521 Mental Energy Visibility | ||||
| Fixed in Version | 0.523 The Sunday Testers | ||||
| Summary | 0028412: mouse clicks in the world sometimes fail to register | ||||
| Description | This only happens when clicking in the world, to move/select/deselect units for example, or on the city map. It never happens clicking on toggles in the settings menu or main UI buttons. Those don't seem to care how long you click or whether you move the mouse. It seems to happen a lot more at 30 FPS (via in-game Framerate limit setting), and not when my Framerate is set to Vsync (144hz G-Sync display). It's rare at 60 FPS, but if you play a bit at 30 FPS it happens just often enough to be annoying or make you wonder if your mouse is failing. Click and hold always seems not to select/deselect. That seems ok, but the code might be related to this issue. Likewise, a long right-click will not cause unit movement, and a long left-click always lets you rotate the view. | ||||
| Tags | No tags attached. | ||||
|
|
....ooh. This is probably related to the amount of time the game expects for a mouse click to register. If you're not brisk with your clicks, then it registers it as a click and hold. And in general, at a lower framerate, the precision of understanding how long a button was down is a lot more coarse, so even if you ARE brisk with your clicks, it's going to have failures. This is quite a critical discovery, thank you for that. |
|
|
Thanks! * The general timings for what is considered a mouse click have been increased for the main game view. Things are not selected on mouse down, but rather on mouse up when there is not too long of an interval. ** The other part is that the mouse cannot have moved too far during the click, or else it's considered to be a drag operation rather than a click. These have also been doubled. ** So far I don't notice much of a difference, personally, but I can be much more deliberate about my clicks. The concern of unintentionally registering clicks when clicking to drag currently does not seem to be an issue. ** Please let me know if this isn't working out for your specific setup well. Please reopen the ticket or open a new one if this doesn't solve it for you. |
|
|
I think the 0.522 patch made it worse. It's easier to trigger a miss now than before, and it seems to happen with very fast clicks (as in short duration). Maybe the mouse down+up messages are landing within a single 30Hz frame (0000097:0000033.3ms window) and getting filtered out somehow? I can't get a miss in my text editor or the HOTM settings toggles with the same technique. This is imprecise and tiresome to test, and I won't be normally playing at 30 FPS. I suggest reverting the change and leaving this alone until it affects other players. |
|
|
That bit in parentheses is supposed to say "approximately 33.3 millisecond window", but some bit of webform magic turned the "~" (tilde symbol) + "33" into an erroneous link. |
|
|
Thanks! * Reverted most of the changes from the prior build related to the mouse click detection in the main game. They evidently made things worse. ** I did keep the relaxed "area your mouse has to stay in during a click," to help with folks who have shaky hands, if that winds up being a thing. It shouldn't hurt anything. * Added in another adjustment to the mouse click detection, which should solve a case where, at low framerate, if your mouse click was faster than two frames, it would not register in the main game map. ** Essentially, if it was down one frame and up the very next frame, then it would not register it as a click, which was an error. But one that was almost physically impossible to hit at 60fps or higher. ** I had thought that this was a problem with slow-clickers, but actually turns out this was a problem with fast-clickers. Near as I can tell, pending feedback about any further problems. Please let me know if you experience any further issues, either with reopening this ticket or opening a new one. |
|
|
I think the 0.523 fixes did the trick. |
|
|
Sweeeet! That's wonderful news! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| May 25, 2024 11:22 pm | Bobtree | New Issue | |
| May 26, 2024 12:38 am | Chris_McElligottPark | Note Added: 0068655 | |
| May 26, 2024 12:38 am | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| May 26, 2024 12:38 am | Chris_McElligottPark | Status | new => confirmed |
| May 26, 2024 1:38 am | Chris_McElligottPark | Status | confirmed => resolved |
| May 26, 2024 1:38 am | Chris_McElligottPark | Resolution | open => fixed |
| May 26, 2024 1:38 am | Chris_McElligottPark | Fixed in Version | => 0.522 Earlier Contemplation |
| May 26, 2024 1:38 am | Chris_McElligottPark | Note Added: 0068668 | |
| May 26, 2024 3:48 am | Bobtree | Status | resolved => feedback |
| May 26, 2024 3:48 am | Bobtree | Resolution | fixed => reopened |
| May 26, 2024 3:48 am | Bobtree | Note Added: 0068675 | |
| May 26, 2024 3:52 am | Bobtree | Note Added: 0068676 | |
| May 26, 2024 10:35 am | Chris_McElligottPark | Status | feedback => resolved |
| May 26, 2024 10:35 am | Chris_McElligottPark | Resolution | reopened => fixed |
| May 26, 2024 10:35 am | Chris_McElligottPark | Fixed in Version | 0.522 Earlier Contemplation => 0.523 The Sunday Testers |
| May 26, 2024 10:35 am | Chris_McElligottPark | Note Added: 0068682 | |
| May 27, 2024 5:51 pm | Bobtree | Note Added: 0068765 | |
| May 27, 2024 10:32 pm | Chris_McElligottPark | Note Added: 0068784 |
