Lockup when you hit terrain from high above
by Danner Jones · in General Discussion · 06/19/2004 (11:37 pm) · 9 replies
I was experiencing some "random" crashing/lockups but I think I've gotten it narrowed down. While I could go into debug mode and walk through code, I wanted to first see if anyone else has seen this problem.
First, I'm using a clean download of RW from CVS. I've also had this problem with the latest download from realmwarsgame.com (the full "game").
To replicate:
Start any mission (I choose all the defaults) and press F8 to enter "camera mode". Go high above the terrain (maybe 3 or 4 times the height you can jump - maybe more or less). Press F11 twice (just so that pressing F7 next will work). Then press F7 to "drop player at camera".
The player will drop and when it hits the ground, the game "locks up". It appears to be stuck in some kind of loop, though I haven't had time to investigate beyond this point.
When I wake up, I'll try using VS to find the problem. If it's an infinite loop (more or less) it should be easy to find.
-ner
First, I'm using a clean download of RW from CVS. I've also had this problem with the latest download from realmwarsgame.com (the full "game").
To replicate:
Start any mission (I choose all the defaults) and press F8 to enter "camera mode". Go high above the terrain (maybe 3 or 4 times the height you can jump - maybe more or less). Press F11 twice (just so that pressing F7 next will work). Then press F7 to "drop player at camera".
The player will drop and when it hits the ground, the game "locks up". It appears to be stuck in some kind of loop, though I haven't had time to investigate beyond this point.
When I wake up, I'll try using VS to find the problem. If it's an infinite loop (more or less) it should be easy to find.
-ner
#2
The first pass at debugging shows some kind of problem with the netmaskbits, according to the error message (I finally had some time to compile and test in Debug mode of VS). I'm not that familiar with the engine, but I'll do some digging.
If this is a problem with the engine (as opposed to scripts), I'd imagine RW would be unplayable right now. I was mostly feeling around to see if I alone was having this problem or if others are seeing it happen.
-nerseus
06/20/2004 (7:38 pm)
I know what you mean about vehicles, but this happens easily with non-vehicles. In fact, you don't have to hover high over land to do it - you can just jump off a small hill and when you "land" it will freeze up.The first pass at debugging shows some kind of problem with the netmaskbits, according to the error message (I finally had some time to compile and test in Debug mode of VS). I'm not that familiar with the engine, but I'll do some digging.
If this is a problem with the engine (as opposed to scripts), I'd imagine RW would be unplayable right now. I was mostly feeling around to see if I alone was having this problem or if others are seeing it happen.
-nerseus
#3
In player.h the MaskBits defines a value for ImpactMask but it's set to a value too large for the enum and it wraps around to 0 (zero). A platform assert catches it. Luckily it was only being used in one place, to send an update in packUpdate when the player hit the ground too hard.
My simple workaround was to introduce a new bool field in the Player class and use that in packUpdate in place of the MaskBits. I'm not sure what "built in" features MaskBits may provide but the bool value seems to work just fine. You have to manually set it back to false in packUpdate and it's a *whole byte* of memory (maybe DWORD) for the bool, versus 1 bit in the enum. I can't imagine that, for the player object, that makes any difference.
-nerseus
06/20/2004 (8:10 pm)
Ok, problem found (luckily it wasn't that hard - I'm a mediocre C++ developer).In player.h the MaskBits defines a value for ImpactMask but it's set to a value too large for the enum and it wraps around to 0 (zero). A platform assert catches it. Luckily it was only being used in one place, to send an update in packUpdate when the player hit the ground too hard.
My simple workaround was to introduce a new bool field in the Player class and use that in packUpdate in place of the MaskBits. I'm not sure what "built in" features MaskBits may provide but the bool value seems to work just fine. You have to manually set it back to false in packUpdate and it's a *whole byte* of memory (maybe DWORD) for the bool, versus 1 bit in the enum. I can't imagine that, for the player object, that makes any difference.
-nerseus
#4
So I guess this is something that needs to go on the GG todo list, provided it happens in stock TGE.
06/20/2004 (10:33 pm)
The problem with that is that the updateMasks are assumed to work in certain ways, specifically, that all the information about updates are stored in it. The NetObject docs should go into this in some detail.So I guess this is something that needs to go on the GG todo list, provided it happens in stock TGE.
#5
Unless we're going over the enum value because we've got too many masks in Realmwars.
But its likely to happen to other people if thats the case. Maybe a guard for this in the general case is a good idea.
06/20/2004 (10:46 pm)
I doubt its anything special in RW there Ben, so its likely in TGE too. Although Ive never come across it in either.Unless we're going over the enum value because we've got too many masks in Realmwars.
But its likely to happen to other people if thats the case. Maybe a guard for this in the general case is a good idea.
#6
06/21/2004 (5:14 am)
This doesn't happen in stock Torque - there are extra flags in some of the base classes in RealmWars (ShapeBase for one). I didn't look too far up the chain once I saw that RW used extra flags.
#7
06/21/2004 (8:06 am)
Aw, lame.
#8
07/20/2004 (11:54 am)
I have the same prob, can you please post up what you had done to fix this?
#9
07/20/2004 (12:02 pm)
Thats strange.. extra flags.. hmm.. wonder what for :) 
Torque Owner Thomas Glennow