how do i speed up a macro?

kallell · Post by **kallell** » Mon Aug 18, 2003 1:12 pm

I see all these macros taht say you can speed it up or down depending on computer, but what i dont get is that how to do it? For example Fryfrogs ts macro... What exactly do i need to edit???

-kallell

EqMule · Post by **EqMule** » Mon Aug 18, 2003 1:57 pm

the speed of your cpu and *maybe* your gfx card, is what makes macros involving tradeskills, go faster, there is not much you can do to optimise the macros, well maybe shave of a few ms, here and there, but thats it (by changing /delays) So short answer: ugrade to a faster cpu

I closed explorer.exe on one computer i have that is *slow* and just let eq and mq run, that increased performance but not too much...

when or i should say if I decide to release /moveitem and autodroponinventory I guess thoose can speed things up just a little, but there is a limit to how fast things can go, even if you have all thoose things done, its about 900ms per combine, try doing it faster than that and it wont be accepted by the UI

blueninja · Post by **blueninja** » Tue Sep 23, 2003 8:34 pm

Doing the normal stuff to increase video performance seems to help somewhat too, stuff like lowering clip plane, facing a wall or turning off luclin models.

Mckorr · Post by **Mckorr** » Wed Sep 24, 2003 9:42 am

Speeding things up too much will mess up macros using /click. EQ needs time to recognize there is something on the cursor. How long that takes varies by machine AND connection speed. I can get away with less delay on my cable modem than I can on dialup.

Start by changing /delay after a /click to about 2. That seems to be the minimum on my 2ghz system (GeForce 4 Ti and a gig of RAM, and a RAID 0 array) when connecting via cable. If that works you can try to lower it to 1, if it doesn't work just start increasing the delay by one till everything works.

Valerian · Post by **Valerian** » Wed Sep 24, 2003 9:38 pm

or get rid of the delay altogether, and set up loops and events (or checks... e.g. if $cursor()==FALSE /goto :WaitToPickUpItem)

Mckorr · Post by **Mckorr** » Thu Sep 25, 2003 10:15 am

Great idea Valerian. Replace all the /delays after /clicks with the following:

Code: Select all

/call WaitForCursor

Code: Select all

sub WaitForCursor
  :waiting
  /if $cursor()==FALSE /goto :waiting
/return

Can add that to your basic routines.mac as a standard #include. If I get around to it I'll see if I can't just integrate it with left clicks in the source, and remove the need for a delay statement all together.

MQSEQ · Post by **MQSEQ** » Thu Sep 25, 2003 11:00 am

That would work great, but what if you fail to combine something and nothing was returned for example, this now has become a endless loop that is going to east up the CPU.

I like the routine but I would only use it when you know there is going to be something returned pass or fail.

Mckorr · Post by **Mckorr** » Thu Sep 25, 2003 12:24 pm

Would have to make the change conditional on the arguments passed to /click.

For /click left somebutton or target, no delay. For /click left someslot, or just /click left, wait for cursor.

For /click right no delays at all, since we are opening and closing things that way. Then a function to check if the pack, bank, merchant, whatever IsOpen. $isopen(pack,0), $isopen(merchant) etc.

fryfrog · Post by **fryfrog** » Fri Sep 26, 2003 1:36 am

in the case of ts.mac or sits.mac, reading the documentation that is included at the top of the macro should get you a long ways. failing that, posting to the thread which includes the macro will get you even farther.

somewhere in the variables there is a built in one called "dly" which can be tuned to your system if you like. i believe it comes set to about 2, but can be adjusted up or down if you need to.

Valerian · Post by **Valerian** » Fri Sep 26, 2003 6:47 am

MQSEQ wrote:That would work great, but what if you fail to combine something and nothing was returned for example, this now has become a endless loop that is going to east up the CPU.

which is why you also use events for the failed combine message, and a /doevents in the loop, and check for $return as well as $cursor()... gets complicated, but works great once you figure it out.

MQSEQ · Post by **MQSEQ** » Fri Sep 26, 2003 8:08 am

Using an Event and setting a flag on failures and then checking that flag during CheckCursor routine could work. But you will need to pass a parameter that would be ReturnOnFailure so you know tgo wait for CursorItem on failures with a return component vs. one that doesn't.

Example:

/macro ts 0 {Container} {ReturnItem on Failure} {Item1} {Item2} etc. etc