Forum › Forums › Discussion › Reliable interaction with NPCs using numkeys?
This topic contains 2 replies, has 3 voices, and was last updated by malarkey 4 years ago.
-
AuthorPosts
-
December 1, 2020 at 1:43 pm #25164
Hey All,
I was wondering if there was a way to reliably interact with npcs and their menus using the numpad keys?
I can for example very quickly submit a levequest using the numpad keys manually. And tried creating a scenario using the Key() functionality to replicate this. such as:key(num4,1.5)
key(num0,0.5)
key(num6,0.5)
key(num0,0.5)
key(num0,0.5)However it seems very unreliable, keys don’t always get picked up or skipped. Am I missing something obvious? or is this just a limitation of the bot
December 1, 2020 at 7:46 pm #25165I was working on a scenario last night that involved navigating NPC menus via sendKey().
It’s very finicky. If a key gets skipped, it’s because Miqo tried to send it and the game was not able to respond (for example, the menu was loading). The default delay I use is 1.0, but for opening/closing menus I use anywhere from 2.0 – 3.5 depending on how long it takes the game to process the command. For scrolling through lots of items, or otherwise spamming a certain key, the delay I use is 0.5. Also, sending “esc” to close menus doesn’t seem to work at all unless FFXIV is in focus, so I set a secondary keybind for “Close all UI windows” or whatever it’s called and had Miqo send that instead.
My logic with choosing delays is to err on the side of caution, and choose a longer delay, because all it takes is one lag spike to completely mess up the scenario flow.Edit: When testing the scenario, you also need to make sure that menu navigation is in “cursor mode” as opposed to “mouse mode” (not actual names, just what I think of them as). If you move your mouse in-game, it will switch to “mouse mode” even if the last menu you nagivated was in “cursor mode”. This will mess up the menu navigation because the first key sent to the game (while in a menu) won’t do anything other than activate “cursor mode”.
- This reply was modified 4 years ago by jponry.
December 2, 2020 at 12:01 am #25167It definitely depends on what part you are currently on as to how long the delay should be. I have a scenario for each retainers, buying things with GC seals, and accepting/turning in leves. After testing them I have the timings down and they never mess up.
Things to note with making key() sequences:
If you have the game not minimised and want to keep using your computer you will need an additional monitor as sometimes moving the cursor on another application with the game in the back can mess it up.
The game responds quicker if it is the main window. Increase your delay if it is not, or if it’s minimised from the last point.
Always err on the longer side for a delay and trim it after testing.
Keys with names like esc work but it needs to be key({esc}, 1).
At the beginning of the sequence, add an extra key() to “wake up the cursor.” The key used will depend on which menu you are opening and where the initial default position of the cursor is. For instance, num4 is mine on my retainer scenario because trying to move the cursor left doesn’t do anything in that menu.
I recommend using commented-out notes on each line to keep things straight. A bunch of num2 or whatever might start getting confusing when you try to go back to fix a step. Miqo won’t let you use tab in-app to make space on the same line to start your note so I write them in a notepad first and it makes it all nice and neat. (Miqo forums don’t like tab either it seems lol)
key(f12, 2) //targets bell
key(num0, 2) //opens bell
key(num4, 2) //wakes up cursor- This reply was modified 4 years ago by malarkey.
-
AuthorPosts
You must be logged in to reply to this topic.