View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0025429 | AI War 2 | Gameplay Issue | Jul 17, 2021 4:04 pm | Aug 3, 2021 11:31 am | |
| Reporter | Daniexpert | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.313 Input, Selection, And Flagships | ||||
| Fixed in Version | Beta 3.502 Input Salve | ||||
| Summary | 0025429: Extremely annoying delay between right clicks | ||||
| Description | After the selection rework I noticed an annoying delay when placing structures, especially turrets which I place clicking fast. Right now there is an almost 1s delay between one click and the other; if you click faster than that, the game will just ignore the input. This delay is probably on any type of input you can give in game. | ||||
| Tags | No tags attached. | ||||
| related to | 0025436 | resolved | Chris_McElligottPark | Orders being on key-up is eating a lot of my inputs |
|
|
There are also issues where the GUI and ship selection completely disappears, forcing me to reload the game to be able to control the ships again. |
|
|
I get a feeling this is due to the double-click implementation. IF solving that proves too difficult (conflicting features and what not) I suggest scrapping the functionality to attack from the galaxy map which IMO, won't get used nearly as much as the new "zoom to object", and use right-click to zoom from galaxy icons to their corresponding planet map object. |
|
|
Okay, so what is happening here is that it's "eating" these commands because of how quickly the mouse is being moved. I just tested this out on my own machine, and I can definitely duplicate it. Essentially, in recent versions I set it to only register a mouseup if you are within 60px (dpi adjusted) of where your mouse button went down. But our hands are much faster/slower than that (faster on moving the mouse sideways, slower on moving the mouse down). I implemented this logic for two reasons: 1. For double-clicking, but I don't really have to have that part of it for that. It is true that if you are double-clicking, you need to keep your mouse cursor within a small area or it should not be counted, but that doesn't conflict here. 2. The second thing was more esoteric. For people who want to use their right mouse button as the "grab and pan" button (there was one guy), I was trying to make it not also trigger right-clicks for him. Somehow C&C manages to do this, but I am not sure how. I reasoned that essentially if you are clicking and holding the right mouse button and flicking your screen to the side, that might still be a very short event but involves a large movement. So I have it filtering those out. Unfortunately, flicking your screen while holding down the mouse button looks a LOT like rapid-clicking orders around on the screen. I don't know what the proper solution is, but that guy will just have to get used to using the middle mouse button. For the rest of us, I need to take the distance restriction off for sure. I spent most of my time with this input stuff testing things in the interface, or the galaxy map, where you don't move your mouse much on purpose because you're precisely clicking. I missed this on the planet view. |
|
|
Thank you! * Vastly updated the input code once again. ** First, there's no time limit related to single-clicks anymore. Mouseups, that is. ** Second, we now once again use mousedown for detecting when you click, rather than mouseup. That just feels way more responsive. *** This does mean that, definitively, you can't bind something like the grab and pan to the right mouse button without it also triggering the right mouse click. You'll need to use the middle mouse button, or mouse4 or 5 if you have those. ** Third, In the mouse event handling code in particular, we now handle ALL of the events that come in a frame, which includes double-clicks and single-clicks from either button, all at once if needed. This is something that has a lot of common with the central windows pipeline pump, and should keep certain things from otherwise being blocked. ** Third, the way that we activate bandbox selection mode is a bit different now, and more responsive. There were some funky bits in the code in general that just needed to get ironed out. ** All in all, things just feel a lot more responsive now, and the double-clicking logic still works just fine. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jul 17, 2021 4:04 pm | Daniexpert | New Issue | |
| Jul 17, 2021 4:07 pm | Daniexpert | Description Updated | |
| Jul 17, 2021 11:31 pm | Zweihand | Note Added: 0062497 | |
| Jul 19, 2021 1:54 pm | Daniexpert | Relationship added | related to 0025436 |
| Jul 20, 2021 12:23 am | Asteroid | Note Added: 0062522 | |
| Aug 3, 2021 10:15 am | Chris_McElligottPark | Note Added: 0062555 | |
| Aug 3, 2021 11:31 am | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Aug 3, 2021 11:31 am | Chris_McElligottPark | Status | new => resolved |
| Aug 3, 2021 11:31 am | Chris_McElligottPark | Resolution | open => fixed |
| Aug 3, 2021 11:31 am | Chris_McElligottPark | Fixed in Version | => Beta 3.502 Input Salve |
| Aug 3, 2021 11:31 am | Chris_McElligottPark | Note Added: 0062558 |
