Game Development Community

Ghosting and GameConnection

by Joshua Jewell · in Torque Game Engine · 03/21/2006 (5:10 pm) · 7 replies

I have a few, hopefully simple questions I was wondering could be answered about ghosting and the GameConnection object.

1. Does a GameConnection Object exist as a ghost on every client during its lifetime?

2. Is a GameConnection Object Ghosted on all other clients when it is first created?

3. If a client enters a server do they obtain a Ghost copy of all of the GameConnection Object that exist in the server?

What I am trying to do is use commandToClient to relay an id for a GameConnection Object to a client so that it can be used with its ghosted copy. However right now I am not quite sure how to go about finding out the id it was ghosted to so hopefully these questions will point me in the correct direction. Thanks for all of your time in advance.

#1
03/21/2006 (5:39 pm)
I don't know definitively,
but these all seem like the same question to me,
and i'll bet the answer is no.

why do you want Client A to have a ghost of Client B's GameConnection ?

what *will* be ghosted to every client is every player in scope for the given client.
#2
03/21/2006 (7:26 pm)
Torque does not distinguish between client and server in script. This is mentioned in TDN.

The engine itself however maintain a separate list of server and client objects.
In another words, the ID for the object on the client is different from the one stored on the server.

Like what Orion said, the ghosted objects are within the client's scope so if they can't view an object based on the server's scoping rules, then the object is never transmitted.

But this is only true in most common FPS games.
Other gamestyles like RTS may have a different scoping rules.
Unless you modify the the code to deal with these I don't see how you can precisely relay the ghost id.

RTS pack should contain a different scoping rules. You can check that out.

Otherwise, he can make an attempt to manage the communcations between client and server that involve Object/GhostID's

NetConnection::resolveGhost
NetConnection::resolveObjectFromGhostIndex

I'm not sure if this would work but you might to able to pull it off if you try to "force" it :)
#3
03/21/2006 (7:28 pm)
@Joshua:

Only Netobjects and objects dervied from are ghosted. So there's no such thing as a GameConnection object being ghosted AFAIK.

Check out this quick seach on TDN for ghosting.

Since I'm not perfectly clear on what you're trying to accomplish, it's probably the most benefical to check out this article discussing ghosting more in depth.

Although I may not have helped your problem as directly as you would have probably liked - this should give you a better idea as to what is going on. It'll probably give you some insight and better understanding of what your problem is.

Of course if you have any more questions, post them here.

- Eric
#4
03/21/2006 (8:24 pm)
Since ShapeBase Objects are Ghosted and they contain the method getControllingClient I assumed that perhaps GameConnections were also ghosted. I know that I can call getControllingClient on my ShapeBaseObject and get my GameConnection object ID so your own GameConnection is ghosted. The reason I want to do this is so that I can display only certain Player Objects, ones that are in your squad, without the overhead of having to update the information each time a client dies and spawns another Player. Nothing is set in stone, but I figured if I could store an array of GameConnections then it would be efficient and straightforward. If someone could tell me for sure if GameConnections of other clients are ghosted or not I would appreciate it. I want to thank everyone for their comments so far.
#5
03/22/2006 (12:51 pm)
I would think that when you call getControllingClient, you're doing it from your server end.

That is to say, when you call getControllingClient on your ShapeBase object you're calling it on the server copy of the object (not the ghosted copy on the client). If there's a client controlling the ShapeBase object (this goes for any Control Object such as a player, vehical, camera), it'll return the ID of the client controlling it.

I believe that the list of clients connected to server are stored in ClientGroup.

To access the list of clients you need to iterate through the list. An example of this is in the Lightning class where the method ::warningFlashes() creates and posts a Lightining strike event on each client.

In the method is the following code
SimGroup* pClientGroup = Sim::getClientGroup();
   for (SimGroup::iterator itr = pClientGroup->begin(); itr != pClientGroup->end(); itr++) {
      NetConnection* nc = static_cast<NetConnection*>(*itr);
      if (nc != NULL)
      {
         LightningStrikeEvent* pEvent = new LightningStrikeEvent;
         pEvent->mLightning = this;

         nc->postNetEvent(pEvent);
      }
   }

You can also access the client group from script, and iterate through the list as well.
%count = ClientGroup.getCount():
for(%i = 0; %i < %count; %i++)
{
   %client = ClientGroup.getObject(%i);
   //Do your thing here with the client object ID
}


I'm certainly not the expert on this, and what I've explained is what I understand of the engine AFAIK. So I would encourage you to verify everything for yourself by setting a breakpoint in getControllingClient(), and checking if the isServerObject() method ever evaluates to false. If it doesn't, you're always calling it on the server side and you can pretty much be assured that the client connection objects are never ghosted (why would they be?).

Hope that helps,

- Eric
#6
03/22/2006 (4:48 pm)
"I would think that when you call getControllingClient, you're doing it from your server end."

No I was calling getControllingClient in a GUI element, so it was strictly client side, however I have solved my problem another way since I was not sure if I could get a definite answer without way more work then it was worth. Thank you everybody for your comments.
#7
03/22/2006 (5:05 pm)
Although I'm glad you've found an answer I remain a little skeptical about the solution because of this. And a little more specifically about the problem of running your server and client both on the same executable as someone mentioned earlier. Which you may or may not be currently aware of.

If you were, all the more power to you.

- Eric