[T3D 1.1 Final] More script callback argument corruption (DECLARE_CALLBACK) - LOGGED (THREED-2100)
by Jeff Faust · in Torque 3D Professional · 07/01/2011 (6:57 am) · 4 replies
Build: T3D 1.1 Final (and possibly Preview)
Platform: Windows Vista and others
Target: Script callbacks (DECLARE_CALLBACK) with more than one Point3F arguments.
Issues:
For callbacks containing more than one Point3F argument, the output of one of the values will likely clobber the buffered output of another Point3F argument. In the scripting half of the callback, where the values are received, some of the Point3F arguments will be incorrect.
This bug is very similar to one posted previously here, however, this fix is already folded into T3D 1.1 Final, and although it did fix the problem in B3, a similar problem has returned in 1.1 Final.
Steps to Repeat:
Take an existing callback, add two Point3F args. Make the call happen with two different, recognizable values for the Point3F args. Add Point3F args to the corresponding call in script and echo the values. Do something to make the callback happen and examine the values output to the console.
For my test, I modified the "preProcess" callback for PostEffects. Modified LightRayPostFX::preProcess() to take Point3F args and echo them, and then enabled LightRays to force a call so I could see the values. Second value clobbered the first one.
Suggested Fix:
None yet.
Platform: Windows Vista and others
Target: Script callbacks (DECLARE_CALLBACK) with more than one Point3F arguments.
Issues:
For callbacks containing more than one Point3F argument, the output of one of the values will likely clobber the buffered output of another Point3F argument. In the scripting half of the callback, where the values are received, some of the Point3F arguments will be incorrect.
This bug is very similar to one posted previously here, however, this fix is already folded into T3D 1.1 Final, and although it did fix the problem in B3, a similar problem has returned in 1.1 Final.
Steps to Repeat:
Take an existing callback, add two Point3F args. Make the call happen with two different, recognizable values for the Point3F args. Add Point3F args to the corresponding call in script and echo the values. Do something to make the callback happen and examine the values output to the console.
For my test, I modified the "preProcess" callback for PostEffects. Modified LightRayPostFX::preProcess() to take Point3F args and echo them, and then enabled LightRays to force a call so I could see the values. Second value clobbered the first one.
Suggested Fix:
None yet.
About the author
Jeff Faust creates special effects indie middleware and games for Faust Logic. --- Blog: Effectronica.com --- Twitter: @FaustLogic
#2
for instance if I have the script:
GuiMouseEventCtrl::onMouseDown(%this, %modifier, %mousePoint, %mouseClick)
the modifier and mousePoint values are being stomped by mouseClick value.
07/09/2011 (4:48 am)
I was having issues with GuiMouseEventCtrl callbacks as well.for instance if I have the script:
GuiMouseEventCtrl::onMouseDown(%this, %modifier, %mousePoint, %mouseClick)
the modifier and mousePoint values are being stomped by mouseClick value.
#3
The old Con::executef() method of initiating callbacks still works (and is what I used to fix the projectile issue) but the new console API is certainly preferable.
07/09/2011 (10:27 pm)
I believe this also causes issues with the onCollision callback for projectiles (ProjectileData::onCollision(%data, %proj, %col, %fade, %pos, %normal). Last I checked, %pos was being overwritten by %normal. The old Con::executef() method of initiating callbacks still works (and is what I used to fix the projectile issue) but the new console API is certainly preferable.
#4
Notice that in my getReturnBuffer() I'm using mBuffer and not mArgBuffer, same difference for getArgBuffer(), and that they're both progressively allocating space. Now it is possible that mArgBuffer might not actually be the real stack argument buffer and mBuffer is (therefore my changes are backwards), but I swapped their usage based on the function names anyway to see what would happen.
stringStack.h badly needs to be reviewed and heavily documented as to what the hell is going on with it. Variable names need to match their usage, mBuffer and mArgBuffer definitely are not, etc... ;)
07/10/2011 (9:25 am)
Something still isn't quite right with getReturnBuffer() and getArgBuffer() methods to me at all. Here's what I did in my 1.1 beta 3 code, now I'm not absolutely sure this will solve it completely, but I haven't noticed any problems since I used this code for Engine/source/console/stringStack.h:char* getReturnBuffer(U32 size)
{
validateBufferSize(mStart + mFunctionOffset + size);
char *ret = mBuffer + mStart + mFunctionOffset;
mFunctionOffset += size;
return ret;
}
char *getArgBuffer(U32 size)
{
validateArgBufferSize(mStart + mFunctionOffset + size);
char *ret = mArgBuffer + mStart + mFunctionOffset;
mFunctionOffset += size;
return ret;
}Notice that in my getReturnBuffer() I'm using mBuffer and not mArgBuffer, same difference for getArgBuffer(), and that they're both progressively allocating space. Now it is possible that mArgBuffer might not actually be the real stack argument buffer and mBuffer is (therefore my changes are backwards), but I swapped their usage based on the function names anyway to see what would happen.
stringStack.h badly needs to be reviewed and heavily documented as to what the hell is going on with it. Variable names need to match their usage, mBuffer and mArgBuffer definitely are not, etc... ;)
Torque 3D Owner Christopher Tauscher
Default Studio