Diablo III

[Administrator]

Well, first thing I noticed was that you had the wrong order of parameters for atan2. The y coordinate comes first, not x. Second, I see you are using degrees, when I don't really see any reason to convert from radians as that's what you'll be using in most of your calculations.

[lisa]

Well, first thing I noticed was that you had the wrong order of parameters for atan2.

Yeah I hadn't actually started to code it for usage as yet because I still need to work out how I am going to determine where to click on screen. Didn't want to do a great deal of code that might not even get used.

I see you are using degrees, when I don't really see any reason to convert from radians as that's what you'll be using in most of your calculations.

I pretty much only understand degrees in my head, so I did that so it actually made sence to me as opposed to the -15 to 15 radians.

I still have no idea how I am going to actually determine where to click according to the angle.

I of course looked to RoMbot for inspiration but since it turns the character to face the direction it is different to just clicking on the screen in the direction.

I might need to do some serious web browsing to get the answer, time I don't have that much of at the moment =(

--=== Edit ===--

I think for now I will just do it as radians and a table, since only like 30 to deal with it won't be that bad.

At a later date I might look at some fancy maths stuff to do it.

[Administrator]

Well, I don't know how you got -15 to 15. Radians go from -pi to pi, or 0 to 2pi.

Anyways, to calculate a point on a circle, you'll need three things: the center of the circle, the radius, and an angle (in radians).

Code: Select all

-- nx, ny = x,y coordinates on the circle
-- x, y = center of circle
-- a = angle (in radians)
-- r = radius
nx = x + cos(a) * r;
ny = y + sin(a) * r;

So, if x,y is (0,0) and you want to calculate the point that is 10 units away from it at 1.57 radians (1/2pi), you get this:

Code: Select all

nx = 0 + 1 * 10; -- the cos of 1/2pi is always 1
ny = 0 + 0 * 10; -- the sin of 1/2pi is always 0

It makes sense that the point would be (10,0).

[lisa]

hmm ok so in my situation.


Center of the circle would be the middle of screen.
angle would be of course angle
radius is how far away I want to click.

Code: Select all

wx,wy,wwide,whigh  = windowRect(getWin());
angle = math.atan2(waypoint.Z - playerZ,waypoint.X - playerX);

nx = (wwide/2) + cos(angle) * 10;
ny = (whigh/2) + sin(angle) * 10;

mouseclick(nx, ny, wwide, whigh)

probably going to have to do the alteration of 45 degrees to angle before using it hmmm

very late, I'll see if I can get some time tomorrow to work it out.

Well, I don't know how you got -15 to 15.

The prints I did of angle and changing the values ie.(1-0,0-1)
were prints of -1.57 to 1.57 , I just moved the decimal place when I remembered it.
So I guess it is -pi/2 to pi/2

[Administrator]

That looks right to me.

45° would be pi/4. To get the other angles, you can just add pi/2 to that.

[lisa]

This might not be 100% accurate to the decimal point but it seems to be working well.

Code: Select all

	local wx,wy,wwide,whigh  = windowRect(getWin());
	local angle = math.atan2(-(waypoint.Z - playerZ), waypoint.X - playerX)
	if 0.78 > angle then angle = angle + 2.35 else angle = angle - 2.35 end
	nx = (wwide/2) + math.cos(angle) * 80;
	ny = ((whigh/2)-23) + math.sin(angle) * 80;
	return nx,ny

Not sure why I had to do - Z though but it just needed it to work correct /shrug

Worked great for the first 5 or 6 waypoints and then suddenly went the wrong direction.
Still not working 100% and now I am wondering why I had 1.57 when other prints do -3.14 to 3.14 which is -pi to pi like you said.

Think I need to come back to this with a fresh head, might work on it later tonight.

[lisa]

Ok well I worked out what might be causing an issue, in my head atleast, is the axis goes in a different direction as such than I originally thought, hence the needing -Z

So this changes my whole theory of how to make it work lol

From what I can tell so far the angles look like this.

So if the angle is
0 then click (X+1, Z-1)
-0.78 then click (X,Z-1)
-2.2 then click (X-1,Z)
+-3.14 then click (X-1, Z+1)
2.2 then click (X+1,Z)
0.78 then click (X,Z+1)

