How is the player created after connection to a hosted game ?

#1 Short version:

You are correct, that script is only ever called on the server. Once the server object is created, it is marked as the control object for that client, which means that the ghosting system will network the object to the client, causing the client to create a copy of the object.

Long version:

When a client connects to a server, it goes through hundreds of calls that negotiate the connection, finally winding up in the server side script GameConnection::onClientEnterGame().

This in turn sets up all the things required for the client to "play", including creating the control object, setting scope for that object, and doing an initial scope query so that the ghosting system will then send down all the information the client needs to replicate the server side simulation.

In general, this is always how things should be done--the client never creates "in game" objects on it's own, but instead is told when, and how to create them based on networking. The only real exceptions to this rule are client side only objects, such as GUI's, and some replicated objects.

There are many threads in the forums discussing various ways for letting players pick different shapes/players/characters before they enter the game, and you should search for "player selection" as a starting point.

In general however, all they do is have some way of telling createPlayer() which datablock to use, and the ghosting system takes care of the rest.

#2 Stephen

Thanks for the explanations.

I have found this tutorial : www.jamestadeo.com/Games-by-James-Tadeo/torque/Torque-Tutorials/Torque-Player-Se...

But I have a concerned : this tutorial is based on the call of 2 functions by the engine:
function GameConnection::onConnect( %client, %name, %jtPlayerBody )
function GameConnection::createPlayer(%this, %spawnPoint)

But these functions are called only when the game is hosted.
When I use the menu "join server" , these 2 functions are never called. I guess that these 2 functions are called automatically by the torque engine.

I have put traces into these 2 functions : I can garantee that these 2 functions are not called.

I wonder what happens ?

#3 The console for the server :

*** Phase 3: Mission Lighting

Successfully loaded mission lighting file: 'starter.fps/data/missions/stronghold_60644527.ml'

Mission lighting done

Mapping string: MissionStartPhase3Ack to index: 2

GameConnection::createPlayer %this=1490 spawnPoint=209.506 98.2568 228.396 0 0 -1 0.143171

Mapping string: MissionStart to index: 11

Mapping string: SyncClock to index: 12

Could not locate texture: starter.fps/data/shapes/player/crossbow

Could not locate texture: starter.fps/data/shapes/player/clip

*** Initial Control Object

Could not locate texture: starter.fps/data/shapes/player/crossbow

Could not locate texture: starter.fps/data/shapes/player/clip

Mapping string: Kork to index: 13

Received info request from a master server [IP:69.64.50.217:28002].

Got Connect challenge Request from IP:192.168.1.12:32867

Got Connect Request

Connect request from: IP:192.168.1.12:32867

GameConnection::onConnect client=1729 name=

CADD: 1729 IP:192.168.1.12:32867

*** Sending mission load to client: starter.fps/data/missions/stronghold.mis

Mapping string: %1 joined the game. to index: 14

#4 The console for the client after join server :

*** Phase 3: Mission Lighting

Successfully loaded mission lighting file: 'starter.fps/data/missions/stronghold_60644527.ml'

Mission lighting done

Mapping string: MissionStart to index: 12

Mapping string: SyncClock to index: 13

Could not locate texture: starter.fps/data/shapes/player/crossbow

Could not locate texture: starter.fps/data/shapes/player/clip

Could not locate texture: starter.fps/data/shapes/player/crossbow

Could not locate texture: starter.fps/data/shapes/player/clip

Could not locate texture: starter.fps/data/shapes/player/crossbow

Could not locate texture: starter.fps/data/shapes/player/clip

Mapping string: Kork to index: 14

*** Initial Control Object
Issuing Disconnect packet.

Exporting server prefs...

Exporting client prefs

Exporting client config

Exporting server prefs

Exporting client prefs

Exporting server prefs

#5 From what I understand TGE is client/server in both single and multiplayer modes. The gui is a mechanism that allows you to send data to the game.

