Mouse memory addresses

Runes of Magic/Radiant Arcana (http://www.runesofmagic.com)
Message
Author
KillerTHC
Posts: 63
Joined: Tue May 25, 2010 8:49 pm

Re: Mouse memory addresses

#21 Post by KillerTHC » Thu Jun 24, 2010 11:29 pm

If RoM is hooking the mouse then could we not detour the API function that it is hooking? Thus allowing us to return bogus results that we determine to make RoM think that it knows where the mouse is instead of changing the addresses themselves. I am currently not skilled enough in C++ to do this but I will be reading up more on it.

P.S. I don't think detours would be considered "modifying the EXE" since it modifies the API function and not the program calling it.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: Mouse memory addresses

#22 Post by rock5 » Fri Jun 25, 2010 1:05 am

Administrator wrote:You can get the ID, yes, but not the pointer to it's instance in memory (which will change every time you see it). That won't work, unfortunately.
I've had another idea for the "target and attack".

If you have a mob targeted can you get the "pointer to it's instance in memory"?

If so, then maybe when you have agro'ed multiple mobs, after killing the first mob you can store it's address in memory, kill the next mob then loot both bodies after you are no longer agro'ed.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
3cmSailorfuku
Posts: 354
Joined: Mon Jan 21, 2008 6:25 pm

Re: Mouse memory addresses

#23 Post by 3cmSailorfuku » Fri Jun 25, 2010 5:46 am

KillerTHC wrote:If RoM is hooking the mouse then could we not detour the API function that it is hooking? Thus allowing us to return bogus results that we determine to make RoM think that it knows where the mouse is instead of changing the addresses themselves. I am currently not skilled enough in C++ to do this but I will be reading up more on it.

P.S. I don't think detours would be considered "modifying the EXE" since it modifies the API function and not the program calling it.
It doesn't work like that, but it's the same deal. Detouring means to modify functions and redirect them to your own and then jump back or call it yourself. Which would still require a trigger, such as the input the bot makes but then what? You can't excactly modify this to what you want, you would need to use a game function to actually accomplish this.

Just to verify this, but in Kingdom of Heroes it doesn't work too sending mouseclicks into a backround window. What I did was using Spy++ to check out if it receives any special messages once I give it it's focus and I saw that it's changing an adress. Once I had added this and froze it to 1 (1=has focus/0=no focus, it doesn't really give the program the focus, it just makes it think it does) I was able to send anything I'd wanted. Someone tried this already, right?

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#24 Post by VoidMain » Fri Jun 25, 2010 10:34 am

3cmSailorfuku wrote:Just to verify this, but in Kingdom of Heroes it doesn't work too sending mouseclicks into a backround window. What I did was using Spy++ to check out if it receives any special messages once I give it it's focus and I saw that it's changing an adress. Once I had added this and froze it to 1 (1=has focus/0=no focus, it doesn't really give the program the focus, it just makes it think it does) I was able to send anything I'd wanted. Someone tried this already, right?
I'm not entirely sure about RoM behaving the same way, i can see a WM_ACTIVATE_APP there, both when becomes active and inactive, we might be able to emulate that but i fail to see a flag saying the window is active in game memory...

I still think finding a pointer to surrounding objects is our best bet, think about it, we can select much more eficiently the target to attack or harvest, many times we miss an attackable just because we can't tab that fast to target it, if we can read that table (and the table exists i'm able to see it but can't find a static pointer to it) we can get closest mob even if it is behind us (like a human player does) we can get a better behaviour to loot (we can check the flag that indicates the mob has loot), etc., etc., etc....

I¡ll apreciate some help to find that pesky pointer tho... Will keep searching for it anyway...

KillerTHC
Posts: 63
Joined: Tue May 25, 2010 8:49 pm

Re: Mouse memory addresses

#25 Post by KillerTHC » Fri Jun 25, 2010 11:20 am

VoidMain if you teach me a little bit on the pointer stuff I would be happy to help out because this stuff is getting really interesting to me. As for using detours I see what you mean and will try to think of a way to use them in theory.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: Mouse memory addresses

#26 Post by rock5 » Fri Jun 25, 2010 11:33 am

KillerTHC wrote:VoidMain if you teach me a little bit on the pointer stuff I would be happy to help out because this stuff is getting really interesting to me. As for using detours I see what you mean and will try to think of a way to use them in theory.
There are guides to pointers and offsets on this site:
http://www.solarstrike.net/phpBB3/viewforum.php?f=5
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

KillerTHC
Posts: 63
Joined: Tue May 25, 2010 8:49 pm

Re: Mouse memory addresses

#27 Post by KillerTHC » Fri Jun 25, 2010 1:31 pm

thanks rock5 I will look into it. VoidMain is the table populated with the IDs of each object? Just curios on what I should be looking for to locate part of the table.

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#28 Post by VoidMain » Fri Jun 25, 2010 2:19 pm

