Back Previous Next

What can cause crashes

There are five known causes for game crashes: missing files, bad files, external hardware/software problems, messing with files while the game is running, and exceeding the game's loading limits.

To tackle the list backwards: older versions only allowed a limited number of walls/floors and would convert the surplus into plants..? I have this from hearsay, and haven't heard that it crashes anything.

Too many skins: I've read that an over-full skin directory can make the game crash. The solution used by the person who discovered this problem was to move all bitmap files (the skins proper) to GameData\Textures, where, strictly speaking, they belong, and to keep only the meshes and CMX files in GameData\Skins.

For Mac users: too many files, of any kind. The Mac operating system allows only so many files to be open at one time, and it appears the maximum number of files is lower in MacOS X than on MacOS 9. I've heard of a Mac installation crashing at 192 files (whether objects or other files, I'm not sure). A solution is to combine objects in FAR files: all individual objects in the FAR will be available to the game, but the FAR counts as only one open file. Objects and textures can always be FARed, other files may need conversion. See The joys of FARing and What goes where for info on how to FAR and where to put the file, and Utility quirks for info on FAR makers; ironically, there doesn't seem to be a reliable one for the Mac. (The only one I know is FARsight, which I only use to browse and extract.)

Messing with files: I once made the mistake of putting a FAM file in the import directory while the game was running. When the cursor hovered over the Import button, the game quit. The only files that can be safely moved during gameplay are House[nn].iff files, of a not currently selected lot. Which means they are best moved while in the Neighbourhood screen.

Hardware and software problems are things like wrong swapfile configuration, harddisk failure, defective CDROM drive, bad RAM, overheated processor, bad graphics card or not enough video memory. Causes that deserve their own paragraph:

Memory: the game may exit more or less gracefully when the system runs out of RAM. I had this happen on the Mac (but MacOS 9 usually warns when memory is critically low) and on the PC (Virtual Memory was off, even though the box was ticked!) and all unsaved changes are lost. The house and user files loaded at the time of the crash may become corrupted. On the Mac, I've had several complete freezes under both systems (though in MacOS X, eerily, the sound keeps playing) to which the only remedy was pulling out the plug; so far, this has not resulted in corrupted files. Mac memory freezes seem to be related to accelerating the game speed, although they've also happened during extensive building.

Damage to the game CD: unless one is playing off an image or using the no-CD patch, all versions of the game want a CD in the drive. The game checks if the CD is an original by (at least on the PC) sniffing it over for special copy-protection weak sectors. It would seem to me that the slightest scratch over such deliberately hard-to-read sectors would make them illegible, and have heard from someone who had played the Sims for a long time and whose computer now simply refused to load the game, probably because the CD was damaged.

Next, bad files. These are either corrupted, the wrong version or files that shouldn't be there in the first place. The game will try to load any files it finds in its designated load directories, whether they're legitimate Sims game files or not. Once, when loading, the game showed a shrunk startup logo with jumbled captions underneath and quit halfway through. Somehow, a number of HTML, gif and zip files had found their way into "UserData5". Removing them solved the problem. Utilities that stay behind in game directories have the same effect: another game crash was caused by "BMF2SKN.EXE" in the "Downloads" directory. It's perfectly safe to make a directory "0" or "junk" directly under C:\Maxis\The Sims\ (or whatever the game's root directory is) to park such files in; the game won't load them from there.

Bad game files can be: objects; walls and floors; textures; meshes; CMX files; possibly corrupted soundfiles; FAR files; corrupted houses and neighbourhood IFFs (these are the files that keep track of all Sims in a neighbourhood). Warning! HD and higher versions, including Deluxe, store extra information in the Sim IFFs, the neighbourhood IFF and the lot files. Simply copying a Deluxe neighbourhood to a Sims/LL/HP installation will crash the game. I thought that copying a lower-version neighbourhood into an installation wouldn't cause problems, but have heard that it does, this time because the Sims copied to a Vacation installation didn't have the bodystring format that HD+ installations require. To be on the safe side, Sim families/lots should always be imported as FAM files so that their bodystring will be filled in correctly (after which Sims with dress sets and/or custom body types may need to have their bodystring manually edited).

Objects should always be the right version for the installation within which they are used. Internal coding can vary considerably between versions, and cause freezes, lockups, crashes, random Sim teleportation and all sorts of annoyances. HD+ buyable objects have a new "category" system, and I've read that categorization for a missing expansion pack may cause crashes: see Categories revisited, right at the bottom.

