LocalClientConnection? ServerConnection?
by William Ball · in Torque Game Engine · 06/23/2006 (10:05 am) · 8 replies
What do these torquescript objects represent, exactly:
LocalClientConnection
ServerConnection
I know the LocalClientConnection exposes an instance of a GameConnection object for a client running on the same machine as the host server. So, should I not use it for client-side code? How would a client, for example, request that the camera be moved to "0 0 10 1 0 0 0" (arbitrarily chosen) without calling LocalClientConnection.setTransform (which seems like a violation of the client-server contract).
I thought the ServerConnection was intended for clients get get access to those methods, but it appears to represents a different GameConnection object. So what is it?
LocalClientConnection
ServerConnection
I know the LocalClientConnection exposes an instance of a GameConnection object for a client running on the same machine as the host server. So, should I not use it for client-side code? How would a client, for example, request that the camera be moved to "0 0 10 1 0 0 0" (arbitrarily chosen) without calling LocalClientConnection.setTransform (which seems like a violation of the client-server contract).
I thought the ServerConnection was intended for clients get get access to those methods, but it appears to represents a different GameConnection object. So what is it?
About the author
#2
06/23/2006 (10:15 am)
Errr, LocalClientConnection.[some camera].setTransform(), rather.
#3
If you want the client to do something game-related, you'd have to do a commandToServer(), which executes on the server. Through ghosting, all relevant events are sent to the client to reflect what the server has done.
If you want the client to do something gui related, you don't need the server connection. If you wanted to do something gui-related but depends on actual client/player info, you would have to do a commandToServer(), where the server knows what info is needed, and then call a commandToClient() with the information needed to correctly set the GUI-related components.
In your example, you'd do something like this:
To illustrate the example in my third paragraph, you'd do something like this:
I think client vs. server causes a lot of confusion with beginners (myself included).
But as far as LocalClientConnection & ServerConnection, I understand it like this:
LocalClientConnection you can use if the client == the server which allows you to disregard commandToServer() calls if you want to do something to the %client object.
If you had a function declared as: function GameConnection::doThis(%this) { echo "doing it"; }
from the client OR server, you could do
for it to work. If all you're developing is Single Player, I guess it's fine, but if you're doing multiplayer, it won't work and you shouldn't use LocalClientConnection.
ServerConnection is the connection made when you connect to a server. It only knows about GameConnection:: methods (and objects) defined on the client-side. The only use I've seen for it is ServerConnection.setFirstPerson(true or false); If you have all of your GameConnection:: methods defined in server/scripts/game.cs, and on the client, you try to do ServerConnection.oneOfThoseMethods(), it won't work 'cause they were declared on the server.
There's 4 components:
Server-side context (stuff executed on server)
- Server-side GameConnection declarations (methods defined in server scripts)
Client-side context (stuff executed on client)
- Client-side GameConnection declarations (methods defined in client scripts)
LocalClientConnection is all those 4 components in 1.
ServerConnection would only be the last two components (meaning you're ignorant about stuff executed on server, which makes a multiplayer game possible). So to achieve all four components, you need the commandToServer/commandToClient interoperability.
So in conclusion, don't use them for real game play. This is the way I understand it and have only recently started truly understanding the procedure, so if I'm wrong, someone correct me.
06/24/2006 (6:39 pm)
To me, it seems people don't use LocalClientConnection or ServerConnection.If you want the client to do something game-related, you'd have to do a commandToServer(), which executes on the server. Through ghosting, all relevant events are sent to the client to reflect what the server has done.
If you want the client to do something gui related, you don't need the server connection. If you wanted to do something gui-related but depends on actual client/player info, you would have to do a commandToServer(), where the server knows what info is needed, and then call a commandToClient() with the information needed to correctly set the GUI-related components.
In your example, you'd do something like this:
//----in a client side script
commandToServer('SetCameraTransform',"0 0 10 1 0 0 0");
//----in a server-side script
function serverCmdSetCameraTransform(%client, %newTransform) {
if (isObject(%client.camera))
%client.camera.setTransform(%newTransform);
}To illustrate the example in my third paragraph, you'd do something like this:
//----in a client side script
commandToServer('UpdateClientScoreDisplay');
//----in a server-side script
function serverCmdUpdateClientScoreDisplay(%client) {
//let's say score is stored as a field named 'score' on the %client object
commandToClient(%client, 'SetScoreDisplay', "Score: " @ %client.score);
}
//---in a client-side script
function clientCmdSetScoreDisplay(%scoreText) {
//let's say there's a GuiTextCtrl named GUIScoreLabel in the client/ui/playgui.gui file
GUIScoreLabel.setText(%scoreText);
} I think client vs. server causes a lot of confusion with beginners (myself included).
But as far as LocalClientConnection & ServerConnection, I understand it like this:
LocalClientConnection you can use if the client == the server which allows you to disregard commandToServer() calls if you want to do something to the %client object.
If you had a function declared as: function GameConnection::doThis(%this) { echo "doing it"; }
from the client OR server, you could do
LocalClientConnection.doThis()and it would work. However, if client != server, you would have to do
//(from the client)
commandToServer('CallDoThis');
//(on the server)
function serverCmdCallDoThis(%client) {
%client.doThis();
}for it to work. If all you're developing is Single Player, I guess it's fine, but if you're doing multiplayer, it won't work and you shouldn't use LocalClientConnection.
ServerConnection is the connection made when you connect to a server. It only knows about GameConnection:: methods (and objects) defined on the client-side. The only use I've seen for it is ServerConnection.setFirstPerson(true or false); If you have all of your GameConnection:: methods defined in server/scripts/game.cs, and on the client, you try to do ServerConnection.oneOfThoseMethods(), it won't work 'cause they were declared on the server.
There's 4 components:
Server-side context (stuff executed on server)
- Server-side GameConnection declarations (methods defined in server scripts)
Client-side context (stuff executed on client)
- Client-side GameConnection declarations (methods defined in client scripts)
LocalClientConnection is all those 4 components in 1.
ServerConnection would only be the last two components (meaning you're ignorant about stuff executed on server, which makes a multiplayer game possible). So to achieve all four components, you need the commandToServer/commandToClient interoperability.
So in conclusion, don't use them for real game play. This is the way I understand it and have only recently started truly understanding the procedure, so if I'm wrong, someone correct me.
#4
Jaun points out one of the primary ways in which the client and server communicate, and the Move system is the other. It's a very highly optimized system and not modified much, but you can (after careful study of what it is and how it works) utilize it to broadcast movement/input information to the server.
And just for study/research purposes, commandToServer and commandToClient are script implementations/wrappers for the NetEvent base class functionality, specifically Guaranteed Ordered messages.
06/24/2006 (7:35 pm)
In general as Juan discusses, they are not the primary means to accomplish functionality. They are exposed as named global variables for a very few reasons, and should be used only in those very specific scenarios.Jaun points out one of the primary ways in which the client and server communicate, and the Move system is the other. It's a very highly optimized system and not modified much, but you can (after careful study of what it is and how it works) utilize it to broadcast movement/input information to the server.
And just for study/research purposes, commandToServer and commandToClient are script implementations/wrappers for the NetEvent base class functionality, specifically Guaranteed Ordered messages.
#5
Obviously if you don't implement your game code on the principle of least trust and assuming that the client will do the worst possible thing, you open the door for bad stuff to happen. :)
06/24/2006 (11:24 pm)
BTW - in general if you call "server stuff" (like settransform) from the client side, the effect is either non-existent or transitory (as new updates come down the wire from the server). It's occasionally possible to foul things up for a single client by doing this (esp. if you run across a poorly designed object) but it never effects the server's simulation or the simulations of anyone else.Obviously if you don't implement your game code on the principle of least trust and assuming that the client will do the worst possible thing, you open the door for bad stuff to happen. :)
#6
06/25/2006 (3:15 am)
I remember doing something like this (but inside the engine where I had put some function calls after an isClientObject() statement). The result was that my object would begin moving, but a split second later, it suddenly reverted to its previous position. It was like the client wanted to "go outside" but the server said "no, get back in the house". Sorry for the horrible analogy.
#7
I recall that setBlackOut/setWhiteOut needed the GameConnection handle but other than that I haven't really had to use it.
06/25/2006 (3:24 am)
Lol that's an excellent analogy, actually.I recall that setBlackOut/setWhiteOut needed the GameConnection handle but other than that I haven't really had to use it.
#8
06/26/2006 (7:34 am)
Quote:Search is your friend... www.garagegames.com/mg/forums/result.thread.php?qt=45142
What do these torquescript objects represent, exactly:
LocalClientConnection
ServerConnection
Torque Owner William Ball