cWindow and cWindowOwner
#1
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 Smile
Reply
Thanks given by:
#2
(02-16-2012, 11:48 PM)xoft Wrote: 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.

(02-16-2012, 11:48 PM)xoft Wrote: I'd say this is a good candidate for a rewrite, or at least for a very good documentation Smile
Perhaps, I don't really understand it much myself, other than that it works XD
Reply
Thanks given by:
#3
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.
Reply
Thanks given by:
#4
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
Reply
Thanks given by:
#5
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).
Reply
Thanks given by:
#6
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)
Reply
Thanks given by:
#7
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.
Reply
Thanks given by:
#8
It doesn't matter anyway, since it only becomes multiple threads when there are 64+ players on
Reply
Thanks given by:




Users browsing this thread: 4 Guest(s)