This doesn't technically belong under advanced hacking because it's not about hacking proper, but sooner or later the advanced hacker will be making objects that include suits and animations, and will want to make them into a neat little package so as not to have files scattered all over the place. Standard Maxis content generally comes in FAR files, and the advantages of putting all the odds and ends into one FAR file are twofold; a FAR can simply be put in one directory, so no instructions are needed to put meshes in directory A, textures in directory B etc. and, for Mac users, there's no 31-character filename limit; provided the FAR has a short filename, the names of the files inside can be as long as necessary. As the title indicates, my own attempt at FARing was a dismal failure; if anyone knows what I did wrong, please correct me.
First recap: FAR files can contain IFF object files; XA soundfiles; BMP textures; mesh/animation files in binary format, ie. BMF, not SKN; and CMX files in binary format, ie. BCF, not CMX - they often end on "cmx.bcf" but believe me, they're binary; an ASCII CMX in a FAR crashes the game. A SKN in a FAR doesn't crash the game, but is ignored. The game's FAR files can also contain floors, walls, game icons and anything you can think of, but these files are generally not referred to from an IFF file and so there's no reason to FAR them up with one.
Second recap: FAR files are opened only from certain directories, and only certain filetypes are loaded from them depending on which directory they were found in. It's no good FARing wall and floor files as they will not be loaded from anywhere, not even from their own Gamedata subdirectory. Fan-made FARs are expected in the two directories Downloads and Gamedata\UserObjects and any subdirectories under them. FARs in Downloads may contain sounds, skins, meshes and animations (and of course BCF files), but only if these are referred to in the included IFF's strings, otherwise they're ignored; if the FAR is in Gamedata\UserObjects, only the IFF will be loaded, and any other filetype is ignored. FARed skins and meshes from either location will certainly not show up the the Create-A-Sim screen. Skins, meaning textures, will be loaded from FAR files in Gamedata\Textures, Gamedata\Skins and ExpansionShared\Skins providing the necessary CMX and mesh files can be loaded from elsewhere. These skins will show up in the Create-A-Sim screen, so FArin them is a handy way of organizing downloaded skins. The CMX and mesh files, provided they are in binary form, will be loaded from FARs in Gamedata\Skins and ExpansionShared\Skins.
On to my experiment: the What Hair Day Mirror, which comes with mesh and texture files for the hair/mask/cloak accessories, two animations for the villain laugh, and CMX files for both the meshes and the animations. These, I thought, I would put in a FAR with the main object.
The texture BMPs presented no problems whatsoever. These were easily FARed.
Now for the files that need a CMX file for the game to load them. Putting an ASCII CMX file in a FAR file and then starting the game and letting it load this FAR file ends in "kaboom". The CMX must be converted to its binary format, a file that ends on "cmx.bcf" or plain ".bcf". There is a utility called BCF2CMX which converts from one format to the other, but it only accepts "skin" CMXs, not animation files. The only program I know that produces animation BCFs is Simpose, which exports both BCF and CMX when saving an animation.
I made two animations - moving up to the mirror, and moving away - in Simpose 9, which saved them as two CFP files (which is already a binary format and doesn't need converting) with accompanying CMX and BCF files. So I added the CFP files to the FAR, and tested the object; it worked. I deleted the CMX files (backed up safely, of course) added the BCF files to the FAR, and tested again. The character assumed the start pose, froze, and assumed the end pose; no animation in between. I thought the fault lay in the filenames, which didn't follow the "a2o" naming conventions, and changed the names. No effect. Of course when I used CMX files outside the FAR - whether the CFP files themselves were in the FAR or not - I could use whatever names I liked. It seems the Sims itself uses a subtly different BCF format to what Simpose outputs. The CMX.BCF files in the FAR are ignored because they are not referred to in the FAR's "[name].ndx" file. More info will follow as I discover it..
The meshes were even more problematic. These were so-called accessories, which meant that I could call the ASCII CMX files "suit-[name].cmx" both as filename and internally (the CMX file contains its own filename without extension, and it is this internal filename that's loaded by the game) but once I'd BCF'ed them and put them in the FAR file, they were totally ignored. I had to rename the BCF files "accessory-[name].BCF" before FARing them. This only applies to the filename; the internal name, as well as the suit name string in the mirror object, stays the same. Having got the BCF files to work, I added the SKN files to the FAR file. Suddenly, the suits didn't show up any more. This is because SKN files are ASCII and FAR files can only contain binaries, or rather, only binaries will be loaded from the FAR file. The SKN file can be converted to a binary format with BMF2SKN. So I changed the meshes to BMFs and added those to the FAR. Now, the game crashed. Do BMFs in a FAR crash the game too? I extracted and deleted them from the FAR and put them in Gamedata\Skins. The game crashed again. It was the BMFs themselves that crashed the game. It seems that the Sims also uses a subtly different format from what BMF2SKN outputs. The problem is in the conversion of blend vertices. I wrote a script to deal with this. See remarks about BMF2SKN in Utility Quirks and the Miscellaneous section.
At this point I gave up.
To add insult to injury, after I restored the SKN and CMX files, the BCF name with its
added "accessory-" was already in the test-Sim's body strings, and it was only after a
number of game restarts that the object worked again for this Sim.