[Bot] movement other than CTM

[Megamike55]

I have been programming a wow bot for a while, always improving updating and adding features...

But its time to go back to my bot's basics. Movement. Up until now I have used key press based movement (Edit: via PostMessage),.. and that coupled with a nice navmesh equals decent bot movement overall, but it lacks precision, so sometimes the bot can be found running in spot stuck on the edge of something (not frequently, but it is still a problem).

My current scheme is to have the main bot logic running in one thread, and when it wants to start turning or stop turning, it sets flags that another, separate thread reads and presses or depresses the appropriate key. The key-presser thread runs every 100 ms, and is responsible for all movement keys (not combat keys - the numbers and F1-12), which results is very in-accurate turning, since if I try to turn EXACTLY to the value I want to, it will always pass that value and end up in a right-left-right-left-right-left pattern. So needless to say, I'm less than satisfied with this arrangement. I first programmed it to be temporary but never went back and updated it.

I want to avoid memory writes as much as possible, even to the "safe" CTM. You may think it is silly, but if possible I'd like purely input based movement. I also realize based on a
thread I found here that instead of writing to CTM you can call functions instead, which I'd also like to avoid if possible.

My question is, has anyone come up with a relatively accurate way of key-based (or even mouse based) turning that is accurate up to lets say 3 or 4 degrees? Right now my bot is only accurate up to 12 degrees (ouch, right).

Or, if you think I'm being absolutely ridiculous by not using CTM, could anyone tell me why exactly it is so safe? I understand of course that warden does not scan it, but it could potentially scan it for consistency with regards to (1) the set xyz pos is actually on the ground and not floating, and (2) mouse events

[pred.is.god]

For some reason I think there is a LUA function for setting facing by degrees. rather then turning using keys, you might set facing or similar. then you have avoided using the CTM address

[mongoosed]

You can set rotation directly to the player, no CTM required. Use some arc tangent math and you can get some pretty decent navigation going without touching the CTM.

[Megamike55]

I realize my post is long and you don't want to read it, and I appreciate your advice, but I'd appreciate it even more if someone actually read what I wrote. :P

[Sychotix]

Can't you use Windows API like PostMessage and SendInput (or whatever the exact functions are). I would think that is alot more accurate than using keyboard events.

[pred.is.god]

I realize my post is long and you don't want to read it, and I appreciate your advice, but I'd appreciate it even more if someone actually read what I wrote. :P

to be fair - i thought it a very elegant solution to you problem of inaccurate turning.
at each waypoint calculate angle and turn you toon onto exactly the heading -via setting its heading- to take you precisly to you next waypoint. when you hit that one rinse and repeat.
a little easy math to determine relative headings and set it at that - then manage you forward/back by keypress running.
the accuracy comes from not pressing turn, checkinking heading pressing it again etc.
if thats not what your looking for then sorry for wasting ur time

[Sychotix]

He said he did not want to do any memory writing, thus he can't "set" the angle.

[caytchen]

And you seriously think that using some Windows API to outright fake key input is safer?! Normal key input never goes through these channels.

[Apoc]

Your other option is to do a ton of math to figure out ScreenToWorld (and vice-versa) to "click" the screen where you want your CTM to go. Keep in mind; that it only works if you can actually *see* the point. (You may end up clicking the side of a building, instead of the other side of it, etc)

[Megamike55]

And you seriously think that using some Windows API to outright fake key input is safer?! Normal key input never goes through these channels.

As to that, how can world of warcraft tell the difference between my program and any other program that allows remote input. KVM software and so on, so I'm not worried about that. Also most multi-boxing software for wow uses the same methods.

[Xarg0]

With rightclick + mousemove you can turn very fast and accurate easiely, however almost instant turns have lead to bans in the past so you might want to use spline pathing.
You can easiely calculate the amount of degrees to turn in a certain amount of seconds in order to reach point B from point A in a nice curved motion, ofc this involves the probability of getting stuck if your waypoints are far apart from each other.
If you are already using a turn based waypointsystem, meaning that you're placing waypoints when facing changes, you should be fine with using almost instant facing trough mouse input.
It might seem a little tricky to get mouse based turning done at first, since the turning speed increases with the speed of the cursor movement, but you can actually split the turning process up into little brackets of pressing the mouse button moving a little and releasing until you've reached the desired angle.
I'm pretty sure Malus old travelbot was using this method, you can surely find the source code at the autoit forums, if you're comfortable with the syntax it'll probably help you to implement your own accurate turning function.

[BoogieManTM]

why not just pulse your movement key thread more often? 10 times a second isn't very often, and the thread in general isn't very taxing. why not lower the sleep time? 50ms? 10ms? 5ms? should get better precision from that, while making nearly no code modifications.

the system i used for clientless might actually work too, which was to build a movement 'queue' of events that would be played back nearly down to the millisecond. What i would do is define a movement structure, which would define commands and a time to execute them (offset from the previous command). my movement thread would then loop through, sleeping itself until the next command needed to be executed. if there was no queue, it would default to a 500ms sleep until there was something to execute. This system is pretty simple, and avoids needing to manage flags or anything else like that. you just build out legs of your movement at a time and append it onto the queue.

[DrGonzo]

Write a test function to turn for an amount of time and calculate the amount turned to come up with a push-time to turn angle conversion, you should be able to get fairly accurate.
If you need higher accuracy, implement a click and drag on the center of the screen to turn for smaller angles.

[MaiN]

The turn speed is pi radians per second IIRC. It's in the movement info struct, so you can read it and have results that are accurate no matter what.

[Megamike55]

Awesome replies, great food for thought. +Rep to you all.