Error in CPawn:update()

[Alkaiser]

Argh, with some of my waypoints I get CPawn:update() errors quite often, but the client doesn't appear to have gone screwy. I can restart with rom/bot no problem without restarting the client.

Is there a way to automate the restarting of the bot in the event of a CPawn:update() failure with the same functionality as typing "rom/bot" from command line?

I tried this, but I guess it isn't deep enough... from CPawn:update()

Code: Select all

	if( self.Alive ==nil or self.HP == nil or self.MaxHP == nil or self.MP == nil or self.MaxMP == nil or
		self.MP2 == nil or self.MaxMP2 == nil or self.Name == nil or
		self.Level == nil or self.Level2 == nil or self.TargetPtr == nil or
		self.X == nil or self.Y == nil or self.Z == nil or self.Attackable == nil ) then
		
		player = CPlayer.new();
		settings.load();
		return;
	end

After update() fails, bot ends with an error message like "Tried to perform arithmetic on HP, a nil value"

[rock5]

After update() fails, bot ends with an error message like "Tried to perform arithmetic on HP, a nil value"

That's because, for what ever reason, it can't read the pawns values from memory at the moment. So when it executes

Code: Select all

player = CPlayer.new();

it's still not going to be able to read memory.

A lot of changes have been made in the past to stop this error from happening which has been difficult because there seemed to be many causes. I don't think it's a common occurance anymore. Maybe there's something about your setup that's causing the error? Are you using code at those problem waypoints? Do you have code in your profile 'events'? Do you run too many clients at once?

[Alkaiser]

I had considered that something in my profile is responsible, but, I can run the same character with the same profile on one set of waypoints and get the update() error often, while running a different waypoint I never get it. The update() fails often (but not always) in the same point in the waypoint file, but there is no extra code running at these waypoints.

Waypoints for Weeping Coast - Bunga Lake:
Bunga Stomach farming waypoints...I often get update() errors in this area, usually after killing a Bunga, but before looting takes place.

Cyclops Farming Waypoints:
Along the path between Kalice (friendly Cyclops) and the merchant at the military outpost. update() seems to fail at one particular waypoint. This waypoint is just a plain waypoint with no extra scripting. It is near a subzone border though... I've wondered if this might cause problems.

Northern Weeping Coast Waypoints:
ZERO problems, bots can run for 12+ hours easy

I have some things in onLeaveCombat. cathcavy() and useHousemaidPotions(), but again on some waypoints, update() doesn't fail with these in place.

Since it seems so difficult to track down the cause, wouldn't be easier to change it so the bot doesn't give up so quickly on update() fail?

[rock5]

If it was that simple it would have been fixed by now. You could try adding a pause then rerunning 'self:update()' but I'm not sure what would happen if you nested the function like that.

Seeing as you find it only happens at certain locations, have you concidered that there might be problem mobs? After all, pawn:update() is used for mobs as well as players. Are there any unusual mobs that appear at those locations?

[Alkaiser]

If it was that simple it would have been fixed by now. You could try adding a pause then rerunning 'self:update()' but I'm not sure what would happen if you nested the function like that.

I didn't mean to imply it was easy, just easier than finding every cause.

Seeing as you find it only happens at certain locations, have you concidered that there might be problem mobs? After all, pawn:update() is used for mobs as well as players. Are there any unusual mobs that appear at those locations?

Around Bunga lake, I don't think so. There are pond lizards and red-skippers, non-hostile... and three variations of Bunga. Near the cyclops lair there are some Cyclops who have a wolf pet follow them around. update() has failed at times when being engaged by them, but it's never 100%. Is there away to make the bot completely ignore a specific mob? That would help with testing.

UPDATE: fail again when engaging cyclops wolf pet

Clearing target.
Waiting on aggressive enemies.
Engaging enemy [Giant Battle Wolf] in combat.
Moving in | Suggested range: 50 | Distance: 54
C:/micromacro/scripts/rom/classes/pawn.lua:346: Error reading memory in CPawn:update()

UPDATE 2: In my cyclops waypoints, one of the waypoints that update() often fails on is very near to the spot where the "Warning you are nearing Battlewolf Commander Axis" appears.

[rock5]

To not target a specific mob just add its name to your friends list. You don't want to be targeting pets anyway.

Try that first. See if it helps.

[Alkaiser]

I've added

Code: Select all

settings.profile.friends = {"Giant Battle Wolf"}

to the waypoint <onLoad> section. After a couple hours, there was only one crash when entering the Cyclops Lair. However it wasn't caused by CPawn:update(), but rather the client crashed like it usually does after a while (botting or not). I'll keep watching it.

[Alkaiser]

Gah! It still happens, though much less often. Even with the Giant Battle Wolf being set to friend, it still occasional enters combat against them and update() fails.

[Alkaiser]

I think I've found out exactly when update() fails. Bot kills pet's owner first, pet begins to fade out after its owner dies, bot scans the pet but gets bad/incomplete data as its being removed from the game world... update() fails.

[Alkaiser]