#6 @Phillipe:

You aren't tracing the network information that flows back and forth between the client and the server, which is why this seems confusing. Following the tutorial carefully, here is the flow of information across both the client and the server during the entire process (once the resource is installed):

Client
--player goes to joinServer gui
--player selects which character to use
--player selects and joins a server
--client sends this information across the network to the server

Server
--GameConnection::onRequest is called due to the network traffic from the client
----since the network information from the client includes which selection the player made, we can decide which of our player datablocks to use, and we set it as a persistent field within the current client's GameConnection object
--server waits for the rest of the connection to be established, and finally calls GameConnection::onClientEnterGame()
----since in the step above we've already set our chosen player body on the GameConnection object, we can access it on the server with (according to the tutorial) %this.jtPlayerBody -- it contains the name of the datablock to use
----call %this.spawnPlayer with the data provided
------the player object is created on the server
----set the new server side player object to be the control object for this client

Now that we've set things up server side, the networking system takes over. Next network tick, and update will be packed up, and since we've set our new player object to be the control object for this client, it will deliver an initial update for the new player.

Client
--receive a network packet from Server
----packet contains information on an object we don't know about (yet), the player object, so create it on the client and update it in the future.

Again, hidden deep in the network code, this automatically creates a client side player object for us. We never do anything on the client side (other than use stock networking) to actually manually create a player object--it happens automatically!

PS: James, that is probably one of the best tutorials/explanations of how to accomplish this type of functionality, thanks a ton for working so hard on it! Is there any chance you'd be willing to put it on TDN? :)

#7 ...yeah, what he said.

re:"PS: James, that is probably one of the best tutorials/explanations of how to accomplish this type of functionality, thanks a ton for working so hard on it! Is there any chance you'd be willing to put it on TDN? :)"

Whoa, why sure :) I have a few files I am adding to the download so peeps don't have to type out the player.cs file datablocks.

#8 Question regarding this: Suppose I store unique statistics for each player, and use a username/login to "select" what player data to use. Could I (theoretically) store each player's statistics in a unique datablock (thus having hundreds of files), and load the appropriate datablock using the module system? Then unload it when the player drops, to avoid accumulating them all in memory.

An alternative would be to create a ton of dynamic properties, and load them from some more traditional storage (such as a database) -- how much would I really save by using "unique" datablocks? I'm assuming the datablocks are sent on start-up, and dynamic properties are also sent on start-up, as well as when they change, so in this case, maybe there aren't any savings?

(There's also the question of how to reflect changes in this data, but one thing at a time :-)

#9 @JW:

In my personal (and professional) opinion, datablocks are not the way to go on this. Datablocks have one root purpose: networking, and specifically, to send static data once that many objects will use.

Datablocks should describe static (not changing during game play) behaviours and statistics that are shared by many objects, not unique to one object. If you have properties that will change during play, as well as be different for different objects, then dynamic properties are really the way to go.

In the long run, especially in a large number of players scenario, you would be -losing- efficiency by using unique datablocks per player, and definitely not gaining anything.

#10 OH YES !

It is a big misunderstanding of my side.

When I read the tutorial I understood that the update described after joinServer.gui are linked to the mode "join server".

Sorry to disturb you because i am not able to read correctly a tutorial.

Now it is clear

thanks a lot !

#11 With the new player.cs file provided by James : it works perfectly !

#12 @Phillipe: not a problem at all, this is actually an amazingly complex interaction between client and server!

To follow-on readers: If you study both the tutorial and the underlying code that you are going to modify, and understand the concepts behind what it is doing and why, you are well on your way to understanding both the client/server model, and Torque ghosted object networking.

I highly suggest this tutorial be run on a stock installation on the engine for pretty much anyone, as it's an excellent learning mechanism for what Torque is actually doing.

#13 Do you know some adress games created in Torque Engine when user can play in internet in this game. Who know help.

email: jekelon@gmail.com