Need help with table structure

[MiesterMan]

I'm working on something and I need to be able to read data around elements in the tables. Though I can search for them and find them I need to know how to read the pointers and offsets. For some reason I can't make sense of the way the memorytable functions work so I was wondering if someone could post a pic of what the cheat engine pointer to a set of table ids looks like. Specifically the "Add address" dialog with the path the pointers take.

Whenever I see "memoryReadIntPtr" or anything with Ptr at the end I know I'm not gonna be able to figure it out, those funcs seem to do something wierd.

[lisa]

I could be wrong but the way I understand it is the
memoryReadIntPtr
is for when you have multiple offsets.
example
address = 0x932123
offsets = {0x32, 0x8, 0x61}

memoryReadIntPtr( getProc(), address , offsets )
So it starts at

Code: Select all

0x932123 which points to 0x1243211
then do first offset 0x32
0x1243243

which points to 0x1031301
then do next offset 0x8
0x1031309

which points to 0x11929200
then do offset 0x61
0x11929261

So final address is 0x11929261

But like I said I could be wrong.

[rock5]

I thought I had a good handle on how it worked before Spiralv did his great work. Now I only have a vague idea how it works. Best if he helps you. And he's been online lately. I hope he sticks around. I liked his work.

[MiesterMan]

Ok, I'll be more specific. In memorytable.lua the GetIdAddressLine function has the following:

Code: Select all

	local lineSize = 0x20;

	local tablePointer = memoryReadIntPtr( getProc(), addresses.tablesBase, addresses.tablesBaseOffset )
	local startAddressOffsets = {0,addresses.tableStartPtrOffset, addresses.tableDataStartPtrOffset}

	local dataPointer = memoryReadIntPtr( getProc(), tablePointer , startAddressOffsets ) - lineSize

Now, I try and try but no matter what I do I end up pointing to someting that can't be right. A region of memory near the start of the memory (close to 0x00000000) that has no data or inaccessible data. Interpreting with the current values it looks like this:

local tablePointer = memoryReadIntPtr(getProc(), 0x9EEE4C, 0x28)
local startAddressOffsets = {0, 0x124, 0x1C}
local dataPointer = memoryReadIntPtr(getProc(), tablePointer, startAddressOffsets) - 0x20

I've been able to pull some information just copying these but I wanted to find some more pointers in the paths, some extra offsets to other information I'm looking for. I can't do that if I can't figure out how to follow the address path.

Btw, no promises but what I'm working on is a quest class...

[rock5]

I'm not sure why you need to break down the memory tables.

If you are creating a new class, all you have to do is find addresses and pointers to the list of quest information. Then to get the base information for the quest id, like we do with the bag items, you use "GetIdAddress" to get the base address and then work out what furthur information is stored at that address.

Which quests are you doing? Is it the quest log?

[MiesterMan]

I was going to include the quest log search as part of it, yes. I've already created the pattern search for the pointer to the quest log.

What I was wanting to do was find an association (sp?) between tables in the path that I could use to emulate certain query functions you can already do in game. For instance, there are functions that let you find out what quests are offered by an NPC including their statuses. What I was wanting to do with that is make a function that would let you only have to type GetQuest("QuestName"); when in proximity of the NPC that has the quest. It felt like this would be more efficient than loading a large database of quests with statuses and information. Just pull the quest info up as needed.

While looking at the quest data at the end of the quest pointer is great (most of them are dirrectly followed by their SysDesc) it's not what I wanted. Searching strings for the info isn't efficient, it's just another slow option.

All in all, the biggest challenge is getting around having to use quest id's. I learned this the hard way by mapping all of the quests in logar. I worked out a system using variable checks but it required constant use of quest id's and "CheckQuest()". Memory is deffinately the better option. XD

Though I also found that now I can use the GetIdName() function to remove the need for typing out the name too, it doesn't fix the problem. Having a bunch of numbers in waypoint files without names is even more confusing than having them with names.

[rock5]

If you are creating something for yourself, then it doesn't matter if you are using names but if you are going to share then you have to use ids. Names change but ids don't. A common practice I use is, if I use and id then I put a comment next to it saying what it is. Makes it easier to follow.

[SpiralV]

memoryReadIntPtr( getProc(), address , offsets )
So it starts at

