Spawn Position Updates, which is the valid record?

[Protector]

For a while now, it has been a minor annoyance when the mobs start/stop moving on the eq client before or after the seq map shows them doing so. It is never too crucial, a second or two delay at most, but it is annoying.

So I started looking for extra packets besides the spawnupdate maybe containing intermediate move information tied to attack records or something, but couldn't find anything. I did notice however that the update packets can contain multiple records for a single mob (my pet in particular). The way it appears to work in seq code now is that the last one in the packet will overwrite the preceeding ones with the same spawn id, but I am starting to wonder if that is the right way to do it. Suppose VI coded it as a list of updates that accumulate until the packet is sent, with the most recent updates going to the end of the list. If they build the packet based upon this lifo method then it would be right to take the first record as being accurate, instead of the last.

As it is, it seems very inefficient to send over two updates for the same spawn in a single packet. You wouldn't get this with a single loop check for updates, so I presume they are making an independent accumulation list (possibly in a different thread from the packet build and send), and then not checking for duplicates during the actual packet build. I have looked for some possible timing delay information that might aid the client in sequenced small action playback, but don't see room for any such information in the packet (at least on a per record basis). There are three extra bytes at the end of the packet that I can't figure out the usage of that might make the multiple update records make more sense...

But for now I am just going to only take the first record in the packet and see if that makes things synch a bit better with what the client shows. If anyone has any ideas or experience feel free to comment :)

[Protector]

Bah, that's not it, in fact it makes it worse :)

Further checking versus the direction angle and turn velocity for subequent records in the same packet indicates the later ones are more accurate.

I just don't get it, for the EQ client to show the mob moving before SEQ there must be some information passing down.

[Ratt]

Hmm... I haven't noticed this issue you are speaking of, except in a couple of circumstances:

1. The CPU is already overloaded on the SEQ machine
2. The SEQ machine is slow

Are you sure you aren't seeing processing lag and artifacting? The packet processing structure of SEQ isn't exactly the most efficient thing in the world, and with a really busy network, it can get backed up (even by as much as 30 seconds or more). I suspect that this might be what you are seeing. How fast is your CPU? If you have the ability to put it on a fast machine and test it out, does it issue go away?

Right now, on a PIII 700, I get about a .5 second lag vs the client machine on mob / player movement, this is running 2 - 3 concurrent sessions. I'm confident a faster CPU would reduce this time even further.

[Protector]

Hmmm Ratt, have you tried watching a roaming mob going from standing still to moving to see if there is any latency ever, it might also be a zone related issue since I recall quite a bit of lag / latency issues associated with certian zones (The Overthere being one) a while back.

I am running an "enhanced" Windows seq derivitive with a dual-threaded approach one for packet acquisition decode and queueing and one for processing/ui, etc. To test latency early on I attach a timestamp for when a packet is queued versus when it is processed. On the P3 850 machine I am running the SEQ/Bot code on it worst case latency is less than 5 ms, typically 0.

The most noticible effect is when I go to target a mob for a pull and on the eq client it turns and starts to move away while the seq map information doesn't update. At worst the delay seems to be one or two seconds. Once I have the mob targetted, during combat, etc, there is no latency at all, and I suppose this is because of the code VI added a while back to make more frequent updates to targetted mobs, group members, etc. Reviewing the captured packets the single mob update packets for your targetted one are obvious.

This is beyond the normal EQ client latency where you see the mob move further than actual and then bounce back to where it actually stopped.

My map updates are at 300 ms, none being missed, map draw time is less than 10 ms, mob animations, etc are progressing as normal, bot movement / feedback is flowing, it's just that the change from standing still to moving for the mob is delayed noticibly maybe once out every 5 mobs or so.

Perhaps there is something else I am missing in the control code, or maybe there is some relavant data in the last 4 bytes of the spawn update packet. Any idea what that is?

[Ratt]

If you aren't using the latest CVS SEQ, then the issues may or may not be relevant to what you have vs what is currently in use. They could be the same, but if we aren't testing on the same build, especially not even the same software platform, the testing would be like comparing apples to oranges, at least there's a good chance of this.

I will try to remember to look again at the mobs and look specifically for what you are saying, however I have not noticed this on my builds of the SEQ tree. Perhaps I'm subconciously ignoring it, though.

The "normal" client latency you are talking about is with Animation turned on in SEQ. This is a result of the movement prediction not being 100% in line with the SEQ prediction. That's to be expected, and I don't think it's worth any major effort to fix. If you turn off Animation, you will not have the "rubber band" effect, you'll get EXACTLY what the client is getting, but without movement prediction. So mobs will tend to jump around a bit more.

If you duplicated the exact method used for spawn movement prediction in EQ, SEQ would match movements.

I'd like to see you try with the latest Linux build of SEQ and see if you experience the same problems.

If so, give me the name of the zone and perhaps even the location / type / name of the mobs in question so I can as closely duplicate what you are seeing as to what I am seeing.

[Protector]

While the code and platforms may be different, the messages packets and meanings are the same. So I figured I would ask here...and I think I have it figured out.

It's the so called animation byte in the update structure. Someone in the SEQ code base sort of figured it out already, at least to make the connection that if this animation value is 0 (believed to be the stand still animation) then the deltas should be set to zero as well. However if it is indeed used for animation (didn't check but there may be values here for swimming, falling, crouching etc) then it is also used for speed.

What can happen, possibly because of simulated acceleration on the server side, or something else I have no clue of, is that the animation/speed can go from 0 to non-zero without the deltas changing at all. SEQ using just the deltas for movement animation and prediction sees the mob as stationary, while the EQ client starts it moving, using the walk animation at the speed setting and the current angle. The value for speed seems to be 1/2 the expected delta values, with normal mobs cruising at 0x05 or a speed of 10, aggroed mobs at a speed of 0x0D or a speed of 26 just faster than normal PC speed of 24, and sow capable non-agro mobs at 0x0B, or 22.

Ironically SEQ ends up having more accurate stop moving info then the client, since both the animation/speed and deltas are being checked for 0 velocity.

What I am going to do in my code is look for a animation/speed change from last update pass within values of 0-1F and if that occurs, override the deltas on that update, otherwise go with the deltas.

Note: if you are checking this out, make sure not to target the mob you are watching in EQ, otherwise the server will increase the update rate for that mob and you will not see any observable difference. I spent 20 minutes looking for it that way, failed to catch any, but saw several non-targeted mobs with latency :)