I did mention this stuff isn't my strong suit right? lol
even writing it down I still don't fully unstand how I am going to do it.
Maybe if I look at this post long enough I might understand, that's why I added the pix =)

--=== edit ===--

So for -pi all the way around to + 3/4 pi I should be able to just add pi/4 to the angle and for the 3/4 pi to pi I should -1.75 * pi

That kind of makes sence, kind of. I'll test and see.

[lisa]

Maybe prints will help me more lol

Code: Select all

dest.Z , playerZ   ,   dest.X , playerX)
angle

461    471               581        598
2.609

461    473               581        594
2.414

461     476              581        589
2.084

461     480              581        589
2.00

removed the decimal points, well most of them.
angle is unaltered.

second -12 -13 angle 2.414 which to me should be straight up, close to it. Maybe my +pi -pi is backwards.


going to set Z back to not -Z and see what prints.

--=== results ===--

Code: Select all

461 480 581 598
-2.313

-19 -17, should be close to straight up
-2.313, so with Z back to normal the -pi and pi is same as my pic.

Code: Select all

461 474 581 571
-0.979

-13 +10
-1

Ok this now puts the angle axis the same as the actual game coords axis, I am thinking this is a good thing lol

Now to work out how to tell the bot to click to the right if angle == 0
Might see what prints I get from the click position now with this.

I feel like I am going in circles =(

[lisa]

sigh of relief, Well this "seems" to be working now.

I eventually had around 15 print lines before I worked it out.

Code: Select all

	local wx,wy,wwide,whigh  = windowRect(getWin());
	local angle = math.atan2(waypoint.Z - playerZ,waypoint.X - playerX)
	if math.pi*0.75 > angle then angle = angle + math.pi*0.25 else angle = (angle - math.pi*1.75) end
	nx = (wwide/2) + math.cos(angle) * distance;
	nz = ((whigh/2)-23) + math.sin(angle) * distance;
	return nx,nz

--=== Edit ===--

Used math.pi with fractions and now works almost perfectly, not sure I can actually do any better.
Only issue now is if you click center of screen then you move down, I put in a -23 to counter it but it is still slightly out and -24 is to much. Ohh well it will have to do.

I will probably have to make that a fraction of screen height aswell to allow of other screen resolutions.

[lisa]

--=== Already done ===--

1. I have player coords and have a waypoint creating setup
2. Found a way to tell if screen is zoomed in or not
3. Have Hp all classes and use it to get max (not ideal).
4. added in usage for moving to follow the waypoint system


--=== Immediate To Do ===--

1. Possible add in distance check and add hold mouse click for period of time which would mean less mouse clicks to move or click further away, maybe both.

2. Determine a way to tell which class character is


--=== long term to do ===--

1. Work on addresses + offsets for each class maxHP -- currently just using HP and updating max HP if HP goes higher than HP, not ideal but working for now.
2. create table of mobs and objects, big job.
3.Everything else

[lisa]

Patched and updated addresses, just need servers to go online again to test them. It can wait til tomorrow =)

---== Update ===--

Addresses all worked fine.
So next step is find an indicator for player class or creating a table of objects/mobs. Not looking forward to that, big job lol

[lisa]

Ok been doing some browsing memory, my eyes are starting to feel like they are bleeding lol

Anyway, might be on to something.

Ok so the pointer in pic is for player HP and is 90% reliable, it seems to change when I get the nefalum buff, not sure why at this stage.

But anyway, I figure the 0x40,0xC8,0xC offsets are to get to the hp pointers for pawns/objects.

Basically I believe the C indicates hp and that all mob/object hp info is in that section of memory with just 1 more pointer. So I am going with the theory I can do a for i = 1,# do and have it as a +4 byte at that spot after the 0xC and get the hp for all objects, as to how many the size should be, not sure just yet. Concidering player was 0x2A0 it might be a lot.

I also figure that changing the 0xC will get other info, like max hp and so on. Needs a lot more testing/searching to confirm that.

Atleast it is a ray of light, this is all new to me lol


--=== edit ===--

Ohh well it was a nice dream, max HP is
0x40,0xC8,0xC,0x27C,0x8

so the only difference is the 0x27C and 0x2A0 between max hp and hp, for player.

Might have another look tomorrow with fresh eyes.

[Administrator]

