RC1 - datablocks.cs seems to get munged sometimes..

#1 When this happens, is the datablocks.cs file completely empty? Or does it have something like $managedDatablockSet = new SimSet() { }; in it?

I have never reproduced this so any more information anyone could give would be great. Things like approximate number of datablocks you had, whether the engine crashed at any time, or any console spam during startup or shutdown.

#2 I've seen it reset like $managedDatablockSet = new SimSet() { }; But that was early on like in B2.

It seems as if the file gets completely truncated now in RC1, so all sorts of weird stuff happens when $managedDataBlockSet isn't initialized.

This has always occured during a crash for me, but a few other forum posts suggest it happened to thme after clearing their DSO's, I haven't been able to duplicate that. I've asked in the other forum posts, for the people experiencing the same problem to post up their experience also.

The datablocks were not very large, standard T2D resources with a few of my own sprites thrown in.

I wish I had more information sorry, I just decided to post this after the last few days, I've noticed a few new posts on the forums suggesting it was happening to more people than just me, and since i couldn't duplicate it, I never posted it.

#3 A few links to other posts as I find them again...

www.garagegames.com/mg/forums/result.thread.php?qt=45453

www.garagegames.com/mg/forums/result.thread.php?qt=45371

#4 I have been attempting to recreate the issue with no success. I don't know if clearing the dso's was a cause or not, however i do know that datablocks.cs was completely blank. I will continue to try to recreate the bug and get back to you

#5 I could be wrong, but I may I have seen this happen when a sprite has the same name as the underlying image datablock. There is a namespace conflict going on that is a known issue I think. But just a guess...

Alex

#6 @alex, that might be the case under some scenarios, but I'm sure my names were all distict. I basically did something stupid in script , and ran dsprintf's buffer out, and crashed the engine. On subsequent reload, datablocks.cs was hosed , in my example. Although others having a similar problem could be related to resource naming.

#7 Ah, writing some self modifying script-code eh? Just kidding. Good thing you are running CVS though to backup your datablocks.cs

#8 All my Script is self modifying :-) Yeah I learned about revision control the hard way early on in my career. Even my checkbook is under revision control :-)

#9 Alright, neither me or Justin were able to repro this, but we cleaned up some stuff anyway that may have been causing this. Of course, that means we aren't entirely positive the bug is fixed - and this is rather major. If it happens to anyone with RC2, please let us know with as much info on the circumstances as you can give. Console logs would be awesome. Thanks.

#10 Thats all we can ask for adam, a good effort :-) Like I said, its so intermittant, and depending upon what the user breaks that crashes TGB, could be causing it as well. Although I tread fairly safely usually.

If I notice any more trouble with it, I'll zip up the entire project without going further and ship off to you via email, it might shed some light for you guys.

#11 As I reported in this thread (http://www.garagegames.com/mg/forums/result.thread.php?qt=45658), my datablocks.cs has been wiped twice since upgrading to RC2.

I wasn't paying attention the first time when it happened. The second time, I selected an option from my menu menu that calls "quit();" The game seemed to exit normally, but when I ran the game again, the datablocks.cs file was empty.

If it happens again, I'll take a look at the console log.

#12 Patrick,
If you could provide me with your current games directory (minus the EXE's unless you've modified them) it would be a great help to me and hopefully help me verify that the problem is resolved if i can manage to reproduce it using your scripts. We have been trying like crazy to reproduce this bug so any information you could provide would be great. For example, what OS are you using? This could entirely be something that could affect where the bug (if any) originates.

Best Regards,

-Justin

#13 Justin,
Let me check with my boss before sending our scripts. Additional details:
* I am using windows xp, sp2.
* I run the game through the debugger in Codeweaver.
* I run the game both with and without the level editor, and had one wipe in each.

#14 Patrick,

Have you been able to reproduce this error again? Also, I'm curious about the following.

* Are you directly editing any files in your [yourGameName]/managed directory?
* Have you tried using Torsion instead of CodeWeaver? CodeWeaver has been reported to cause data loss in script files for many users, even in our internal testing.


Cheers,
-Justin

#15 Justin,

I just had this problem occur today. I am running the Windows version of RC2 and I use vim to edit my scripts. I "built" my project yesterday-ish because I mostly have a bunch of scripting left. I had edited my 'managed' directory to turn a sprite into a 3d-shape. I ran many times after that. Currently I have to press Alt-F4 to exit because I've been lazy about adding the 'Esc'-key exit dialog. One of those times I exited, I got "$managedDatablockSet = new SimSet() { };". Fortunately, I had a back-up from the pre-"built" project. I still continue to use Alt-F4 to exit my game and haven't seen the problem again (*knocks on wood*).

It's an unfortunate problem because you don't see it until you re-run your application. I've set my console log mode to append. We can hope something appears there.

#16 Justin,
I have not reproduced this since friday. Responding to your points:
* I am editing my datablock.cs because of this issue:
http://www.garagegames.com/mg/forums/result.thread.php?qt=45657

* I have been using Codeweaver for almost a year and haven't had it wipe a file yet. Although this may have a known problem with Codewever, I think its statistically unlikely that the codeweaver bug happened twice in one day. Plus, datablock.cs was not open in codeweaver when it got wiped. I don't see how Codeweaver could erase/corrupt a file that wasn't open.

#17 Well it just happend to me again while using SC2.

Justin, I believe I was editing mainscreen.gui right before it happend. I may have changed the window extent value, and I think t2d was running at the time. Is that something I'm not suppose to do?

Then the next time I tried running it, nothing happend, no t2d window appeared (crashed?). Then when I double clicked again it ran but my game had no datablocks, yay.

im using: winxp, SC2, torsion

I dont think its the editor--this has happend before, multiple times, and I have always used torsion--I dont even have datablocks.cs opened.

I'm definitely backingup from now on

#18 One way to recreate this on RC2 is as follows:

1. start up tgb and open the fish game demo. Open explorer and look in it's managed directory (in fact, make a backup of the managed directory now just in case :) )
2. attempt start up a second tgb instance and while it won't launch, you'll notice the datablocks.cs file is down to just 1kb now instead of 3kb.
3. control alt delete and end task on the running tgb.

note: I can't say this is what's happening for everyone, but hopefully it'll provide a clue.
-Andrew

#19 Excellent find Andrew! I can vouch that this is exactly what happened to me.

#20 While attempting to start up the second version of TGB shouldn't probably be clearing the file, using ctr-alt-del to end a program is going to cause an abnormal shutdown, and therefore won't allow the program to gracefully exit.

If you do everything up to the ctrl-alt-del point, but use TGB to exit as intended, is the file still corrupted?