I have a few minor questions about MQ2.
1.When you issue the /DoEvents function, does it just check the event que for text that matches the user events? Do i have to manually flush the events or does /DoEvents do that after it is called?
2.Not really a programming question but, does MQ basically 'press keys' as far as the client is concerned? It's really neat how you guys figured that out. You must use directinput or something to do this.
Few NON RTFM Questions :)
Moderator: MacroQuest Developers
rtfm!
just kidding
1. You dont need to flush the events
2. Depends on what you're asking. The /press and /sendkey commands currently use directinput but I will probably modify them soon. The /keypress command does not use directinput. The MQ2 bind system recreates EQ's own keypress handling system, so any MQ2 binds will now function exactly the same way things would if they were EQ binds. /keypress calls a function that is part of this system.
just kidding
1. You dont need to flush the events
2. Depends on what you're asking. The /press and /sendkey commands currently use directinput but I will probably modify them soon. The /keypress command does not use directinput. The MQ2 bind system recreates EQ's own keypress handling system, so any MQ2 binds will now function exactly the same way things would if they were EQ binds. /keypress calls a function that is part of this system.
Lax Lacks
Master of MQ2 Disaster
Purveyor of premium, EULA-safe MMORPG Multiboxing Software
* Multiboxing with ISBoxer: Quick Start Video
* EQPlayNice, WinEQ 2.0
Master of MQ2 Disaster
Purveyor of premium, EULA-safe MMORPG Multiboxing Software
* Multiboxing with ISBoxer: Quick Start Video
* EQPlayNice, WinEQ 2.0
I am designing a Beastlord Necro group hunting script and am doing it from scratch (i will be looking at other script for examples). I am flowcharting the processes and ran into a few more questions about events.
My 'bot' will be state driven and i have 6 states that the bot can be in.
Example: INIT, IDLE, SEARCH, PULL, COMBAT, EVADING.
I have a main loop that basically checks what the current state is and then
calls that state routine. Then that routine will loop until some condition is met that cause it to change state. i.e from search to pull state. After it changes the state it /returns and the main loop pickup the new state and goes to that routine. I have an event that fires when it detects the bot being attacked. Looking at the manual, is it correct to assume that unless i call doevents in my various loops, the event cannot be acted upon? What i mean to say is if i am in the search routine loop, i have to include a doevents in that loop?
These events are 'user' events right? I looked though the manual and didnt see them but what are the 'system' events?
Thanks for your time and i can't wait to start dieing trying to debug my script hehe
My 'bot' will be state driven and i have 6 states that the bot can be in.
Example: INIT, IDLE, SEARCH, PULL, COMBAT, EVADING.
I have a main loop that basically checks what the current state is and then
calls that state routine. Then that routine will loop until some condition is met that cause it to change state. i.e from search to pull state. After it changes the state it /returns and the main loop pickup the new state and goes to that routine. I have an event that fires when it detects the bot being attacked. Looking at the manual, is it correct to assume that unless i call doevents in my various loops, the event cannot be acted upon? What i mean to say is if i am in the search routine loop, i have to include a doevents in that loop?
These events are 'user' events right? I looked though the manual and didnt see them but what are the 'system' events?
Thanks for your time and i can't wait to start dieing trying to debug my script hehe
-
SlimFastForYou
- a hill giant
- Posts: 174
- Joined: Sat Jan 24, 2004 1:38 am
Looks like I figured out why sometimes my character never sees the text...
I would often have "/doevents flush" because my ignorant ass thought you had to flush all the text out otherwise it would see the same event over and over again. Kinda thought it was like a toilet... ya gotta flush the shit before you shat again.
Anyway, according to my new understanding, once /doevents catches some text, it only will catch it once and will NOT keep interpreting the same event.
Could anyone tell me what /doevents flush is for and maybe a scenario of when it would be favorable?
I would often have "/doevents flush" because my ignorant ass thought you had to flush all the text out otherwise it would see the same event over and over again. Kinda thought it was like a toilet... ya gotta flush the shit before you shat again.
Anyway, according to my new understanding, once /doevents catches some text, it only will catch it once and will NOT keep interpreting the same event.
Could anyone tell me what /doevents flush is for and maybe a scenario of when it would be favorable?
Use /doevents flush if you might get multiple text triggers to an event but only wish to call it once (or twice, or whatever).
A random example (and there are other ways to do this but for illustration's sake) would be triggering an event off your taking damage, say to re-rune, feign, bug out, etc; the mob might hit 2, 3, or 10 times, however you want to only execute the triggered event code once till you get to the next state of the macro. So instead of calling it however many times, you'd re-rune and then /doevents flush it to get it out of the queue.
Another and likely more practical reason is if you're individually calling events at certain points in your script; the events that aren't being executed are still being batched up however through the incoming text triggers. Prior to you getting back to the next individual trigger set flushing the event queue prevents execution of it however many times.
G
A random example (and there are other ways to do this but for illustration's sake) would be triggering an event off your taking damage, say to re-rune, feign, bug out, etc; the mob might hit 2, 3, or 10 times, however you want to only execute the triggered event code once till you get to the next state of the macro. So instead of calling it however many times, you'd re-rune and then /doevents flush it to get it out of the queue.
Another and likely more practical reason is if you're individually calling events at certain points in your script; the events that aren't being executed are still being batched up however through the incoming text triggers. Prior to you getting back to the next individual trigger set flushing the event queue prevents execution of it however many times.
G