It could be a linked list. So, something may point to the first element, which contains a pointer to the second, which contains a pointer to the third, and so on.

[lisa]

Not sure I fully understand but I will have to do more testing to see what I can work out.

I know for sure that hp of player and mobs all were from same static address and 1,2,3,5 offsets were all the same, only the 4th offset varied.
The player Max HP was also same static with same offsets 1,2,3,5.

On occasion the 90% reliable offsets for player would "change" I noticed it mainly when I get a special buff called Nefalum, adds to magic find.

So I have been using this as my player HP code.

Code: Select all

	playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x2A0,0x8}) or 0
	if playerhp == 0 then 
		playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x29C,0x14}) or 0
	end
	if playerhp == 0 then 
		playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x298,0x20}) or 0
	end	

If the usual offsets fail then it tries another set which again has the same offsets 1,2,3 but 4,5 are different. So far I haven't noticed it not get the player HP with using this method but I would love to understand it more as to why it changes, my theory is that the player "pawn" isn't always 2A0 (4th offset).

I think more investigating of the section of memory that offsets 1,2,3 point to will hold the key. That region of memory seems to point to all the mobs hp atleast. It seems rather a large section of memory allocated for it, so will be hard for me as I am still working out what most of this stuff means lol

[lisa]

can I print the hex value of an address instead of decimal value?
Anytime I do a "print(address)" it prints the decimal value, I then pop it in my calculator and convert it to hex that way lol

[Administrator]

Code: Select all

printf("0x%X\n", address);

[lisa]

Ahh cool, that will make it a little easier for me, I should have looked at the % things.

In addition to the hp address issue.
I found last night that the address changes when an elite/champion mob is within memory range, when you kill them at lvl 60 you get the buff I mentioned. So it has nothing to do with the buff itself but the mob you kill to get the buff.

So I am going along the lines of normal mobs are in range of 0x4-### and then player and elites are in range of ###-###, probably starting at 2A0. Obviously this theory needs more testing.

The FFFFF067 before a HP value is holding true, so determining if an address is an actual hp is still reliable by just checking value 4 bytes before the possible hp address.

Code: Select all

FFFFF067  31741
(hex)       (hp float)

[lisa]

Did some playing and testing tonight, this is getting confusing/weird.

Code: Select all

	playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x2A0,0x8}) or 0
	if playerhp == 0 then 
		playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x29C,0x14}) or 0
	end
	if playerhp == 0 then 
		playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x298,0x20}) or 0
	end	
	if playerhp == 0 then 
		playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0x28,0x6C8,0x8}) or 0
	end	

Ok I am now up to 4 sets of offsets for player HP, first is just normal, second is when you first encounter a champion/elite, 3rd is when you have max nefalum buff (5) and the 4th is when you see/kill a boss.
Now the offsets don't work earlier, so can't just use 3rd set before any champions.

It's very possible that the offsets are changing without the champions and it is just that is when I notice the change, really hard to say at this stage. All I know for sure is that it's a pain.

For testing what I did was just add them to the bottom of CE and check the float value every now and then and see what is getting the right hp value and what isn't.

Need some sleep, might have another look tomorrow night.

[Administrator]

Do you think that is the player struct, or is it just HP? Maybe that could just be the info getting passed to the HUD to display HP/mana/whatever else. If those buffs and stuff change the UI at all, that might then explain what you are experiencing.

[lisa]

it is possible,
the HuD displays in whole values though with no decimal and the float values are 30754.234214, so it seems like a full calculation of hp. Even when HP is at max the value can have many decimal places, if you have a +hp% buff.

I could do more testing on this by just having buffs without actually killing anything, not hard to do but I am pretty sure that the offsets won't change with just buffs.
The nefalum buff has a 30 min duration so I'm not going to just let it run out for testing at this stage.

--=== Edit ===--
Played with buffs and didn't affect the first set of offsets.

Interestingly today this set

Code: Select all

playerhp = memoryReadFloatPtr(getProc(), addresses.playerhp, {0x40,0xC8,0xC,0x298,0x20}) or 0

Held true for all chars all the time (I didn't kill a boss though)

*puts on tinfoil hat*
I am starting to wonder if their "warden" is set up to change the addresses when it feels like it lol

*takes off tinfoil hat*
So yeah still nothing definate as to how the offsets work.