I may have found a simple solution. Without extensive testing side effects are unknown.

Here's what I did... I added fallbacks for all class variables in CPawn:update()

Code: Select all

	...
	self.HP = memoryReadRepeat("int", proc, self.Address + addresses.pawnHP_offset) or self.HP;

	self.MaxHP = memoryReadRepeat("int", proc, self.Address + addresses.pawnMaxHP_offset) or self.MaxHP;
	self.MP = memoryReadRepeat("int", proc, self.Address + addresses.pawnMP_offset) or self.MP;
	self.MaxMP = memoryReadRepeat("int", proc, self.Address + addresses.pawnMaxMP_offset) or self.MaxMP;
	self.MP2 = memoryReadRepeat("int", proc, self.Address + addresses.pawnMP2_offset) or self.MP2;
	self.MaxMP2 = memoryReadRepeat("int", proc, self.Address + addresses.pawnMaxMP2_offset) or self.MaxMP2;

	self.Race = memoryReadRepeat("int", proc, self.Address + addresses.pawnRace_offset) or self.Race;

	self.Id = memoryReadRepeat("uint", proc, self.Address + addresses.pawnId_offset) or self.Id;
	self.Type = memoryReadRepeat("int", proc, self.Address + addresses.pawnType_offset) or self.Type;
	...
	self.Level = memoryReadRepeat("int", proc, self.Address + addresses.pawnLevel_offset) or self.Level;
	self.Level2 = memoryReadRepeat("int", proc, self.Address + addresses.pawnLevel2_offset) or self.Level2;

	self.TargetPtr = memoryReadRepeat("int", proc, self.Address + addresses.pawnTargetPtr_offset) or self.TargetPtr;

	self.X = memoryReadRepeat("float", proc, self.Address + addresses.pawnX_offset) or self.X;
	self.Y = memoryReadRepeat("float", proc, self.Address + addresses.pawnY_offset) or self.Y;
	self.Z = memoryReadRepeat("float", proc, self.Address + addresses.pawnZ_offset) or self.Z;

If a nil value is found, use the class default value instead.

Update:

It's been running all day without a single update() fail. I haven't noticed any abnormal behavior either.

[rock5]

That sounds promising. I would never have done it that way myself as I would just keep trying to fix it, not bypass the problem. But maybe, in the end, this might be the only reliable way to get it to work.

Of course there may be unforeseen problems with this solution that you haven't come across yet so it would probably be a good idea to do more testing, maybe even get other people with the same problem to try it. Maybe you could post your pawn.lua so others can try it.

[Alkaiser]

Ok, for testing, here it is.

I've been running it for more than 24 hours now on a couple of waypoints that were giving me trouble before... since I made the changes, not a single update() fail! And no unexpected behavior.

[botje]

im using this, so far no problems whatso ever, i can posivitly say this is a huge improvement, lately i was getting these errors once per hour or so >.<

Botje

[rock5]

By the way, Administrator said he would like more testing on this before it gets added.

So keep testing guys and posting your results.

[Alkaiser]

After several days of testing, I've had no problems.

[Giram]

That fix is similar that i suggested some time ago but code is much better. I have used that for few days and i haven't got any cpawn:update() errors.

[rock5]

Committed to rev 581.

Be aware that this might mean that if the bot stops being ables to read the pawn info because of a problem with the client then it wont error, although probably something else eventually will.

[Auto Pilot]

Anyway it's probably better in most situations to have the bot keep trying to spam attack/nuke/heal than just exit and leave the char standing there.

Also wondering if it would be possible to add a <onError> section for profiles that would be triggered before exiting when error() is called ? That way I could at least setup the bot to cast recall and (if it's not screwed up hard enough) load a waypoint file to move him to house for XP/TP bonus.

But that would require to replace all error() calls in code which might be a bit painfull :/

Edit : forgot the most important and why I was coming to this thread in the first place Had a CPawn:update() error happen a few mins ago when clicking on game window to activate it (and I must have double clicked by mistake), it made the char move to the place I clicked (while in a fight) and it immediatly triggered the CPawn:update() error.

I tried to reproduce the bug and "successfully" got 2 new CPawn:update() errors. It's probably not the same cause than while normal botting but who knows ...

Edit 2 : tried a bit more to get some more infos and can't get it to crash anymore ....

[Administrator]

Also wondering if it would be possible to add a <onError> section for profiles that would be triggered before exiting when error() is called ? That way I could at least setup the bot to cast recall and (if it's not screwed up hard enough) load a waypoint file to move him to house for XP/TP bonus.

You should already be able to do this. Kind of, anyways. There may be a number of things that go wrong which prevents you from fully making use of some functions (which is why this hasn't been fully adopted), but it's possible to perform some simple actions.

For example:

Code: Select all

<onLoad>
function error_callback(filename, line, message)
  printf("Something bad just probably happened. Good job breaking it.\n");
end
atError(error_callback);
</onLoad>

NOTE:
atExit() may not be available with your current version of MicroMacro. It's a newer function.