Utility quirks

There are a number of fan utilities for The Sims. Most of these assume The Sims is installed on the same computer as they are.

For instance, some FAR extractors automatically start in the directory which the registry says is the Sims data path. Skin programs can be very disgruntled when they can't find "GameData\Skins". Character Viewer wants at least a Userdata directory.

These directories can be created, but the utility may still not work, since the Sims data path remains unknown. To deal with this, importing the following information into the registry is enough:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Sims.exe]
"Path"="N:\\Maxis\\The Sims"
@="N:\\Maxis\\The Sims\\Sims.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Maxis\The Sims]
"SIMS_MUSIC"="N:\\Maxis\\The Sims"
"SIMS_SOUND"="N:\\Maxis\\The Sims\\SoundData"
"SIMS_DATA"="N:\\Maxis\\The Sims"
"InstallPath"="N:\\Maxis\\The Sims"
"SIMS_GAME_EDITION"="49"

This text can be copied and pasted into an ASCII text file of any name, which should then be renamed "[name].reg" and double-clicked to enter the information in the registry. Doesn't that look remarkably like the .reg file I use to alternate between installations (see: Installation and after)? Yes, it does; I've only left off the neighbourhood info as being unimportant. The Sound and Music lines could probably go too, but they won't do any harm. By trial and error, I could whittle the .reg file down to maybe two vital lines. But this is what I used to get IFF Pencil working on a computer without The Sims installed.

IFF Pencil wants more than a data path and a Gamedata directory; it also needs a file which is in every Sims GameData directory: "behavior.iff". It uses this file to translate the hex in an IFF file into strings the user understands. The behaviour IFF file grows with each release, and to be sure to get the most accurate description possible, it's best to use the file from the latest release installed: in my case, Makin' Magic. Without the behaviour IFF, the program won't start at all; but it's a good idea to create a Global and Objects subdirectory and copy at least "Global.far" to the right place, to "translate" all those calls to global routines, which will otherwise only show up as numbers.

Not only do utilities assume The Sims is installed, they also assume its language is US English. My language is UK English. I load a character of which I changed the bio with Character Viewer, and see the original bio; because the original bio is in the US block, which Character Viewer reads, while the new bio is in the UK block. In Unleashed, I have cats called Luna, Cali, Aristotle; to Character Viewer, they're all called Luna. So where there are different language blocks, it's probably best to set the same description for all languages (which can be done in IFF Pencil - see Editing the bio).

Most utilities will run fine on older computers. Not so BodyWarp. It's a fine program, but every few minutes I have to stop and restart it to prevent all other running programs from chugging to a halt. (This applies to any less-than-1GHz processor. It doesn't apply to an AMD Athlon XP Notebook. It may also have something to do with running the program under Windows 95 rather than Millennium or XP.)

BodyWarp has another quirk. In SKN files, vertices are assigned to bones in the format "Bone" - "First vertex" - "Total vertices". Leaving off the blend vertices, a vertex assignment might look like this:
0 0 9
1 9 16
2 25 3
So bone 0 has 9 vertices starting at 0, bone 1 has 16 vertices starting at 9 and so on. Bodywarp counts the total vertices but ignores the starting vertex. So if I made a mistake in assigning the vertices:
0 0 9
1 10 16
2 25 3
then BodyWarp would show the mesh correctly, but the game would not.

Blueprint won't run at all unless installed in C:\Program Files\blueprint. When installed on, say, N:\Maxis\Programs, it refuses to run. When installed under Windows ME, it may refuse to run after complaining of a DLL problem. Its most useful feature - to me - is that it can import .3DS files and, create z-buffers for them, because there's nothing I hate more than fiddling with z-buffers. However, I've read in an online tutorial that the import function is not bug-free, and the Z-buffers produced have the right shape, but not the right shading.

FAR packers: most FAR tools will not only open and view FAR files and extract their content, but also create new FAR files. Far Edit (by Bil Simser) includes the absolute path when packing a file into a FAR. Far Out (from Simwardrobe.com) was written to get around this problem; it can also convert BMF files to SKN files when extracting them. The FAR tool of my choice, File Archive Reader II, doesn't create internal paths and refuses to pack subdirectories, so I can't build a subdirectory "Skins" into a FAR. It does read FAR files that already contain subdirectories, and will offer to preserve the directory structure when extracting. It will also, if interrupted while packing a FAR, quit, leaving the FAR with zero content. This happened when I wanted a file from "ExpansionPack5.far", accidentally deleted instead of extracting, took the file from another installation and tried to import while at the same time doing something else; my expansion pack was shot and I had to copy the whole FAR from elsewhere!

