Death ghost bug

[kidpaddle94]

I think this bug has had quite a few different names over the years, but I'll call it the death ghost bug because the only video I could find featuring this bug referred to it as death ghost bug. Here's the video. Basically, when you die, sometimes your character will resurrect on (apparently) the client-side. Once you're in this state, you're not able to truly resurrect, leave game, and while you can walk around, you're usually limited to a certain distance (you'll start seeing black void if you go too far)

Now here's the actual topic: I'd like to know under which conditions does this bug occurs? Where should I look into to get rid of this issue?

Back when I would play on bnet, I remember some people thought it was caused by stats such as life after kill, life when struck or basically any kind of thing that would give life. The theory here, is that you were receiving life after the death sequence had executed, and the client thought you were alive because you still had life (something like that...)

So, if you know something about this bug, please share your information.

Thanks.

[Necrolis]

From the video (and the desc), I can tell you its a client side effect, wouldn't be surprised if its from receiving the death packet and various other life or movement related packets in the same frame. However, there is something more sinister that is could be: packet ordering. D2 use UDP for the game packets, UDP doesn't guarantee sequence preservation (because of the lack of ACK and some other things), what may have happened is the death packet preceded some other packets that got delayed due to spurious routing, those other packets put the client into the wrong state. This is easy to test if you have some network utilites that can mix up UDP datagrams locally (else you have to randomly reorder the packets on the client, till you hit a sequence that triggers this, but its also because the client is a little too quick to believe all its told; this is where a packet capture and replay tool comes in very hand, especially one built into D2 ).

[devurandom]

May or may not be on topic but..

I think limiting the client framerate too low, is asking for more packet related issues to crop up.
Client Framerate is going to effect packet latency, queuing delay, and may also play into desyncs issues.
On the other hand uncapped client framerates gives the infamous CPU loop bug.

EDIT:

Also I do have a couple questions on packets..

Is there a limit imposed on packet size, before a packet becomes fragmented ?
Does D2 use some type of packet validation routine.. limiting packet size before its sent,
that would need to be corrected in order to append a packet struct?

[Necrolis]

Also I do have a couple questions on packets..

Is there a limit imposed on packet size, before a packet becomes fragmented ?
Does D2 use some type of packet validation routines, that would need to be corrected before
appending a packet struct?

So there are two limits, most packets are limited to 254 bytes (plus the one byte id), technically though you can send packets of 511 bytes in size (from the server to a client, this is due to a clients packet being buffered up in pages of 511 bytes; I need to just double check its 511 and not 512 - sizeof(void*)).

When sending and receiving packets internally, there is only two sets of routines you need to worry about, these are the hardcoded packet size tables in D2Net (access via 4 ordinals, the are easy to find); after that you just need to hook the parsers (just look for the D2Net recvfrom ordinal).

Some advice: if you want to add new packets, sometimes its easier to expand an unused packet slot, and add a second byte id to it, then you can multiplex it with ease. If you are looking to do spanned packet however (like sending stash pages ) then you either need a sequencing id for the server, with the ability for the server to request a specific packet again, or you need to open a TCP connection for that. Technically game chat should run over TCP, though the game runs it via its UDP connection; having a TCP slot stops it congesting the game packets, and makes it reliable, also means you have a reliable channel for other things like savefile sending etc. Alternatively you can look at things like reliable UDP.

[devurandom]

I was able to track down the Packet Size table and fix my issue.


Thanks Again Necrolis!