Game Development Community

T3D 1.1 Final - clientCmd param list corruption - LOGGED (THREED-2389) RESOLVED

by Richard Ranft · in Torque 3D Professional · 08/03/2011 (11:06 am) · 7 replies

Build: 1.1 Final

Platform: Windows 7

Target: Client connected to dedicated server

Issues: I discovered that a clientCmd function I've been using for single player did not seem able to access members of the $Game namespace when running a dedicated server, so I modified my function to accept parameters. The first parameter was being overwritten by the object namespace that the function was accessing on the client. To wit, I was telling my PlayGui.RedScoreLabel.text to equal the first parameter and my PlayGui.BlueScoreLabel.text to equal the second parameter, and what it was doing was setting the PlayGui.RedScoreLabel.text field to equal PlayGui - not what I had in mind at all.

Note that this only seems to happen when I attempt to update these gui objects. All of the stock calls seem to work just fine.

Steps to Repeat:
1. In GUI Editor, add a new GuiTextControl to the PlayGui.
2. Set up scripts to send a commandToClient() call to modify the GuiTextControl text field.
3. Start a dedicated server.
4. Trigger the call.
5. Observe the parameter values.


Suggested Fix: My workaround was to accept a third parameter at the head of the parameter list and discard it in the function.

About the author

I was a soldier, then a computer technician, an electrician, a technical writer, game programmer, and now software test/tools developer. I've been a hobbyist programmer since the age of 13.


#1
08/03/2011 (11:18 am)
Thanks Richard. I've logged a ticket for this issue under THREED-2389.
#2
08/14/2011 (3:50 pm)
While we're digging - I'm noticing interesting characters showing up in log files when using the c tags for color in the console. Might be related. Also, in a recent multiplayer test I was getting disconnected during mission download for missing assets but the filenames reported were gibberish - I took pics.

72.193.82.104/image1.jpg

72.193.82.104/image2.jpg

72.193.82.104/image3.jpg

Note we have fresh gibberish with each connection attempt. The log for each attempt was different only in the port used, and that only changed between successful connection attempts:

Got Connect challenge Request from IP:192.168.15.101:65369
Got Connect Request
Connect request from: IP:192.168.15.101:65369
CADD: 3651 IP:192.168.15.101:65369
*** Sending mission load to client: levels/arena01.mis
Mapping string: MissionStartPhase1Ack to index: 0
Mapping string: MissionStartPhase2Ack to index: 1
Client 3651 disconnected.
Issuing Disconnect packet.
CDROP: 3651 IP:192.168.15.101:65369

Also, even though there are log entries showing master server interaction the game doesn't actually show up if you query it from the Join interface.

Sending heartbeat to master server [IP:209.90.70.170:28002]
Received info request from a master server [IP:209.90.70.170:28002].

I think I'm going to add timestamps to the network log entries.
#3
08/29/2011 (9:52 am)
@Richard
Could you post the code you ran into this with? That would help sort this one out.
#4
08/29/2011 (12:39 pm)
Ok, the client command function is
function clientCmdUpdateScoreboard(%rScore, %bScore)
{
   //echo("Updating scores - red:"@%rScore@", blue:"@%bScore);
   // Tell the PlayGUI to update the scoreboard
   PlayGui.updateScores(%rScore, %bScore);
   // Tell server to check the score
   commandToServer('checkScore');
}

and the called function is
function PlayGui::updateScores(%extra, %redScore, %blueScore)
{
   
   //%redScore = $Server::RedScore;
   //%blueScore = $Server::BlueScore;
   //echo("PlayGui::updateScores - extra:"@%extra@", red:"@%redScore@", blue:"@%blueScore);
   RedScore.text = %redScore;
   BlueScore.text = %blueScore;
}

And I just realized that, after tweaking and fiddling with this for a few weeks this has changed a little. The commandToClient() call isn't introducing garbage, it seems to be more related to object hierarchies. This functions correctly in my project as it is written - the %extra parameter comes in with the name PlayGui stored in it.

As for the network code issue, it was caused by missing terrain files - but the file names were gibberish so I wasn't at first aware of the issue (which was caused by my failure to add them to my repo before we pulled a copy and started fiddling with it). I have not modified the mission loading system in any way so somewhere in the stock code that comes with the full template there is something wrong.
#5
08/29/2011 (1:03 pm)
Try this:
function PlayGui::updateScores(%this, %redScore, %blueScore)  
{

On the definition of a function, the %this is required for all objects. Is a pointer to the objectID.

So, if u will add another paramater, u must write as this example:

function clientCmdUpdateScoreboard(%rScore, %gScore, %bScore)  
{  
   // Tell the PlayGUI to update the scoreboard  
   PlayGui.updateScores(%rScore, %gScore, %bScore); 
 
   // Tell server to check the score  
   commandToServer('checkScore');  
} 

function PlayGui::updateScores(%this, %redScore, %greenScore, %blueScore)    
{
   RedScore.text = %redScore;
   GreenScore.text = %greenScore;  
   BlueScore.text = %blueScore;  
}

To isolate the controls, i suggest you to use the hierarchies. In this way, if you have some other GUI objects with the same name, do not risk to change the values even of them.
function PlayGui::updateScores(%this, %redScore, %greenScore, %blueScore)    
{
   // Only the RedScore/GreenScore/BlueScore on the PlayGui are updated
   %this-->RedScore.setText( %redScore );
   %this-->GreenScore.setText( %greenScore );
   %this-->BlueScore.setText( %blueScore );
}
#6
08/29/2011 (1:29 pm)
Ah, yeah the issue is what I thought, just needed to see it to be sure.

The extra parameter there isn't extra, it's required. When you have a namespace function in script the object in that namespace is always the first argument. Typically this argument is %this, but can be anything really.
#7
08/29/2011 (3:06 pm)
lol - figures - must have missed it in my reading. My original assessment was based on a quick glance at the problem. I'll have to make a note of it to myself. Sorry 'bout that!

@Alfio - funny you should say that, I thought of that about 10 minutes after my last post on my way to get some tacos. Thanks for throwing in with that - confirms my thought.

Ok, problem solved - cranial rectal inversion corrected.