rev 645

[lisa]

Just a couple of small updates.

Fixed an error in the buff duration check, hopefully will fix the issue people had of bot constantly using buffs before the buff actually runs out.

Also added in a check in to findenemy for what I believe to be invisible mobs, basically found 3 parts of the memory which are invisible, unattackable and ???

If I find anymore mobs which are invisible I will be able to determine the exact meanings but for now this is working.

[botje]

sadly enough this update didnt fix ID errors.

nor changed the warrior skill terrorize > terror.

rest works great though :)

Botje

[rock5]

nor changed the warrior skill terrorize > terror.

I have the terrorize fixed. When I commit, it will be fixed.

[lisa]

sadly enough this update didnt fix ID errors.

Just curious do you often bot in a party but the other party member/s are not in range?
That is the only time I ever get id not found errors.

[lisa]

Might have something here for the id issue.
I added in a print like this in pawn.lua around line 411. Basically I wanted to see what the Id was.

Code: Select all

		tmp.Id = memoryReadRepeat("int", proc, i + addresses.pawnBuffId_offset);
		printf("Temp ID for buffs, pawn 412 "..tmp.Id.."\n")
		local name = GetIdName(tmp.Id)

Ran fine for a abour 5 mins, only printing id 500*** but then it suddenly did this.

Code: Select all

Temp ID for buffs, pawn 412 500369
Temp ID for buffs, pawn 412 500369
Temp ID for buffs, pawn 412 620313
Temp ID for buffs, pawn 412 620313
Temp ID for buffs, pawn 412 509578
Temp ID for buffs, pawn 412 501932
Temp ID for buffs, pawn 412 500548
Temp ID for buffs, pawn 412 620313
Temp ID for buffs, pawn 412 500369

The 6***** suddenly appeared, few seconds later it did this.

Code: Select all

Temp ID for buffs, pawn 412 1818324319
Id 1818324319 not found
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 1834774113
Id 1834774113 not found
Temp ID for buffs, pawn 412 1818324319
Id 1818324319 not found
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 1834774113
Id 1834774113 not found
Temp ID for buffs, pawn 412 1818324319
Id 1818324319 not found
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 0
Temp ID for buffs, pawn 412 1834774113
Id 1834774113 not found
Temp ID for buffs, pawn 412 500369

It then went back to the 500***

Could probably add in a check for if the tmp.Id is in the right range of numbers.
There is probably still an issue of the right start and end of buff range though that needs looking into.

[lisa]

you can always give it as test run botje since you seem to have the id not issue quite often.

pawn.lua line 408, replace the entire for code with this

Code: Select all

	for i = buffStart, buffEnd - 4, BuffSize do
		local tmp = {}
		--yrest(1)
		tmp.Id = memoryReadRepeat("int", proc, i + addresses.pawnBuffId_offset);
		if tmp.Id >= 500000 and 600000 >= tmp.Id then
			local name = GetIdName(tmp.Id)

			if name ~= nil and name ~= "" then
				tmp.Name, tmp.Count = parseBuffName(name)
				tmp.TimeLeft = memoryReadRepeat("float", proc, i + addresses.pawnBuffTimeLeft_offset);
				tmp.Level = memoryReadRepeat("int", proc, i + addresses.pawnBuffLevel_offset);

				table.insert(self.Buffs,tmp)
			end
		end
	end

basically just adding in the line to check for the id between 500000 and 600000 with an end of course.

I am pretty sure buff Id's are only in that range, could be wrong.

[rock5]

Don't you remember Lisa when the new 620xxx buffs were giving us trouble after a patch a while back?

620313 is "Bleed". That is a buff (or I should say debuff).

[botje]

i do bot in party yes, but regardless, it shows when im botting alone just the same >.<

so, should i add that code, or does rock mean that doesnt work?

Botje

[rock5]

Code: Select all

      if tmp.Id >= 500000 and 600000 >= tmp.Id then
         local name = GetIdName(tmp.Id)

Actually I think that will work because I think the reason you are getting the "Id not found" warnings is because when updating the buffs, if the start and end address is messed up then the buff ids wont be valid. So it sends invalid ids to "GetIdName".

This shouldn't affect it's performance but it shouldn't be printing those messages when there is nothing wrong. So just adding an id check before using GetIdName should fix it. Of course the range would have to be increased to include all buff ranges but I would just make it the whole id range to be sure, ie. 1 - 999999.

I'm interested to know, when it started spitting out ids of 0 and those large numbers, how long did it last?

[rock5]

Here is an altered version of pawn.lua.

I think all the problems stem from occational invalid start and end addresses for the buffs. The changes I've made should make sure that they are correct.

I haven't added the line that lisa said above because I believe if the addresses are correct then the ids will probably also be correct. If it still happens we can add it later.

[lisa]

I'm interested to know, when it started spitting out ids of 0 and those large numbers, how long did it last?

