Lock input after selection

[desmondw]

Problem

After selecting an input via keyboard, there is a transition period where the selection chosen is highlighted and then selected. During this transition the user is still able to enter input and that input can change the selection.

Example

I'll often hit "2, space" quickly and since it was still transitioning still it changed the choice to "space" (1) instead.

Solution

After user input for selection, further user input should be locked (ignored) on the same timer as the delay to actual selection.

[Numynum]

Do you mean with dialogs? Cause I can't reproduce that I hit 2+space, and it always selects option 2 (and then 1 if a follow-up appeared)

I'm thinking of adding an option to set a sort of "cooldown" between clicks, which should solve your problem as well, even if I can't get the same thing to happen on my end

[desmondw]

Yes, I usually run into this when doing repeat turn-ins but it's generally an issue. Here's a short video to illustrate: https://youtu.be/mFJjblFQwNE

[desmondw]

I'm not familiar with wow addon development but it appears DialogKey is relaying events to the relevant wow frame (in my example a gossip frame) without limitation. This means the UI processes all of the keyboard input events made before the frame transitions. I can roll through sending inputs with the num keys 1,2,3,4 before the first event changes the frame, with all options getting highlighted in sequence before that transition occurs. After transition the next frame shows the result from input 3 when it loads and then it swaps to the result from input 4 quickly. Presumably all inputs create a timer to transition to that frame, but the next frame is a singular object being overwritten by the subsequent inputs.

Anyway the solution to this is to either remove the animation period (transition instantaneously) or to block user input upon a frame transition and then re-enable the input after the transition is completed.

[Numynum]

While it might visually look like that's happening, what's actually happening is a little different

In general terms, this is the process:

1. Keyboard input is detected, if it's not 0-9 or , nothing happens, logic stops
2. check if any frame is showing which needs clicking (using priority lists), if none: stop
3. configure a secure temporary keybind to click the specific frame
4. the temporary keybind is triggered, clicking the button in the gossip list
5. at the same time as the click, a short glowing animation is shown (this is purely visual, and has no effect on functionality)

the strange thing in this case is that it's possible (with other addons) to completely automate gossip windows within the blink of an eye; which makes me question what's up with this "transition period" I'm also not really seeing this myself personally, but I can see it on your recording, very odd

I wonder if a 1 frame "global cooldown" would fix your issue 🤔 , I'll see if I can make a quick test version for you

[Numynum]

can you try this version? https://github.com/NumyAddon/DialogKey_Numy/releases/tag/v1.2.12-alpha1

[desmondw]

This did not fix the problem.

I'm curious why you aren't able to reproduce. I've disabled all other addons and I cannot think of any game settings that would affect this. The timer delay is ample enough that most people should be physically able to hit two key strokes in that period (seems like a ~200ms delay).

Figuring out why you can't reproduce might be a clue to the issue, or if nothing else will speed up investigation.

[Numynum]

hm, it seems to be very specific to quests, maybe even specific to just starting (repeatable) quests anything else, no matter how fast I spam keys, it works exactly as expected

to be honest, I'm inclined to suggest to just be slightly more patient when spamming quests, as putting in some kind of cooldown doesn't make much sense to me, if it's only quests that are affected, and the workaround is quite trivial 🙂

I'll keep the issue open, in case I think of something clever that doesn't make it suck for all other usages ^^ (a timer is out of the question, since you can spam other things much faster no problem, whereas quests take quite some time to pop up)

[desmondw]

I am able to reproduce at any gossip frame. For example, I've been testing at my garrison where there is an NPC that has 6 starter quests for invasions:

In fact the pet menagerie NPC is a great test case, where all 4 options do something different:

With her it is apparent that the vendor selection has a much shorter timer delay as I'm only able to get off one subsequent input sent instead of three.

Gossip frames are the only reason why I have the addon, so for me it is a disruption in flow where the inconsistency of the results almost make it more of a nuisance than an aid. I wouldn't be so quick to discount my experience as an edge case since I'm merely performing the "good path" but faster. Considering the userbase is gamers I'm sure I'm not the only one to have encountered this!

I wish Blizzard would create some well maintained docs for the addon API so I could help out more. If you know of a good docs source I'd be interested.

[Numynum]

To me it looked limited to just quests, where often just spamming spacebar works well (especially now that in progress quests are ignored by default) a long list of repeatable hand-in quests is quite a bit rarer this may be a deal-breaker to you, but to me it's quite a bit further down on my lengthy todo list

I didn't test opening a vendor interaction, I'll try that out in the next few days (my time is sadly quite limited atm, didn't log in for more than a few minutes the past days)

When it comes to API documentation, official documentation is nearly non-existent (only the ingame /api chat command pretty much), but https://warcraft.wiki.gg has good community driven API documentation

[Numynum]

Btw just to clarify, with the menagerie npc, you say you got a few extra actions of, was that just the glowing highlight, or did something actually happen? cause I can get the highlight to go off on any gossip frame, it's just that those extra clicks after the first are ignored

[desmondw]

This is interesting... I went back to check with the menagerie NPC. Earlier I had not done the daily and I recall the problem persisting as I'd explained before, where the subsequent action is always executed. Now checking back without having a quest option it is acting as you say - where the second option quickly inputted is highlighted but does not execute. I'd have to wait for the reset to double-check this but it appears it may be linked specifically to the frame having quests listed.

I also tested with clicking and the same behavior persists... even with the addon disabled. So that is to say that the inherent bug here seems to be in the native UI and related to NPCs with quests, or to quest-selection event hooks, but the issue is more noticeable with a keyboard input system due to not having to look at the frame.

I wouldn't blame you for not wanting to fix native bugs. I've been looking reading over the code and some docs but it might take a while. It should be possible to just block user input after a selection has been made and re-enable it when the input selection choices are updated.

[Numynum]

Interesting

There are some options when it comes to blocking input for a bit but it needs some considerations that I haven't fully thought through yet

1. Should the addon literally block user input until the frame "transition" finished? (So that pressing 1 doesn't trigger your normal actionbutton keybind)
2. how to make sure the addon never gets stuck in a blocking state? (I've had that once while developing, it's.. not fun :p)
3. remember dealing with edgecases, such as a user pressing a button, and then instantly ESC or clicking the close button (or walking away from the npc)

[desmondw]

1. That is what I would expect if a dialog box with numbered options tied to a keyboard is visible. In fact I find it a tad odd that currently if you press numbered keys past the options available it is not blocked.
2. This should be as simple as implementing the input blocking to only be within the scope of the addon's logic. Then any 'blocking' is limited to the current status quo. Since the only time a user would need to put in input next is when the options change, then we'd always want to make input available anyway. This logic does assume that there is a flush of the options when the frame is closed (handles a quick close and re-open) and assumes that options have some unique identifier past their static text (to handle quickly opening a second gossip frame of a neighboring NPC that has the same exact options).
3. Of course! I think the logic of the above implementation is pretty defensive programming, but I also don't know too much of the API or wholistically understand all the code here yet. So sans my ability to implement it, take it with a grain of salt :)