Engine hangs after a killing explosion [BUG1.1B1] - CONFIRMED
by Richard Marrevee · in Torque 3D Professional · 06/14/2010 (12:38 pm) · 13 replies
This is the situation:
I have implemented AISK 1.3 and the melee resource by Sean Rice in T3D1.1Beta. All works fine until I kill a bot with the exploding crossbow bolt or with the rocketlauncher.
After hitting the bot I hear the deathcry and I can see that the engine is creating the materials for the health patch which is tossed by the killed bot, but after that everything hangs and is there just 1 solution....
Edit:
If I hit a bot, but don't kill him, everythings fine. The same goes for hitting statics.
Tried to run a debug-version which seems to stay in a loop checking terrain::convex or something like that. I don't even know if this is the point where the crash starts.
If somebody has the same problems or anybody knows where to start searching, please help me.
Thanks in advance.
Edit 2: Cause and Solution
It seems that the cause of the crash was somewhere in the radiusDamage function in scripts/server/radiusdamage.cs. After a few test it was clear that applyImpulse(..) was causing the crash. Now the problem here is caused by 2 things.
1 - the damagelevel of the object hit by a projectile;
2 - the value of the applied impulse which can be found in the projectileData block and is called areaImpulse (it was set to 2000 in my datablock).
After a few test started with an areaImpulse value of 20 (which ran ok) I found out that the engine is not crashing but runs into some kind of delay, which took longer with higher values (a value of 1000 took a few seconds before everything continued). Maybe it is system dependent but I have set it to max 200 and everything runs fine.
I have implemented AISK 1.3 and the melee resource by Sean Rice in T3D1.1Beta. All works fine until I kill a bot with the exploding crossbow bolt or with the rocketlauncher.
After hitting the bot I hear the deathcry and I can see that the engine is creating the materials for the health patch which is tossed by the killed bot, but after that everything hangs and is there just 1 solution....
Edit:
If I hit a bot, but don't kill him, everythings fine. The same goes for hitting statics.
Tried to run a debug-version which seems to stay in a loop checking terrain::convex or something like that. I don't even know if this is the point where the crash starts.
If somebody has the same problems or anybody knows where to start searching, please help me.
Thanks in advance.
Edit 2: Cause and Solution
It seems that the cause of the crash was somewhere in the radiusDamage function in scripts/server/radiusdamage.cs. After a few test it was clear that applyImpulse(..) was causing the crash. Now the problem here is caused by 2 things.
1 - the damagelevel of the object hit by a projectile;
2 - the value of the applied impulse which can be found in the projectileData block and is called areaImpulse (it was set to 2000 in my datablock).
After a few test started with an areaImpulse value of 20 (which ran ok) I found out that the engine is not crashing but runs into some kind of delay, which took longer with higher values (a value of 1000 took a few seconds before everything continued). Maybe it is system dependent but I have set it to max 200 and everything runs fine.
About the author
Started programming in 1984 on an Oric, when time progressed switched to MSX, Amiga and finally the Windows PC with T3D. Now developing an epic fantasy game: The Master's Eye. Creator of the DoorClass pack and VolumetricFog pack @ richardsgamestudio.com
#2
In the meantime try commenting out the scheduled corpse delete in onDisabled() inside player.cs --- terrible hack, I know, but see if you get any joy with it.
06/14/2010 (5:09 pm)
There's also a death crash issue in the code based on how delete works - fixed for 1.1b2.In the meantime try commenting out the scheduled corpse delete in onDisabled() inside player.cs --- terrible hack, I know, but see if you get any joy with it.
#4
06/15/2010 (1:44 am)
Thanks guys, I will check all these things and see if it brings me any joy.
#5
06/15/2010 (12:38 pm)
See edit 2 above for cause and solution to this problem. 
#6
Try disabling the health & weapon drop upon death. In scripts/server/player.cs in function Armor::onDisabled() remove or comment the following:
I've been noticing a correlation between this type of impulse related hang/crash and dynamically created/added objects of Item class. Stock examples include this death toss functionality and also with weapons or ammo that are thrown in-game by player command (alt+w, alt+a).
Notes from my own observations: Excessively large impulses when applied to the Item Class will cause the game to hang. A 1:2000 ratio (mass to impulse) seems to be an approximate maximum (numbers could vary on different systems).... doesn't seem to matter for other classes. The larger the ratio the longer the "hang-time" with a potential crash if the impulse is too large. Impulses also seem to be ridiculously large, in comparison, as applied to the Item Class when the same mass/impulses are used with other object types.
06/15/2010 (2:11 pm)
Quote:
after a killing explosion
Try disabling the health & weapon drop upon death. In scripts/server/player.cs in function Armor::onDisabled() remove or comment the following:
// Toss current mounted weapon and ammo if any
%item = %obj.getMountedImage($WeaponSlot).item;
if (isObject(%item))
{
%amount = %obj.getInventory(%item.image.ammo);
if(%amount)
%obj.throw(%item.image.ammo, %amount);
%obj.throw(%item, 1);
}
// Toss out a health patch
%obj.tossPatch();I've been noticing a correlation between this type of impulse related hang/crash and dynamically created/added objects of Item class. Stock examples include this death toss functionality and also with weapons or ammo that are thrown in-game by player command (alt+w, alt+a).
Notes from my own observations: Excessively large impulses when applied to the Item Class will cause the game to hang. A 1:2000 ratio (mass to impulse) seems to be an approximate maximum (numbers could vary on different systems).... doesn't seem to matter for other classes. The larger the ratio the longer the "hang-time" with a potential crash if the impulse is too large. Impulses also seem to be ridiculously large, in comparison, as applied to the Item Class when the same mass/impulses are used with other object types.
#8
An impulse applied to a non-static item causes either framerate stuttering or crashes, depending on the impulse’s size.
And yes eb, it would be nice to have QA finally log this bug.
Personally I consider this to be the worst bug currently in T3D 1.0.1, and I already posted it in the high priority bug thread. If this isn't fixed by the final release of T3D 1.1, I'll probably have to disable item tossing on death in my kit to stop the game from crashing every time you get into a fire fight with the AI.
06/15/2010 (9:20 pm)
It seems like both of you (Richard and Michael) came to about the same conclusion that I did. Which is:An impulse applied to a non-static item causes either framerate stuttering or crashes, depending on the impulse’s size.
And yes eb, it would be nice to have QA finally log this bug.
Personally I consider this to be the worst bug currently in T3D 1.0.1, and I already posted it in the high priority bug thread. If this isn't fixed by the final release of T3D 1.1, I'll probably have to disable item tossing on death in my kit to stop the game from crashing every time you get into a fire fight with the AI.
#9
I was not able to link the impulse to the dynamically added items, so I don't know if this is related.
@Twisted:
Right now the tosspatch function is executed from
Maybe a work-around is to schedule to toss after a few seconds. Haven't try it, but the thought behind this is that these objects are not present in the world when the impulse is applied.
06/16/2010 (12:58 am)
@Micheal:I was not able to link the impulse to the dynamically added items, so I don't know if this is related.
@Twisted:
Right now the tosspatch function is executed from
function Armor::onDisabled(%this, %obj, %state)
{
...
%obj.tossPatch();
...
}in player.cs.Maybe a work-around is to schedule to toss after a few seconds. Haven't try it, but the thought behind this is that these objects are not present in the world when the impulse is applied.
#10
Good idea, a short delay before tossing items would be a good work around. Of course it would be preferable to just have the source of the bug fixed instead of needing to use a work around.
06/16/2010 (1:17 am)
@RichardGood idea, a short delay before tossing items would be a good work around. Of course it would be preferable to just have the source of the bug fixed instead of needing to use a work around.
#12
06/16/2010 (10:12 am)
Richard, please change the title of this thread from "[with cause and solution]" to "[BUG 1.1B1]"
#13
The problem is the Item class collision detection taking WAY too long when a large impulse is applied.
A very temporary workaround is to limit the size of the bounding box used by the Item during collision checking. Add this line to Item::updateWorkingCollisionSet
This will prevent the collision checking going insane and chewing up all the available CPU time. No guarantees that Items will bounce around correctly with this change, but it will work around the engine hang. A proper fix will be in beta 2.
06/16/2010 (4:19 pm)
QA may have missed this particular thread, but this bug has been logged (THREED-937).The problem is the Item class collision detection taking WAY too long when a large impulse is applied.
A very temporary workaround is to limit the size of the bounding box used by the Item during collision checking. Add this line to Item::updateWorkingCollisionSet
// it works ok. bool updateSet = false; newLen = 0.0f; // @hack: limit size of extruded collision box Box3F convexBox = mConvex.getBoundingBox(getTransform(), getScale());
This will prevent the collision checking going insane and chewing up all the available CPU time. No guarantees that Items will bounce around correctly with this change, but it will work around the engine hang. A proper fix will be in beta 2.
#14
Additionally, and this seems to correct the problem, you can add a "maxVelocity" field (set to something not outrageous, 15 for example) to your item datablocks to prevent their impulse velocities from getting out of control. By default they have no limitation on this which results in massive surplus physics/collision calculations taking place at high velocities.
08/12/2010 (10:12 pm)
This was still occurring despite the above fix.Additionally, and this seems to correct the problem, you can add a "maxVelocity" field (set to something not outrageous, 15 for example) to your item datablocks to prevent their impulse velocities from getting out of control. By default they have no limitation on this which results in massive surplus physics/collision calculations taking place at high velocities.
Torque 3D Owner JANR
See the second to last post here for an easy fix, if this is your issue:
http://www.torquepowered.com/community/forums/viewthread/76400