Mouse mapping support #741
Conversation
lightmanLP
force-pushed
the
feat/mouse-mapping
branch
2 times, most recently
from
df0a498 to
9a9c219
Compare
lightmanLP
force-pushed
the
feat/mouse-mapping
branch
from
f78eda8 to
00a4da7
Compare
There was a problem hiding this comment.
overall stuff is looking good! left a few comments (some you already had todos for)
i wasn't able to test this out locally (now that the resourcefilter stuff landed it seems the soh side of that will need to land before testing this is straightforward), but i was hoping to test out what the mapping experience - specifically what happens when this popup is visible
and someone clicks on (or misses when trying to click on) the cancel button
| bool ControlDeck::KeyboardGameInputBlocked() { | ||
| // block keyboard input when typing in imgui | ||
| return AllGameInputBlocked() || ImGui::GetIO().WantCaptureKeyboard; | ||
| ImGuiWindow* activeIDWindow = ImGui::GetCurrentContext()->ActiveIdWindow; | ||
| return AllGameInputBlocked() || | ||
| (activeIDWindow != NULL && | ||
| activeIDWindow->ID != Context::GetInstance()->GetWindow()->GetGui()->GetMainGameWindowID()) || | ||
| ImGui::GetTopMostPopupModal() != NULL; // ImGui::GetIO().WantCaptureKeyboard, but ActiveId check altered | ||
| } |
There was a problem hiding this comment.
just curious - why does the keyboard game input blocking logic need to change for mouse support?
There was a problem hiding this comment.
If you hold mouse down, ActiveId changes from zero and locks keyboard inputs
There was a problem hiding this comment.
so this is codifying "we want to block keyboard input when mouse is held down"? the previous logic here was "this is when we don't want to send keyboard input to the game" (if we're blocking all game input or if someone is typing in imgui)
There was a problem hiding this comment.
ImGui blocks in-game input via WantCaptureKeyboard when you holding down mouse button
There was a problem hiding this comment.
My changes replicates WantCaptureKeyboard, but without this block
src/controller/controldevice/controller/mapping/mouse/MouseKeyToAnyMapping.cpp
Outdated
Show resolved
Hide resolved
|
Cancel button click should work without any problems, you can test it here https://github.com/lightmanLP/2ship2harkinian/tree/mouse-mapping-test |
the cancel button does seem to work as expected, but i am still somewhat concerned about always capturing mouse when reading input for mappings accidental mouse inputs are decently common, so having some safeguards would be nice one example i noticed when testing this out was if someone accidentally double clicks on an existing mapping it'll replace the mapping Screencast.From.2024-12-18.10-13-50.mp4i'd like to hear what others think about this (is it a problem we should worry about? if it's a problem we should worry about, what would a good solution be?) |
src/controller/controldevice/controller/mapping/ControllerMapping.h
Outdated
Show resolved
Hide resolved
It might be fixed by spawning binding popup offsetted from cursor and checking for cursor to be in popup boundaries for mouse binding |
that seems reasonable to me! it doesn't solve the "tried to click the cancel button and missed" problem but that's probably fine - if people start reporting that as a bug once this ships we can look into other solutions |
cause Ive got recursive include problem
now compatible with sdl one
casually forgotten
lightmanLP
force-pushed
the
feat/mouse-mapping
branch
from
a913bb5 to
d27d4f4
Compare
Support for binding mouse keys