I've always assumed that FAR packers can handle any kind of file, but have read somewhere that Far Edit will produce corrupt FAR files when packing anything other than IFF files. I know for a fact that FAR files containing ASCII CMX files make a game crash, so maybe someone put a CMX in a FAR using Far Edit, found the FAR crashed the game, and assumed the FAR was corrupt.

BMF2SKN converts BMF files to SKN files and vice versa. That is to say, it accurately converts a BMF to a SKN, but a SKN converted to BMF will crash the game. I converted a BMF from the game to SKN and back and compared the binaries:

At some point the values are converted in reversed order, that is, "00 xx 00 yy" instead of "00 yy 00 xx". These are the blend values; BMF2SKN converts them in the same order as the SKN, ie. vertex-value, but in a BMF the game expects the reverse, ie. value-vertex. This quirk only affects meshes with blend vertices. (See the Miscellaneous section for a QuickBasic script that will convert such SKNs.) While converting between formats, I also discovered that BMF2SKN uses the internal name. So if the file is called "xskin-B000Fafat_01-PELVIS-BODY.skn" and the name on the first line of the file is "fatwoman" then a conversion produces a file "fatwoman.bmf". This I found out when renaming a SKN so that converting it wouldn't overwrite the original BMF; the original BMF was overwritten anyway!

A handy tool by the same author, SKN2OBJ, converts SKN files to OBJ files and back, provided the OBJ file is the right format: one vertex point to one UV point, the same number of vertices as what's in the accompanying SPJ file, and only triangular faces; faces with four or more vertices are halved, leaving holes in the mesh. The texturing freeware UVmapper inserts an extra space between the "vt" and the UV points in the UV-map lines when saving an OBJ, which causes SKN2OBJ to skip the U column entirely, so OBJs saved with UVmapper should either be hand-edited or opened and saved in another 3D program (I find Wings3D, a freeware Nendo clone, very useful) before being converted back to SKN with this tool. SKN2OBJ has two error messages that it regularly shows, before simply quitting: the "object required" message is shown when loading a SPJ and corresponding OBJ containing vertices which are not in any face, and the "input past end of file" message when loading a SKN, which means that the SKN is saved in Unix format, or some other format which doesn't use DOS line endings.

The popular tool Transmogrifier, affectionately known as T-Mog, comes with a manual. Being older than Hot Date, it will, if used to edit the object definitions, wipe the Hot Date subsort and presumably all buy category info for non-residential lots. These then have to be reset in an IFF or hex editor. It exports the object information and graphics in an IFF file to external files, and can then re-import these external files (usually after the graphics have been altered) into the IFF file, but only once at a time. If I want to import an alteration into an object I'm working on, the best thing to do is move the altered files, export the object again, move the alterations back into the export directory, and then import. Otherwise, I may get error messages about some palette or other block that couldn't be made. T-Mog really prefers to make its own palettes, so while the alpha and z buffers should be greyscaled, the graphics should be non-paletted, 16-bit or 32-bit. If I helpfully load a common palette into the graphics, T-Mog may, instead of altering the existing PALT resource, build a new one and throw away the old one, so that the first PALT resource is 101 instead of 100; as one rarely gets one's object right first time, next import has the PALT resource number changed to 102, and so on. Lastly, T-Mog can really screw up the small zooms. When I first used it, I exported all zooms, all channels; but on re-importing, the small zoom graphics were often skewed or otherwise deformed. It's safest to export the big zoom, all channels, and let T-Mog create the medium/small zooms.

