File Reference

The main file format for everything in The Sims – objects, characters, career data, UI strings. Each IFF file is a container that holds multiple resources bundled together:

• Sprites – how the object looks
• Behaviour scripts – what the object does
• Constants – tunable values like price and skill gain
• Text – catalogue name and description
• Other resources for sounds, interaction lists, slots and more

When you download a mod or create one yourself, you're working with IFF files. Custom objects go in the Downloads folder. Mods that replace base game behaviour go in other locations.

A FAR file bundles multiple IFF or other files into one archive. Think of it like a zip file that the game can read directly without you needing to unpack it. All base game objects and global behaviour files live inside FAR archives – that's why you don't see individual object files when you browse the game folders.

TMog reads FAR contents automatically when you open it, so you don't need to extract anything for retexturing. Use FARx if you need to pull out a specific file for manual editing.

Flat bitmap images that wrap around a Sim's body, head, or hands to create their appearance. Every outfit, hairstyle, and skin tone is a BMP file. They must be saved as 256-colour indexed bitmaps – any other colour depth (like standard 24-bit BMP, PNG, or JPG) will show as a white silhouette in game.

A plain-text file that tells the game which BMP texture to use on which SKN mesh, and can also attach accessory meshes (like glasses, hats, or extra hair pieces) to the main body. The file is an ASCII “Character File” header followed by a short set of numbered lines. Only a couple of those lines carry content that changes per skin; the rest are structural markers shared across every CMX.

The broad structure is:

• Fixed header lines (copyright and version) – identical across all CMX files.
• Self-reference line – the CMX’s own filename without .cmx. Must match the filename on disk exactly; if it does not, the game silently ignores the CMX and the skin fails to load.
• Mesh count – how many meshes follow. Usually 1 (the body itself). Adding an accessory adds another mesh and bumps the count.
• Per-mesh block – an attach-point name (PELVIS, HEAD, SPINE1 etc.) followed by the SKN mesh filename without .skn. Repeated once per mesh.
• End marker – a single 0 closing the file.

Knowing this structure is enough to use CMX files for: sharing one mesh between several skins, moving an outfit between clothing categories by renaming, adding an accessory like glasses on top of an existing body, and similar jobs. See the Editing CMX Files section of the Retexturing Clothing page for worked examples. New CMX files are also generated automatically by The Sims Creator when you export a skin from GIMP – so for ordinary outfit creation you do not need to touch them by hand.

The 3D shape data for a Sim's body, head, or accessory. Contains:

• Vertices – the 3D points that define the shape
• Faces – the surfaces connecting those points
• UV coordinates – how the BMP texture wraps around the shape
• Bone assignments – which part of the skeleton each point follows during animations

Mesh filenames always start with xskin-. Never rename xskin files – the name inside the file must match the actual filename, or the mesh won't load and the Sim may appear headless or as floating hands.

Vertices in detail: a vertex is a single point in 3D space. Each vertex has a position given as three numbers – how far left or right (X), how far up or down (Y), and how far forward or back (Z) from a centre point. A body mesh has hundreds of vertices; editing the mesh means moving these points around to change the shape.

Faces in detail: a face is a triangle formed by connecting three vertices. Faces are the actual visible surface of the mesh – what you see in game. The game wraps your flat BMP texture image over these triangles to create the clothed appearance.

Bone assignments in detail: each vertex is tied to one part of the skeleton (the skeleton bones are named things like PELVIS, SPINE, L_ARM, R_HAND). When the Sim walks, the leg bones move and pull any vertex assigned to them along with it. When the Sim waves, the arm and hand bones move.

This is why you cannot just move a vertex anywhere you like during mesh editing. If you move a vertex that is assigned to the L_LEG bone up to shoulder height but do not change which bone it is assigned to, the mesh looks fine in a still pose – but the moment the Sim walks, the L_LEG bone moves and drags that vertex back down, causing a visible spike or hole in the shoulder area.

