NULL ghost and Out of Range Read asserts
by Andy Schatz · in Technical Issues · 02/23/2005 (5:38 pm) · 3 replies
I am hitting the following assert in netGhost.cc:
AssertFatal(mLocalGhosts[index] != NULL, "Error, NULL ghost encountered.");
I also quite often get this assert in BitStream::readFlag():
AssertFatal(false, "Out of range read");
This second assert implies that my read/write packet functions are out of synch, but I've quadruple checked them and they appear to be fine. However, I do seem to remember that I started getting some of these problems when I changed the entries in RTSUnit::MaskBits (I added one and deleted two).
I am modfying the RTS pack. I've made a fair number of changes to the RTSUnit, RTSCamera, fxShapeReplicator, fxFoliageReplicator, and various scripts. I hit these asserts after spawning in a fair number of units, like around 20-40. It appears to be inconsistent in its behavior.
It appears to me that what is happening with the first assert is that I am trying to delete a unit before its ghost has been created, but this seems odd and would be more rare than what I have seen. My game is running single player as a stand-alone server.
Secondly, I have seen occassional odd behaviors, such as my units showing up as a barely-visible white phantom, or my units not displaying at all, despite the fact that they are selectable. This happens quite rarely. Once I even saw one of my units displayed as what we used to call a nut-cluster (the verts were completely screwed up so it rendered as a spazzy series of polies in front of everything.
I have a vague feeling that I am overrunning memory somewhere since I am also occassionally getting crashes in terrain rendering.
So to sum it up, can someone help me out? I'm tired of curling up in a corner and screaming at the top of my lungs. Or just send me a case of beer. I hear that helps to make one feel better about program instability, even if it doesn't fix it.
Thanks,
Andy Schatz
AssertFatal(mLocalGhosts[index] != NULL, "Error, NULL ghost encountered.");
I also quite often get this assert in BitStream::readFlag():
AssertFatal(false, "Out of range read");
This second assert implies that my read/write packet functions are out of synch, but I've quadruple checked them and they appear to be fine. However, I do seem to remember that I started getting some of these problems when I changed the entries in RTSUnit::MaskBits (I added one and deleted two).
I am modfying the RTS pack. I've made a fair number of changes to the RTSUnit, RTSCamera, fxShapeReplicator, fxFoliageReplicator, and various scripts. I hit these asserts after spawning in a fair number of units, like around 20-40. It appears to be inconsistent in its behavior.
It appears to me that what is happening with the first assert is that I am trying to delete a unit before its ghost has been created, but this seems odd and would be more rare than what I have seen. My game is running single player as a stand-alone server.
Secondly, I have seen occassional odd behaviors, such as my units showing up as a barely-visible white phantom, or my units not displaying at all, despite the fact that they are selectable. This happens quite rarely. Once I even saw one of my units displayed as what we used to call a nut-cluster (the verts were completely screwed up so it rendered as a spazzy series of polies in front of everything.
I have a vague feeling that I am overrunning memory somewhere since I am also occassionally getting crashes in terrain rendering.
So to sum it up, can someone help me out? I'm tired of curling up in a corner and screaming at the top of my lungs. Or just send me a case of beer. I hear that helps to make one feel better about program instability, even if it doesn't fix it.
Thanks,
Andy Schatz
#2
Out of range reads normally means that you've exceeded the number of allowable changes in a pack/unpack--in other words, IIRC, your resulting packet woud be greater than (I think?) 1500 bytes. Not really sure how to change the limit (or even if you should), but normally it just means that you are packing too much data that really isn't needed, or not optimized your bits used in the updates.
03/21/2005 (1:01 pm)
Good to hear--not sure how I missed this one to be honest :(Out of range reads normally means that you've exceeded the number of allowable changes in a pack/unpack--in other words, IIRC, your resulting packet woud be greater than (I think?) 1500 bytes. Not really sure how to change the limit (or even if you should), but normally it just means that you are packing too much data that really isn't needed, or not optimized your bits used in the updates.
#3
08/31/2005 (12:16 pm)
I just got this out of range read issue, I've poked around in the forums, and found this. All I did was build the base torque, and try to connect to the starter.fps master server. It started to download, what appeared to be a huge jpg file for the player, and then puked this message up. I have not changed anything, other than revert the lightning.png files back to version 2.1, because the 2.2 versions were corrupted. Any help on this issue would be great. 
Torque 3D Owner Andy Schatz