Basic question: where to store globals?
by Phil Shenk · in Torque Game Builder · 02/27/2005 (1:26 am) · 19 replies
I'm not familiar with TGE at all, but I can code a bit. So, my questions with T2D are probably really, really basic stuff for people coming over from TGE. Two that I'm coming up with right away are:
1) Where do I store any kind of global variables or data? Things like playerMaxVelocity, playerHP, playerLives, etc? I'm assuming I instantiate a datablock, but the T2D references only describe T2D specific datablocks.
Along these lines, are all variables scoped inside of datablocks? Which are basically like structs? (Sorry I'm kind of a noob coder). Can I declare local variables inside of functions? Is it basically like C/C++ as far as control structures, etc? I guess this is a big huge topic... any help is appreciated though.
2) Are there any references for other useful commands, such as writing to the console for debugging. Anything like "printf" type parsing so I can check variables? Even better would be text on the screen. (There may be reference for this... haven't looked for that yet).
1) Where do I store any kind of global variables or data? Things like playerMaxVelocity, playerHP, playerLives, etc? I'm assuming I instantiate a datablock, but the T2D references only describe T2D specific datablocks.
Along these lines, are all variables scoped inside of datablocks? Which are basically like structs? (Sorry I'm kind of a noob coder). Can I declare local variables inside of functions? Is it basically like C/C++ as far as control structures, etc? I guess this is a big huge topic... any help is appreciated though.
2) Are there any references for other useful commands, such as writing to the console for debugging. Anything like "printf" type parsing so I can check variables? Even better would be text on the screen. (There may be reference for this... haven't looked for that yet).
About the author
#2
Here's the official GG Documentation to look through.
Two other useful references are...
Language Reference
Console Commands
Other than that Phil, just ask, we're always here, time-zones allowing. :)
Good Luck.
- Melv.
02/27/2005 (2:10 am)
@Phil: Welcome! Glad to see you're playing around with T2D. :)Here's the official GG Documentation to look through.
Two other useful references are...
Language Reference
Console Commands
Other than that Phil, just ask, we're always here, time-zones allowing. :)
Good Luck.
- Melv.
#3
Robert V Frazier
03/12/2005 (6:53 pm)
Melv, several chapters are restricted to those of us who have the T2D license, but not the TGE. Can we get access?Robert V Frazier
#4
you can also then do
in the console and it will dump all the contents of the object...
writing to the console for debuging
03/13/2005 (12:33 am)
$playerInfo = new ScriptObject(); $playerInfo.hp = 100; $playerInfo.lives = 10; etc.....
you can also then do
$playerInfo.dump();
in the console and it will dump all the contents of the object...
writing to the console for debuging
echo("debug info");:)
#5
Sorry for the inconvenience, we'll get more information to your fingers just as quick as we can.
- Melv.
03/13/2005 (1:37 am)
@Robert: Yeah, we're sorry about the problems with getting access to some of this stuff. We are working on something that'll allow you to get access to the appropriate information. T2D is kind of a unique product so far in that it is a subset of the TGE platform unlike something like TSE which is more of a superset.Sorry for the inconvenience, we'll get more information to your fingers just as quick as we can.
- Melv.
#6
--Global variables are automatically placed in a namespace that is visible to other modules. It is as simple as using the $ in the front of the variable--that's what makes it global, and the script console takes care of the rest.
--local variables are created dynamically as well (simply use them), and are indicated by the % in the front of the variable. These act pretty much just like local variables in other languages, and are only accessable via the same scope/namespace.
03/13/2005 (9:11 am)
@Phil: To answer some of your specific questions:--Global variables are automatically placed in a namespace that is visible to other modules. It is as simple as using the $ in the front of the variable--that's what makes it global, and the script console takes care of the rest.
--local variables are created dynamically as well (simply use them), and are indicated by the % in the front of the variable. These act pretty much just like local variables in other languages, and are only accessable via the same scope/namespace.
#7
Is there a way to dynamically select a namespace? For instance:
is itself a variable. I'm trying to break user preference settings into groups by user name. Is this possible?
Edit: While I'm guessing that this isn't possible, if it is I'd love to know. :) But meanwhile, I've chosen to just do this:
03/13/2005 (7:13 pm)
This is somewhat related, so instead of a new thread I figured I'd ask it here.Is there a way to dynamically select a namespace? For instance:
$myPref::<username>::someVariable = "X";Where
Edit: While I'm guessing that this isn't possible, if it is I'd love to know. :) But meanwhile, I've chosen to just do this:
$myPref::someVariable[<username>] = "X";since it does essentially the same thing.
#8
03/13/2005 (9:20 pm)
@Jason: You could also do something like:eval("$mypref::"@<username>@"::someVariable = "@<value>@";");Your array method looks a lot cleaner, though.
#9
03/13/2005 (9:58 pm)
@Matt: Ah, so it is possible. Thanks for that. :) Although I agree that the array method is cleaner. I can iterate over or index into the array-style variables easily.
#10
%client.stats = new ScriptObject() {
str = 10;
power = 20;
blah = 22;
};
To save stats you would then do:
%client.stats.save("T2D/saves/" @ %client.name @ ".cs");
Loading and re-attaching to the correct client would be an excercise for the reader :)
03/13/2005 (10:48 pm)
The situation you describe is just one of those places where I'd use a scriptObject.%client.stats = new ScriptObject() {
str = 10;
power = 20;
blah = 22;
};
To save stats you would then do:
%client.stats.save("T2D/saves/" @ %client.name @ ".cs");
Loading and re-attaching to the correct client would be an excercise for the reader :)
#11
I went through the console reference several times trying to figure out how to write the data to a file, and so figured export() was the only alternative. I must have just missed it somehow..... thanks for the info!!
03/14/2005 (10:11 am)
Is that save function documented somewhere? :O Is it a T2D function?I went through the console reference several times trying to figure out how to write the data to a file, and so figured export() was the only alternative. I must have just missed it somehow..... thanks for the info!!
#12
There is one other method for saving data to a file with scripts and that is with the fileObject.
Here's the information as it's in the TGE private forums.
Below are two code samples I wrote to demonstrate the file functions. The first is simply two functions one to read a file and echo out the contents and write specific information into a file.
The second is two functions that allow you to open a file (read or write), specify a filehandle ID and reference it from anywhere in your code.
03/14/2005 (11:03 am)
It's part of the the base Torque code, as for being documented... I'm not sure if it is. I've never really relied on documentation much. I ether use %obj.dump() or I check the c++ source... There is one other method for saving data to a file with scripts and that is with the fileObject.
Here's the information as it's in the TGE private forums.
Below are two code samples I wrote to demonstrate the file functions. The first is simply two functions one to read a file and echo out the contents and write specific information into a file.
The second is two functions that allow you to open a file (read or write), specify a filehandle ID and reference it from anywhere in your code.
function readfile(%filename)
{
%file = new FileObject();
if(%file.openForRead(%filename))
{
while(!%file.isEOF())
{
%input = %file.readLine();
echo(%input);
}
}
%file.close();
%file.delete();
}
function write(%filename)
{
%file = new FileObject();
%file.openforWrite(%filename);
%file.writeLine( "This is an output file);
%file.writeLine( "I can contain any plain text that the user wishes to output." );
%file.close();
%file.delete();
}// Usage:
// openFile("name","fileHandle","R");
// Open a file named "name" assign a fileHandle ID of "fileHandle", open as Readonly.
// Reference in another function:
// fileHandle.readLine();
//
// openfile("name","fileHandle","W");
// Open a file named "name" assign a fileHandle ID of "fileHandle", open as Writeonly.
// Reference in another function:
// fileHandle.writeLine();
//
// closeFile("fileHandle");
// Closes the file associated with the fileHandle ID of "fileHandle"
function openFile(%filename,%IDname,%rw)
{
%file = new FileObject(%IDname);
if (%rw $= "R")
{
if(%file.openForRead(%filename))
{
return 1;
}
else
{
return 0;
}
}
else if (%rw $= "W")
{
%file.openForWrite(%filename);
return 1;
}
else
{
return 0;
}
}
function closeFile(%IDname)
{
%IDname.close();
%IDname.delete();
}
#13
[rant]
I can't believe that TGE doesn't have this stuff documented. GG would have oodles more projects using it if they could organize this stuff into an easy to find place. Even if they actually implemented the "usage" part of the error output--a great idea totally ignored--that would be a huge help. I usually dig through the other scripts to figure out a function's usage parameters. Tedious, slow, waste of time. Digging through code to find usage parameters doesn't serve the interests of getting my game done quickly (time is money for some of us).
Docs for an engine are a lot like the interface for a game--if it sucks, you aren't going to have players no matter how good the game is. And quantity doesn't trump quality. 8,000 pages of spaghetti documentation does me no good if I can't find what I'm looking for quickly. In fact, that massive amount makes it much worse. So far, this is the most frustrating part of using T2D--and it's not really a T2D issue.
No offense to the T2D team who seem to be going full-speed ahead with more documentation. It will be much appreciated, and I hope that sense of professionalism and service will spill over to TGE in general.
[/rant]
03/14/2005 (12:20 pm)
Wow, thanks for that! Very useful information and very fundamental to creating a game.[rant]
I can't believe that TGE doesn't have this stuff documented. GG would have oodles more projects using it if they could organize this stuff into an easy to find place. Even if they actually implemented the "usage" part of the error output--a great idea totally ignored--that would be a huge help. I usually dig through the other scripts to figure out a function's usage parameters. Tedious, slow, waste of time. Digging through code to find usage parameters doesn't serve the interests of getting my game done quickly (time is money for some of us).
Docs for an engine are a lot like the interface for a game--if it sucks, you aren't going to have players no matter how good the game is. And quantity doesn't trump quality. 8,000 pages of spaghetti documentation does me no good if I can't find what I'm looking for quickly. In fact, that massive amount makes it much worse. So far, this is the most frustrating part of using T2D--and it's not really a T2D issue.
No offense to the T2D team who seem to be going full-speed ahead with more documentation. It will be much appreciated, and I hope that sense of professionalism and service will spill over to TGE in general.
[/rant]
#14
Let me ask this (just for reference, not a dig!): How much of your code is fully documented using doxygen comment criteria? The answer for me is "none". If the coder doesn't do it from the beginning, that means that someone else has to go back and analyse, and then doxygen comment everything--and that takes precious resources that could be coding elsewhere.
Perfect world, all coders would have doxygen formatted create comment macros in their IDE, and have the discipline to actually use them. Real world--none of us, and I do mean none of us do!
03/14/2005 (12:36 pm)
They are working on it guys, they are working on it!Let me ask this (just for reference, not a dig!): How much of your code is fully documented using doxygen comment criteria? The answer for me is "none". If the coder doesn't do it from the beginning, that means that someone else has to go back and analyse, and then doxygen comment everything--and that takes precious resources that could be coding elsewhere.
Perfect world, all coders would have doxygen formatted create comment macros in their IDE, and have the discipline to actually use them. Real world--none of us, and I do mean none of us do!
#15
It has been said, and I don't think it's an exaggeration, that to fully document every class would probably take 5 people 2 years and to do it so that it suits people of all different skill sets. Sounds about correct to me. At the moment T2D people haven't got access to everything either and that adds to the frustration but we are organising that.
I'm not making excuses because, like Harold, I've always found it easy to find the functions by going to the file and looking for "ConsoleMethod/Functions". Not the best way I agree.
As for the usage call, it actually works in the DEBUG build of the engine (and T2D). I put a consistently formatted comment in every T2D function and I know a majority of TGE functions do use it. In RELEASE mode, it is assumed that you would use this one to ship and it doesn't build those strings into the exe.
There is a huge amount of work going on now to address this issue by, don't forget, a handful of guys. All will be revealed in good time,
In the meantime, I'll just have to keep answering your questions as quick as I can. :)
- Melv.
03/14/2005 (12:37 pm)
I can understand the frustration and I'm truly sorry. The problem has been that GG are only a handful of people and if you saw the TGE documentation two years ago, you wouldn't believe it was the same engine now. This also goes for the engine comments themselves. It is simply an enormous job to document everything. For one thing that isn't, there really are 50 that are. If too much effort gets put into doco on this kind of timescale, no technology would get done. If all effort was put into technology then you wouldn't be seeing the huge amount of documentation that currently exists. It's a damn hard balance but it is moving forward and there's new stuff being worked on to address this issue.It has been said, and I don't think it's an exaggeration, that to fully document every class would probably take 5 people 2 years and to do it so that it suits people of all different skill sets. Sounds about correct to me. At the moment T2D people haven't got access to everything either and that adds to the frustration but we are organising that.
I'm not making excuses because, like Harold, I've always found it easy to find the functions by going to the file and looking for "ConsoleMethod/Functions". Not the best way I agree.
As for the usage call, it actually works in the DEBUG build of the engine (and T2D). I put a consistently formatted comment in every T2D function and I know a majority of TGE functions do use it. In RELEASE mode, it is assumed that you would use this one to ship and it doesn't build those strings into the exe.
There is a huge amount of work going on now to address this issue by, don't forget, a handful of guys. All will be revealed in good time,
In the meantime, I'll just have to keep answering your questions as quick as I can. :)
- Melv.
#16
@Melv: Kudos to you and Josh for your superhuman efforts. And the docs for T2D show what can be done in a short time. How many people wrote the docs provided with EA1? The reference doc alone is worth its virtual weight in gold. It can be done! :) (Thanks for the tip about the usage call in debug mode, I'll bear that in mind--and I apologize for that oversight. Knowing this should go a long way!)
Sorry to derail the thread!
03/14/2005 (1:53 pm)
@Stephen: GG have created a wonderful set of tools, and I love what they've done--otherwise I wouldn't have paid them! :) But documentation is a bit more serious with hundreds or thousands of other people relying on your code to ship games that they intend to sell. I don't want to be Oscar the Grouch, but it's business to me. Otherwise I have very few complaints. I love the Torque engine, and T2D especially.@Melv: Kudos to you and Josh for your superhuman efforts. And the docs for T2D show what can be done in a short time. How many people wrote the docs provided with EA1? The reference doc alone is worth its virtual weight in gold. It can be done! :) (Thanks for the tip about the usage call in debug mode, I'll bear that in mind--and I apologize for that oversight. Knowing this should go a long way!)
Sorry to derail the thread!
#17
03/14/2005 (1:59 pm)
Another apology for derailing, but maybe the biggest issue with the docs is the simple lack of organization and search facilities. It's just plain hard to find what you need to know. That would be my #1 suggestion for fixing the problem in a way that doesn't require 5 people and 2 years. :)
#18
Writing a simple tutorial for T2D and marshalling all of the TGE engine details are just two different task completely.
Hopefully though, new stuff in the pipeline will help to resolve some of these issues.
- Melv.
03/14/2005 (2:38 pm)
No problem, you're not asking for anything that hasn't been asked lots of times before.Writing a simple tutorial for T2D and marshalling all of the TGE engine details are just two different task completely.
Hopefully though, new stuff in the pipeline will help to resolve some of these issues.
- Melv.
#19
Things like the FileObject, TCPObject, HTTPObject, they just weren't documented well because frankly... no one used them. Their use in Tribes 2 was pretty much non-existant also.
03/14/2005 (3:57 pm)
One thing to remember... T2D was documented from the start. TGE was built as an In-House engine with minimal documentation, all the documentation available has been written from scratch with huge portions of it being written by people who did not write the origional code.Things like the FileObject, TCPObject, HTTPObject, they just weren't documented well because frankly... no one used them. Their use in Tribes 2 was pretty much non-existant also.
Torque Owner Harold "LabRat" Brown
echo($playerHP);