Well i found something i think might be the table we are looking for, it is in a fixed addres but i'm not that sure if it really is what we are looking for, it certainly points to resources near but... it changes every second... anyway if someone wants to take a look, the address is: 0012E620 it starts there and points, at least, to pointers of resources i restarted the game like 20 times and that doesn't change i hope i can find something better than this...

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#29 Post by VoidMain » Fri Jun 25, 2010 4:33 pm

Ok, great news I found the pesky table of surrounding objects!!! ^^

The address is: 9F4FDC it is an array of 67 ints, the ints are pointers to the pawns surrounding the player, this are great news, at least for me, this means that, with a few minimal modifications, now we can harvest in background ^^

Edit: The table is larger than 67, i spoke too fast ^^ it holds, at least 200 objects i still have to search for a terminator...
Last edited by VoidMain on Fri Jun 25, 2010 5:37 pm, edited 1 time in total.

User avatar
Administrator
Site Admin
Posts: 5318
Joined: Sat Jan 05, 2008 4:21 pm

Re: Mouse memory addresses

#30 Post by Administrator » Fri Jun 25, 2010 4:46 pm

This is great news! I'll have to check this out later and see if I can't get something workable. I've been very busy lately.

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#31 Post by VoidMain » Fri Jun 25, 2010 5:21 pm

Tiis is a userfunctions file to test new functionality, just change the player:harvest() in your waypoint for player:harvestmem() ... yeah, i know, name sucks, but it is just for testing, in my tests it works really nice ^^

Edit: Changed the file to search for more objects, handle aggro and timeouts of harvestables with higher lvl than our own skill lvl (we should be able to check for this)
Attachments
userfunctions.lua
Test file.
(2.27 KiB) Downloaded 293 times

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: Mouse memory addresses

#32 Post by rock5 » Fri Jun 25, 2010 10:58 pm

HURRAY! Kudos to VoidMain!
Hip hip...hurray!
Hip hip...hurray!
Hip hip...hurray!
(rock5 pops a dozen streamers filling the air, heartily slaps VoidMain on the back and hands VoidMain a cake with sparklers on it)
Champagne for everyone.
We're partying tonight.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: Mouse memory addresses

#33 Post by rock5 » Fri Jun 25, 2010 11:41 pm

I been thinking about how it should be implemented.

We need a function that collects nearby objects to a range specified and returns a table with vital information like addresses, ids, names.

We need an attack function that will look up a name in the table from the previous function and attack it. Used for initiating attacks, starting dialogs with npcs, opening mail boxes and bulletin boards and harvesting. Or maybe this should just be a targeting function that uses the table and memory addresses to target the object.

I think this makes the harvest command obsolete. What we need is to be able to use type="HARVEST" for a harvest waypoint file.

We also need a creatpath option for collecting the information to use the new attack function to open not only npc dialogs but also mailboxes and bulletin boards and the like.

Like I said before, we need to keep track mobs we kill so we can deal will all aggro before looting the bodies. We should have the option to loot unlooted bodies left by other people. We could also probably use this to make using AOE skills possible too.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#34 Post by VoidMain » Sat Jun 26, 2010 11:29 am

I been thinking about it too, i don't think we need to keep a table of surrounding because we have it accessible in memory any time we want to check it but, we can have have a small table with the mob we're attacking and the aggro ones that are attacking us, so we can kill all of them before looting, that would be something awesome and will make us look alot less "botish"...
Also, loot dead corpses around us will be a nice plus...

As for targettin non attackable NPCs while i was searching game memory looking for this table i was able to see the database, we should be able to get a pointer to it too so we can have all the info about our target, for harvesting this has an obvious benefit, you can check the required skill lvl to harvest a resource so the bot doesn't stay in front of it looking stupid and doing nothing...
One thing i noticed is that the surroundig objects table also holds info about quests, yes, available and completed quests in range...

Another thing, i was thinking also in a "HARVEST" type waypoint file too, basically it will behave the same as "TRAVEL" but it will also make the bot scan every waypoint in the file, that would be great, you just need to pass over resources, set a waypoint near them and let the bot find exact location while approaching...

KillerTHC
Posts: 63
Joined: Tue May 25, 2010 8:49 pm

Re: Mouse memory addresses

#35 Post by KillerTHC » Sat Jun 26, 2010 4:57 pm

Thanks a lot for all the work you have done! This is awesome! Im going to do some testing and report back.

Edit: The basic provided functions will give you an error. However after the following modifications it works nicely.

Original Line 32 - 37 userfunctions.lua

Code: Select all

if( nearPawn.Address ~= 0 ) then
	if( nearPawn.Id >= 560000 and nearPawn.Id < 570000 ) then
		printf("\rHarvestable found id %d %s %x\t\t\n", nearPawn.Id, nearPawn.Name, nearAddress);
		table.insert(harvestables, nearPawn);
	end;
end;
Modified Line 32 - 37 userfunctions.lua

Code: Select all

if( nearPawn.Address ~= 0 and nearPawn.Id ~= nil) then
	if( nearPawn.Id >= 560000 and nearPawn.Id < 570000 ) then
		printf("\rHarvestable found id %d %s %x\t\t\n", nearPawn.Id, nearPawn.Name, nearAddress);
		table.insert(harvestables, nearPawn);
	end;
