Game Development Community

Assertions in torquescript?

by Alex Rice · in Torque Game Builder · 10/23/2005 (3:50 pm) · 10 replies

I see that in the C++ engine code, assertions are used extensively (keyword "assert" appearing in the T2D code nearly 1,000 times.).

In torquescript, what is the best way to use assertions, since there is no builtin console function for this purpose?

#1
10/23/2005 (4:14 pm)
As far as I know, there aren't any assert functions exposed to script. You can get away with it by using ifs and echoes, but it's not as neatly a packaged deal as asserts.

--
Hans
#2
10/24/2005 (5:52 am)
I added a script assertion in the T2D utility function group that only works in debug builds. Currently, there's no way to get at the originating script line/function from the "ConsoleFunction" macro else I would've exposed that info but you can enter your own condition and a failing message as you would expect.

Here it is if you're interested:

//-----------------------------------------------------------------------------
// Assert Fatal.
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssert, void, 3, 3, "(condition, message) - Fatal Script Assertion" )
{
    // Process Assertion.
    AssertFatal(  dAtob(argv[1]), argv[2] );
}

Used as...

function doSomething(%count)
{
  t2dAssert( %count > 0, "doSomething() - Invalid Count!" );
}


EDIT: I was thinking of adding something like a "t2dAssertISV" which worked in release builds (same as C++ AssertISV call - In-shipping version) as well but this will be there in your final products which isn't necessarily the best way to go but it isn't the worst either. ;)


- Melv.
#3
10/24/2005 (6:05 am)
Okay, I just added an additional "t2dAssertISV" call as well.

- Melv.
#4
10/24/2005 (6:12 am)
Thanks Melv I am going to start using that.
#5
10/24/2005 (6:50 am)
No probs. Here are both functions but again, be careful with the ISV one as it'll always be there in your code, even in release.

//-----------------------------------------------------------------------------
// Assert Fatal.
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssert, void, 3, 3, "(condition, message) - Fatal Script Assertion" )
{
    // Process Assertion.
    AssertFatal( dAtob(argv[1]), argv[2] );
}


//-----------------------------------------------------------------------------
// Assert Fatal ISV (In Shipping Version).
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssertISV, void, 3, 3, "(condition, message) - Fatal ISV Script Assertion" )
{
    // Process Assertion.
    AssertISV( dAtob(argv[1]), argv[2] );
}

- Melv.
#6
07/03/2006 (9:20 pm)
Thanks for adding these Melv. When using t2dAssert() in a RELEASE build of TGB, I was wondering if it's "free" or is there a runtime cost in script with creating the string object for the message parameter when the call to t2dAssert() is encountered? I know that in RELEASE the t2dAssert is a noop.
#7
07/03/2006 (9:39 pm)
I just noticed the condition is evaluated in RELEASE as well as DEBUG. I guess I will stick with my script-only assertion function, and just comment out the function calls before relase.
#8
07/04/2006 (9:17 am)
At some point real assertions in TorqueScript need to be worked out... especially with the amount of script being written with TGB.

The quick solution is to treat assert as a special function name at the script parser level. When encountered in a release build the function and all parameters are ignored and would not generate opcodes. If this is done assert would work as one would expect and have zero overhead with DSOs from release builds.

The better solution is to implement a simplified macro system into TorqueScript, but this may be a big task and possibly be as troublesome as it is in C/C++.
#9
07/04/2006 (2:41 pm)
I second the preprocesor system:

Only the basic:

#define
#undef
#ifdef
#else
#endif

with those we can code scripts for testing purpouses that are
ignored if we want with only one line, comment don't do it here
because the code could spread along all the project.
#10
07/05/2006 (12:42 am)
NAY to C style macros
YAY to Tom's idea !
Quote:treat assert as a special function name at the script parser level. When encountered in a release build the function and all parameters are ignored and would not generate opcodes.