REQUEST: Crash detection at line 574 in functions.lua

[Alkaiser]

In my Clops waypoint the most common crash occurs just after the bot gets teleported by Kalise to the front of the cyclops lair. The bot doesn't seem to be able to detect this crash and more often than not my character ends up dead because the client won't disconnect. The bot hangs up on memoryReadByte() when the client crashes.

line 574 functions.lua

Code: Select all

while( memoryReadByte(getProc(), macro_address + addresses.macroSize *(resultMacro - 1) + addresses.macroBody_offset) == 6 ) do

[rock5]

What exactly does the error message say? If the error is happening during teleport, are you using "waitForLoadingScreen()".

[Alkaiser]

I do use waitForLoadingScreen(). Sometimes a crash occurs before waitForLoadingScreen() clears when entering the Cyclops Lair and the error message reflects that, but that isn't a problem for me since the character isn't killed that way (its safe on the other side). What I'm talking about happens after transport just outside the Cyclops Lair and just after waitForLoadingScreen() clears. I'll post the exact error message the next time it happens.

There is something else I thought was strange... when teleporting to the CL entrance, there are two cyclops guards there. The bot will engage them in combat immediately after waitForLoadingScreen() clears, even if waypoints are set to "TRAVEL". I wonder if the crash might have something to do with the bot entering combat before its ready to do so.

I assumed "TRAVEL" meant the bot will not fight back ever... or is there a situation where it will (by design)?

[kx9488]

i'm not sure why you are crashing, but "travel" waypoints still enter combat by default, but only after you enter combat/are attacked.

i'm not sure how to change the settings, unless the mobs that you do not want to fight have a different level or name you can make the bot not target them in profile settings.

[rock5]

"TRAVEL" is supposed to never attack. Where are you making it travel? Are you possibly teleporting, waiting for loading screen then loading a new waypoint file that is set to travel mode? If so it might be targeting the guards just before loading the new file. You could try changing the travel mode manually before teleporting.

Code: Select all

__WPL:setForcedWaypointType("TRAVEL");

[Alkaiser]

"TRAVEL" is supposed to never attack. Where are you making it travel? Are you possibly teleporting, waiting for loading screen then loading a new waypoint file that is set to travel mode? If so it might be targeting the guards just before loading the new file. You could try changing the travel mode manually before teleporting.

Code: Select all

__WPL:setForcedWaypointType("TRAVEL");

No, it is teleporting but its using only one waypoint file. "TRAVEL" is activated before teleport and isn't returned to "NORMAL" until after it enters the Cyclops Lair.

After teleport, mobs will attack the bot before waitForLoadingScreen() finishes. When waitForLoadingScreen() finishes, the bot will attack the mobs that were attacking it before waitForLoadingScreen() finished, even in TRAVEL mode. Any mobs encountered after this point are ignored as would be expected, being in TRAVEL mode.

On the error message. There is no error message until I manually terminate the client process. The bot appears to just stop at line 574 of functions.lua. After closing game client, error message pops up .../Runes of Magic/micromacro/scripts/rom/functions.lua:574: bad argument #1 to 'memoryReadByte' ((null))

Also, "Clearing Target" always appears in console immediately prior to a crash.

[Alkaiser]

Gah! I apologize for my idiocy and wasting people's time.

My waypoints are set to RUN by default. The waypoint I was starting at for testing purposes was one waypoint AHEAD of the waypoint that sets TRAVEL mode, thus TRAVEL was never getting set and the bot was doing its thing in RUN mode the whole time acting just as it should. Why it took me several days to see this is a mystery to me.

So... the only thing remaining is crash detection on memory read fails. Would it be possible to detect whether or not the crash report dialog window has appeared? If the bot could sense that that would be a good time for the bot to terminate the process.

[rock5]

Would it be possible to detect whether or not the crash report dialog window has appeared? If the bot could sense that that would be a good time for the bot to terminate the process.

That's a good idea. The bot can find processes and windows so why couldn't it find the error window? I'm not experienced with those functions though. Probably Administrator would need to comment.

[Administrator]

Should work. What is the exact window title? Or what about the process? Isn't it named something like romcrash.exe?

[Alkaiser]

Window title is "Crash Report". Not sure about the process name yet... I forgot to look during the last crash.

Update:

I'm don't think the Crash Report is a separate process... at least I can't find it. client.exe is the only thing RoM related that I can see running.

[Alkaiser]

Here's another one that's a problem, but isn't a RoM crash.

Use MACRO: KNIGHT_DISARMAMENT 6:18am - ...s of Magic/micromacro/scripts/rom/classes/player.lua:651: invalid option '%Z' to 'format'

Any idea what this means?

This error occurs on only one of my characters, a K/R.

[rock5]

That message doesn't make sense in regard to the line, unless the targets name has "%Z" in it. Is your player.lua original, or have you edited it? What did you do to cause the error? I don't think it's normal for the bot to use sendMacro to execute skills. Do you have some code in your profile that executes skills?

[Alkaiser]

It happens when facing off against the three stooges in the Cyclops Lair: Gorn, Masso, and Ordig. They do act a bit differently than normal mobs when their health gets near zero. They turn from red to green and then disappear. They don't actually die unless they are the last remaining of the three.

My player.lua is unmodified.

[rock5]

Should work. What is the exact window title? Or what about the process? Isn't it named something like romcrash.exe?

I got a crash report. The window title is "Crash Report". Right clicking the task in Task Manager and going to process takes you to "client.exe".

[Administrator]

What about the window class? You can use spy++ to view the window's class. This would allow us to check, with a high degree of accuracy, whether or not it was RoM's crash window.

[rock5]

I thought about that but you didn't ask for it. I tried using some of micromacro process commands but got "Edit" as the class name which I didn't think was right.

I'll try Spy++ next time. I wonder if there is a way to induce a crash?

[Administrator]

You could try memory editing. Just change a bunch of random stuff and it'll probably crash.

[lisa]

I noticed while playing with some in game functions you can crash the client very easily. I just can't remember which I was playing around with at the time. I'll see if I can remember, then you can simply type in game and bammo crash at will.

[rock5]

Ok I induced an error.

Spy++ says;
Handle: 0018084A
Caption: Crash Report
Class: #32770 (Dialog)

[Administrator]

Well, that is annoying. "Crash Report" is a bit too general for me. Can you double check the class name?

Code: Select all

local win = findWindow("Crash Report");
local class = getWindowClassname(win);
printf("Class: %s\n", class);