Commandtoserver help?
by kc_0045 · in Torque Game Engine · 02/07/2004 (3:58 pm) · 11 replies
Hey geting this error
(0): Call to commandToServer in (null) uses result of void function call.
when i run a commandtoserver here are the cmds any one no why its not working?
function getpackcount()
{
return commandtoserver('getpackcount');
}
function getpackname(%num)
{
return commandtoserver('getpackname',%num);
}
and then im just calling them functions and its giving me that error :( all the
servercmds do is return a varable help me plz!
(0): Call to commandToServer in (null) uses result of void function call.
when i run a commandtoserver here are the cmds any one no why its not working?
function getpackcount()
{
return commandtoserver('getpackcount');
}
function getpackname(%num)
{
return commandtoserver('getpackname',%num);
}
and then im just calling them functions and its giving me that error :( all the
servercmds do is return a varable help me plz!
About the author
#2
messageClient( %client, 'PackCount', %packCount );
sends the info to the Client...
addMessageCallback( 'PackCount', updatePackCount );
Then i kinda get lost here so do i add this to a function or just make sure it gets exec?
02/07/2004 (6:08 pm)
Ohhh ok hmmm just making sure i under stand this...messageClient( %client, 'PackCount', %packCount );
sends the info to the Client...
addMessageCallback( 'PackCount', updatePackCount );
Then i kinda get lost here so do i add this to a function or just make sure it gets exec?
#3
addMessageCallback( 'PackCount', updatePackCount );
Calls for the "PackCount" message data to be sent to this function...
function updatePackCount(%msgType, %msgString, %packCount)
{
Receive %packCount data here.
}
%msgType should return "clientmessage"
%msgString should return "PackCount"
%packCount would be the data that was sent per your request.
The way you build a handle and call back is to place the handle just in front of the function it services. That will help you keep them together. You could use clientcommand() to get the job done, but the flexibility is not as great IMO. This function here is one of mine. It demonstrates how one message from the server can set off several functions, each with its own data. All transfered in one message much like a chat message....First, just place the callback(In this case, the server is sending a "MsgClientJoin" callback to each client to notify them of a player joining. The players client will then adjust all relevant huds and data by calling the function named "handleClientJoin")
Just remember that each callback must proceed the function it calls, or you'll get console errors upon compile. I just keep all my callback and handles in one easy to work file. Good luck.
02/07/2004 (10:51 pm)
Kc, it is very confusing at first because the data is not passed to the callback, but to the function the callback refers to. In this case....addMessageCallback( 'PackCount', updatePackCount );
Calls for the "PackCount" message data to be sent to this function...
function updatePackCount(%msgType, %msgString, %packCount)
{
Receive %packCount data here.
}
%msgType should return "clientmessage"
%msgString should return "PackCount"
%packCount would be the data that was sent per your request.
The way you build a handle and call back is to place the handle just in front of the function it services. That will help you keep them together. You could use clientcommand() to get the job done, but the flexibility is not as great IMO. This function here is one of mine. It demonstrates how one message from the server can set off several functions, each with its own data. All transfered in one message much like a chat message....First, just place the callback(In this case, the server is sending a "MsgClientJoin" callback to each client to notify them of a player joining. The players client will then adjust all relevant huds and data by calling the function named "handleClientJoin")
addMessageCallback('MsgClientJoin', handleClientJoin);
//
// then place the function
//
function handleClientJoin(%msgType, %msgString, %name, %client, %guid, %score, %isAI, %isAdmin, %isSuperAdmin, %caps, %ping, %team)
{
PlayerListGui.update( %client, detag(%name), %isSuperAdmin, %isAdmin, %isAI, %score, %caps);
SpectatorMenuGUI.update(%client, detag(%name), %score, %caps, %team);
AdminDlg.update( %client, detag(%name), %ping, %team);
}Just remember that each callback must proceed the function it calls, or you'll get console errors upon compile. I just keep all my callback and handles in one easy to work file. Good luck.
#4
messageClient( %client, 'PackCount', %packCount );
the client cmd that the addMessageCallback is set to gets called... ok i got it ty Alot Gonzo! :D
02/08/2004 (12:06 am)
Ohhh ok i think im geting this now! :D just to make sure one more thing. so like when the server callsmessageClient( %client, 'PackCount', %packCount );
the client cmd that the addMessageCallback is set to gets called... ok i got it ty Alot Gonzo! :D
#5
first i call the client cmd
then it runs
then back in the client scripts i got
then i shoud be able to use that buy just going like this for a eg right?
02/08/2004 (12:52 am)
Edit: ok i though i had it but i dont :( idk why this is not working but here's what im doing.first i call the client cmd
function getpackcount()
{
commandtoserver('getpackcount');
}then it runs
function servercmdgetpackcount(%cl)
{
messageClient( %cl,'packcountcall',"",$inv_current);
}then back in the client scripts i got
addMessageCallback('packcountcall',handlepackcount);
function handlepackcount(%msgType, %msgString, %packCount)
{
$packcount=%packCount;
}then i shoud be able to use that buy just going like this for a eg right?
getpackcount(); echo($packcount);but thats not working :( well thanks for all ur help for fare :D
#6
You have to think of your coding in terms of events. If you start setting up polling events for information from the server then you're going to struggle. Set it up in such a way such that the server actively sends such information rather than the respective clients polling it. This way you can always be sure that the client reference is as up-to-date as the server can maintain.
As an example, if you want to show a screen when a counter changes on the server then rather than polling the server from the clients, simply get the server to make the change and then send a message to the clients informing them of the change and then the clients can respond to this event by showing the screen.
Remember, in such a model, think of the server controlling all and the clients being ancillary. There will be cases where the clients need to actively control some logic on the server but in this case you need to be careful regarding security from script-hacking and make such control a request to the server to do so rather than an instruction.
Here's a basic handshaking example...
On the client...
- Melv.
02/08/2004 (2:08 am)
One of the things to understand fully is that the calls are asynchronous meaning that they don't finish what they're doing and then return to you, they return immediately and the network communication happens at another stage.You have to think of your coding in terms of events. If you start setting up polling events for information from the server then you're going to struggle. Set it up in such a way such that the server actively sends such information rather than the respective clients polling it. This way you can always be sure that the client reference is as up-to-date as the server can maintain.
As an example, if you want to show a screen when a counter changes on the server then rather than polling the server from the clients, simply get the server to make the change and then send a message to the clients informing them of the change and then the clients can respond to this event by showing the screen.
Remember, in such a model, think of the server controlling all and the clients being ancillary. There will be cases where the clients need to actively control some logic on the server but in this case you need to be careful regarding security from script-hacking and make such control a request to the server to do so rather than an instruction.
Here's a basic handshaking example...
On the client...
commandToServer('GetTheCount');On the server...function serverCmdGetTheCount(%client)
{
// Send Response.
commandToClient(%client, 'SendTheCount', $countOnServer);
}Back on the client...function clientCmdSendTheCount( %count )
{
$countOnClient = %count;
// Maybe trigger some action on the client here?
// ...
}- Melv.
#7
This is why I was teaching him about message callbacks. The server can send messages with OR without text, and achieve multiple results with the same function. I find them extremely versatile and fun to make. For instance, you could have a popup gui that pop's up a little HUD with every flag cap. Using a message callback you could send everyone the same message about the flag cap, but for the guy that capped it, you could send his own special message and it wouldn't have to go through any trouble to do it. Also the point of the message callbacks was to allow for indexing messages which helps save packetsize between client and server.
Example from logs...
For our new freind here's benifit...The first time "MsgClientJoin" is sent to a client, it is indexed(in this case to "6"). All times after that, it will send "6" in place of "MsgClientJoin" and the client will reference index 6 to get the proper meaning. Just another way to save interpretation and to save valuable bits.
If you were to change the functions to get rid of the word "get", you might have some luck. I have heard stories of "Get" causing problems for others. I never use it because Torque already has a thousand gets in it. Your code looks fine, but the "get" worries me that the interpreted commands might be biting the dust on them. What I mean is...
commandToClient(%client, 'syncClock', %time);
is executed by this function.....
And as you can see, the "Tagged" string is attached to clientCmd to create a unique function. Tagged strings have caused a lot of heartache for coders that dont know how they interact. I myself fell victem of a tagged string that almost made me go nuts. I used to run debug code through my chat hud to give me instant feed back and save me from pouring through a log. Imagine my surprise when the first tagged string went through the ChatHud. Holy cow, it was like a DDoS attack on my hud that just lagged and lagged. One string caused 2 minutes of superspam in my hud that moved so fast, I couldn't read it. Took a while to figure out exactly what was causing that. So if you would, try to clean them up like this and see if they work right.
function servercmdpackcount(%cl)
{
messageClient( %cl, 'packcountcall', "", $inv_current);
}
If not, check your log and see if you notice anything unusual. You have the right idea, dont get frustrated now. There is just some unknown at work here, and unless its just a simple problem caused by the "gets" in your functions, i'd say it's probably not your fault. BTW, are you using the Demo? Or are you scripting from scratch? If you dont have the demo's scripts to start with, then these wont work at all.
02/08/2004 (9:34 am)
"As an example, if you want to show a screen when a counter changes on the server then rather than polling the server from the clients, simply get the server to make the change and then send a message to the clients informing them of the change and then the clients can respond to this event by showing the screen."This is why I was teaching him about message callbacks. The server can send messages with OR without text, and achieve multiple results with the same function. I find them extremely versatile and fun to make. For instance, you could have a popup gui that pop's up a little HUD with every flag cap. Using a message callback you could send everyone the same message about the flag cap, but for the guy that capped it, you could send his own special message and it wouldn't have to go through any trouble to do it. Also the point of the message callbacks was to allow for indexing messages which helps save packetsize between client and server.
Example from logs...
Mapping string: ServerMessage to index: 0 Mapping string: MsgConnectionError to index: 1 Mapping string: ServerSettingsInfo to index: 2 Mapping string: MsgLoadInfo to index: 3 Mapping string: MsgLoadDescripition to index: 4 Mapping string: MsgLoadInfoDone to index: 5 Mapping string: MsgClientJoin to index: 6
For our new freind here's benifit...The first time "MsgClientJoin" is sent to a client, it is indexed(in this case to "6"). All times after that, it will send "6" in place of "MsgClientJoin" and the client will reference index 6 to get the proper meaning. Just another way to save interpretation and to save valuable bits.
If you were to change the functions to get rid of the word "get", you might have some luck. I have heard stories of "Get" causing problems for others. I never use it because Torque already has a thousand gets in it. Your code looks fine, but the "get" worries me that the interpreted commands might be biting the dust on them. What I mean is...
commandToClient(%client, 'syncClock', %time);
is executed by this function.....
function clientCmdSyncClock(%time)
And as you can see, the "Tagged" string is attached to clientCmd to create a unique function. Tagged strings have caused a lot of heartache for coders that dont know how they interact. I myself fell victem of a tagged string that almost made me go nuts. I used to run debug code through my chat hud to give me instant feed back and save me from pouring through a log. Imagine my surprise when the first tagged string went through the ChatHud. Holy cow, it was like a DDoS attack on my hud that just lagged and lagged. One string caused 2 minutes of superspam in my hud that moved so fast, I couldn't read it. Took a while to figure out exactly what was causing that. So if you would, try to clean them up like this and see if they work right.
function servercmdpackcount(%cl)
{
messageClient( %cl, 'packcountcall', "", $inv_current);
}
If not, check your log and see if you notice anything unusual. You have the right idea, dont get frustrated now. There is just some unknown at work here, and unless its just a simple problem caused by the "gets" in your functions, i'd say it's probably not your fault. BTW, are you using the Demo? Or are you scripting from scratch? If you dont have the demo's scripts to start with, then these wont work at all.
#8
02/11/2004 (3:23 pm)
Ya ty all for helping me i got it working now :D c-ya l8er
#9
in playGui.cs file
function PlayGui::increaseLapCounter(%this)
{
// Increase the lap.
PlayGui.lap++;
PlayGui.updateLapCounter();
}
in checkpoint.cs file:
... lots of code
commandToClient(%obj.client, 'increaseLapCounter');
... more code
in console i can see the error
clientCmdsetMaxLaps: Unknown command.
can anyone help me ?
07/12/2006 (8:59 am)
Hi, i have the same problem with the "TAGGED" string, the thing is that it doesnt recognize the function because of the clientCmd in front of it... in playGui.cs file
function PlayGui::increaseLapCounter(%this)
{
// Increase the lap.
PlayGui.lap++;
PlayGui.updateLapCounter();
}
in checkpoint.cs file:
... lots of code
commandToClient(%obj.client, 'increaseLapCounter');
... more code
in console i can see the error
clientCmdsetMaxLaps: Unknown command.
can anyone help me ?
#10
07/12/2006 (10:35 am)
Answered you in the other thread, Vilain. Generally, it's considered poor etiquette around here to post your question on multiple threads, especially by resurrecting a 2 year old thread.
#11
09/11/2007 (9:14 am)
MY GOD THIS IS CONFUSING!!!!
Torque Owner Gonzo T. Clown
function getpackcount()
{
commandtoserver('getpackcount');
}
function serverCmdgetpackcount(%client)
{
Here is where your server retrieves the clients pack data;
then you would send
messageClient( %client, 'PackCount', %packCount );
}
*Then your client needs a message callback*
addMessageCallback( 'PackCount', updatePackCount );
*Finally your function to handle the update*
function updatePackCount(%msgType, %msgString, %packCount)
{
Receive %packCount data here.
}
It's never as easy as we would like it to be is it? LOL