SMSG_MONSTER_MOVE oddness...

[amadmonk]

To the packet parsers out there, my bot/radar are working fairly well except for one bit of oddness.

When I attack a monster, I get an SMSG_MONSTER_MOVE packet back, but no further moves until the monster dies.

Peeking into the monster move packet, what I see is a current position, and then at least one waypoint position; so basically the Blizz servers are sending back an "intent to move" packet to the client.

However, I don't see any further actual movement until the creature dies.

So, are my fears true -- do I need to do position-guessing based upon the creature's movement speed, target location, and time offset?

I was hoping I could just maintain positional state through the packets without any hocus-pocus velocity vector computation...

[BoogieManTM]

I'm not 100% sure on this (will try to confirm later), but I think once in combat, movement is handled by the smsg_object_update packet, specifically the movement block. It should be sending you field blocks anyways, for health/power/etc updates. It's a good place to start looking, at least

[amadmonk]

Hmm... I'm handling the object updates (I'm getting health updates and so on).

That being said, the movement code in object update DOES have a lot of weird flag testing blocks in it, and I do 99% of my positioning through MSG_MOVE packets, so it's quite possible that my object update move handler isn't working correctly.

It's a pain in the butt to debug with VC# express, since it doesn't let me do conditional breakpoints (as in, break here, but only if the guid is xxxxx). I may have to just shell out for the full ver soon...

[Ugge]

Combat movement is handled by SMSG_MONSTER_MOVE too.
When you gain aggro from the mob the sent packet looks a little different from what it usually is. The first flag is set to 3 followed by an unpacked guid (of the local player in this case). After this you just read the rest of the packet as normal. You will in most cases receive a waypoint ~3.66 yards away from you towards the mob.

[amadmonk]

Yeah, I'm getting the waypoint (I snaked the code for the packet layount from Mangos to save a little reversing time); if I have my radar set the mob's "current" position to the waypoint, I can see it (the mob) just suddenly "jump" to my location after I gain aggro.

But what you're saying is that there's no "in between" position packets? In other words, the only way for me to know where the mob is between the moment I gain aggro and when it dies is to do motion prediction?

Ugh.

On an interesting note, I just ran through a 10k packet capture and never once hit my breakpoint on the UPDATETYPE_MOVEMENT case in SMSG_UPDATE_OBJECT. My position updates work fine on object create (I do the standard create, position, values block). And I'm seeing almost all the other cases hit (values, create, create2, out of range, but not near objects). But interestingly, I never see the position update block hit on its own. If that's incorrect behavior, that might be my root cause (if BoogieMan is right).

[Ugge]

nope, no in between packets. you need to interpolate the mobs position towards the waypoint over the amount of time that is specified just before the waypoint count field.

[amadmonk]

That seriously sucks, but it's sort of what I was starting to assume (since I can't find any obvious bugs in my code).

Is the time before the count a ms count or an absolute time value? If it's just MS, that's a little easier; I can figure out how to flag my Position objects for interpolation and do the math based on packet timestamps, I guess.