UV coordinates in detail: every vertex has a UV coordinate, which is a position on the flat BMP texture image. The UV coordinate tells the game “this point on the 3D mesh corresponds to this pixel on the texture.” This is what makes the trouser texture appear on the leg and not on the torso.

When you reshape a mesh by moving vertices, the UV coordinates do not move automatically. If you make the trouser legs of a mesh longer by stretching the leg vertices, the trouser part of the BMP gets stretched to fit the new shape – pixels look elongated. To fix this you need to update the UV coordinates so the same pixels map cleanly across the new, longer geometry.

Custom wall textures that appear in Build Mode. Created by importing an image into HomeCrafter, which converts it into the game-ready format and generates the tiling pattern. Unlike skin files, wall coverings can be organised into subfolders.

Custom floor textures that appear in Build Mode. Same workflow as walls – import an image into HomeCrafter to generate the game-ready file. Subfolders are supported for organisation.

An intermediate file produced by SKN2OBJ when it converts a .SKN mesh. The SPJ records which body part each vertex belongs to – information that does not survive the trip through OBJ. When editing a mesh via the OBJ route, you open the SPJ in SKN2OBJ at the end of the edit, and SKN2OBJ combines it with the updated OBJ to produce the final SKN. Do not delete the SPJ before finishing a mesh – without it, body-part grouping is lost and the mesh cannot be reassembled.

A widely-supported plain-text 3D mesh format used as the editable intermediate in the classic Sims 1 mesh workflow. SKN2OBJ exports a SKN to OBJ for editing in MilkShape 3D or any other OBJ-compatible editor, then converts the edited OBJ back to SKN via the SPJ. OBJ files do not carry which body part each vertex belongs to – that information lives in the SPJ, which is why the SPJ must be kept alongside the OBJ. For adding a new accessory (a mesh attached to a body part, like wings), a separate OBJ is built in a 3D editor and then brought in through SKN2OBJ’s Import OBJ function – a dialog where you pick the OBJ file, give the new piece a full xskin-… name including its attach point, name a default skin BMP, and choose the attach site from a dropdown. The output of that dialog is a fresh SPJ which you then save as a SKN.

A plain-text file produced alongside an OBJ that defines material properties – primarily which texture image file to display on the mesh. SKN2OBJ generates an MTL when it converts a SKN to OBJ. The MTL is used by 3D editors to show the correct texture during mesh editing. Keep it in the same folder as its paired OBJ.

A binary mesh format used by some older Sims 1 content packed inside FAR archives. BMF files cannot be edited directly – they must first be converted to SKN format using BMF2SKN, after which they work like any other SKN. BMF files are uncommon and only encountered when extracting content from certain older FAR archives.

The actual images you see on the lot – the object rendered at fixed isometric angles. A full set of sprites covers 4 camera rotations (north, east, south, west) at 3 zoom levels (near, medium, far) – 12 frames for a non-symmetrical object. Bilaterally symmetrical objects (like the Pink Flamingo) only need 2 rotations because the game mirrors the opposite angles automatically, bringing the total to 6 frames.

Each sprite frame has three channels:

• Colour pixels – what you see on screen
• Z-buffer – depth information that tells the game how to layer Sims in front of and behind the object. Missing or incorrect z-buffers cause Sims to visually clip through the object.
• Alpha channel – transparency data

When you retexture an object using TMog's Export Whizzer, these are the images it exports as editable BMP files. You paint over the colour channel, and TMog regenerates the z-buffer and alpha automatically when you import back in. When creating new objects from scratch, the TS1 Renderer addon for Blender generates all rotation and zoom sprites plus their z-buffers automatically.

Small images used outside of gameplay. These are separate from the game-view sprites (SPR2) and serve specific UI purposes:

• ID 2000+ – the catalogue thumbnail, the small picture shown in the Buy Mode catalogue when you are browsing objects to purchase
• ID 4000+ – small speech bubble image, shown when a Sim thinks about or talks about the object
• ID 6000+ – large speech bubble image, same purpose as the small bubble but in a larger size