Code: Select all

0x932123 which points to 0x1243211
then do first offset 0x32
0x1243243

which points to 0x1031301
then do next offset 0x8
0x1031309

which points to 0x11929200
then do offset 0x61
0x11929261

So final address is 0x11929261

But like I said I could be wrong.

Yes that's how it is, it forms a tree structure which begins with a constant address. This constant is the same in each 'client.exe' proccess.
all others may be constant also, but only for the running process itself. 0x1243211, 0x1031301 ..
Now if you want to find a special address in memory and it should work with all clients ^^ then these set of instructions must be executed
-> address (deeper in the tree?) offset (deeper in the tree?) offset (deeper in the tree?) ...
it was already part of memorytable.lua long before

Code: Select all

   local tablePointer = memoryReadIntPtr( getProc(), addresses.tablesBase, addresses.tablesBaseOffset )
   local startAddressOffsets = {0,addresses.tableStartPtrOffset, addresses.tableDataStartPtrOffset}

   local dataPointer = memoryReadIntPtr( getProc(), tablePointer , startAddressOffsets ) - lineSize

The id database is totally different.
We are looking for a id number but do not know where it is, before we knew where it is but not the content.
Now the instruction specifies only what's to be performed to get closer to the correct id, running in a loop until the id was found or not.
Thats why it doesn't work with id names.
I think now it's easy to understand, right?
btw: there are more databases, with the same structure as the id database

[rock5]

btw: there are more databases, with the same structure as the id database

What's stored in them? Anything interesting?

[MiesterMan]

Thanks for the replies. I've been getting distracted lately. I managed to find a way to work with the table values without being able to follow the trail to them, just using what's already available. I guess I really don't need that since you guys did such a good job with what's already available.

So far I found in the table with the pointer to the names of quests:
Pointer to the requirements
Pointer to the short description
Pointer to the completion description
Id of required items (I suspect required kills are there too but I haven't taken the time to decipher it)

In the skills table that contains the pointer to the name I found:
Pointer to desc
Required Item Type (mana, rage, focus, energy, consumable, ammo)
Required Item Amount/ID
Required Buff ID
Self Buff ID
Target Buff ID
Range of skill (scout skills are different though)

I'm really excited about what I can find in the bag and equipment slot tables but I haven't chopped into those yet (might be able to finish SR swap).

So um, I'm not spread thin, I'm taking my time!

Again, thankyou for replying, sorry I didn't see it sooner.

[rock5]

I'm not too excited by the quest info as I'm happy with the solutions we have already. Sure, getting info from memory is quicker but how often do you check quest info anyway. So if it takes a few ms or half a second doesn't really matter.

The skills, on the other hand, could reduce our reliance on the skills database even further. And there is a real need. Just the other day I noticed that the bot was trying to cast skills when it didn't have enough mp. When I looked into it I realized, at least for that skill, that manainc couldn't work properly because the amount the mana increase changed the higher the player level. So your Required Item Type and Ammount will fix that. Although I don't really like the name "requireditemtype". It's a bit confusing or misleading. It's mostly a power so I'd prefer 'requiredpowertype' or just 'requirementtype'.

I'm confused by 'Required Buff ID'. Skills might require buffs on a target or the player. How does it destinguish. Is "Target Buff Id" and "Self Buff Id" the buffs the skill applies?

As a goal, you should try to get as many of the values from the skills database as possible. That will make the database much more managable. Of interrest are values we can actually use. Descriptions, for example, the bot would have no need for so we probably wouldn't add those.

Lastly, try not to spread yourself too thin. Focus on one class and complete it before focusing on the next.

[MiesterMan]

Sorry, I left the name as item type to refer to what I'm looking at in the function "item address".

Since Id's refer to everything, I figured referring to them as items would be good. I guess we could call is fuel or something more specific, since buffs are in a different offset.

The required buff ID is for the player specifically. The required target buffs are a little more complicated so I put those on hold until my mind is ready to be wrapped around something like that. One of the things to consider for that is, are they really required or do we just get a bonus for them having it? It looks like there's a list of recalcs in the middle of the table.

I've got some theories about manainc and the like but have yet to confirm it. I guess I'll do that now. (I play rogues/scouts/warriors mainly so my theory leaves my normal characters out)