(I've read somewhere that T-Mog gets its order wrong with the first clone, so to get proper object, clone an original, clone the clone, and use the second clone. Maybe this has something to do with the skewed image and other problems.)

The above applies to T-Mog 1.4. There is a version T-Mog 2.0 out, which may have some bugs worked out but has the same habits when it comes to palettes.

Official Maxis utilities can have their quirks, too. Art Studio is nice for giving an image the right skew and Z-buffer to go on a wall, and adding a frame and reverse side, although the frames and the sizes are limited. It does not make catalogue and speech balloon bitmaps of this image. It does not include the post-HD reference to ArtGlobals, or put in the code that makes Sims look at the work and consider it in a thought bubble. There's something wrong with the palette creation, so that the item may show up in strange colours in the catalogue. The templates are imperfect; the paintings aren't quite centered horizontally, and have a one-pixel edge sheared off their frame in the front zooms. Lastly, and this is a fault in the IFF template: menu options usually start at string #129. Looking in an IFF editor, I found Art Studio produces a mangled string #129 and has the menu option start at #130. Editing string #129 makes the painting unviewable, though not editing it at all and simply leaving it where it is won't hurt. (How to make use of the ArtGlobals code is explained in Making an object from scratch.)

Another official Maxis utility with a quirk is Sims Creator, bundled with Deluxe. Because of the Mac's 31-character limit, I tend to give custom meshes the shortest possible name, and soon left out the "PELVIS-" part from "PELVIS-BODY" when I found the game doesn't need it. Sims Creator does need it and won't show any body meshes that don't have it in their name. It also won't show head meshes or textures with gender code "U" in the name and will compress double-head textures (sized 256x128) into a square, making editing difficult. But editing a head texture is difficult anyway, because the lighting is too harsh to see what colour you're painting on. The best way to use it is to paint on the rough lines and then finish the texture in another program. Additionally, this program seems to demand the identifier "_01" in a CMX. The B815 Bubba mesh from the Unleashed expansion pack isn't loaded unless I extract all files and rename (also internally) the CMX from "B815MAfit_UnleashedBubba.cmx" to "B815MAfit_01.cmx". Of course body meshes with custom body types or skin colours, or standard meshes whose code doesn't begin with "B", aren't loaded anyway.

Many older Sims utilities may not work with newer Sims releases. In fact, they may hang when run on a computer with a newer release installed. In fact, they may make the whole computer hang. Two problem programs are Sims Bodyshop by Ratt Salad and The Sims Editor. Bodyshop will simply hang, and possibly take the comp down with it, if run against Unleashed. And TSE, which goes back to the days of Livin' Large; I don't remember whether it had problems with Unleashed or just with Deluxe, but I never got beyond this screen:

Something similar applies to Simshow and its derivatives. In the beginning, the number of meshes was limited and the range of B001 to B200 was enough to cover them all. Now, there are skins beginning with B713 and S401, and Simshow can't handle this. And it certainly can't handle pet skins! Load these, and you'll be lucky if Simshow is the only thing to crash.

There are two well-known utilities to make Sim wallpapers: Homecrafter for PC and IFFSnooper for Mac. Both accept a full-colour bitmap as input, from which they create one flat "diagonal", two skewed "straight" walls, a narrow "transverse section" and two smaller zooms for these four graphics. For HomeCrafter, the bitmap has to be 240x128, but since the actual large diagonal measures 128x231, the end result will be squashed in places.

A striped wallpaper graphic, and what HomeCrafter does with it.

IFFSnooper uses the right size. Both utilities darken the left side by -5 and lighten the right side by +5, but whereas IFFSnooper uses the input file for the neutral values, HomeCrafter takes the bitmap, makes the left skew using the bitmap's colours, then makes the diagonal +5 lighter and the right skew +10 lighter. In other words, the end result will be lighter (though not noticeably so) than the original graphic.

HomeCrafter also assumes that black (RGB value 0 0 0) is the transparent colour in any wallpaper, so wallpapers that use this colour are see-through in places. If a wallpaper graphic uses 256 colours and none of them are true black, HomeCrafter assumes the darkest colour is the transparent colour, and bands of this colour show up where they shouldn't.

The black and white arrows point at the "transparent" colour.

Both HomeCrafter and IFFSnooper do their own colour reduction. To be safe, a wallpaper should be reduced to 64K or 32K colours, or its colours may look different in the game. This is probably why HomeCrafter won't run unless the display is set to 16-bit colour mode. (IFFSnooper works in any mode and reduces colours better; HomeCrafter wallpapers may still look banded at lower colour settings.) However, neither utility "tiles" the graphics, so this process may result in "seamy" wallpaper. (I may be wrong about IFFSnooper which is still being developed, had a wallpaper and floor-tile support added at about version 1.1.8 and may, by now, also have tiling added.) Sometimes, it's just easier to code the wallpaper sprites by hand. One method for doing this is described in the Miscellaneous section.