Ticket #539 (new defect)
Game cursor state is not consistently reset
| Reported by: | sergiovier | Owned by: | |
|---|---|---|---|
| Priority: | If Time Permits | Milestone: | Backlog |
| Component: | Core engine | Keywords: | gui simple |
| Cc: |
Description (last modified by k776) (diff)
When you are playing, select a soldier and click over a tree, appear an wood icon. If you press ESC key and quit of the game to main menu, this icon persist in this place
Edit: The same bug can occur when pressing F10 to open the in-game menu
Change History
comment:4 Changed 3 years ago by k776
No longer valid. In the next release, ESC closes menus, it doesn't open them.
comment:5 Changed 3 years ago by Philip
- Status changed from closed to reopened
- Resolution invalid deleted
- Milestone changed from OS Alpha 2 to OS Alpha 3
The same bug can occur when pressing F10 to open the in-game menu (the cursor doesn't change back to default unless you move the mouse, and if you somehow exit to the main menu without moving the mouse then I believe it'll be stuck on the wrong cursor since nothing will try to reset it).
I'm not certain what's the best solution. Maybe the cursor changes should be scoped to the current GUI page, so session cursors can't leak out, and/or maybe we should send mouse movement events when showing/hiding pages (even if the mouse didn't really move), so the session code doesn't forget to set its cursor after changes.
comment:10 Changed 2 years ago by historic_bruno
Technically this could happen anytime you switch GUI object focus without moving the mouse. Hard to do now, but if we add something like tab focus switching between GUI elements, then you'd potentially see this more often. Maybe scoping the cursor somehow is most correct, but it seems like just as good or better of a solution to send an extra message when GUI focus changes (assume the mouse should move to cause this, even when it doesn't).
I've not looked in great depth at the code responsible for this, but perhaps key presses in addition to mouse movement, could trigger a cursor update.
comment:11 Changed 2 years ago by Philip
With focus changing, e.g. when opening the chat box under the mouse, the cursor doesn't change to the correct (default) cursor until the next input event (e.g. the key release event). I think input.js handleInputBeforeGui is setting mouseIsOverObject which determines whether to show the default cursor or the world-interaction cursor; the problem is that the mouse might become over an object (e.g. when the chat box pops up) without handleInputBeforeGui being called so it doesn't notice.
Maybe we should add some new engine function so updateCursor can tell if the mouse is currently over an object, rather than relying on the value from the last call to handleInputBeforeGui.
I don't think the same solution would work for the issue when exiting to the main menu, though - in that case the session GUI code stops running entirely so there's nothing to revert the cursor.
comment:17 Changed 12 months ago by historic_bruno
- Summary changed from take wrong icon (pointer) in menu of the game to Game cursor state is not consistently reset
comment:18 Changed 6 weeks ago by historic_bruno
#1904 was a duplicate of this.

Milestone Unclassified deleted