The Sims™ Technical Aspects

rsmp Resource Format

Originally analyzed by Dave Baum. Documented by Greg Noel. Analysis of version one by Greg Noel.

A rsmp ("resource map") resource is a table of contents for an entire resource (iff) file. Although all of this information could be inferred from the resource headers, the rsmp is present on most .iff files. It probably allows much faster lookup and indexing of resources on slow-seeking filesystems such as those found on PCs. (The game does not care; objects in .iff files without rsmp resources work just fine. Moreover, other file types that use the IFF format, such as .wll and .flr, rarely have rsmp resources.)

In essence, the rsmp is a two-dimensional ragged array (or a list of lists) of references to the resources within the .iff file. The primary index is by the four-character type code and the secondary index is the entries of that type.

All numeric values in the rsmp are stored in little-endian order (least significant byte first).

The format of the rsmp resource is a twenty-byte header followed by one or more type lists.

The first field of the header is always zero. Its purpose is unknown, but many other resource formats have the same thing.

The second field is the version. This page documents versions zero and one. Version one first appeared in The Sims Online™ and has not been seen in any expansion pack.

The third field is 'rsmp' encoded as a little-endian integer.

The size is either zero or the total size of the rsmp resource.

The number of types is how many type lists are present. There is no type list for either 'rsmp' or 'XXXX' (the space-filler psuedo-resource, should these exist in the file); otherwise, there is one type list for each distinct resource type in the file. For example, a resource file with four STR# resources and three FWAV resources would have two type lists (STR# and FWAV), with four and three list entries respectively.

A type list identifies the type of resource, and lists all of the resources of that type.

The type lists are not sorted in any particular order.

The type code is the four-character type, such as 'FWAV', 'CARR', 'STR#', etc.

The number of list entries is how many resources of this type occur within the file. There is one list entry for each.

The list entries are not sorted in any particular order.

The offset is the location within the file of the resource header for the resource.

The ID, flags, and name string are copies of the corresponding information from the resource header. Presumably, they are here to improve search performance.

In theory, the ID, flags, and name string in the list entry should always match the resource header, but sometimes they don't; they probably aren't always updated when the resource header is changed.

In version one, either the ID field was expanded to four bytes or a new field of unknown purpose was added. Whichever the case, these bytes are always zero. (Note that the ID field in the resource header is only two bytes, so its upper bits will necessarily be zero.)

In version zero, the name string is null-terminated. If necessary, it is followed by an extra byte of zero to align subsequent fields on an even boundry. In version one, the name string is a Pascal-style counted string (one byte for the length, followed by the string itself). Subsequent fields are not aligned.