opentnl-general

[Opentnl-general] Persistant ghosts and bullets

[Benjamin D. <be...@fi...>]

Hello list,

I'm currently trying to find my way around OpenTNL. It seems perfect for 
my game project, but I've basically got two questions:

1) If I understand correctly, gosts are created "on demand" on the 
clients. If an object falls out of scope, however, it is possible that 
the client-side version is deleted, right? In my game, however, each 
client basically knows of all the ghostable objects anyway, so deleting 
and reallocating seems kind of like a waste. Is there a way to avoid 
this, and just tell a ghost "you've fallen out of scope (at this
timestamp), so forget about getting updates for now"?.

Incidently, what's with the "GhostAlways" methods? They're not really 
documented.

2) There will be bullets / shots from one player to another, which are 
created at one point in the world, travel in real time, and then are 
destroyed. The server takes care of these, and informs the clients about 
creation and destruction. Since the state of each shot (time created, 
direction and speed of travel) don't change, I assume a NetObject / 
ghost is overkill. My idea wold be to implement these in a NetEvent, as 
a list of current create/destroy sub-events, and send them 
GuaranteedOnly. I may have to add my own scoping, but that's not so 
important now.

My question is: how are other people handling such "linear unchanging 
objects"? Is the use of ghosts fast/convenient enough that I should 
consider them? Or is there another, even better way?

Thanks for everyone's input!

   Benjamin

Re: [Opentnl-general] Persistant ghosts and bullets

[Mark F. <ma...@ga...>]

Benjamin Deutsch wrote:

> 1) If I understand correctly, gosts are created "on demand" on the 
> clients. If an object falls out of scope, however, it is possible that 
> the client-side version is deleted, right? In my game, however, each 
> client basically knows of all the ghostable objects anyway, so 
> deleting and reallocating seems kind of like a waste. Is there a way 
> to avoid this, and just tell a ghost "you've fallen out of scope (at this
> timestamp), so forget about getting updates for now"?.

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.

>
> Incidently, what's with the "GhostAlways" methods? They're not really 
> documented.

GhostAlways objects are objects that are always in scope.  They are sent 
to each client before any other objects are ghosted.  Zap uses ghost 
always objects for the current game type as well as the barriers 
surrounding the level.

> 2) There will be bullets / shots from one player to another, which are 
> created at one point in the world, travel in real time, and then are 
> destroyed. The server takes care of these, and informs the clients 
> about creation and destruction. Since the state of each shot (time 
> created, direction and speed of travel) don't change, I assume a 
> NetObject / ghost is overkill. My idea wold be to implement these in a 
> NetEvent, as a list of current create/destroy sub-events, and send 
> them GuaranteedOnly. I may have to add my own scoping, but that's not 
> so important now.

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.

> My question is: how are other people handling such "linear unchanging 
> objects"? Is the use of ghosts fast/convenient enough that I should 
> consider them? Or is there another, even better way?

See Zap's projectile.cpp/.h as an example of this.

Re: [Opentnl-general] Persistant ghosts and bullets

[Benjamin D. <be...@fi...>]

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

Re: [Opentnl-general] Persistant ghosts and bullets

[Mark F. <ma...@ga...>]

Benjamin Deutsch wrote:

> 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? 

Well, GhostAlways is supposed to be the same as ScopeAlways, but the 
code is a little broken at the moment.  I think I'm going to make 
mNetFlags private, and make access to those fields through accessor 
functions -

setGhostable(bool ghostable);
setScopeAlways(bool scopeAlways);

to limit confusion.

- Mark