Comunication error with macro ingame

[spyfromsiochain]

Don't know if this should be in micromacro tab or here but...

Hi there all.

In my token accounts, and only there, I have the error in attachment.

I am using 1.04.157 version of micromacro and rev 772 of rombot.

regards

Ps: its completely impredictable, I deleted the macro I had before this error started to occur, thought it would help, but nah...

[rock5]

Possibly what's happening is you have a userfunction that does some code when loaded and forces setupMacro to run early. I was guilty of this a few times. Basically userfunctions should not do any code when loaded. This causes problems because userfunctions are loaded before the check to see if update.lua needs to be run. So after a patch you get an error before the addresses can update. Try running "rom/update" first before starting the bot and see if that fixes it.

[spyfromsiochain]

Well in att I send the content of the macro when it crashes (well its not really a crash).

then one userfuntion I see using is the gm detect, I have it updated I think -- ver 7.8d (userfunction_gmmonitor.lua)

wich is pulled in the profile with the function startgmdetect() in the onload section

Code: Select all

 <onLoad><![CDATA[
         startGMDetect()
   ]]></onLoad>

What u think rocks?

regards

[rock5]

Did you run "rom/update"?

[spyfromsiochain]

addresses.lua is has the red sign, it did the update automatically in the first run of micromacro after patch.

and I run also the rom/update.lua.

[rock5]

Maybe your macro.bsd file is corrupt. macro.bsd files are unique to each character. Does the bot start when loading other characters or do you get the error with all characters? Also could you show me more of the MM output? Edit out any profile names.

[spyfromsiochain]

It only returns this error of communication, on the loading of a new character from that account, so first character of the account has no problem, but in the transition to second character, might get the error.

It changes from character to character, I have 32 characters, one day might stop in one character and the other day not stop in any character, its predictable, at least I dont see any relation.

I can erase all the macro.bsd for those characters no problem.

what u mean about "more mm output"?

regards

[BlubBlab]

My 5 cent:
Hm what I last changed in the d version from GMDetection was adding a kill client routine for the logout(so it could have something to do with changing chars) but this is strange the related code will only be touched when a GM is found.

Do you relog the whole client for changing chars?

[spyfromsiochain]

When I start the tokens accounts in elven island, I do it with 4 accounts all at same time, and use the loginxml to scroll though the accounts, pretty straight forward, I think.

Code: Select all

sendMacro("}LoginNextToon=true;a={")
sendMacro("Logout();");
yrest(60*1000);                -- wait 1m for next character to load
waitForLoadingScreen()

[rock5]

Sometimes when changing character the game might not be completely ready when waitForLoadingScreen returns. So it's good practice to add a few seconds rest afterwards to make sure it has finished loading. Eg.

Code: Select all

waitForLoadingScreen()
rest(3000)
player:update()

I used a rest instead of a yrest because we don't want to yield to other processes that might have trouble if the game isn't fully loaded. The player update if in case you are doing some other code before moving to the next waypoint. If it's immediately going to go to the next waypoint then it's not needed.

Also that code is old. It might still work but I think it at least sometimes causes strange behavior. The way to change to the next character now is to just use "ChangeChar()" with no arguments. This will change to the next character on the same account, do the waitforloadingscreen and wait 3 seconds before updating player. So it's an all in one function. You can also use it to change to any specific character on any account. This assumes you are using the latest version of fastLogin(loginxml) and userfunction_loginNextChar.lua.

[spyfromsiochain]

First of all, my excuse for only now answering this post, I wanted to try everything before answering.

Tried the following:

-deleted all macro files from alts
-traded codes from:

Code: Select all

sendMacro("}LoginNextToon=true;a={")
sendMacro("Logout();");
yrest(60*1000);                -- wait 1m for next character to load
waitForLoadingScreen()

to

Code: Select all

  player:rest(4);                -- wait 4s to make correctives
          ChangeChar()
	  rest(3000)
	  player:update()

- tried doing the 4 accounts without the software that releases memory free ram xp pro (in my case) I thought since memory fails in the switch of character usually, some files or code could be destroyed in the process (IDK)

