Game Development Community

GameConnection different in Code and Script?

by James Laker (BurNinG) · in Torque Game Engine · 06/19/2007 (1:12 pm) · 6 replies

Hi

Trying to get proper teams implemented. Now I'm using the CommanderMap to determine my Spawnpoint. I've extended the Gameconnection to have getTeamNo and setTeamNo.

In script I call them like this:
echo("%this.getTeamNo = " @ %this.getTeamNo());
   %this.setTeamNo(%this.team.teamId);
   echo("%this.getTeamNo = " @ %this.getTeamNo());

and the results are fine.... It gives me 0... and when I set it, it changes to 1 or 2 depending on my decision.

But in code when I use this with a guiControl (guiCommanderHud):
GameConnection* conn = GameConnection::GetConnectionToServer();
if (conn)
{
    Con:printf("conn->getTeamNo() = %i", conn->getTeamNo());
}

It returns 0 (set in the Contructor)

Shouldn't these be the same GameConnection? Help me understand pls.

Thanx
James

#1
06/20/2007 (9:40 am)
*bump
#2
06/20/2007 (6:27 pm)
Where are you executing each of these scripts?

If you did it properly, your "setting of team" should be done server side, but putting it into a GUI needs to be done client side--which means that you have to use the network to "deliver" the data to the client. Since you appear to be using c++, this means teamNo is probably stored as a class member variable, and therefore can be networked via PackUpdate/UnpackUpdate, but you have to actually do it.

Alternatively, you could store them in dynamic fields, and send it across via commandToClient.
#3
06/21/2007 (3:24 am)
Hi Stephen.

I am doing the setTeam on the serverside in function GameConnection::joinTeam(%this, %teamid). There I get the correct Echo values.

Aaaah.... I added it to the readDemoStartBlock/WriteDemoStartBlock but not the ReadPacket/WritePacket... No wonder.

Thinking about it for a second... Keeping Gameconnection as light as possible, would it be more traffic efffcient to use the commandToClient than having the TeamNo in Gameconnection as a variable/member?

Guess it would make sense, if dynamic fields dont get transmitted...

Thanx the reply
#4
06/21/2007 (3:37 am)
Since the first section is run on the server, and the second section is run on the client - you'd have to add it to packUpdate () and unpackUpdate ().

Like:

[b]packUpdate ()[/b]
writeInt (teamId, 3);

[b]unpackUpdate ()[/b]
teamId = readInt (3);

Make sure they line up in both methods to be written and read at the same order.
You should also implement some sort of mask here, so you're not sending the team ID each update, because I'm sure you're not changing teams every update. :)

For this to work on the controlling client as well, you'll have to do the same in packData () and unpackData ().
#5
06/21/2007 (7:53 am)
Personally (in response to the "keeping GameConnection object light") I would be careful with modifying the GameConnection class with this type of information, as you seem to be thinking--there really isn't any (currently stated) reason that it has to be done at the c++ level, and a dynamic field would work for most of what you need, and when the team is set/changed, a commandToClient used to deliver the change.

There are cases (team-mates are invulnerable to my fire, for example) where it might make sense to have the team info in c++, but in general the data is really only going to be changing very rarely, and this makes it a much more appropriate choice to use a NetEvent (which is what commandToClient uses) as opposed to a ghosted data field.
#6
06/21/2007 (7:59 am)
Awesome...

Thanx alot guys!