Macro BEST Practices and Principles (/doevents and /delay)

[robdawg]

This is a "how much" and "when" question.

First, how much /delay should be used inbetween clicks? For example moving 8 items to a combine container. Should there be seconds of delay? Couple units of delay?

Second. when should I use /doevents? I think that I have seen a post on it somewhere around here, but is it necessary? And if so when would be good times to use it?

I am looking for optimal solutions so scripts run fast but not to fast that they skip a few steps.

Thanks...

[Preocts]

Your answer is: Use them when it makes logical sense.

How much delay is needed from the time you pick up an item to the time you put it in the combine container? How ever long it takes for the ${Cursor.ID} to change. If you want optimal preformance you won't use many /delay commands at all. You'll do checks.
"If my cursor.ID has changed from what it was before I clicked then I know that the click has been done". This accounts for system lag, server lag, and all sorts of other delays.

Use Events the same way. Don't make a /delay inbetween the time you hit combine and the time you start loading the container again. Do it with an Event that triggers if you have a successful combine. Make one for a failed combine. Each event can have it's own personal behavior.
"On Event "You have fashioned something new" unload the cursor and then setup the combine again"
"On event "You failed" just setup another combine because the cursor is empty"
or whatever suits the needs of the script.

In a nutshell: Events help streamline the code and get rid of /delay commands that, in the case of lag, can completely fubar your macro. Use /delays only when you need to force your macro to slow down. I find I always need a /delay before /doevents and after I open a pack in my inventory. Even with checks.


These are my thoughts, not yours.

[fantum409]

Seems like some of my macros also work better with a little delay added into some of the loops. If you have a loop that cycles waiting for an /if condition to be satisfied, sometimes it can consume enough CPU cycles that framerates slow up. (The newer versions of MQ2 have handled this much better...) Especially if you dont need an absolutely instant response to the /if condition, benefit can be seen from using /delay

[Preocts]

The newest versions, within the last month, handle these loops so much better because people can't set the freaken #Turbo higher than 40 and it defaults at 20 if you don't set it.[/code]