And the same problem continues, either one of the error in the pictures below happens.

Either way, I will attach the profile I use and the waypoint I use.

Hope it helps.

Regards

Ps: The only thing I see that changed in my build for farming tokens was:
-the new patch 6.07 of rom
-the userfuntion for gmdetect ver 7.8d
-rombot v. 772

[rock5]

Code: Select all

ChangeChar()
rest(3000)
player:update()
-- Re-initialize player
player = CPlayer.new();
settings.load();
loadProfile("tokens"); -- profile name to load

loadProfile is an all-in-one function. So all you need to do is

Code: Select all

ChangeChar()
rest(3000)
loadProfile("tokens"); -- profile name to load

As to the problem, I'm not sure what else to suggest. Have you tried removing any unnecessary userfunctions and/or addons?

[spyfromsiochain]

Well, "macro test: ok" on 24 transitions (32 characters)

The only thing I did was:

Code: Select all

ChangeChar()
rest(3000)
loadProfile("tokens"); -- profile name to load

has request by rock5 and

Removed from <onLoad> in the profile, gmdetect call. After that worked perfectly. So I traced back my steps on userfunctions_gmdetect and the last version of it (in that one I didn't had this problem) was ver 7.7a, actual version I am using is ver 7.8d.

Any clues what changed? I had a quick look at the code and the only thing that I saw different was:

Code: Select all

--=== New feature ===--
-- this is for monitoring players who may be following you.
local ignoreplayertime = 90 
-- time in seconds when alarm will be sounded for a player "following" you

local clearplayertime = 90 
-- time in seconds for players to be removed from table

-- when the ignoreplayertime time is reached it will play the alarm sound
-- if you want your own code performed then create a function named beingfollowed() and that code will be done instead.

--Minimum Level for a GM
local gmMinLevel = 86;
--List of the known GM Names;
local gmNameList = {"Thepit","Rhakara","Tohros","Saitomentor","Rakymos","Galorian","Inyrion",
"Riujnara","Lulyane","Akasha","Vayus","Tathros","Ciarog","Aranrod"
,"Nohdrael","Kiareko","Adelynne","Rednaltor","Shenarah","Lonarhune"
,"Rismak","Rakymos","Ketagos","Golightly","Minutal","Farodin","Jyskal","Temper4nce"};

and

Code: Select all

--Interval time config --
local checkmemory = 5;
local checkserver = 180;
local standard_pausetime = 180; --in s
local standard_logouttime = 900; -- in s
--config end--

Has a reminder I would like to say, the macro test with last version of gmdetect only fails sometimes on this pc, so the first thing that pops up in my mind, some sort of delay? a short yrest? Idk, not an expert here.

Regards

[rock5]

Theoretically, ChangeChar never yields so gmmonitor can't do anything until ChangeChar, rest and player:update end. So I'm not sure how it can be interfering. Maybe you need even more time than 3000ms to make sure everything is loaded properly.

[spyfromsiochain]

Thats probably it, the rests... 3000 its in miliseconds right? so 3 sec?

where can I change that?

ChangeChar()
rest(3000)

?

[rock5]

Yes, 3000ms = 3s. Just increase it eg. rest(6000) equals 6s rest.

[BlubBlab]

It could only happened when in ChangeChar() is a loadProfile() call.

[rock5]

I don't under stand that sentence. There is no loadProfile in ChangeChar.

[rock5]

This is a relog issue so I might as well mention it here, I've updated the login and loginnextchar userfunctions to the version I'm using. It was just brought to my attention that I never officially updated them. I've done so now so see if they help with you're issues.

[spyfromsiochain]

Well I would like to start with an apology and a "happy eastern".

I should have reply this post long ago, but since I was busy with alts in the secret garden, I had no way to test this error better, since when garden over, I been trying to go to the root of the problem, and after some tries I can be sure the problem is in the userfunction_gmmonitor.lua rev 7.8d I am using 7.8c and all is good.

Checking the changelog of blubblab:

Small changes based on a report I got.
What I changed was :
-kill client when logout

Best regards (dont eat too many sweets ^^)