Game Development Community

Server id or client id?

by gamer · in Torque Game Engine · 10/11/2006 (4:10 pm) · 10 replies

When I am in game and press F11, there are ids showing on the objects.
1. Are these client object id or server object id? I am guessing they are server side ids?
2. I am also guessing that ServerConnection.getControlObject() returns the client copy of the player? or am I wrong?
3.if I am right in 2, how to I obtain the id to the server copy of the player? because it seems that some methods (or all?) of player works only if I invoke them on the server copy of the player. an example of such method is setVelocity.
4. so if I want to set the velocity of a player dynamically in game, I am guess the right way is to send a command to server from the client, and then in the server callback invoke setVelocity on the server copy of the player?

thanks

#1
10/11/2006 (4:23 pm)
1. If you are running a listen server, then they are server ID's.

2. Right.

3. LocalClientConnection.getControlObject () will get you the server ID of your control object if you are using a listen server. If not, then you could grab client ID, and walk trough the server's ghost index and find the correct server ID. Like getGhostID() does.

4. Not very optimal, but that will work - yes.
#2
10/11/2006 (4:29 pm)
Stefan,
thanks.
4. what is the optimal path then?
#3
10/11/2006 (4:33 pm)
1. Server ID

2. That's the connection object on the client side right? Then probably, yes.

3. commandToServer will try to call a function on the server from the client, and will send up the ID of that client. So to do what you want, have a
function serverCmdsetMyVelocity(%client, %params){
 %client.player.setVelocity(%params);
}
In your server scripts.

And then in a client script you would call
commandToServer('setMyVelocity', %params);

However keep in mind this is not how the normal player movement is handled. This means the action will only happen after it has been sent to the server, and the server sends the action back to the client. The player movement actually applies your movement (only for the player you are controlling) on the client before the server gets any move data. The server then will only correct the client if what it's done disagrees with the server.

4. Essentially yes, but I would limit such things to only sending non-explicit commands such as "moveLeft" "moveRight" etc., or otherwise validate the data the client is sending is within the range of the parameters you want to allow. The example I showed you would let the client set _any_ velocity they want, which is probably not something you want to allow. Also if you are doing very time sensitive player input, you may want to consider implementing it in source, so you can allow client prediction. I'm fairly sure you can't get that from script.
#4
10/11/2006 (4:35 pm)
You could get it from script but it's a PITA your better off with source.
#5
10/11/2006 (4:40 pm)
Thanks Paul,
4. I am in a game where I need to control the velocity of a bunch of AI players constantly based on a player's input, for example, a player shoots at them, then will move faster,etc. what would be the best implementation path for this? can this be done in script only?
#6
10/11/2006 (6:24 pm)
4. In the example you just provided, I'd guess the hardest thing to figure out will be how to determine whether the player is shooting 'at' the AI players. Is there some sort of 'targeting' system (like with guided missiles) where there's no question what the player's target is? Or will they all run anytime the player shoots at anything? In the AI Guard resource (or in the one I modified...not sure now), the bots change their actions based on whether they get *hit* by the player, using the appropriate callbacks in script but if you don't hit them, they don't know you are firing at them.

Once you have that figured out, you can do it all on the server using a basic state engine in each AI player. This method works just as well with multiplayer servers, too. It would work fine in script.
#7
10/11/2006 (7:14 pm)
Bryan, yes my ai guys will only react if they are hit, which can be easily implemented by the existing onDamage callback functions in script. thanks!


a related question:
when user press forward button now, the client sends a command to server (with a single parameter that tells it to go forward), -> then the server process it, update its player's states and send command back to client -> client update its player states. the client continuously sends this command to server as long as the user is pressing down the forward button.

is this how it works in the engine?
#8
10/12/2006 (1:44 am)
No, it is not.

When you press forward, there is no command being sent because that is terribly inefficent for important updates like moves. When you press forward, there is a move added to the next moveManager update (which has a high priority) which is then sent to the server. The server processes the move, and does what it should.
#9
10/12/2006 (2:12 am)
"When you press forward, there is no command being sent because that is terribly inefficent for important updates like moves. When you press forward, there is a move added to the next moveManager update (which has a high priority) which is then sent to the server. The server processes the move, and does what it should."

how is the moveManager update more efficient than sending the command? doesn't that still require data traveling from moveManager to the server and back before the player can update his states? or does the client process the move rightaway without waiting for server's response?
thanks
#10
10/12/2006 (11:29 am)
Yes, the client processes the move right away, and then only gets corrected by the server if the server tells it otherwise.