Fatal: bitstream.cc@194 error on debug only?

#1 When I get those errors (many many many times over the years :)), it's almost always due to using too many bitmasks. With a few in gamebase, a few more in shapebase, and a handful in player, etc, its a bit tough to remember when you're over the 32bit limit.

#2 Thanks Eric, but I now get this error with a FRESH install. Is the problem in a memory cache? somewhere?

I deleted my engine files and replaced them with fresh ones, and it still occurs.

Thanks,

Tony

#3 Don't take offense, but are you _sure_ you're running the executable you think you are ?
that error simply shouldn't happen w/ a fresh install.

#4 This can happen when you have too much data in a datablock (like too many sequences in a player).

#5 Good point.

#6 @Orion, no offense at all. I make stupid mistakes all the time.

But yes, I'm sure, I open the NEW torque.sln, build, and hit the green triangle to debug, and get the same error.

@Jaimi, I haven't added anything, all fresh install engine files. I'll try uninstalling torque completely, and do another fresh install...

Thanks,
Tony

#7 One thing i do to make sure i'm running what i think i'm running is to throw in a print statement.
ie, if you change that particular error print, you should see the change in the log of the run.

#8 Run the application under the debugger. It will stop when you get that exception. Look at the variables it is trying to pack into the bitstream, it should give you a clue as to what is wrong. It may stop on a hard breakpoint - if so, you will need to walk back down the call stack to find the function that is doing the packing. This overflow is caused by the bitstream being too large for your network packets. Something has changed in your .CS files that has caused the problem - not your Exe.

#9 Well, I deleted all Torque folders and files from my computer, and then copied my backup folder from CD back to harddrive. I open the solution, and click debug. I click Start Mission, then Launch Mission, and it gives the same "Out of range write" error. This happens during the LOADING DATABLOCKS stage.

I still don't get it, because this use to work before my changes to player.cc, but now I'm using the old version of player.cc that used to work fine.

I cancel debugging, and the Output window lists several .dll's loaded, but "No symbols loaded."

The entire output text is about loading and unloading .dll's.

And the last line of the console.log is

"Error: shape starter.fps/data/shapes/crossbow/ammo.dts-collision detail 2 (Collision-3) bounds box invalid!"

But that's always been that way.

I'll keep trying.

Tony

#10 Did you clean the project to get rid of any cached crud that might be mucking up the system? I don't recall if I've seen this error from munged builds, but I know I've torn my hair out debugging things that a clean fixed in the past.

#11 Thanks David, I think I did that, but I'll try it again.

Update:
Sorry, but it didn't work. I did a Clean Solution, and Rebuild Solution. No errors on compiling, but my debug still brings up the same Fatal bitstream error.

I can still run the TorqueDemo.exe without problems, but the debugger in VC++ triggers the error.

Tony

#12 Are you sure you are running all of the stock .cs files - you haven't tweaked the packet size, or modified any datablocks before backing up?

#13 Yep. I just did a fresh install, and it gives the same bitstream Fatal Assert error. That's why I thought there must be something in memory somewhere.

I'll try to uninstall Torque completely and try again.

Tony

#14 Boy, frustrating. tony, it really sounds like you're somehow running the old executable.
another thing to try is copying the freshly-built executable into the freshly-installed application folder and try it there. you also mention you're not re-installing, but using a backup folder. maybe try re-installing ?

#15 I did an uninstall, cold reboot, and a fresh install. and its building now. I'll let you know.


UPDATE:
OK, I went to lunch, build finished without errors while I was gone. Changed the working directory so it could fine main.cs, started the debugger, and it loaded the tutorial.base demo without error.

Closed the demo, changed "tutorial.base" in main.cs to "starter.fps", saved, and started the debugger again. It didn't error on LOADING DATABLOCKS (yay!) but I think it stalled on LIGHTING MISSION... The console says "Lighting interior object 3 of 11 (starter.fps/data/interiors/to" and that's as much as I can read.

I'll give it a few more minutes.

At least there is no Fatal Assert. I'll try with my backup again, and if it errors, then obviously its me.

Thanks for all your help guys!

Tony

#16 Lighting works. I just forgot how long it takes the first time.

Tony

#17 OK, Jaimi is right, it must be a scripting problem. I copied my server, data, and client folders from my backup over the fresh install, making NO engine changes at all, and the debug threw the Fatal Assert error.

Now I have to figure out which script is doing it.

Update: Its not missions or shapes. Both folders copied to a fresh install and debugged without error.

Tony

#18 Found it! Its Player.cs

In Player.cs I was loading the animations twice.

I had ./data/shapes/player/player.cs
and I had also renamed it playerAnim.cs, but I had forgotten to change the exec.

As far as I can tell, that was it. When I removed the duplicate exec line, it works. No more Fatal Error. Don't know why it started showing up now, but I'm sure it was MY fault and not the resources.

UPDATE: That WASN'T it...

Its back. I'm sure its player.cs, because the stock file works, but MY version draws the error. I was able to run debug once without the error, then it started again.

Back to trial and error.

UPDATE: Still not sure what it was, but I replaced the error prone player.cs with a fresh stock version of player.cs. Then I went in and made some changes to try to get it as close to my old version as possible without hitting the Error.

So after two weeks of trying, I think I'm finally back where I started. I'm starting to see the appeal of using an SVN, even as an individual.

Thanks everyone for your help!

Tony

#19 Just an update-

Well, I think Orion was right. I MUST have been running an old .sln That's all I can think of. I did a complete uninstall of Torque 1.5.2, deleted all traces of it, and uninstalled/deleted VC++, did a cold boot, defragged my harddrive, another cold boot, ran a virus scan, again cold boot, cleaned the registry, cold boot, reinstalled VC++, cold boot, reinstalled a fresh download of TGE1.5.2, cold boot, reconfigured VC++ to work with Torque (debug working directory = ../example), loaded the new .sln, did a fresh build, ran the Stronghold mission (waited 20 minutes for lighting to complete) and there was NO indication of an "out of range write" bitsream error, therefore, IT WAS SOMETHING I MUST HAVE DONE WRONG!!!!

I'm a doofus, and I have basically NO C++ experience other that what I've learned from the Torque resources, so I'm sure it was all my fault.

I'm going back and trying to redo things one step at a time, and if I can recreate the error, I should know exactly what causes it. If I CAN'T recreate the error, then Halleluja!

I need to start taking my own advice and BackUp more often. At least once a day, preferably after each edit has been tested thoroughly.

Thanks again to everyone for all their help and suggestions. I wish I could explain what happened.

Tony

#20 good to hear this is hopefully working out, thanks for the update.