Thanks (even though it's not the news I was hoping for...)

[Edit: is this the only place where I'm going to need to do motion prediction for your run of the mill combat bot? So far everything else seems to be fairly well behaved about reporting its position and I can use CTM to move my toon around.]

[Apoc]

Yeah, I'm getting the waypoint (I snaked the code for the packet layount from Mangos to save a little reversing time); if I have my radar set the mob's "current" position to the waypoint, I can see it (the mob) just suddenly "jump" to my location after I gain aggro.

But what you're saying is that there's no "in between" position packets? In other words, the only way for me to know where the mob is between the moment I gain aggro and when it dies is to do motion prediction?

Ugh.

On an interesting note, I just ran through a 10k packet capture and never once hit my breakpoint on the UPDATETYPE_MOVEMENT case in SMSG_UPDATE_OBJECT. My position updates work fine on object create (I do the standard create, position, values block). And I'm seeing almost all the other cases hit (values, create, create2, out of range, but not near objects). But interestingly, I never see the position update block hit on its own. If that's incorrect behavior, that might be my root cause (if BoogieMan is right).

The server sends 'where it should end up', not 'all the points to walk to get to the end'. The client itself actually handles the pathing to the end point. Hence why you'll sometimes see it take some really screwy paths.

[Ugge]

Its a timespan in ms.

Players and regular npcs also need motion prediction. If someone fears you (the local player), you will get a monster_move packet with a bunch of waypoints to interpolate between

I think (not sure), Charge needs prediction also (again monster_move packet)

So basically spells the take control of you...

[amadmonk]

The server sends 'where it should end up', not 'all the points to walk to get to the end'. The client itself actually handles the pathing to the end point. Hence why you'll sometimes see it take some really screwy paths.

Yeah, makes sense. I knew that the client took care of most of the position updates for the player, but I was surprised to find out that the server offloaded some of the mob positioning, too.

In a way it doesn't matter -- my bot will still get all of the damage packets and so on, so it'll know it's in combat (and who's got aggro, threat, and so on). It's just that for calculations of "am I in range?" and "do I need to change facing to cast this spell?" I'll be fubar without doing the motion prediction.

It's not such a huge deal, I guess (except that I'm not super great with coordinate math -- been a LONG time since high school trig -- and WoW's left-handed ortho projection system has been kicking my butt in WinForms).

[amadmonk]

Its a timespan in ms.

Players and regular npcs also need motion prediction. If someone fears you (the local player), you will get a monster_move packet with a bunch of waypoints to interpolate between

I think (not sure), Charge needs prediction also (again monster_move packet)

So basically spells the take control of you...

Makes sense. I think (as I hinted to Apoc) I've just been mostly dreading getting the trig functions working -- getting the translation and rotation to work properly for my radar panel was a major pain; I know the old "cos == x, sin == y" stuff from my high school trig days, but since WoW doesn't use a standard coord system, it's been mostly hit and miss (flipping signs, swapping cos for sin...)

[BoogieManTM]

Well that'd explain it! Just one of those "huh" kind of things we've noticed too but havn't looked into.

float dt = travel_time / 1000f;

float dx = (float)Math.Cos(Direction) * speed * dt;
float dy = (float)Math.Sin(Direction) * speed * dt;

float dist = (float)Math.Sqrt(dx * dx + dy * dy);

Vector4 newPosition = new Vector4(lastPosition.X + dx, lastPosition.Y + dy, lastPosition.Z, Direction);

[amadmonk]

(Edit: duh.

I don't need sin or cos or facing or speed. I know the distance to travel in both X and Y (regardless of facing or anything else, this is expressable as a simple offset).

dX = Xdest - Xstart;
dY = Ydest - Ystart;

Xcur = (travel time in ms) * (dX / total travel time in ms)
Ycur = (travel time in ms) * (dY / total travel time in ms)

I know most of the variables: (X,Y)start, (X,Y)dest, total_travel_time_ms, and can easily compute the rest (dX, dY, travel time, Xcur, Ycur).

I suppose if I wanted to get the facing I could do the correct trig, but for the time being -- since I don't care about monster facing and player facing during fear/charge doesn't really matter -- I can ignore it.

Since I'm rusty in trig, I was out-thinking myself, but it's really not that complicated. Duh!)

[amadmonk]

And here, for anyone needing the facing based upon a start and end position, is C# code. It really wasn't that hard...

/// <summary>
/// Returns a (possibly "corrected") facing from a start and end point
/// </summary>
/// <param name="start">The starting point</param>
/// <param name="end">The ending point</param>
/// <param name="useWoWFacing">Whether to correct for the WoW axis rotation.</param>
/// <returns>The facing (possibly "corrected" for WoW) resulting from the movement.</returns>
/// <remarks>Note that WoW uses a rotated axis.  Also, on most display systems, the
/// Y axis is inverted, with upwards movement decreasing Y and downwards movement
/// increasing it.  This should be accounted for if rendering to screen.</remarks>
float GetFacing(PointF start, PointF end, bool useWoWFacing)
{
    float dX = end.X - start.X;
    float dY = end.Y - start.Y;

    // North in WoW means decreasing Y, so the Y axis needs to be flipped 
    if (useWoWFacing)
    {
        dY = -dY;
    }

    // note:  C# floats correctly handle neg/pos Infinity; there is no need
    // to account for dX being zero!
    float angle = (float)Math.Atan(dY / dX);

    // WoW rotates the axes such that facing 0 is due north (which would be PI/2
    // in a nonrotated coord system; if the flag is set, we return the WoW facing
    // rather than the "correct" facing.
    if (useWoWFacing)
    {
        angle -= (float)Math.PI / 2.0f; // wow axis rotation
    }

    // probably could use an "if" instead of "while" for these, but
    // the "while" formulation allows for angles less than -2PI and
    // greater than 4PI and doesn't cost much computationally.
    while (angle < 0)
    {
        angle += 2.0f * (float)Math.PI;
    }

    while (angle > 2.0f * (float)Math.PI)
    {
        angle -= 2.0f * (float)Math.PI;
    }

    return angle;
}

[amadmonk]

Okay, so this worked (in general... my facing functions are still iffy since I'm trig-challenged).

I notice that I'm still not getting facing/orientation information for a lot of monsters and some players. I wonder... do I need to interpolate the facing based upon move packets? I mean, I know where they were and where they're going, so in theory I should be able to guess from the type of packet (forward, back, strafe, etc.) what the facing is.

It's not really all that important for my bot to know facings, but it would make my radar (which shows facing nubs) prettier...