Bad objects can work in devious ways. If the Sims in a family are frozen and the clock doesn't run, this points towards a bad object. I once imported FAM files from Deluxe into LL and found that some of the families were frozen. When I tried to save these families, the game crashed. Eep, I thought, are LL and Deluxe houses incompatible after all? But importing the same FAM files into LL on the Mac caused no problems. So, on the PC, I evicted one frozen family, which emptied the house of objects, saved without problems, and replaced the missing objects bit by bit in Buy mode, saving every so often. After one such save, the game crashed. I had evidently just bought a bad object. Which object exactly, I can't remember, but it may have been some old T-mogged clone in the Downloads directory. (Update: starting the game with "-debug_objects", I found it was the Ukelele Lady lamp. Invisible objects, like social interactions, can have the same effect. Apparently LL for Mac is more robust where internal object errors are concerned.)

A problem of badly cloned fan objects: missing sprites in an object have the effect of making it crash the game immediately. Such objects, when viewed in something like Sim Explorer, have no graphic, or the graphic looks wrong. The two possible solutions are to hack the object, somehow deleting the missing sprites from the drawgroup block, or, if that sounds like mumbo-jumbo, to just delete the object, and possibly ask its maker to put up a fixed version.

An object which is not in itself corrupted but which refers to files missing in that Sims environment - meshes, animations - or calls routines which the game's "Global.IFF" doesn't contain yet, may crash the game at load time, when buying it, when selecting (or hovering over!) the family/lot where it can be found, when importing such a family/lot (if the object file exists, else there's just a "missing object" message when that family is selected) and when updating the neighbourhood's (or just that family's) webpages. FileCop doesn't check for this. (This is why Maxis warns against importing families with custom objects. An object may be cloned from HP and refer to the host/campfire animations. An object cloner who only reshapes/recolours the object, without looking at the code, won't know this. Load a house containing this object in Livin' Large, and blam!) The solution: locate and delete the object, or have the game start with different neighbourhood (see corrupt neighbourhoods below). To simply get rid of the problematic family: as they can't be evicted, import a new, empty lot over the family, which effectively evicts them and takes away their possessions (but they get no money in return), then use the money cheat to build them a new house.

The same goes for custom objects that need other custom objects. My first attempt at modifying the military school check in "PersonGlobals.iff", required me to put a message string in "PedPortal.iff" because global IFFs can't contain dialog messages. It worked, and by way of test I used the modified global file with a standard pedestrian portal which didn't contain this extra message string. Due to the way I called one object from another, the game slowed down to the point of being unplayable (although the hack's final version doesn't have this problem). It didn't crash, but I almost had to use Ctrl-Alt-Del to quit.

Walls, floors; apparently the images inside these can be bad. FileCop checks for this. I've never had it report bad walls or floors to me.

I've never known a bad texture file to crash a game. Texture files must have 8-bit colour depth and 256 colours, although I've had textures that were 24-bit, contained only 256 colour shades, and worked fine; I never noticed them until FileCop reported them. Texture file size must be a multiple of 8 pixels and length/height proportions must be in whole numbers, so a 128x128 (1:1) or a 256x128 (2:1) texture is okay, but a 256x384 (1:1.5) is not. Bad textures don't crash the game, they show up as white. Textures that are bigger than 256x256 may just cause a crash: not the game's fault, but I read somewhere that older graphics cards may choke on bigger textures.

Although meshes with internal format errors will either show up all wrong or simply be invisible, the game may crash over its inability to load a particular mesh. I've seen a complicated head mesh which works perfectly under The Sims, is partly invisible in Deluxe, and crashes in Unleashed; apparently the higher versions are pickier about their meshes. This problem rarely occurs. I've read that it has something to do with the game's inability to make character icons of very big head meshes, and there are various solutions, which are only of interest to meshers. So the only practical solution is to ask the head's maker to put up a "fixed" version. (NB. meshes with serious internal format errors, like the wrong number of vertices, do crash the game when it tries to animate them.)

On the other hand, CMX files with internal format errors can be fatal! If there is no texture to go with them, they won't be loaded. If they have a bad filename or bad internal name, they probably won't be loaded either. If they contain a typo in the mesh name so that the mesh can't be found: KABLAM! FileCop checks rigorously for "bad" CMX files, that is, CMX files pointing to mesh files that can't be found, either because the CMX spelled the name wrong or because the mesh really isn't there.

Bad soundfiles: the formats used are WAV, XA and MP3, and what a corrupted MP3 would do to the game, I'm not sure. But check the note about SS and soundfiles in Installation and after.

Bad FAR files: a FAR is a bundle of several IFF, XA, SKN and other files used in the game. It is possible to bundle meshes and animations belonging to an object into one FAR file with it, but only if the CMX file, necessary to both meshes and animations, is in BCF form; else the game exits when loading it. There may be other file-in-file combinations that the game doesn't swallow; this is one I accidentally discovered.

Bad FAR files can also result from installations gone awry. I once ran into disk space problems installing MM over earlier packs. Installation stopped while existing files were being updated, then resumed after I'd freed enough space. On playing the game, though, I found objects were really missing, and on looking inside "ExpansionPack5.far", I saw several objects with a size of 0 bytes. If any of those had been animations, the game might have crashed. Fortunately, there was an updated ExpansionPack5.far on another computer I could copy, so I didn't have to reinstall both packs.

Neighbourhoods: a corrupt user, house (see next paragraph) or neighbourhood IFF will crash the game when that neighbourhood is loaded. Such files may become corrupted when the game crashes for other reasons, or when tweaking them in a hex editor or utility. FileCop does not report these files. Since the game tries to load the last active neighbourhood when it starts, it will crash each time it is restarted. On the PC, the current neighbourhood number and path can be changed in the registry. On both PC and Mac, the neighbourhood can be renamed and its old name given to a "clean" neighbourhood. Then follows the arduous task of finding the corrupted file and seeing if the family can be re-imported from the FAM file.

After getting stuck this way a few times, I'll add it as a separate paragraph: if a neighbourhood keeps crashing every time you try to load it, before checking all characters' bodystrings and comparing them to the available skins, look in UserData[nn]\Houses for any house IFFs that seem unusually small. Chances are, such a small file is a house corrupted when the game crashes over memory problems. The solution is to either re-import the family or, if it's an unaltered uninhabited house, copy the old house IFF over it from some other directory - UL has the directory TemplateCommunity for that very purpose, as well as separate backup house directories for every neighbourhood (unless these were removed to save space).

It doesn't exactly crash the game, but does make it impossible to play: house IFFs of the wrong version. Adding a family is done by importing a FAM file. Adding only the house is done by simply copying the house IFF into the Houses subdirectory, which automatically removes any old inhabitants. Between The Sims, LL and HP this can be safely done. A house IFF from Deluxe copied into LL (or a FAM file from Deluxe imported in LL) reports missing objects; these are relationship objects that didn't exist yet in LL. A house IFF that's been saved in Unleashed and is copied to LL, will either freeze time when chosen (the player can always return to the Neighbourhood screen, though) or freeze and have half its objects missing, even if these are objects that exist in LL. The new neighbourhood system of Unleashed adds more code to the house IFFs that LL doesn't know what to do with. My solution - and isn't it handy to run different versions side by side - was to copy the house IFFs from UL to Deluxe, save them there (which decreased their size, clearly some code was being sluiced out), copy them to LL and save them there again to get rid of the "missing objects" message. If visible objects go missing, though, the only thing left to do is replace what was lost. UL does export uninhabited lots as "L[nn].rdt" files, but earlier versions can't do anything with those.

Something very odd once happened with the buyable baby object. I bought three babies in a row, which would consequently mature very soon after each other. When they did (and I'd been messing with the "Speed growth" option too) the game crashed. I restarted it. All Sims in that neighbourhood were gone!!! Fortunately they were only "crash test dummy" Sims. I made two new Sims, put them in one of the now deserted houses and watched them play around until the game crashed again. I restarted, and now all my old inhabitants were back (I think minus the new kids, I didn't check) and the new ones were gone. After that, no more crashes. This was in LL on a Mac. Conclusion: especially on a Mac in an older installation, too many babies can do strange things to the neighbourhood IFF.

On to the missing files: two files that will crash the game when missing are meshes and animations. These files are referred to from other files, and those other files may be reported as "corrupted" although there's nothing wrong with them. Animations work like this: an object refers to an animation CMX/BCF which refers to an animation CFP (a file rather like a mesh file). The error message "missing animation" which sometimes appears over a Sim's head doesn't mean that the animation files themselves are missing, but that the object has an "Animate Sim" instruction pointing to a string which is empty or contains a misspelled CMX/BCF name; in other words, the CMX/BCF can't be found. The CFP is a lot like a Sims mesh, and if it's not found when called, the game crashes.

Likewise, if the CMX of a Sim skin contains a mesh name for which there is no corresponding mesh file, KABOOM. This can happen at load time, in the Create-A-Sim screen or when using a wardrobe. Now there are three possibilities: the CMX got the mesh name wrong, the mesh isn't there, or the mesh exists but the game can't load it. (If the game can load it but, through some error, can't display it, it's invisible. That's how you get things like headless Sims.) Why can't the game load it:

* It's not in the right directory. It has to be in Gamedata\Skins or ExpansionShared\SkinsBuy. Accessory meshes belonging to (buyable) objects may be in the same FAR as the object, which in turn has to be in one of the directories that object IFFs are loaded from.
* For Mac users: its name should not exceed 31 characters. The meshes will appear with their proper names under MacOS X, but will be treated as missing in the game. Such meshes need their names shrunk with Namer. (Skins of which the names are too long won't show up in the game, leaving the mesh rendered in that tell-tale milky-white colour.) Incidentally, zipping too-long-named files on a Mac and then unzipping them on a PC can produce files with their names cut off at 31 characters. I've heard that in Superstar for Mac, this issue has been resolved.
*Another one for Mac users: the mesh has been edited in Unix and saved with Unix rather than DOS line endings! That the Sims for the Unix-like MacOS X should choke on Unix line endings which the PC happily accepts is hugely ironic, but then I suspect even the MacOS X version of the Sims is geared at the old Mac. This may also be resolved with SS, though I can't test that. (Note: UltraEdit tells me that Unix uses LF at the end of a line, MS-DOS uses CR/LF and MacOS (that would be pre-X?) only uses CR. Mystery solved, and the line endings were easily replaced.)
* It's been BMFed with BMF2SKN. The SKN files made with this utility are fine, but the BMFs crash the game. See
Utility quirks.
* It's a BMF in a FAR referenced with an ASCII CMX. A CMX is a file that points to a mesh, its binary form (necessary for FARing) is CMX.BCF or just BCF. A mesh can be SKN (ASCII) form or BMF (binary form) but here's a strange thing: although a BCF can point to both SKN and BMF, a CMX can't point to a BMF! The mesh (BMF) will be treated as missing.

Some explanation is called for here. In the old Sims, all meshes that came with the game were in BMF form. I tried to use those meshes with accessories by writing a CMX for that mesh name and the accessory. The game then looks for the SKN version of the mesh referred to, so when I used the wardrobe: blam! In the expansion packs, I noticed FAR files contained a SKN and BMF version of the same mesh. This seemed a puzzling waste of space. Now I know that a SKN doesn't always load from a FAR - see The joys of FARing - and suspect that the SKNs are there for people who like to write their own combinations. The moral: when referring to a mesh in a FAR, convert the CMX to BCF. BCF2CMX does that without problems.

A later discovery which may disprove what I've said above: the meshes for the original Sims, also used with all expansion packs, are packed as BMF in "Animation.far". They are linked to BCF files via "Animation.ndx" and are otherwise not available for being referred to by CMX/BCF files, where they will automatically be treated as missing. Although there is a difference: CMX files referring to the "missing" mesh will crash the game, but BCF files will simply not show the unavailable mesh, so trying to tack an accessory onto one of these meshes results in the accessory floating in the air around a partly invisible Sim.

The game is not so harsh about missing or mis-spelled accessory meshes, like a hat added to a head or body CMX. These simply won't show up. (Um, I'm no longer sure about that, since the game crashed on a missing - actually misnamed - accessory in a BCF file. Was it the fact that this CMX was in BCF form, or was it a coincidence to have the game crash just after adding this file? This led to the truncating and thereby corrupting of a house file which made the game crash four times in a row, before I figured out that the house IFF had gone bad.)

Missing CMX files are no problem for normal wear, but the game expects all dress style CMXs for any body type to be present, or it exits when changing to that dress style. In the pre-HD system, for a skin with, say, custom body type SUM, if there is no nude skin/CMX of type SUM, the game crashes. If there is a nude body but no formal/swimwear/pyama, the first available defaults for these styles will be written into the Sim's bodystring (usually of the FAT body type), and the game crashes when changing to that dress style with the wardrobe. In HD+ installations, where buyable clothes can have a different body type (usually "fit") than the normal and nude styles, the Sim gradually changes body type and the game becomes more and more unstable until one day it won't load and the only option is to reload the Sim from a FAM and change the bodystring.

The HD system has introduced another weakness with the possibility to customize CMX files. Let's say I have an outfit with CMX file "B001MAFit_glasses.cmx" which unites the B001MAFit mesh with a pair of specs to appear on the character's head. When the Sim with this outfit is created, the CMX identifier "_glasses" is automatically filled in for the three or more buyable dress styles. Provided, of course, that these files exist. If there is no "L100MAFit_glasses.cmx", no "S100MAFit_glasses.cmx" and no "F100MAFit_glasses.cmx", or if one is present and the others are missing, the game may crash, either when creating the Sim or when changing outfits. Pre-HD installations where dress-style CMX files with different identifiers are used may also experience crashes; in all, for body files, it's safest to use identifiers only in the texture filenames.

Sometimes, it's not clear what caused the crash. While early game versions allow a custom nude CMX, manually changing the nude string to "nuskn_02.cmx" (where "nuskn_02.cmx" is a version of the default that joins a hair mesh to the nude body) caused a crash when I loaded the affected Sim's house, but also when I was playing with a family where the affected Sim dropped in for a visit, fully dressed! I had to set the Sim's bodystring back to the default to end the crashes. Was this because there were no "_02" CMXs for the other dress styles, or because I was referring to a BMF mesh (the standard, FARed nude mesh) in a CMX file? Or because, as I later found out, the nude body mesh, being in "Animation.far", is one of the meshes unavailable to other CMX/BCF files?

But then the Sims, or maybe just FileCop, works in funny ways. When the game kept crashing (over a missing SUM nude mesh and consequent progressive bodytype confusion, as I later found; this Sim has now completely converted itself to FAT) this program constantly marked as "bad" three ATN (another custom body file) CMX files. There was nothing wrong with them! Then I found that "F100MASUM_01.cmx" referred to the B004MASUM mesh, not present on the system. Just because they used a custom body code, a bad CMX was being ignored and three good ones were being punished for it. Two things make the game unstable: i. custom body types and ii. CMX files whose mesh code differs from the mesh code of the mesh they refer to; like a "F100MAfit" CMX referring to a "B004Mafit" mesh because the formal and B004 meshes are the same mesh with two names. Or a combination of the two, like making a "B004MASUM" mesh and referring to this mesh from "F100MASUM" to avoid having two meshes where one will do. This sort of thing works OK provided all mesh and CMX files that the game expects, are there. (That includes pre-HD swimsuits in HD+ installations, as these are always written in the bodystring.) If any are missing, the confusion this causes in the internal database of loaded skin files that the game builds will lead to sudden game exits when loading Sims using these CMX files, either on their own lot or when they visit another lot.

Are there any other files that will crash a game when missing? Without basic files like the "globals" IFFs, the game won't even start. If buyable IFFs are missing from a lot, the game just shows a "some objects could not be loaded" error. If skins (textures, BMP files) are missing, the game displays a "missing textures" message and dresses the Sim wearing that skin up in a different body. (Warning: especially with buyable skins, this may lead to a change in body type.) I don't know what would happen if I deleted all the sound files, and am not going to try.

I thought that if the game tried to load a nonexistent neighbourhood, either at startup or by leafing through the hoods, the game would crash. And I have had neighbourhood-related crashes on the PC. The Mac game, however, is totally unfazed by missing numbers and happily skips to the next available one. As I've found PC crashes can damage game files (I've never had files damaged under MacOS X, no matter how ghastly the crash) I'm not going to test this further.

(I read something in a Mac Sims manual that may explain the above; it says that though you can make new neighbourhoods through copying a UserData[nn] folder even while the game is running, you should never delete or rename the main UserData folder, whether the game is running or not; and yes, I did try renaming it to UserData1.)

After a stupid move which called for a total reinstall of all expansions, I found another way to make the game crash! My order of install is: Deluxe, HD, Vacation, Deluxe again, UL, SS, MM. I also have HP for Mac of which I can copy the expansion pack files to an UL installation and reinstall UL or higher, and the HP files will be updated too, provided I first alter the registry. This time I was too lazy and installed Deluxe, copied the expansion pack files of HP, HD and Vacation, and installed UL, then started the game to see if it would run before installing the next two. It went as far as the announcement that the Sims neighbourhood had expanded, then quit. What probably happened is that it queried the registry to see if HD and Vacation had been installed - all the necessary files were there - and, of course, found nothing. Fortunately I had a backup of the Sims registry keys, so I finished installing the packs and imported the .reg file. Moral of the story: the registry does matter, at least on PCs!





Back Previous Next