The id's scroll pretty quickly up the screen, the 0's lasted 1-2 seconds tops. What I posted was all the 0, I stopped testing after that though.

[lisa]

testing your pawn.lua atm,
first test 7 mins and got stuck in a loop.
second test 2 mins and got stuck in loop.

[botje]

same here, gets stuck.

Botje

[rock5]

Assuming you don't have 50 buffs, that would have to mean that the buffs in memory must sometimes get split up in memory. It's not just a temporary failure to get the start and end addresses.

I don't know how I'm going to figure out what happens in memory when this happens. I'll have to think about it. Maybe a memory dump of that region.

I wonder if this "split up in memory" just happens when you have a few buffs. How many buff did you have when it happened?

[botje]

i had like 3 buffs max.

Botje

[lisa]

maybe 1 buff, char I was testing it on runs round with 0 buffs and occasionally uses buffs with 5 min cd and short duration. So can't be by how many buffs it has.

[lisa]

Have a test of this 1 botje, I've had it running for about an hour and not 1 id missing. I did what I said earlier but followed rock's suguestion of 1-999999.

Apparently another patch tonight, see if the addresses change again.

On Tuesday, 4th of October 2011, all European Runes of Magic servers will go down for our weekly maintenance and the installation of a new update - Patch 4.0.3. - The Mighty Shield

I don't play on Eu server, so if it is ONLY Eu server patch then someone else will need to find the new addresses.

If you play on Eu server I would suguest you read my how to guide for finding addresses before the update. Otherwise you might be waiting until the other servers are patched before you can bot again.

[rock5]

Ok here's another version. This dumps an area memory of 50 buffs, when the difference between the start and end buff is more than 50 buffs, to a file called "buffdata.log" in the "log" folder. Hopefully I will see something helpful.

Note: when it writes to the file it will then stop the script. This is to stop it from overfilling the file. After it writes to the file you can just revert your pawn.lua to continue botting.

Post your output here.

[lisa]

I think you are missing something here.
When it gets to much information for buffs it returns a blank table, this doesnt cause the id not found issue.

Code: Select all

	if (buffEnd - buffStart)/ BuffSize > 50 then -- Something wrong, too many buffs
		return
	end

The issue is that the buff information is saying it is within that size but the ID is bad.
i.e. 0 or 174567865374856.
So it is passing the buffsize check but the Id is messed up.


I have a theory which needs testing, might be slightly off but I can't be sure yet.

While playing around with my latest project I discovered the player info is also in a different memory address the same as any other pawn.
I am concidering the addresses we have are just pointers to the pawn address elsewhere.
What if the pawn address moved, as they always do, between the time it does the size check and when it checks the buff Id's.

[rock5]

I think you are missing something here.
When it gets to much information for buffs it returns a blank table, this doesnt cause the id not found issue.

Code: Select all

	if (buffEnd - buffStart)/ BuffSize > 50 then -- Something wrong, too many buffs
		return
	end

Yes but that return an emtpy "buffs". The previous pawn.lua I posted had this

Code: Select all

	repeat
		buffStart = memoryReadRepeat("int", proc, self.Address + addresses.pawnBuffsStart_offset);
		buffEnd = memoryReadRepeat("int", proc, self.Address + addresses.pawnBuffsEnd_offset);
		yrest(1)
	until buffEnd and buffStart and (buffEnd - buffStart)/ BuffSize < 50

That should keep reading the start and end value until the difference is less than 50 but it got stuck in the loop, right? So that means when the start and end address are "messed up" they stay messed up and so it gets stuck in the loop. If it was only temporary then it would eventually leave the loop when it got valid addresses.

So what I'm trying to find out is what data is there in memory when the start and end address are wrong. If we know what's there maybe we can work out how to still get valid buff data and never return empty buffs tables.

The issue is that the buff information is saying it is within that size but the ID is bad.
i.e. 0 or 174567865374856.
So it is passing the buffsize check but the Id is messed up.

Yes, and I realise an id check would stop the "Id not found" errors but it will still return empty buffs. Obviously if the addresses are bad then some or all of the ids will be bad. But will they all be bad? That's one of the things I want to know.

I have a theory which needs testing, might be slightly off but I can't be sure yet.

While playing around with my latest project I discovered the player info is also in a different memory address the same as any other pawn.
I am concidering the addresses we have are just pointers to the pawn address elsewhere.
What if the pawn address moved, as they always do, between the time it does the size check and when it checks the buff Id's.

My guess would be that it isn't that. It get's the ids immediately after getting the start and end address so you can pretty much take it as being instantanious. The odds of reading the data right in the middle of when it's changing would be miniscule.

It might be more likely that somewhere a pawn is created and then later updatebuffs is run without updating the pawn first. And maybe the pawn changes between when it was created and when updatebuffs is run.

BTW: I would still like to see the output of my new file, if someone would test it please?