When you retexture an object with TMog, these images are not updated – the catalog thumbnail will still show the old appearance. To update it, create a new thumbnail in your paint program and import it using IFF Pencil 2 (right-click the BMP_ resource → Import).

Draw groups tell the game which sprite frame to display for each combination of camera rotation and zoom level. They map the SPR2 sprite frames to specific viewing angles – so the game knows to show frame 0 when looking from the front at close zoom, frame 1 from the back, and so on.

You rarely need to edit these directly. TMog handles draw group mapping automatically during the retexture workflow.

A 256-colour palette shared across the object's sprites. Each pixel in an SPR2 sprite references a colour by its index number in this palette rather than storing the actual colour value. This is why Sims 1 objects are limited to 256 colours per object.

TMog manages palettes during export and import, so you don't need to edit them directly for retexturing.

SimAntics code – the programming that controls what an object does. Each BHAV is a "tree" of numbered instructions. Every instruction is a primitive – a small built-in operation like "check a motive level," "play an animation," or "change a BCON value." You cannot invent new primitives; a BHAV is a specific sequence of existing ones wired together.

Each instruction has two outcomes: True and False. Each outcome points to either another instruction number (to continue the tree) or a special return code: 0xFD (Return True – the routine succeeded) or 0xFE (Return False – the routine failed). Following the chain of True/False branches from instruction 0 is how you read a BHAV.

Objects typically have multiple BHAVs for different purposes:

• Main (ID 4096) – the idle heartbeat loop that runs constantly while the object exists on the lot. Handles background tasks like checking if food has spoiled. This does not control the pie menu – that is TTAB.
• Init – runs once when the object is first placed on the lot or when a saved game loads with the object already placed.
• Interaction BHAVs – run when a Sim performs a specific action with the object (sit, study, eat, etc.). Each is called by a TTAB entry's Action Tree field.
• Test BHAVs – called by a TTAB entry's Check Tree field to decide whether an interaction should appear in the pie menu. Maxis follows a naming convention: Read a Book (action) paired with Read a Book TEST (check).

BHAVs can call other BHAVs, including shared routines from semi-global files (like ChairGlobals.iff or GlobalBathroom.iff). If a BHAV seems to disappear into a call you cannot find inside the object's own IFF, it is probably jumping into shared code in one of these files.

For a full walkthrough of how to read BHAVs, see the How BHAV Trees Work primer on the IFF Hacking page.

The Tree Table controls what appears in the blue pie menu when you click on an object. Each entry in the TTAB represents one interaction option (like "Sit," "Study Cooking," or "Watch TV").

Each TTAB entry has:

