Useage of gloabals for easy access in script functions
by Rick Kelley · 11/30/2006 (1:21 pm) · 4 comments
The use of globals for easy access to calls to script functions are sometimes hard to implement.
In my experience in the Torque scripting language, I have found that trying to figure out
just how to access another scripts functions so it will function as expected is a bit
tedious to figure out exactly how to pass the proper arguments. It sometimes is just plain
frustrating, and you can dig into the documentation, and forums for hours, even days! I
have found a solution to some of this as I come from an old school of plain vanilla C
programming that dates back to Unix. (Way before C++ was around). It involves the use of
global variables. I am not interested in getting in to any flaming wars about the pros
and cons of use of global variables. I will state that you should use them wisely, and
they can become very addictive in programming.
Below is a scripted function for my implementation for a snowmobile class:
function snowmobile::onEnterLiquid(%this, %obj, %coverage, %type)
{
echo("we hit the water in a snowmobile!");
// setting a global variable to test for drowning
$WaterDeath = 1;
switch(%type)
{
case 0: //Water
case 1: //Ocean Water
Armor::doDismount(%this, $MyPlayer, 1);
...
You should notice that there are two variable being used: $WaterDeath, and $MyPlayer. The
$WaterDeath is for a test when the onDeath function is called for the player so you can
deduct score points for a suicide by drowning. The $MyPlayer variable is to send the proper
argument to the Armor::doDismount function. Below shows how it is created and loaded with
the proper asignment taken from the GameConnection::createPlayer function in server/game.cs:
// Create the player object
%player = new Player() {
dataBlock = PlayerBody;
client = %this;
};
// making a global variable to access the player directly
$MyPlayer = %player;
I also got tired of trying to message the client in several functions so I add the following
line below the above:
// making a global variable to message the client
$MyClient = %player.client;
Now all I would have to do to message the client would be to make the call like so:
// messaging the client that you have captured the flag
messageClient($MyClient , 'MsgScorePoint', 'You captured the flag!');
Of course you need to study each function carefully to see if your going to address the function
properly with each new global variable that you set up. Hopefully this will help you get on your
way to spending less time in trying to figure out how to exactly call a function.
In my experience in the Torque scripting language, I have found that trying to figure out
just how to access another scripts functions so it will function as expected is a bit
tedious to figure out exactly how to pass the proper arguments. It sometimes is just plain
frustrating, and you can dig into the documentation, and forums for hours, even days! I
have found a solution to some of this as I come from an old school of plain vanilla C
programming that dates back to Unix. (Way before C++ was around). It involves the use of
global variables. I am not interested in getting in to any flaming wars about the pros
and cons of use of global variables. I will state that you should use them wisely, and
they can become very addictive in programming.
Below is a scripted function for my implementation for a snowmobile class:
function snowmobile::onEnterLiquid(%this, %obj, %coverage, %type)
{
echo("we hit the water in a snowmobile!");
// setting a global variable to test for drowning
$WaterDeath = 1;
switch(%type)
{
case 0: //Water
case 1: //Ocean Water
Armor::doDismount(%this, $MyPlayer, 1);
...
You should notice that there are two variable being used: $WaterDeath, and $MyPlayer. The
$WaterDeath is for a test when the onDeath function is called for the player so you can
deduct score points for a suicide by drowning. The $MyPlayer variable is to send the proper
argument to the Armor::doDismount function. Below shows how it is created and loaded with
the proper asignment taken from the GameConnection::createPlayer function in server/game.cs:
// Create the player object
%player = new Player() {
dataBlock = PlayerBody;
client = %this;
};
// making a global variable to access the player directly
$MyPlayer = %player;
I also got tired of trying to message the client in several functions so I add the following
line below the above:
// making a global variable to message the client
$MyClient = %player.client;
Now all I would have to do to message the client would be to make the call like so:
// messaging the client that you have captured the flag
messageClient($MyClient , 'MsgScorePoint', 'You captured the flag!');
Of course you need to study each function carefully to see if your going to address the function
properly with each new global variable that you set up. Hopefully this will help you get on your
way to spending less time in trying to figure out how to exactly call a function.
#2
Although I'm not certain yet how much multiplayer activity I'm going to deal with (I've been thinking more about the single player game so far), doing things this way assures that I won't run into any weird side effects from shared globals when and if I do add multiplayer games.
I think the only thing I use globals for is actual "global" values that are the same for all players., like the gravity value and atmospheric drag of the current map, the default faction for the current map, etc...
12/01/2006 (10:09 am)
I use my client GameConnections as a 'namespace' for what you'd use globals for. In other words, I set the value in the client object instead of a global variable. To get the client game connection that's controlling just about anything derived from ShapeBase (players, vehicles, etc...), I use 'getControllingClient()' (ie., %vehicle.getControllingClient() ).Although I'm not certain yet how much multiplayer activity I'm going to deal with (I've been thinking more about the single player game so far), doing things this way assures that I won't run into any weird side effects from shared globals when and if I do add multiplayer games.
I think the only thing I use globals for is actual "global" values that are the same for all players., like the gravity value and atmospheric drag of the current map, the default faction for the current map, etc...
#3
12/02/2006 (8:40 am)
Brian: attaching arbitrary script variables to engine objects is actually one of my favourite things in torque script. That, and the huge flexibility provided by torquescript "arrays".
#4
12/05/2006 (11:42 am)
@bank: as I stated, the use of this is to access things that are not accessable in a certain function, and that you should be careful as to how you script the variables. Things can go wrong using this method, but, however; if your function refuses to use, or has no arguments passed to it so you could access the particular variable, this is meant to compensate. The purpose of this resource is to help a person to access what is needed, then if problems arise, start to debug, and test the heck out of your game. It is also for a quick and dirty prototype. I do appreciate the feedback on this, though, as your comments will lead others to find ways to access hidden areas of the toque script, and try to find out how to access some of these variables that are needed. 
Associate Fyodor -bank- Osokin
Dedicated Logic
Imagine you have two players running. First enters the water, and then second player dies. Or if you use $MyClient - it will be overridden.
I prefer using dynamic variables on objects.
If you need to "message a client", use %player.client if you are in function where you have player object.
If you mount player into vehicle, do assing client to it also:
%vehicle.client = %player.client;
Then you can do whatever you want. Don't over-use the globals!
good luck :)