Posted: Tue Mar 22, 2011 10:06 am Post subject:
The infamous savegame bug
I've been running into a weird form of the infamous savegame bug. Whenever I load a savegame, then quit to the main menu and start a new skirmish match, the game crashes on the match loading screen. Also sometimes after loading a savegame and then quitting the entire game, the game freezes when closing and I have to kill the process.
I've moved all the firestorm anims to rules.ini animations list, which is considered to fix all savegame related problems. The firestorm anims start at index 708 and my own anims start at 746 all the way to 842. I've checked the list countless times and everything should be fine so I'm not sure what's causing this. Does it matter if you move the firestorm anims to rules.ini, but the animations themselves are still defined in artfs.ini? Should they go to art.ini as well? I did a quick test and that didn't seem to stop the crash for me. Another thing I was wondering. Is it ok that eg, DJUGG_A is listed in rules.ini, used in firestrm.ini, and the actual shp is in ecache02.mix? I recall having some weird problem overriding firestorm related shps and voxels, I had to create a completely new code entry for them and use a different name.
Has anyone else had these types of savegame problems? Or does the animation list swap fix all the problems for you? _________________ QUICK_EDIT
I know this bug as we had it once in TI, but i can't remember anymore how we fixed it.
At first i would say you should definitely move all firestorm stuff into the normal rules.ini/art.ini so there are really no inconsistencies.
Though a problem with these would imo lead immediately to a savegame bug and not only at the second time.
Right now i would say it's a problem with something that is used but not defined in one of the lists (e.g. a used warhead that isn't listed in the [Warheads] list; or a dummy weedguy hack infantry that isn't listed)
From my feeling/experience, such a bug can occur due to a memory problem, where an object isn't removed correct and thus causes a conflict when loading another savegame.
It might also be a wrong art.ini key like DemandLoad or one of the other memory related keys like DemandLoadBuildup, FreeBuildup etc.
As a standard answer, you could also check that you haven't got a corrupt mix (delete all included files and add them again). There can be cases where a mix is loaded at one point fine and at another causes a crash.
\EDIT
IIRC the mentioned TI bug was caused by a voxel debris with a missing/corrupt hva. So you might check these as well. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Doesn't inviso have to be the very last entry on the animation list? I redid my entire anim list from 0= and removed anything I didn't need and double checked everything that I used, I left it with 707=INVISO at the end of the rules, still had heaps of free entries untill I reached it. This cured it for me. _________________ QUICK_EDIT
If you don't have any new animations in the firestorm inis, you can order the Animations list as you wish.
e.g. TI has INVISO on index 224 with a consecutive numbering and works fine. (If 707=INVISO would have to be the last entry, TI wouldn't work anyway, since we're way beyond of 1000 anims )
The UMP uses this too, to allow an easier modification of the animations.
The problem is that the firestorm inis add their list-entries to the end of the normal inis lists. If you would add something after INVISO you change the relative position of the firestorm stuff and when loading a savegame, the engine seems load them in a different way, thus messing up the index of the firestorm animations which leads to a crash. _________________ SHP Artist of Twisted Insurrection: Nod buildings
I recall reading that HVAs, voxels and ini should go to expand02.mix while shps and auds to ecache02.mix. Currently everything except loading.pcx is in my ecache02. Wonder if this has anything to do with it. Could be a broken MIX file too since I've never rebuilt them in the 1.5 years I've been working on the mod. I'll post back once I've sorted the MIX files. _________________ QUICK_EDIT
One more thing I was wondering. I recently went past the 99 unit limit with some AI only units. Having more than 99 units can cause the AI to go crazy. All my units beyond 99 have Techlevel=-1, so it doesn't affect the AI, but could it lead to this savegame problem? _________________ QUICK_EDIT
Uhhh... the issue SuperJoe is describing is not related to hacking Tiberian Sun its related to Tiberian Sun not made for Dual/Multi Core CPU's or something like that... simply putting Tiberian sun in Win9x compability mode solves this.
(Atleast for me it no longer crashes when starting the second or future skirmish battles after the first battle after setting TibSun in compability mode)
Alt. option set TibSun to only use one CPU core with the Task Manager (dont remember if this works alone or if this is needed together with compability mode since I dont have a computer with Tiberan Sun infront of me right now)
Also I dont remember if it was Sun.exe or if it was Game.exe that required the compability mode.
(and yes I used to have this issue SuperJoe described) QUICK_EDIT
Because i have/use all 4 CPUs without any affinity or compat setting on
my WinXP machine and TS works fine.
It's the first time i hear that a multi core system can cause such a problem. Thanks for the info. _________________ SHP Artist of Twisted Insurrection: Nod buildings
I disabled win98 compatibility mode for game.exe (as Reaperrr suggested in the internal errors thread) and it fixed the problem completely. I have kind of mixed feelings about this... it does remove the savegame problem, but win98 comp mode fixes a few other issues I've been getting. Sometimes the sound and music volumes jump up or down for a brief moment, and sometimes the game simply used to freeze during gameplay. No internal errors or crashes, the whole game simply completely freezing. Having win98 comp mode on removed these problems, at least for me. Picking between these 2 problems I'd still keep the win98 mode on.
I'll have a look at the affinity setting if that can be of any help. Also I'm on 32bit WinXP, with a quad core. I've always been using the compatibility mode for game.exe, thought sun.exe was just the launcher or something.
EDIT: I had win98 comp mode on for over a year and I don't remember the game crashing everytime I quit it after loading a savegame... though I could be wrong. Can someone else test this? Does win98 mode ALWAYS crash the game for EVERYONE if they do either of these load game scenarios? _________________ QUICK_EDIT
The win98 compat mode seems to change the engine behavior in more different ways than i would have ever expected.
e.g. TI had to use for a long time the win98 compat mode, as maps didn't load. When i fixed the DemandLoad keys on all art.ini entries, the compat mode wasn't needed anymore and TI works now fine without any compat mode.
So in short, the compat mode changed how TS loads and finds SHPs in mix files, which should actually have nothing to do with the underlying OS as it should be only a simple file managing issue that should work everywhere the same. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Well now I tested with win98 mode back on and the game crashes sometimes when just loading a savegame. Looks like the compatibility mode has a tendency to screw up save / load functionality. I too I had to use win98 mode for a long time since the game would always crash on the mission loading screen. Recently I disabled the compatibility mode and everything seems to work just fine now. I haven't removed any of the DemandLoad keys, or done anything else that should have solved it. All this just seems to be annoyingly random. I'm not sure there is a fix for these problems that works for everyone. It just seems to be mod and user specific. I'm currenly trying out with win98 mode disabled and affinity set to just 1 core. Hopefully it will fix the sound and freezing issues that win98 mode used to fix for me. Btw, does anyone know a quick and painless way for windows to remember the affinity settings? It's too much hassle to remember to change it every time you run the game. _________________ QUICK_EDIT
Nah I have Windows XP SP3 32bit on a computer with Intel Core2Duo 3GHz CPU (2 Core CPU) and 3.5GB RAM (4GB but Windows 32bit only goes upto 3.5GB) and my private Tiberian Sun Firestorm mod that is using the last version of ETS (0019) and running in NOCD mode, the mod itself has not been worked on for like 2-3 years or something (that computer is out of service for some time untill mabe 1st April)
From what I remember (was a long time ago) my issues started when I upgraded from a single core AthlonXP 2500+ and 512MB RAM and I dont think I have had these problems on a Pentium3'ish Celeron at 1.4xx GHz and some amount of ram below 512MB (both of these ran WinME and the one with AthlonXP ran WinXP for a while but dunno if it ever had the problems then becaus I dont remember) QUICK_EDIT
Joined: 09 May 2011 Location: Approaching the Great Pyramid
Posted: Fri Sep 16, 2011 6:22 pm Post subject:
well I seem to have this same annoying save/load game problem
I have double checked that all my infantry, vehicles, air units, animations, warheads, voxel debris are correctly added to list (correct numbering too)
I also use this on few of my "new" buildings" in art.ini
DemandLoad=false
DemandLoadBuildup=true
and I still have this game crash upon loading game
any possible tip about what else should I look ? _________________
Many different inconsistencies can cause it; including things in rules.ini pointing to non-existent code in art.ini, missing infantry sequences (even if the infantry that use the sequences aren't even buildable or present on a map) and I believe it also happens when (in rules.ini) Engineer= doesn't have ENGINEER specified and Technician= doesn't have CTECH specified (renaming those seemed to have caused the savegame bug for DTA in the past). _________________ QUICK_EDIT
Joined: 09 May 2011 Location: Approaching the Great Pyramid
Posted: Fri Sep 16, 2011 10:50 pm Post subject:
Bittah Commander wrote:
(even if the infantry that use the sequences aren't even buildable or present on a map)
by this you ment, even infantry that use valid sequence but not buildable ?
also to ask, do things like, valid entries but unused can cause it too,
for example I have about 10 animations in my mix file,
they are ALL correctly added in rules.ini list and have all valid art.ini entries
but are not used for nothing, I just added them for "just in case"
can that cause also trouble ?
I ask, because other than that I have no clue what could do such mess
I backtracked and cleaned all my art and rules QUICK_EDIT
Whether something is used or not makes no difference; all that matters is whether it's valid. So if for example an infantry has Sequence=PacmanSequence and that sequence doesn't exist, it'll cause the savegame bug. _________________ QUICK_EDIT
Joined: 28 Apr 2009 Location: Auckland, New Zealand
Posted: Sat Sep 17, 2011 12:01 am Post subject:
I found an issue that caused a save-game bug that might help. It had to do with cloning units. It's hard to explain but here's the gist.
[CYBORG]
Image=SLAVIC ;the image for the cyborg has been changed (I did so I wouldn't have to reprogramme my elite cadre into the AI)
[CYBORG2] ;a clone of the cyborg was created for the campaign
Images=CYBORG ;the image cyborg is used.
Now both units will work in game BUT you get the save game bug. I had to create a clone CYBORG shp to avoid this. Does this help? _________________ Beta Tester for Mental Omega 3.0
Assuming you didn't actually miss-spell "Image=" in rules.ini (you spelled it as Images= in your post), this is the first time I've heard of an image used by multiple units causing problems
In matter of fact many mods use a single SHP for multiple units without any issues whatsoever... _________________ QUICK_EDIT
Joined: 28 Apr 2009 Location: Auckland, New Zealand
Posted: Sat Sep 17, 2011 12:21 am Post subject:
Yeah I had is spelt correctly. The difference is that the game didnt like that I had changed the cyborg image and then cloned the image. Something there messed it up. _________________ Beta Tester for Mental Omega 3.0
Since you said you actually did miss-spell Image= as Images= in rules.ini, it means that CYBORG2 actually used the CYBORG2 image and if no code for CYBORG2 existed in art.ini, this would've caused the savegame bug. _________________ QUICK_EDIT
Cloned unit images and cloned units using the same image do not cause any savegame bug! _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 28 Apr 2009 Location: Auckland, New Zealand
Posted: Sat Sep 17, 2011 10:56 am Post subject:
No not using the same image only if the original unit's image differs. Its hard to explain ill post a set of rule one day with it. _________________ Beta Tester for Mental Omega 3.0
well I seem to have this same annoying save/load game problem
Does the crash happen always when you load a savegame, or only sometimes? One thing could be as simple that your save file is outdated and conflicts with your current ini / echache files. You are trying it with a newly created savegame?
And as discussed earlier in this thread, are you using win98 compatibility mode? I would always recommend to disable it, it causes problems with savegames for me. I even tried to play my mod on a native win98 computer (very old computer with no multicores or anything) and I experienced the same savegame related crash. So from my experience the game just doesn't like windows98.
Finally run your game / mod with this. It forces the game to run on a single core. This is assuming your computer has multiple cores, if not then ignore this.
One thing that has caused problems for me before are broken MIX files. It just seems to randomly happen sometimes, especially when the MIX file has alot of stuff in it and you compact it. But a broken MIX file always crashed me at the mission loading screen, not just when loading a savegame. So it probably isn't due to this. _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
The infamous savegame bug
)
