cWindow and cWindowOwner

[xoft]

I'm not yet sure how the cWindow class works. And how does cWindowOwner fit in?
From what I've seen, cWindowOwner has descendants although they don't really use much of it - there's no virtual members, so there's not much to override.

Also, does the current windowing work multi-player? (both players open the same entity's window, one player puts something in it, does the other player see it?)

I'd say this is a good candidate for a rewrite, or at least for a very good documentation

[FakeTruth]

I'm not yet sure how the cWindow class works. And how does cWindowOwner fit in?
From what I've seen, cWindowOwner has descendants although they don't really use much of it - there's no virtual members, so there's not much to override.

Also, does the current windowing work multi-player? (both players open the same entity's window, one player puts something in it, does the other player see it?)

The whole idea of the cWindowOwner class is that it opens a single window for multiple players. a cChestEntity is a cWindowOwner, because it owns a window.

I'd say this is a good candidate for a rewrite, or at least for a very good documentation

Perhaps, I don't really understand it much myself, other than that it works XD

[xoft]

I'm pretty sure, from the code, that it cannot work correctly. If two players open the same chest, each grabs a (different) item, the chest has only one cWindow instance and only one m_DraggingItem, which means one of the grabbed items will be lost.
Also, multithreading is not accounted for in these classes.

[FakeTruth]

IMO packets should be handled in a single thread instead of multiple threads, so there's no need for making it multithread safe.

You might be right about the dragging item, I only checked if it replicated the items to other clients, I didn't check whether multiple people can drag multiple items around. I'd say try it first

[xoft]

Packets used to be handled in the tick-thread only, so then it didn't matter.
Now packets are handled in the cSocketThreads and therefore *can* call these functions simultaneously from multiple threads (if there are >= 64 players on the server).

[FakeTruth]

There's not much benefit in handling packets in separate threads though. Because so many critical sections are being locked it results in multiple threads running just as fast as a single thread.

There's probably some benefit because not all packets require critical sections to be locked, but all substantial packets do (block/entity interactions)

[xoft]

Packets are handled in the thread that receives them over network and decodes them. Having a thread specifically for handling packet would require handing them over to that thread, meaning even more critical sections etc.

[FakeTruth]

It doesn't matter anyway, since it only becomes multiple threads when there are 64+ players on