Game Development Community

Bug in TorqueScript, datablock declarations.

by Lukas Joergensen · in Torque 3D Professional · 12/27/2013 (8:59 am) · 3 replies

Hey guys! I just spent an hour pin-pointing this issue.
Apparently with my GraphEmitterData datablock, if I set ProgressMode = 0; it affects how other lines of the declaration behaves.
E.g.
datablock GraphEmitterData(FireballChannelEmitterBASE)
{
   ejectionPeriodMS = "10";
   periodVarianceMS = "0";
   ejectionVelocity = "0";
   velocityVariance = "0";
   ejectionOffset = "0.1";
   particles = FireballChannelParticle;
   blendStyle = "NORMAL";
   softParticles = "0";
   softnessDistance = "0.1";
   
   Grounded = true;
   Loop = "0";
   
   xFunc = "cos(t)*t*0.0015";
   yFunc = "sin(t)*t*0.0015";
   zFunc = "0";
   funcMax = "1600";
   timeScale = "10";
};
This works fine, Grounded is to true and everything is fine.

If I do this:
datablock GraphEmitterData(FireballChannelEmitterBASE)
{
   ejectionPeriodMS = "10";
   periodVarianceMS = "0";
   ejectionVelocity = "0";
   velocityVariance = "0";
   ejectionOffset = "0.1";
   particles = FireballChannelParticle;
   blendStyle = "NORMAL";
   softParticles = "0";
   softnessDistance = "0.1";
   
   Grounded = true;
   ProgressMode = "ParticleCount";
   Loop = "0";
   
   xFunc = "cos(t)*t*0.0015";
   yFunc = "sin(t)*t*0.0015";
   zFunc = "0";
   funcMax = "1600";
   timeScale = "10";
};

Grounded is set to false, no errors thrown, no warnings, nothing.
Apparently there is something wrong with the ProgressMode in general, since it doesn't get loaded at all, but why can one line of code, affect how another line gets executed?
And can we be sure this isn't the cause of other Script errors? Kindda undermines my believe in TS.. But I'll keep digging to try and establish the cause of the issue.

Pin-pointed issue can be found in comment #2

#1
12/27/2013 (9:04 am)
Oh wait, apparently it's just if there is any line between those lines..
This fails as well:
datablock GraphEmitterData(FireballChannelEmitterBASE)
{
   ejectionPeriodMS = "10";
   periodVarianceMS = "0";
   ejectionVelocity = "0";
   velocityVariance = "0";
   ejectionOffset = "0.1";
   particles = FireballChannelParticle;
   blendStyle = "NORMAL";
   softParticles = "0";
   softnessDistance = "0.1";
   
   Grounded = true;
   xFunc = "cos(t)*t*0.0015"; // moved this up here
   Loop = false;
   
   yFunc = "sin(t)*t*0.0015";
   zFunc = "0";
   funcMax = "1600";
   timeScale = "10";
   ProgressMode = "byTime";
};
*Flips table*
I don't even.. What?

Edit: apparently it's because of the ProgressMode = "byTime"; at the end still. Doesn't matter where it is, it conflicts with the Grounded bool.
#2
12/27/2013 (9:17 am)
Okay this is the specific cause of the issue:
If the ProgressMode field is marked as "dirty" or whatever... If the editor writes it into the datablock when you save it, it means it conflicts with the Grounded field and then Grounded = true; is disregarded.

ProgressMode is exposed like this:

addField( "ProgressMode", TYPEID< GraphEmitter::EnumProgressMode >(), Offset(ProgressMode, GraphEmitterData),
		"String value that controls how the t value is increased." );

Grounded like this:
addField( "grounded", TypeBool, Offset(mGrounded, GraphEmitterData),
		"Emit particles along the terrain rather than at the nodes position." );

And EnumProgressMode is defined like this:
typedef GraphEmitter::EnumProgressMode gProgressMode;
DefineEnumType( gProgressMode );

ImplementEnumType( gProgressMode,
				  "The way the t value of the graphEmitter is increased.n"
				  "@ingroup FXnn")
{ GraphEmitter::byParticleCount,				"ParticleCount",	"Increase t value when a new particle is emitted.n" },
{ GraphEmitter::byTime,							"ByTime",			"Increase t value with time.n" },
EndImplementEnumType;

Any ideas as to why they might conflict?

#3
12/27/2013 (10:44 am)
Thanks to Aswin and Michael for helping me figure out the solution!
It was because of a mismatch between the C++-type and the TorqueScript type, basically making ProgressMode override the "Grounded" bit because it wrote too far.