PACKAGE File Documentation

Summary

An .package file from an Electronic Arts game is a Maxis DBPF archive (Database Packed File): a binary bundle of game resources (meshes, textures, tuning XML, audio and catalog data) used by The Sims 2, 3 and 4, plus SimCity and Spore. It is the standard form of Sims custom content and mods. A genuine EA package starts with the ASCII tag DBPF at offset 0. The same extension is also reused by unrelated software (Visual Studio, Unreal Engine) without that tag.

Technical details

Feature	Value
Full name	Electronic Arts / Maxis DBPF Game Package
File extension	`.package`
MIME type	`application/octet-stream`
Format type	Binary DBPF archive (Database Packed File)
Developer	Maxis / Electronic Arts
Introduced	The Sims 2 (2004)
Used by	The Sims 2, 3, 4; SimCity; Spore
Open standard	No — format documented by the community
Byte order	Little-endian
Magic number (hex)	`44 42 50 46` (ASCII `DBPF`)
Header	`DBPF` tag + 4-byte major and minor version
Resource identity	Type / Group / Instance IDs per index entry
Typical contents	Meshes, DDS textures, tuning XML, audio, thumbnails
Cross-game compatible	No — Sims 2/3/4 versions differ despite the shared tag
Editors	Sims 4 Studio / s4pe (Sims 4); s3pe (Sims 3); SimPE (Sims 2)
Installed by	Copying into the game’s Mods folder
Same-extension (unrelated)	Visual Studio/SharePoint package; Unreal `.package`/`.upk`
Related extensions	`.sims3pack`, `.sims4pack`, `.ts4script`, `.dbc`, `.dat`
Specification	`simswiki.info/wiki.php?title=DBPF`

File signature (magic bytes)

44 42 50 46

Offset 0, 4 bytes, ASCII DBPF (“Database Packed File”). This tag marks a Maxis/EA game package. It is immediately followed by two 4-byte little-endian integers, the major and minor version, which differ between The Sims 2, 3 and 4 — so the games are not cross-compatible even though every one of their packages shares this same DBPF header. The tag is also the reliable way to distinguish a real EA package from the unrelated .package files written by Visual Studio/SharePoint or Unreal Engine, which do not begin with DBPF.

What is a PACKAGE file?

The dominant meaning of a .package file is Electronic Arts game content stored in the Maxis DBPF container. DBPF stands for Database Packed File, the archive format Maxis introduced with The Sims 2 in 2004 and carried through The Sims 3, The Sims 4, SimCity and Spore. A single .package bundles many game resources — 3D meshes, textures, tuning XML, audio clips, catalog and thumbnail data — into one indexed archive. For players, .package is the everyday form of downloadable custom content (CC) and mods.

The extension is overloaded: Microsoft Visual Studio and SharePoint, Unreal Engine (.package/.upk) and various generic installers also use .package for entirely different formats. Those do not carry the DBPF tag. The reliable way to identify an EA game package is its first four bytes, DBPF. The sections below describe that DBPF structure and how the game and its editors work with it.

The DBPF header and version tag

A package begins with a fixed header. The first four bytes are the ASCII tag DBPF (44 42 50 46), and they are immediately followed by two 4-byte little-endian integers: a major version and a minor version. Those version numbers are what separate the games. The Sims 2 uses DBPF version 1.x, while The Sims 3 and The Sims 4 use version 2.x with a different index layout, so a package built for one game will not load in another even though all of them start with the identical DBPF tag.

offset  size  field
  0      4    "DBPF"           magic tag
  4      4    majorVersion     1 (Sims 2) / 2 (Sims 3, Sims 4)
  8      4    minorVersion
 12     12    reserved / dates (layout depends on version)
 ...           index count, index size and index offset
              (exact fields depend on the DBPF version)

The header ends with the location of the file’s index table: how many entries it has, how large it is, and where to find it. The version dictates exactly which header fields hold that information, which is why an editor must know the game version before it can even list a package’s contents.

The index table: Type, Group and Instance

DBPF is a database, not a plain file dump, and its index is what makes it one. The index table lists every resource in the package, and each entry identifies its resource by a triple of 32-bit IDs plus a location:

Index field	Meaning
Type ID	What kind of resource it is (mesh, texture, tuning, audio, catalog…)
Group ID	Which group/subsystem the resource belongs to
Instance ID	The specific resource’s unique identifier (64-bit, split high/low)
Chunk offset	Absolute position of the resource’s bytes in the file
File size	Stored (possibly compressed) length
Mem size	Uncompressed length
Compressed flag	Whether the chunk is compressed

The combination of Type, Group and Instance (often written as a T!G!I key) is the unique address of a resource inside the package. This is how the game and editors find a specific texture or tuning entry without unpacking everything: read the index, look up the wanted T!G!I, seek to its chunk offset, and decompress fileSize bytes into a memSize buffer. Because each entry carries its own compressed and uncompressed length and a compression flag, resources can be individually compressed, and unchanged resources can be copied between packages by their key.

Resource chunks: meshes, textures and tuning

The bytes each index entry points at are the actual resource chunks. Textures are typically stored as DDS images (the DirectX texture format, with mipmaps), which is why exporting a texture from a package to a .dds and re-importing an edited one is the normal retexturing workflow. Meshes hold the geometry of an object or a piece of clothing. Tuning resources are XML that define gameplay values and behaviour. Catalog resources carry the entries that make an item appear in the game’s build/buy or create-a-Sim menus, along with thumbnails. Many of these chunks are compressed, indicated by the index entry’s compression flag, so reading a resource means decompressing its chunk into its declared uncompressed size.

Installing a package versus editing one

Using a .package and editing it are different actions. To use custom content you do not open the file at all: you copy it into the game’s Mods folder (for The Sims 4, Documents/Electronic Arts/The Sims 4/Mods, up to one sub-folder deep), enable Custom Content and Mods in the game’s options, and restart. The game reads the DBPF index at load time and pulls the resources in. If CC does not appear, the usual causes are that mods are not enabled, the file is for the wrong Sims version, it is nested too deep, or it broke after a game patch.

To inspect or edit a package you need the editor that matches the game’s DBPF version, because the wrong editor cannot read the wrong version: Sims 4 Studio or s4pe for The Sims 4, s3pe for The Sims 3, and SimPE for The Sims 2. These tools read the index, let you browse resources by their Type/Group/Instance key, and export or re-import individual chunks. A related distribution wrapper is .sims3pack, the EA-launcher format for Sims 3 content; tools can convert a .sims3pack into loose .package files that go straight in the Mods folder.

Not every .package is a Sims file

Because the extension is generic, a .package from a non-game source is a different format entirely. Microsoft Visual Studio and SharePoint use .package for solution packages; Unreal Engine uses .package and .upk for asset packages; some installers use it for generic archives. None of these begin with the DBPF tag, and none open in a Sims editor. If a .package did not come from a Sims/Maxis context, check the first bytes: no DBPF means it is one of these unrelated formats and needs the software that created it.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents