Great stuff, always wondered about this one. Thanks for taking the time.
Remember Privilege bragging about his source code, from a quick glance it seems that's all what it was: a brag.
No clean code practices, giant Holograph-esque style message handling (atleast it's not a switch, so some...
I remember debugging that issue in my uberEmu fork (the one with Wichard) too, the way I think I solved it was not sending a room status update to the user when it was interacting with rollers, instead having the slide object bundle include the user.
Ah, oops. Read over the "before it's written and flushed" part. That's a weird issue. Is DotNetty deciding to flush the buffer without an explicit call? The only workaround for that, probably, is to only write fully complete packets to the DotNetty buffer.
Append the packets to a ConcurrentQueue<T> (y)
.. or BlockingCollection<T>, might be more efficient.
AFAICT both are FIFO, so no client-side race conditions due to unordered outgoing packets.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.