Re: [Opentnl-general] Persistant ghosts and bullets
Brought to you by:
mark_frohnmayer,
s_alanet
From: Benjamin D. <be...@fi...> - 2004-05-10 21:32:58
|
Hi again, > There is currently no way to tell the GhostConnection that an object is > out of scope but should not be deleted. If you have a lot of static > instance data that is sent with the creation of the ghosts, it might > make sense to send that data over as events, and then just use a token > value as a lookup for that data. On the whole, however, it's really not > that much overhead to create a new ghost as opposed to updating an > existing one. The ghosting system uses log2(total netobject classes) > bits to send a class id, so even if you have 64 different NetObject > classes you'll only be spending 6 extra bits to create the new object. Good to hear that. My plan was to use initial events or something similar to create all (non-TNL) "player objects" when a client connects. The TNL NetObjects would then also contain the player ID (which only changes on ghost creation), allowing the first packUpdate call to hook the NetObject into the correct player object. Actually, it'll be fun to try out safe pointers for this, I haven't seen this idea before, but it sounds terrific. > GhostAlways objects are objects that are always in scope. They are sent > to each client before any other objects are ghosted. So this is an alternative to NetObject::mNetFlags.set(ScopeAlways | Ghostable); or is there still a difference? If so, I assume that while GhostAlways objects are always sent first, this is not the case for ScopeAlways objects? And can I add GhostAlways objects later on? > I would still use the NetObject framework for projectiles - the overhead > of creation is very low and you have the added benefit that projectiles > can be prioritized along with all the other NetObjects that are > currently in scope. Thanks, this does make sense. In fact, projectiles probably stand to benefit more from ghosting than the objects I mentioned above, since they are more or less anonymous, so tracking them around scoping loss is unnecessary. Bye, Benjamin |