Global Mu Online

[luonline]

Hi!
I've been using MiniMacro and MicroMacro for writing my own simple bots (autopick, autobuff, etc.). Until now...
But, since last GameGuard update, my bots run slowly. I mean, if Mu is running, my bots run slowly, but if I close Mu, bots run perfectly.
Users of others bots, like PJ or ChaosBot, haven't found any problem after renaming their executables, as shown here: http://www.mpcforum.com/showthread.php?t=228100.
Any suggestions?
Thanks in advance.

[Administrator]

It could just be a priority issue. Try setting setPriority(priority.high) to allow MicroMacro to have first dibs on processor time.

[luonline]

Hi!

It could just be a priority issue. Try setting setPriority(priority.high) to allow MicroMacro to have first dibs on processor time.

I don't think so... I just uploaded here: http://solarimpact.servegame.com/phpBB3 ... ?f=3&t=123.
Maybe I'm making another mistake...
Thanx.

[Administrator]

Your while loop is pretty cluttered. This could cause it to run slow if another program is consuming large amounts of the CPU.

Code: Select all

    if (usa_autoparty and autoparty_ativo) then
      --para o timer, para nao executar esta rotina antes do tempo
      unregisterTimer("ativaAutoparty");
      autoParty();
      autoparty_ativo = false;
      registerTimer("ativaAutoparty", minutesToTimer(TEMPO_AUTOPARTY), ativaAutoparty);
    end

This kind of code should probably go before the while loop, as it only needs to be executed once. Calling registerTimer() will make the function be automatically called every once in awhile, so there is no need to constantly check if it's ready or not. You also do not need to unregister the timer and reregister it, this is done automatically, and calling these manually just adds extra work to be done. Now, instead of flipping things around and making it more complicated than it needs to be, we can call autoParty() directly, instead of ativaAutoparty().

Code: Select all

-- put this just before your while loop
if( usa_autoparty and autoparty_ativo ) then
  registerTimer("ativaAutoparty", minutesToTimer(TEMPO_AUTOPARTY), autoParty);
end

You could basically clear out your whole while loop using this approach. One other thing I noticed is that you're not making a call to coroutine.yield() directly inside of your while loop. This could potentially make things appear slower, as the timers may not be getting the time they need to processes. You do, however, use myrest() to make a call to yrest() and coroutine.yield() inside of your subfunctions.

If you're using MicroMacro 0.98, you do not need to manually call coroutine.yield() along-side of yrest() to make sure it calls it at least once. This is done automatically now, so you can just use yrest() directly. Now your while loop can look like this:

Code: Select all

while(true) do
  yrest(1);
end

So now your timers will be getting the time they need, and your while loop will waste less CPU power. It's hard to say if this will fix your problem or not without trying.

[luonline]

First of all, thanks for all suggestions. And I'll try to explain my code...

Your while loop is pretty cluttered. This could cause it to run slow if another program is consuming large amounts of the CPU.

Maybe it's cluttered because that script is suitable for many kinds of MU chars.

Code: Select all

    if (usa_autoparty and autoparty_ativo) then
      --para o timer, para nao executar esta rotina antes do tempo
      unregisterTimer("ativaAutoparty");
      autoParty();
      autoparty_ativo = false;
      registerTimer("ativaAutoparty", minutesToTimer(TEMPO_AUTOPARTY), ativaAutoparty);
    end

This kind of code should probably go before the while loop, as it only needs to be executed once. Calling registerTimer() will make the function be automatically called every once in awhile, so there is no need to constantly check if it's ready or not. You also do not need to unregister the timer and reregister it, this is done automatically, and calling these manually just adds extra work to be done.

Let's suppose that TEMPO_AUTOPARTY is set to 1 minute and the effective running time of autoParty() is 2 minutes. I stoped "ativaAutoparty" timer to avoid that autoParty() could be triggered while it's already running.

Now, instead of flipping things around and making it more complicated than it needs to be, we can call autoParty() directly, instead of ativaAutoparty().

I prefer to call autoParty() by myself, avoiding to get it triggered automatically while another function is running, for example autoDrop(). BTW, autoPick() is called directly by its timer, but it doesn't mess with other functions, as it only presses the space bar and doesn't interact with any item of the GUI, like inventory, menus, etc.

Code: Select all

-- put this just before your while loop
if( usa_autoparty and autoparty_ativo ) then
  registerTimer("ativaAutoparty", minutesToTimer(TEMPO_AUTOPARTY), autoParty);
end

You could basically clear out your whole while loop using this approach.

I hope that I made myself clear and I could explain my approach...

One other thing I noticed is that you're not making a call to coroutine.yield() directly inside of your while loop. This could potentially make things appear slower, as the timers may not be getting the time they need to processes. You do, however, use myrest() to make a call to yrest() and coroutine.yield() inside of your subfunctions.

If you're using MicroMacro 0.98, you do not need to manually call coroutine.yield() along-side of yrest() to make sure it calls it at least once. This is done automatically now, so you can just use yrest() directly. Now your while loop can look like this:

Code: Select all

while(true) do
  yrest(1);
end

OK, I will fix it.

So now your timers will be getting the time they need, and your while loop will waste less CPU power. It's hard to say if this will fix your problem or not without trying.

I don't know... It worked great before GG update. Is it possible that GG is slowing down some programs based on their behavior?
Once again, I enjoyed all your contribs.

[Administrator]

Yes, it is possible. Using setPriority() as previously stated should give you higher priority, and therefor it should run at normal speed again.

[luonline]

Yes, it is possible. Using setPriority() as previously stated should give you higher priority, and therefor it should run at normal speed again.

But, unfortunatelly, I already did it... See:

Code: Select all

function main()
  attach(win);
  setPriority(priority.high);

And it doesn't work.
Anyone else use MU+Micromacro?
Thanx in advance.

[Administrator]

Try renaming micromacro.exe to JoyToKey.exe. That sometimes works.

[luonline]

Try renaming micromacro.exe to JoyToKey.exe. That sometimes works.

With this name, nothing happens, not even slowly...
But, I just realized a crazy thing: I got DC (disconnect) from the game and, when I logged on again (without restarting micromacro), my bot run perfectly!
Strange, hun?

[Administrator]

As long as it works, it works, I guess. I'll look into it further when I get some time.

[luonline]

As long as it works, it works, I guess. I'll look into it further when I get some time.

OK, I'd aprecciate it. And I will do some tests here...