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