CommandToClient() vs. %client.method()

#1 Have you seen if this works when connected to a dedicated server? Running in client/server combo mode lets you get away with some things you can't in a real server client setup.

#2 That's really what I'm trying to clear up. I know commandToClient's will work in a real server/client setup but at the moment I have no other machine to test out %client.method() calls. I just don't want to write code following an incorrect assumption.

#3 The first example will:

Work on a dedicated server.
Work on a loopback connection.

The second example will:

Not work on a dedicated server. (It will work for the client hosting the server, though)
Work on a loopback connection.

#4 %client.method() calls are not a substitute for commandToClient(). They aren't nearly the same animal.

#5 You can run a dedicated server and connect to it on the same machine to test things when you wonder if they will work properly.

#6 OK, so all in all, I should avoid %client.method() calls from any server-side code.

Paul, how would you do that? I can't run multiple instances of torque 'cause it tells me it's already running.

Edit: never mind figured it out; start it up with -dedicated & -mission then run the normal tge process.

#7 Well and remember, a client exists on the server too, so it's fine to use for things that should handled there. Just define those GameConnection methods in the server scripts (there are already several uses of this there). Really you only usually need client code for GUI/HUD data, controls, and other per client affairs.

#8 "...a client exists on the server too, so it's fine to use for things that should handled there."

Not sure what you mean by this. Are you talking about when the server is run dedicated?

So are GameConnection methods executed server or client side?

#9 There are three primary "modes" in which the client/server architecture runs in a networked game:

"single player", or co-located executable: one server, one client, in the same executable. Since both are sharing the total memory space, you can "get away with" a lot of poor programming practices (confusing server and client sides of the equation), such as accessing gui's from the server side of the executable.

"hosted multiplayer": this is made up of one co-located executable, plus one or more dedicated clients (no server side except what they are connected to via the network connection). This is a bit more controlled, but you can still make poor decisions on the co-located side, as mentioned above.

"dedicated server/dedicated client": this is where you literally build and execute your server with the dedicated option, and there are no client side aspects to the server at all (no gui's, no sound other than what is needed for execution such as trigger info, etc., and no animations, again except what is needed server side for proper execution). The dedicated clients are the reverse: guis, animation, sounds, input, etc., but no server side of the equation.

GameConnection methods in script are all going to be for server side use only. However, GameConnection (as well as NetConnection, and parent classes) in the c++ (executable) are shared by both, and may or may not act differently depending on what part you are in the client/server relationship.

#10 @ Juan - here's a thread i wrote about running a dedicated server and a client on the same machine.

#11 Stephen, if GameConnection methods are executed on the server, it seems that %client.doThis() would work from a dedicated server. What makes it different so that it wouldn't work (when the server is run dedicated)?

Orion, I just took a look at your thread and will definitely take your advice.

#12 When you do something like %client.doThis(), you are calling a function on the server to perform an action on the server.

The actual (person sitting at keyboard) player's executable doesn't do anything, unless part of that server action you called is to send a commandToClient (or other networked action) telling it to do something.

#13 Juan, calling %client.doThis() on the server assuming that you trying to run GameConnection::doThis(%this) function on the server.
Quck test: create some functions:
1. server-side: ~/server/scripts/game.cs:

function GameConnection::doThis(%this)
{
   echo("S> GameConnection::doThis("@%this@") called.");
}

2. client-side:

function clientCmdDoThis()
{
   echo("C> ClientCmdDoThis()");
}

run the game and ON SERVER perform the following:
// testing server-side function call
%client.doThis();
// testing client-side function call
commandToClient(%client,'doThis');
and you will see the difference.
This is a right way of making client/server function calling routine.
In case you need a to call a function from client on server do the reverse:
on client commandToServer('doThis');
on server you create function serverCmdDoThis(%client).

@Stephen: I remember I've seen a link by you (or other GG employee) to the separate page where was description of how the network works in TGE (1.3).. If was HTML page on separate web-site if i'm not mistaken. Can you share the link again? I'm thinking of updating it and creating a TDN article of how to make proper client/server messaging.
Thanks.

#14 So whenever inside a GameConnection method, there's no reason to do commandToServer because I have access to all global variables & functions defined on-server? I can just directly call functionOnTheServer() and there should be no problems?

ClientGroup - is this only accessible from the server? For example, if a player is trying to search for players around him, he would have to do a commandToServer to get the players around him? What information does a client know about himself and the environment around him?

Are commandToServer/commandToClient calls blocking or nonblocking? After executing a commandToServer, is the client sure that whatever the server was supposed to do happened before the client hits its next statement?

#15 @bank: A non-formatted form of that writeup (it's very ugly at the moment, waiting for the final version of Elixer to be configured) exists on TDN...I think a search for ConnectionSequence on TDN might find it.

@Juan--as long as you've clarified through either placement of the script file (in the /server directory), or careful execution tracking (benchtesting study), or available isServerObject()/isClientObject() calls in c++ that you are on the server, your first paragraph is correct.

Your section paragraph is correct as well. In general, a client is only aware of a limited subset of the server's authoritative set of objects based on scoping rules, and possible net lag (new object comes into scope, the client may take a few hundred to a few thousand milliseconds to receive the initial update). Clients should always be requesting additional information from the server if truly necessary, and still assume that they won't be guaranteed to get it.

Both calls are asynchronous, in that you fire off the function, and once the function execution stack is complete, the appropriate client or server moves on. Of course, during the execution stack itself, they are blocking (if you put an infinite look within a commandToServer/commandToClient, it will lock up that particular executable).

A good example of the asynchronous nature of the underlying concept of CommandToServer/CommandToClient--the NetEvent and derived classes--can be researched by looking at how the loadMission.cs in the /common directory works. It basically communicates state changes between the server and the client to successfully load a new mission and get them both in synch for getting the character into the game.