runelite
Only disable key remapping in dialog when input is expected
Closes #16274
This MR only disables key remapping on dialogs that accept input (options dialog, make X dialog, decant dialog).
NOTE: F-key remapping is already disabled for inputs such as charge interfaces as the isChatboxFocused() call returns false for these already.
This will be really useful for being able to use remapped F-keys to open inventory/gear to access teleports while the received clue dialog is still open.
Short clip of it action allowing remapping for no option dialogs and disabled for options/make-x and decant.
https://github.com/runelite/runelite/assets/107762963/4eac2442-d45e-4767-a0dd-25f70bab3ce4
relevant comment #16274
Yeah I did see that comment. Remapping being disabled when a dialog expects input or a numeric option selection makes sense; dialogs with "click to continue" have neither so will be safe to remap on.
I think it might be better to include all of the cases when it should not remap instead of trying to exclude when it should. Which I think is: isOptionsDialogOpen() || INPUT_TYPE != NONE
I think it might be better to include all of the cases when it should not remap instead of trying to exclude when it should. Which I think is:
isOptionsDialogOpen() || INPUT_TYPE != NONE
Ah cheers, didn't know about that input type var, I'll check it out tomorrow
I think it might be better to include all of the cases when it should not remap instead of trying to exclude when it should. Which I think is:
isOptionsDialogOpen() || INPUT_TYPE != NONE
I updated the logic I think it works the way you were implying here (check for cases where you should NOT remap), I couldn't find any variable or logic tied directly to input but I think options dialogs, decant, make-x and input dialogs (which are already not remapped on) covers everything 🤞
This could noticeably impact people pre-selecting dialog inputs.
e.g. if you have 1 remapped to an fkey: talk to a banker press space and then immediately hold 1 this change makes it so that the dialog option that comes up next is not selected, because the dialog options are not yet visible when you pressed 1.
This of course only matters if you're holding the key down, not if you're spamming it.
This could noticeably impact people pre-selecting dialog inputs.
e.g. if you have 1 remapped to an fkey: talk to a banker press space and then immediately hold 1 this change makes it so that the dialog option that comes up next is not selected, because the dialog options are not yet visible when you pressed 1.
This of course only matters if you're holding the key down, not if you're spamming it.
Hmm good point; I'm struggling to think of a way around that while still enabling non-input dialogs to allow re-mapping. I personally find it more annoying that I can't access my F keys while I have a dialog open (in particular the dialog that says you've received a new clue/casket).
Worth noting what you describe is already sort of an issue with the plugin for things like blast furnace and other make-x interfaces (if you hold 1 down before the dialog pops up and you have 1 re-mapped then it won't receive the input). Actually things like these, as well as accidentally changing tab by holding a re-mapped number too long after a dialog closes are the reasons why I never map the number keys to F keys with this plugin anymore because it causes too many annoyances.
I do think the issue you describe is reasonably niche and it wouldn't take long for a player to learn to just wait for the continue to go away before holding the key down (doesn't actually save any time regardless)
If you think this is a blocker for this pull request then it might just have to be closed (unless you can think of a solution I can try out!)
It's a shame because its something that annoys me daily not being able to F-key with simple dialogs open but recognise my use case isn't the only one