Game Development Community

Client-side warnings for ParticleData and ExplosionData

by John Cooney · in Torque Game Engine · 04/12/2005 (1:44 pm) · 5 replies

I'm encountering some warning messages in my console log that only occur during mission load client-side in network play, such as:

ParticleData((null)) times[2] < times[1]
ParticleData((null)) lifetimeVariance >= lifetime
ParticleData((null)) lifetime < 1 ms
ExplosionData((null)) lifetimeMS < 1

Since obviously this wasn't telling me which explosion or particle these were, I ran the game in a debugger with a breakpoint on the line in the engine that prints these messages. Examining the data at this point gave me no clues as to which particles or explosions these were. The only identifiable data was that of a texture name. I found all of the particles that used these textures, but the various data items such as the times and other properties did not match to any that I had defined.

The backtrace at this breakpoint seems to indicate this is happening on the unpacking of a network packet and then creating data from that:

#0 ParticleData::loadParameters (this=0x407b4c18) at game/fx/particleEngine.cc:646
#1 0x081d39ab in ParticleData::onAdd (this=0x407b4c18) at game/fx/particleEngine.cc:593
#2 0x08092504 in SimObject::registerObject (this=0x407b4c18) at console/simManager.cc:340
#3 0x08092865 in SimObject::registerObject (this=0x407b4c18, id=114) at console/simManager.cc:436
#4 0x0815bd66 in SimDataBlockEvent::process (this=0x40772478, cptr=0x4074ba38) at game/gameConnectionEvents.cc:168
#5 0x08289fd8 in NetConnection::eventReadPacket (this=0x4074ba38, bstream=0xbfffee10) at sim/netEvent.cc:331

[rest snipped]

As I would like to have all warnings and errors removed from gameplay, or at least have a better understanding of them, what could these errors be coming from?

#1
04/12/2005 (11:10 pm)
It looks like maybe a time or lifetime value is too low... Maybe you're specifying very large values that are wrapping around somehow? Given these errors aren't occuring server side, it must be an issue in transmission (which is why you are having a hard time figuring out which is which - almost all the identifying info is on the server).

You can figure out which is which by checking the ID number of the datablock - datablock IDs are the same on client and server (the only such objects for which this is the case). That will help you identify the originating datablock.
#2
04/13/2005 (12:23 pm)
Okay, that was helpful, and I've narrowed it down to the cases that are the issues. I'd like direction on at least one of them. For example, here is one of my ExplosionData datablocks:

datablock ExplosionData(Gib0Explosion)
{
   // Exploding spark debris
   lifeTimeMS = 1;
   debris = Gib0Debris;
   debrisThetaMin = 0;
   debrisThetaMax = 180;
   debrisPhiMin = 0;
   debrisPhiMax = 0;
   debrisNum = 1;
   debrisNumVariance = 0;
   debrisVelocity = 20;
   debrisVelocityVariance = 5;
};

That is the original datablock. This is one of the ones that it is complaining the lifeTimeMS < 1. It will continue to exhibit this problem until the lifeTimeMS is 32. Change it to 31, and somehow lifeTimeMS gets set to 0.

If the code is actually setting the lifeTimeMS to 1 at the point of this error message, why would it not allow me to set it to such myself? Is there a problem somewhere else?
#3
04/13/2005 (2:49 pm)
Because the data is sent over the network at, potentially, a lower resolution than a full floating point number. 1ms is pretty short, couldn't you get by with a 32ms delay?
#4
04/13/2005 (3:18 pm)
As Benjamin says, the problem here lies in the fact that your lifetime values is too small. To minimize how much data is being sent, Torque sends (lifetimeMS >> 5) instead of (lifetimeMS) over the network. So I'd guess that anything smaller than 32ms will end up giving you errors.
#5
04/13/2005 (7:43 pm)
Ah, there we are! :)

Most things under 32ms are (a) almost unnoticeable to the human eye, especially if the game isn't running at > 40fps, and (b) reaching into the realm where Torque's update loops may not deal with it nicely.