Game Development Community

Bug when trying to change the field liftime in projectiledata

by Bill Vee · in Plastic Tweaker · 10/09/2010 (4:05 am) · 3 replies

I was happy to purchase Plastic tweaker to help me with my game and the very first field I wanted to change appears to have some bug when trying to validate the range of the values using the slide control or editing it in the text box.

Here is how you replicate the error.

I used TGEA 1.8.2 fresh install.
I installed Plastic Tweaker per the install instructions, adding the 2 lines of code to the 2 cs files and added the ConsoleFunction pathCopy outside of the #ifdef TORQUE_TOOLS Block and commented out the original , rebuilt the stronghold project and then ran the stronghold.exe.
I loaded the barebones mission then pressed control+T to bring up the Tweaker gui then selected new from the file menu then selected projectiledata for the type dropdown then selected crossbowprojectile for the name then clicked OK.
The tweak page for the crossbowprojectile is then displayed then I try to edit the lifetime field and I get these odd results.

First buy default the slider will only change it between 0 and 127.
If I go into the properties for this field and manually change the range to 0 10000 the slider will max out to 312.
The exact same thing will happen to the fadedelay field as well.

Here is a video of the bug.


Now I normally would just settle down and just debug the code myself to try and find the problem.
But after 3 hours of going over the code I realized I just lost 3 hours of my time debugging code that was suppose to save me time building my game.
So I drop it here and hope someone can fix it.
NextNext Thread
PrevPrevious Thread
More from Plastic Tweaker


Torque Owner Bill Vee
DayOfWar Studios
#1
10/09/2010 (4:21 pm)
Found the problem.
It is not a problem with the Plastic Tweaker code.

It is a problem with the way the source code sets up the fields in initPersistFields for TGEA 1.8.2

It was setup like this
addNamedFieldV(lifetime, TypeS32, ProjectileData, new IRangeValidatorScaled(TickMs, 0, Projectile::MaxLivingTicks));
   addNamedFieldV(armingDelay, TypeS32, ProjectileData, new IRangeValidatorScaled(TickMs, 0, Projectile::MaxLivingTicks));
   addNamedFieldV(fadeDelay, TypeS32, ProjectileData,  new IRangeValidatorScaled(TickMs, 0, Projectile::MaxLivingTicks));
I changed it to this
addNamedFieldV(lifetime, TypeS32, ProjectileData,new FRangeValidator(0, 120000));
   addNamedFieldV(armingDelay, TypeS32, ProjectileData,new FRangeValidator(0, 120000));
   addNamedFieldV(fadeDelay, TypeS32, ProjectileData,new FRangeValidator(0, 120000));

Recompiled and tested it and it works fine now.

There was a source code change in projectile::packdata that avoided the whole Projectile::MaxLivingTicks limitation and Projectile::initPersistFields should have been change to reflect this but was not.

Torque Owner Bill Vee
DayOfWar Studios
#2
10/09/2010 (4:55 pm)
I may have posted too soon.
While the above code will fix the problem with Plastic Tweaker it may not be the correct solution to the problem.

I thought that the field "lifetime" was in milliseconds but appears to actually be the total number of allowed ticks for the projectile.

So since ticks happen every 32ms , a value of 100 set to lifetime will result in and actual lifetime of 32ms times 100 or 3200 or about 3.2 seconds.

As I have been told that Plastic Tweaker works fine for Torque3D I wonder if anyone can tell me how the initPersistFields is setup for the projectiledata class that makes it work correctly

Torque Owner Bill Vee
DayOfWar Studios
#3
10/10/2010 (1:39 am)
What is going on is rather odd.
As mentioned before initPersistFields is setting the internal value of lifetime to a value that is scaled to a value compatible for use with the processtick, in other words it is taking the value set by lifetime in the datablock then dividing it by 32 to get the total number of ticks it would take for the lifetime of the projectile.

Now why GG decided to alter the value directly instead of doing something simple like

if (isServerObject() && mCurrTick >= (mDataBlock->lifetime / TickMs))

instead of

[psudo code]
lifetime = lifetime / TickMs
if (isServerObject() && mCurrTick >= mDataBlock->lifetime)

is beyond me.

I suppose they had a reason.

I have a simple solution that appears to retain the datablocks intent of it being a time in milliseconds and satisfies the processtick requirement that it is the total number of ticks.

Along with the code from before about the changes to initPersistFields add these changes.

In the projectile class

find
if (isServerObject() && mCurrTick >= mDataBlock->lifetime)
and change to
if (isServerObject() && mCurrTick >= (mDataBlock->lifetime / TickMs))

then find
if(time > mDataBlock->fadeDelay)
and change to
if(time > (mDataBlock->fadeDelay / TickMs))

find
if(time > mDataBlock->fadeDelay)
   {
      F32 fade = F32(time - mDataBlock->fadeDelay);
      mFadeValue = 1.0 - (fade / F32(mDataBlock->lifetime));
   }

and change it to

if(time > (mDataBlock->fadeDelay / TickMs))
   {
      F32 fade = F32(time - (mDataBlock->fadeDelay/ TickMs));
      mFadeValue = 1.0 - (fade / F32(mDataBlock->lifetime/ TickMs));
   }

This appears to satisfy all existing datablocks and Plastic Tweaker.

As for Torque3D I have been told that it has addition methods to ensure the data is converted both ways.