end;
Original pawn.lua 244 - 250

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
	error("Error reading memory in CPawn:update()");
end
Temp pawn.lua fix 244 - 250:

Code: Select all

	if( self.Id ~= nil ) then
		if( self.Id >= 560000 and self.Id < 570000 ) then
		else
			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

				error("Error reading memory in CPawn:update()");
			end
		end
	end
And the final problem is that we are now using the pawn class for objects that do not have HP, MP, Alive etc.... So when the pawn is updated with pawn:update(); It will think that there was an error in reading the information and give you an error thus stopping the bot. I am not sure how to fix this one ATM.

smokyru
Posts: 31
Joined: Fri Dec 18, 2009 9:02 am

Re: Mouse memory addresses

#36 Post by smokyru » Sat Jun 26, 2010 7:34 pm

I think i understood like 3% from all what you guys said above. Among those 3%, there is "champaign" and "party".

Nah, seriously, congratulations on what you found, it may open a door that was bloody resistant (and annoying, tbh).

All drinks on d003232 !

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: Mouse memory addresses

#37 Post by rock5 » Sat Jun 26, 2010 11:42 pm

KillerTHC wrote:And the final problem is that we are now using the pawn class for objects that do not have HP, MP, Alive etc.... So when the pawn is updated with pawn:update(); It will think that there was an error in reading the information and give you an error thus stopping the bot. I am not sure how to fix this one ATM.
We should make sure the basics are correct first. I always thought pawn is for things that are alive. As such, I don't think we should be messing around with it to make it work with objects. Maybe we need a new "object" class? We could use it to interact with all interact-able objects that aren't alive, like mail boxes, bulletin boards, resource nodes, quest collect items etc.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

KillerTHC
Posts: 63
Joined: Tue May 25, 2010 8:49 pm

Re: Mouse memory addresses

#38 Post by KillerTHC » Sun Jun 27, 2010 9:58 am

rock5 wrote:
KillerTHC wrote:And the final problem is that we are now using the pawn class for objects that do not have HP, MP, Alive etc.... So when the pawn is updated with pawn:update(); It will think that there was an error in reading the information and give you an error thus stopping the bot. I am not sure how to fix this one ATM.
We should make sure the basics are correct first. I always thought pawn is for things that are alive. As such, I don't think we should be messing around with it to make it work with objects. Maybe we need a new "object" class? We could use it to interact with all interact-able objects that aren't alive, like mail boxes, bulletin boards, resource nodes, quest collect items etc.
I agree that we should not change the pawn class to work with objects but instead we should make a new "object" class with the bare minimum like Id, Name, and Address.

Attached is the stripped down version of pawn.lua called object.lua, it works with the memory harvest function but it appears that not all the objects that are in the table of surrounding objects have an Id.
Attachments
object.lua
Stripped down version of pawn.lua
(2.78 KiB) Downloaded 271 times

VoidMain
Posts: 187
Joined: Wed Apr 21, 2010 12:21 pm

Re: Mouse memory addresses

#39 Post by VoidMain » Mon Jun 28, 2010 7:42 am

KillerTHC wrote:
rock5 wrote:
KillerTHC wrote:And the final problem is that we are now using the pawn class for objects that do not have HP, MP, Alive etc.... So when the pawn is updated with pawn:update(); It will think that there was an error in reading the information and give you an error thus stopping the bot. I am not sure how to fix this one ATM.
We should make sure the basics are correct first. I always thought pawn is for things that are alive. As such, I don't think we should be messing around with it to make it work with objects. Maybe we need a new "object" class? We could use it to interact with all interact-able objects that aren't alive, like mail boxes, bulletin boards, resource nodes, quest collect items etc.
I agree that we should not change the pawn class to work with objects but instead we should make a new "object" class with the bare minimum like Id, Name, and Address.

Attached is the stripped down version of pawn.lua called object.lua, it works with the memory harvest function but it appears that not all the objects that are in the table of surrounding objects have an Id.
Indeed, not all the objects in the table have an Id thats because we have things like quests in that table...

I made another interesting discovery, i found the harvesting status flag, it is at the offset 0x160, it gets a value of 11 when you harvesting, this is nice to detect if we even started to harvest when we supossed to...

I would love to get a pattern to search for the table so we dont lost it when next patch comes alive...

User avatar
Administrator
Site Admin
Posts: 5318
Joined: Sat Jan 05, 2008 4:21 pm

Re: Mouse memory addresses

#40 Post by Administrator » Mon Jun 28, 2010 4:16 pm

I've currently got a working harvesting function using all this new information. It still needs some tweaks, though. I'm testing it for stability (as yesterday I had a few issues with it crashing the client that needed to be worked out). If things go well, I'll commit it.

If this works well, we can expand it to targeting monsters, as well. This will allow us to target and attack aggressive enemies more intelligently, for one, or to tell when many enemies are nearby for an AoE.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests