[Required Knowledge]
1. You have to be able to calculate a points relative rotation to you (ie. south = pi, north = 0 or 2*pi)
2. Must be able to read LocalPlayer.position from ram
When I say 'relative rotation' I actually mean the rotation we need to have to be perfectly facing the
point in-game. So from what I was told on this forum, this can easily be done with Math.Atan2(x1,y1,x2,y2)
where x1,y1 = localPlayer.x/y and x2y2 = the other point in-game..but I don't do it this way..if you don't want
to know how I find it..skip the next section. However, if you have problems w/ the 1 liner..try my code
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''''''''''
[How I find 'relative rotation']
I know this is pretty basic math, and I almost feel like using this equation is a cliche..but it's powerful
and enough for what we need. Pythagorean's Theorem: a^2+b^2=c^2, if you don't understand this one..leave
sorry
Also used are the, basic, Sin, Cos, Tan (well actually just ArcTan, but don't worry..your programming language has it
and it's almost exactly the same as Tan..so if you haven't used it before, don't worry, you don't have to understand it
too well.) So, here is a picture that shows how to calculate all possible angles(taking into consideration which quadrant
the point is in)
The logic behind it goes something like this: At the top of a circle is 0 radians, and going to the LEFT it increases
around the circle all the way back to the top which is 6.2 (actually 2 * Math.Pi). What does this mean? So the top
is 0, what is the bottom? ( Well it's half way around the circle, so it's half of our..total radians) so 2*Pi / 2 = PI!
so south = 3.141! You have to understand that 100% before continuing my way..otherwise you're just gonna copy/paste
So, to the left would be pi/2 (1.5 about) and right is 3*pi/2 = 4.5 about. which makes sense..each one is about 1.5 larger.
So 1.5, 3, 4.5, 6..those are *ROUGH estimates* because you should really use the values of pi, not just say 'about'.
Anyway, the reason I drew out the picture is because at first I just tried a one line equation and apparently got it wrong
and couldn't get the angles correct. I thought it had something to do w/ some values being negative, which was larger, etc
and instead of just throwing in a few math.absoluteValue() and just guess..i decided to..logic my way through it, even if it
requires the use of IF statements in my code vs just 1 equation..trust me, it's still fast code, and it's easier to understand
coming back in a month, imo. Some basic info: Wow's coordinate system is weird: X gets smaller to the right (y is normal)
so this mean if LocalPlayer.x > gamePoint.x then // point is to our RIGHT (top or bottom...don't know yet)
and for y (obvious) if Localplayer.y > gamePoint.y then // point is to our SOUTH (left or right depending on above if
Using that logic (of If statements) I came up with this: (it's vb.net, very basic stuff tho)
Code:
Public Function GetObjectRelativeRads(ByVal posX As Single, ByVal posY As Single) As Single
'Returns 0 for fail/same position , 2Pi for vertical
Dim rads As Single = 0
Dim lpX As Single = LocalPlayer.XPos
Dim lpY As Single = LocalPlayer.YPos
Select Case posX
Case Is > lpX
'To our LEFT
Select Case posY
Case Is > lpY
'Above Us, Top Left
rads = Math.Atan((posX - lpX) / (posY - lpY))
Return rads
Case Is = lpY
'Perfectly Left-->WEST
Return (Math.PI / 2)
Case Is < lpY
'Below us, Bottom Left
rads = (Math.PI / 2) + Math.Atan((lpY - posY) / (posX - lpX))
Return rads
End Select
Case Is < lpX
'To Our RIght
Select Case posY
Case Is > lpY
'Above Us, Top Right
rads = (3 * Math.PI / 2) + Math.Atan((posY - lpY) / (lpX - posX))
Return rads
Case Is < lpY
'Below Us, Bottom Right
rads = Math.PI + Math.Atan((lpX - posX) / (lpY - posY))
Return rads
Case Is = lpY
'Perfectly Right-->EAST
Return (3 * Math.PI / 2)
End Select
Case Is = lpX
'Directly ABove or BElow
Select Case posY
Case Is > lpY
'Directly Above-->NORTH
Return 2 * Math.PI
Case Is < lpY
'Directly Below-->SOUTH
Return Math.PI
Case Is = lpY
'x1,y1==x2,y2 :: SAME POINT!
Return 0
End Select
End Select
End Function
That code has been thoroughly tested and works great. Again..this is the rotation you WANT to be
facing the object.
[END How I find 'relative rotation']
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' '''''''''''''''''''''
Problem: How to rotate our character, using the mouse, toward any in-game point ( x,y,z location)
well We Know the following is true
If Math.AbsoluteValue(LocalPlayer.Rotation -targetPoint.RelativeLocation) < .2 //TODO: use value computed by distance
{
//our rotations are almost ==, so I'm facing it!
}
else
{
//we aren't facing it...we need to rotate left or right
}
VERY IMPORTANT: If the object is top-left of you, and almost perfectly north , and you are facing top-right almost perfectly north
math.abs(local.rot-relativeRot) will == 6 BUT you will still be facing them! BIG BUG..be sure you have an IF or something
to handle that exception in your 'RotateTowardPoint(float x, float y)' function.
I'm sure most (100? hopefully) of us use the right-click-down/move the mouse/right-click-up feature of wow to rotate the view
while in-game. If not..it works really well and can be extremely accurate (MUCH more accurate than pressing a/d
to turn - ASSUMING the camera angle is good. If you're looking directly over yourself...the code still works, but..it's bad.
To start of with an example, I climbed on-top of a fence post and wrote down the x,y pos.
That is the 'target point' referred to in here/the screenshots.
(text in picture, basically) As you see I'm facing north and my .rot almost == 0, so that working.
The point is to the south of me, almost, and has a .relativeRotation of almost Pi, perfect. Also
The distance appears to be correct ( SqrRoot[(x2-x1)^2 + (y2-y1)^2] )
The first problem I ran into was ..when turning towards a point, how close should the two .rotations have to be
before you consider it 'directly in-front of you?' And an even more important question: Does it need to be *almost
perfectly* in-front of you? I say, it depends and sometimes I'll need it. at first I used a constant like .2
which works, well..it works differently when you're far/close to an object. This might not affect you, but if you
plan to have points that are more than...lets say 50 units apart..well..let's just see. I ran 50 units away from the post..and then
rotated until I was within .2 of it and then ran forward...how close did I end up?
As I ran forward, the closest I could get was 10units away... if you plan to use melee this *could* be a problem?
And it'll get stuck on game objects? There is somewhat of a workaround, where in your RunToPoint() function you have
an if statement like (if .diffInRotations > .2 then TurnToPoint() again..) ...sloppy: The RunToPoint() function
should take into consideration the objects distance when calculating the 'closeness' the .rotations need to be.
So for example, at 50u, .2 wasn't so great..but it depends on what you're doing. For something like combat, they don't
have to be exactly dead-center (unless you're using the /tab key to find your mob..then it matters :P ), but for
pathing it's nice to be able to move to a very specific spot (ie. with .2 you could only get w/in 10u!! not close)
So if you tried to run through a city using .2 you'd probably get stuck..using a more exact angle can be good.
At the moment I'm testing different values out (how far to move the mouse, 3px, 2px, etc, and how far that changes your rotation)
Depending on resolution, moving only 1px might not change rotation much, but on 60x80 it'd move a lot
There could be
some initialization function that turns 1px and sees how much the angle changes, and used that in calculations later also.
At the moment all I have is something like...
While (differenceInRotations > .2)
mouse_move 10 * Random(10) pixels
}
while (differenceInRotation > .004)
mouse_move 2*Random(4) pixels
}
which equates to..it spinning faster at first..and then slowing down to get the most exact rotation. I did this because if you just
use something like 10, sometimes it'll spin too far past the point, but if you use 2 the whole time it's too slow..I like the multi-
speed thing that code does..I wonder what type of monitoring (pattern recognition :P?) blizzard does on things like position, rotation
etc ? I don't think it's too bot-like tho...I want more opinions for sure, maybe I'll make a video on how well it runs a path/what it
looks like while rotating if anyone is interested.
[Conclusion]
The only problem I can foresee is if the camera angle gets mess up..it'll still rotate your character, but you'll be looking at the ground.
Since we're controlling the mouse..chances are we might mess up the angle (..I hope not? So far the code doesn't..but for example if you
use /tab to target the mob in front of you...it won't work if you're looking down)
One last thing: The 'relative rotation' doesn't take into consideration you're local play.Rotation, which means
if the object is to the south of you..it will always be around 3.1 (duh) 'relative rads' even if you're facing it. Sometimes
I would be facing the target and think 'difference in angles' (if I'm looking at it or not) but look at the 'relative rads' and confuse myself. Just a tip.
Anyway, I hope this helps someone.
-Andrew
edit: Just ran into my first problem --> On the mouse_right_up it keeps changing my camera angle down a little bit..after a few Rotations i'm looking down over myself..definitely not good. It works fine while actually rotating, but when it releases the right_click it's changing the view. I think it has something to do the mouse_event function and how it handles the dx,dy inputs..but I can't figure it out. Anyone have an idea?
