Anyone Interested...New Development

Hiyoal · 12/12/2008, 01:39

A click recorder (Active Window) which works on Vector calculations to find the opposite lines from the origin. Im going to include a memory check to cross-reference a click and check whether the bot has clicked at the right coordinate.

Hiyoal

Ian* · 12/12/2008, 01:46

if it clicks the wrong coord what'll you have it do then.. lol. It'd be hard to correct that I'd think. Instead of checking whether or not it's clicked the right coord after the jump, you should have it check the position of the mouse before it clicks, else you could end up having it jump in circles instead of going for the real route.

Another problem would be if it clicks on an NPC, a tree, or something like that, it'd keep trying to click it and you wouldn't go anywhere, so what you'd need to do is have it check the coords before the move, then if they don't change after the click is done, have it click again except (2, -2) over so you can avoid the object preventing you from moving

unknownone · 12/12/2008, 01:53

Didn't behelit's CoProxy do this like 4 years ago?

Hiyoal · 12/12/2008, 02:31

Quote:

Originally Posted by Ian*

if it clicks the wrong coord what'll you have it do then.. lol. It'd be hard to correct that I'd think. Instead of checking whether or not it's clicked the right coord after the jump, you should have it check the position of the mouse before it clicks, else you could end up having it jump in circles instead of going for the real route.

Another problem would be if it clicks on an NPC, a tree, or something like that, it'd keep trying to click it and you wouldn't go anywhere, so what you'd need to do is have it check the coords before the move, then if they don't change after the click is done, have it click again except (2, -2) over so you can avoid the object preventing you from moving

I was going to add PixelSearch to correct for the NPC Problem, but I could think up an algorithm which corrects the vector path using the memory-read conquer coords. Rather than jumping in circles, I could give it a tolerance of (+2 -2) which would still work. And with this (+2 -2) a math algorithm could correct the already found MouseClickPos to change it to fix the problem.

I am also going to include a memory address read which checks if the character jumps or not.

@Unknownone
I wasnt here when Behilit's CoProxy was working. Did it have it in it, and just for confirmation...Is my idea plausible?

Hiyoal

UPSman2 · 12/12/2008, 02:46

tried this one, but then got bored. what i personally did was set it like this

c: conquer coord mode

EX: say you at (100,100)c and want to jump to (107,110)c so the difference is (7,10)c what i would do would just have a preloaded pixel point(relative to the center of the screen to avoid screen size issues) for moving (7,10)c.

advice: in algorithm account for zoom

Ian* · 12/12/2008, 03:01

Quote:

Originally Posted by UPSman2

tried this one, but then got bored. what i personally did was set it like this

c: conquer coord mode

EX: say you at (100,100)c and want to jump to (107,110)c so the difference is (7,10)c what i would do would just have a preloaded pixel point(relative to the center of the screen to avoid screen size issues) for moving (7,10)c.

advice: in algorithm account for zoom

One problem with that would also be shift screen. If you were shifted it'd jump too far or not far enough, or it'd click off the screen, possibly resulting in crashes and invalid jumps... He's using memory to check his jump points which is more effective than clicking based on pixels.

UPSman2 · 12/12/2008, 03:10

in memory there 2 address that store where the character is on screen (in screen coords), that's actually what i meant by center of screen

but ofcourse you have to compensate if the person is to far to left/right with if...then statements (it was easier for SendMessage b/c you can send clicks off screen)

although "character is on screen" is actually where the animation is loaded so it changes while jumping since the animation moves from the center of screen. but in the same respect you could use this to time when your character is done with a jump since it'll return to the original center point after the jump

P.S. theres usualy a better way that pixel clicking and probably the best way would be using the built-in CO jump function through dll injection and such, but i dont know how to do that and it might have a clickjail effect with using it

UPSman2 · 12/12/2008, 04:21

you know what i realized... this game is ridiculously stupid

*account permanently suspended*

no...srsly i just changed the pw and logged out

Hiyoal · 12/12/2008, 05:00

Lol. So is there really an address showing the x and y coordinates for the conquer window (In correspondance to Opt("MouseCoordMode",2)) and not for the "In Game" conquer coordinates? I need to get back into haxing their memory again XD.

Hiyoal

Ian* · 12/12/2008, 05:19

in joeks memory tables it's got the memory addresses for x and y already. just look at them. then obviously you gotta get the &H or whatever off and change it to 0x, i think it's that way for C# anyways...

Hiyoal · 12/12/2008, 07:28

Lol, not the "In-Game" character coords...The Mouseclick ones...They are new if your asking me. Joek doesnt have the mouseclick coordinates for your person.

So like, say you shift screen, the "In-Game" coordinates stay the same...as they would but the MouseClick ones change because your character might shift from the middle of the conquer window into the top left.

Hiyoal

Edit: Found the 2 coordinates in memory giving the exact location of the character on the screen

They were both quite close to my mab tool estimates I found xD My X-Cords were off with both 800*600, and 1024*768 windows by +1, and both Y-Cords were exact

Evan Lim · 12/12/2008, 10:08

Hiyoal@
i think UPS is referring to this:

Code:

CharNameAddress = 0x5DA660  
xAddress := CharNameAddress + 68
yAddress := xAddress + 4

Hiyoal · 12/12/2008, 15:04

I found these two adresses.

xcord=0x5DA6AC
ycord=0x5DA6B0

The origins change when in 800*600 compared to 1024*768. And they change accordingly to shift screen.

Hiyoal

unknownone · 12/13/2008, 00:51

Quote:

Originally Posted by Hiyoal

@Unknownone
I wasnt here when Behilit's CoProxy was working. Did it have it in it, and just for confirmation...Is my idea plausible?

Hiyoal

Yeah, it was there. Basically worked by clicking a button to start recording, then you'd follow your path and it'd record it until you stopped. All that was recorded was a continuous list of coordinates, saved in the file in this format:
jump B8 01 80 01
jump B5 01 74 01

Your idea is possible, but I wouldn't advise doing it based on click emulation. You could probably find the actual jump routine within the client where you specify just the destination coordinates and have that function triggered from your bot.

I'm curious to know how the pathfinding feature in the client is done anyway. I stopped playing before they added it. Are they pre-set paths stored in a file, or is it just a pathfinding algorithm where the destination location is specified? If you figure out how it's done, you could probably take advantage of it and use if for your own paths without messing about with 3rd party tools.

Evan Lim · 12/13/2008, 01:26

unknownone@
from what i think i understand is:
there are finite declare "points" existing in the map
when u call the path function in CO, it will go to the closest "point" to the direction

similarly if there is a little pond between u and ur click, ur character can get to the destination point with walking around the pond.
thats why sometimes the client dc users with invalid walk (especially people that doesnt update patches), because those coordinates are not declare in the existing finite "points"