• Action Tree – points to the BHAV script that runs when a Sim selects this option
• Check Tree (also called Guardian) – points to a BHAV that decides whether this option should appear at all (for example, only showing "Study Cooking" if the Sim's Cooking skill is below maximum)
• Motive advertising values – eight numbers, one per motive (Hunger, Comfort, Hygiene, Bladder, Energy, Fun, Social, Room), telling autonomous Sims how attractive this interaction is for each need. This is what makes a hungry Sim walk to the fridge instead of the bookcase. If you want to change how appealing an object is for autonomous use, this is where you do it – not in OBJD.
• Flags – who can use this interaction: Adults, Children, Visitors, or any combination. Also includes flags for things like "must be next to object" and "can run while seated."
• Human Readable String Index – links each entry to its text label in the matching TTAs resource. Entry 0 uses label 0, entry 1 uses label 1, and so on.

Some objects have more than one TTAB. The Maxis IntelliHome desktop computer has four TTAB resources (Cheap, Moderate, Expensive, Very Expensive) because the game swaps which pie menu is active based on the object's graphic state.

The text labels that appear in the blue pie menu – the words a player actually reads when they click on an object. "Sit," "Read a Book," "Watch TV," "Study Cooking" are all TTAs strings. Each TTAs entry pairs with a TTAB entry by index: TTAB entry 0 uses TTAs label 0, TTAB entry 1 uses TTAs label 1, and so on.

When editing TTAs, change the text but never reorder the entries. The TTAB references them by position – swapping entries around would assign the wrong label to the wrong interaction.

Structurally, TTAs is a specialised form of STR# (string table). The editing tools treat it the same way – open the resource, edit text in a list, save.

One TTAs resource exists per TTAB. If the object has multiple TTABs (like the Maxis computer with four), there will be a matching TTAs for each one.

An array of numeric values that BHAV scripts read during gameplay. These are the "knobs and dials" of an object – things like comfort gain rate, skill teaching speed, energy drain, room score impact, and price. Changing BCON values is the easiest way to modify how an object behaves without writing any code.

Not every object has BCONs. Simple decorative objects (like the flamingo) may have only one, while complex interactive objects have many.

Example: the Maxis bookcase has 7 BCON groups named Side, Skills, Tuning - Time, Tuning - School, Tuning - Motives, Tuning - Skills, and Tuning - Room Impact.

Text data stored in numbered blocks, used for various purposes depending on the ID number. Different string table IDs serve different functions within the game. The most common ones you encounter in objects:

• ID 129 (a2o) – Adult-to-Object animation names, tells the game which animation to play when an adult Sim interacts with this object
• ID 130 (c2o) – Child-to-Object animation names, same as above but for child Sims
• ID 301 – Dialog text, the lines that appear in thought or conversation bubbles related to the object

Character files (Sims themselves) use a different set of STR# IDs for body skin references and outfit mapping. Many objects also carry additional STR# resources for specific purposes – MakeActionString strings (ID 302), Call Named Tree strings (ID 303), suit primitive strings and custom speech strings are common. Open the file in IFF Pencil 2 to see what your particular object has.

The master record for the object. Contains:

• Price – shown in the Buy Mode catalogue
• Catalogue category – which room and function section it appears in
• GUID – the unique identifier that distinguishes this object from every other object in the game
• Resource pointers – which TTAB for interactions, which DGRP for graphics, which SLOT for approach positions, which Main BHAV for the idle loop

Motive advertising values (the numbers that tell Sims how desirable an object is for Hunger, Comfort, Fun and other needs) are not here – those live in the TTAB, per interaction.

Multi-tile objects (beds, dining tables, sofas, the foosball table) have one OBJD per tile plus a master OBJD – the master is the one that appears in the catalogue, and the per-tile OBJDs handle the game's internal tile bookkeeping.

Points to the BHAV scripts that run automatically without a Sim clicking on the object:

• Init – runs when the object is first placed on the lot or when a saved game loads with this object already placed
• Main – the idle loop that runs continuously while the object exists. Handles things like checking if food has spoiled or if a plant needs watering.
• Load – runs when the lot is loaded from a save file

The object's name and description as they appear in the Buy Mode catalog. Contains text in multiple languages – the game displays whichever matches the player's language setting. When creating a custom object, you write your catalog text here.

TMog lets you edit catalog text directly without opening IFF Pencil – click "Edit Object" in TMog to change the name, description, and price.

Defines how Sims physically approach and interact with the object. Includes where the Sim stands, how close they get, which direction they face, and containment slots (positions where other objects can sit on top of this one – like a plate on a table or a book on a shelf).

SLOT editing is rarely needed for beginners. IFF Pencil 2 can display SLOT data but has limited editing support for this resource type.

References to sound files that play during object interactions. Each FWAV entry points to a sound effect (stored as .XA files in the game's sound archives). BHAV scripts trigger sounds by referencing FWAV IDs – for example, a chair might have an FWAV for the "sit down" creak and another for "stand up."

Tells the game which semi-global file to load shared behaviour routines from. Many objects share common code – for example, all chairs use the same "sit down" animation routine rather than each chair duplicating that code. The GLOB resource points to the right shared file (like "ChairGlobals.iff") so the object can call those routines.

You rarely need to edit this unless you're creating entirely new object categories.