id error

[Jellenser]

i get this id error.. maybe someone want to know

[rock5]

Just ignore them, unless there is actually a problem.

GetIdName reports them as invalid ids anyway.

It's strange that they are always in that range. I have rogue that often gets 2 or 3 and they are in that range too. I suspect they might actually be something but unless there is a problem and/or we know what those ids are, there's no way to do anything about them.

[SpiralV]

First memorytable.lua works since a couple of client-patches so i'm really happy about
Maybe these IDs are some old event items and they don't exist in the current Id table?
if so does the client display the item name?

[rock5]

I don't think the devs actually remove ids. There may be a lot of ids not being used but I think they would be left in. Anyway, I have copies of some older 'itemstables' and those ids are not part of them so they are not old ids.

How are we to see if the client displays the name if we don't know what the ids are? That's why I said we can't do anything for now. We don't know what they are or what part of the bot is generating the error message.

I suspect it's a new range and the way memorytables is set up it misses that range. I'm pretty sure they wouldn't be ids we use a lot, like inventory items or mob ids as that would cause problems and we would pick up on it quick enough and so far it doesn't seem to cause any problems. I suspect they might be buffs or hidden effects the type of ids that are lot listed on runesdatabase.

[SpiralV]

How are we to see if the client displays the name if we don't know what the ids are?

/run DEFAULT_CHAT_FRAME:AddMessage(TEXT("Sys533025_name"))
I've tested a few of those ids, no translations, so I guess memorytable.lua is not the problem here.

I suspect it's a new range and the way memorytables is set up it misses that range.

Well that can not be because there are no ranges anymore, there is only one large id range.
Some words how it's works, within the client-memory id-table there is an address which is repeated again and again (the same in 0x0 and 0x8).

Code: Select all

        --Reads into the table to get a 'IdTableHeader' address
	for i=0,10 do
		local offset0 = memoryReadInt( getProc(),  dataPointer - lineSize * i )
		local offset8 = memoryReadInt( getProc(), (dataPointer - lineSize * i ) + 0x8)
		if offset0 == offset8 then
			IdTableHeader = offset0
			break
		end
	end

I called it IdTableHeader, now you get more information about the table.

Code: Select all

	--Get informations from the 'IdTableHeader'
	local smallestIdAddress   = memoryReadInt( getProc(), IdTableHeader )
	local middleIdAddress     = memoryReadInt( getProc(), IdTableHeader + 0x4 )
	local largestIdAdress     = memoryReadInt( getProc(), IdTableHeader + 0x8 )

	local smallestId    	  = memoryReadInt( getProc(), smallestIdAddress + addresses.idOffset )
	local largestId     	  = memoryReadInt( getProc(), largestIdAdress + addresses.idOffset )

The middleIdAddress is the most important because the search starts here.

Code: Select all

		-- Use the middleIdAddress from IdAddressTables to start search
		local dataPointer = middleIdAddress

The search engine is probably exactly the same as in the client itself.

That's all and it's pretty easy.
Hm I guess it is a little faster when the locals are stored.
Are there performance problems at the moment?

[rock5]

/run DEFAULT_CHAT_FRAME:AddMessage(TEXT("Sys533025_name"))

I didn't think of that. Of course the ids might not have names. Not all ids do. Although I'm not sure of the normal behaviour for that command is, when using valid ids with no name.

Well that can not be because there are no ranges anymore, there is only one large id range.

There are still ranges in memory. That's what I meant. It still has to jump from one memory region to another and needs to find the beginning of the next region. But I seem to remember we took away all limitations on how it finds the next region so it should always find the start address of the next region. Or was that before you completely changed the way it searched?

Most likely then it is just a bug and they aren't real addresses.

Are there performance problems at the moment?

Not that I'm aware of.

[SpiralV]

/run DEFAULT_CHAT_FRAME:AddMessage(TEXT("Sys533025_name"))

I didn't think of that. Of course the ids might not have names. Not all ids do. Although I'm not sure of the normal behaviour for that command is, when using valid ids with no name.

Hm well then there is no other possibility unless you look in the memory.

Or was that before you completely changed the way it searched?

After a few days I realized that the search will work only if started from the middle address, because these addresse is frequently read by the client, so it was obvious, since it is not necessary to connect the memory regions.

Are there performance problems at the moment?

Not that I'm aware of.

Currently does GetIdAddressLine (id) read the memory each time, to get the local variables, and then if the id is known, it takes the address from the own table.
It's your decision

[rock5]

Actually it was easy to find an id with no name. The first one I tried worked.

Code: Select all

print(GetIdName(210000)) 

printed nothing and didn't error, so it has no name and is a valid id.

Code: Select all

/run DEFAULT_CHAT_FRAME:AddMessage(TEXT("Sys210000_name")) 

printed "Sys210000_name". So it behaves the same as it would if you used an invalid id. So that command doesn't tell us it's invalid or not.

Anyway, don't worry about it. Like I said, it's not causing any problems and probably isn't going to.