Re: [Opentnl-general] Server vs Client objects
Brought to you by:
mark_frohnmayer,
s_alanet
From: Mark F. <ma...@ga...> - 2005-05-24 14:49:16
|
boB Gage wrote: > Mark, > > You said having a common Player & descending PlayerServer and > PlayerClient is not recommended... does that imply that having two > classes named Player but implemented differently is the preferred > method? Also, in the PlayerClient/PlayerServer method, you mention > the alphabetical sorting, does that mean if there's a PlayerDeath > object, for example, that it would cause problems because it would > land between PlayerClient & PlayerServer when sorted? Yes, this is the problem with that approach. Which is why having 2 Player classes (one on the client, one on the server) is the preferred way to do it. > > But I'm not sure I understand how to handle the situation when one of > these threads needs to reposition an object, or record damage, or just > about anything else that requires mucking around with the object's > data... I can mutex every object to allow only one of the server > threads access at a time. But, what's to stop OpenTNL from changing > things that I'm also changing ( like clearing dirty bits because it > just sent an update ). > > Wait.....an epiphany! Since OpenTNL is not multi-threaded it will > only update net object classes during, what, the interface->tick() > call? I can mutex around that call to ensure I'm not mucking with > data at the same time as OpenTNL . Will that do the trick?? :-) This will work, but you may end up blocking for a long time waiting for the network interface to process all the incoming packets, etc. A more optimal solution would involve message passing from the background (non-network) threads that update the state on the object in predictable ways. You could use the TNL ThreadQueue class to pass messages back to objects on the main thread. Another solution would involve using a zone type system where zone processes ghost objects to the main process, and the main process ghosts all objects to players, as well as border objects between zones. |