The Sims™ Technical Aspects

SLOT Research


The following information is not based on any proprietary knowledge or restricted documentation—it was entirely derived from observation, experiment, and public information, thus it may be inaccurate or incomplete.

PRELIMINARY

Analyzed by Peter Gould.  Documented by Greg Noel.  BADLY NEEDS TO BE PROOFED (and have the spellling corrected)! 

Although there are a lot of SLOTs in the game, information sufficient to analize them is sparse, since there are only a few dozen distinct varieties. 

The SLOT resource most likely defines locations relative to an object where a character can approach.  The virtual machine instruction "go to routing slot" probably evaluates the slots described in this resource and takes the character to the closest one. 

If an STR# resource with the ID 257 exists in the same IFF file as the SLOT resource, it contains the labels for the slots. 

Fill in stuff here...

In the description below, integers are in little-endian order (least significant byte first).  Also, floats are IEEE short float format with the bytes in little-endian order. 

SLOT Resourse Format
Offset Size Value
0 4 zero
4 4 version
8 4 'TOLS'
12 4 count (N)
16 var repeating group 1
var var repeating group 2
var var . . .
var var repeating group N

The SLOT resource begins with a more-or-less typical header, followed by a series of repeating groups. 

The first word of the header is zero. 

The second word of the header is the version number.  Versions 4, 6, 7, 8, 9, and 10 have been observed in the field. 

The third word of the header is the string "SLOT" in little-endian order. 

The fourth word is not a part of the header and contains the count of repeating groups. 

Following the count are the repeating groups themselves. 

repeating group
V Offset Size Value
? 0 2 integer@0
? 2 4 float@2
? 6 4 float@6
? 10 4 float@10
? 14 4 integer@14
? 18 4 integer@18
? 22 4 integer@22 (flag)
? 26 4 integer@26
4 30 4 integer@30
5 34 4 integer@34
? 38 4 integer@38
? 42 4 integer@42
? 46 4 integer@46
6 50 4 integer@50
7 54 4 float@54
8 58 4 integer@58
9 62 4 integer@62
10 66 4 integer@66

About the only thing that is definitive about the SLOT resource is the span width of the repeating group.  The span varies with the version; additional elements are added with each new version. 

The span for version 4 is 34.  The span for version 6 is 54.  The span for version 7 is 58.  The span for version 8 is 62.  The span for version 9 is 66.  The span for version 10 is 70. 

In the table at left, the version where the field first appears is shown in the column labled 'V'.  Using the reasonable assumption that at least one field was added in each version, we can deduce when some of the fields appeared; the others are marked with a '?'. 

Analysis of the integer field values suggests that all of them are four bytes.  It's possible that some of the four-byte fields are pairs of two-byte fields, but from the ranges of the values involved, only the integer at offset 62 is very likely. 

It's also possible that a two-byte field is two one-byte fields (the patterns as numbers and as bitfields are both logical), but it seems just a bit more likely that they're all integers. 

This link contains a very simple analysis of the values found in each field.  For each unique value in a field, it lists how many times that value was found and the value both in decimal and hex.  In general, the fields have relatively few values, but that doesn't go very far in figuring out what they mean.  A breakdown by field has also been done for type zero, type one, and type three

Don Hopkins' Transmorgifier now imports and exports slots.  Below is the XML generated for the SLOT resource of an example file; it has one each of the two primary types and offers some interesting fieldnames to consider. 

     <slots>
         <slot
             name=""
             id="128">
             <slotdescriptor
                 type="0"
                 xoffset="0"
                 yoffset="0"
                 altoffset="4"
                 maxsize="100"
                 flags="0"
                 height="5"
             />
             <slotdescriptor
                 type="3"
                 xoffset="0"
                 yoffset="0"
                 altoffset="0"
                 rsflags="1"
                 standing="1"
                 sitting="1000"
                 ground="0"
                 snaptargetslot="-1"
                 facing="-2"
                 minproximity="16"
                 maxproximity="128"
                 optimalproximity="48"
                 gradient="0.025"
                 resolution="16"
             />
         </slot>
     </slots>

The sections below analize each field and give the best guess for its name from the fieldnames above.  In the cases where the field may not exist because a version of the SLOT format does not contain it, a best guess at a default value is given. 

integer@0

The integer at offset 0 only has the values zero, one, and three.  It clearly controls the interpretation of the other fields, so it's a type of some kind. 

A SNAP or GOTO-SLOT instruction in a BHAV resource always references a type three slot, so it presumably controls the routing of a character. 

This would be the type field. 

float@2, float@6, float@10

The floats at offsets 2, 6, and 10 all seem to have similar patterns.  Changing the values in the first two fields affects the X and Y position relative to the object, respectively.  It's not too great a stretch to assume the third field is for the Z position (height). 

If in front of the object and facing it, positive X is to the left, negative X is to the right, positve Y is toward the back, and negative Y is toward the front.  Measurements are relative to the center of an object.  (((Peter should confirm this.)))

Peter reports that "the difference between 0xC0000000 and 0x40000000 is about 1/4 of a tile."  Converting the hex into float values, the former is -2 and the latter is 2, so the unit of measure is presumably one-sixteenth of a tile. 

The float at offset 10 is always zero for type three, reinforcing the premise that type three controls routing for characters (which would never be at non-zero heights). 

These would be xoffset, yoffset, and altoffset

A reasonable default value for all of them is zero.

integer@14, integer@18, integer@22

These three fields are only non-zero for type three. 

The integer at offset 14 has the range 0, 1, 2, 9, 10, and 100.  The integer at offset 18 has the range 0, 1, 2, 9, 10, 100, and 1000.  The integer at offset 22 has the range 0 and 1.  They could all have the same range (with values not present for all), in which case they could match up with the previous three fields. 

Alternately, the integer at offset 22 could be a flag; it only has been observed to have the values zero and one. 

The triple that seems to match these three integers are the three positions standing, sitting, and ground.  The example has a sitting value of 1000, which only occurs in the integer at offset 18, strengthening the presumption. 

A reasonable default for these is zero, although it's unknown what a character will do if no preference is given. 

integer@26

The integer at offset 26 is non-zero only for type three.  Peter reports that it seems to affect positioning. 

The integer at offset 26 is most likely a bitfield.  With a few exceptions, all of the values have only a few bits set, and the exceptions tend to have a series of bits set.  Decoding this will take a lot of experimentation. 

The obvious candidate is rsflags

Zero should be a reasonable defalut; about half of the type three slots have that value, so it's certainly common. 

integer@30

The integer at offset 30 is always -1 for types zero and one.  For type three, about 65% of the values are -1 and the remainder are integers less than 289.  Of the latter, all values from zero to 288 are present. 

This is probably snaptargetslot, with the small integer being a global(?) position. 

The obvious default is -1. 

integer@34, integer@38, integer@42

The integers at offsets 34, 38, and 42 all have very similar patterns of values.  In all cases, types zero and one are either one or sixteen, with sixteen being about 90% of the cases.  Type three is sixteen in about 90% of the cases, one in about 9%, and scattered for the remaining cases, with most of the values being either multiples of sixteen or values close to that. 

The sample minproximity value is sixteen, making it a good candidate for one of these integers, since distance is likely to be in multiples of a base value.  By symmetry, maxproximity and optimalproximity would be the other candidates. 

Of the three integers, only the integer at offset 38 has values of 128, making it maxproximity, and suggesting that the integer at offset 34 is minproximity and the integer at offset 42 is optimalproximity

It's interesting to note that in the vast majority of cases, all three would be sixteen.  If the unit of measure is one-sixteenth of a tile, this would cause the required distance to be exactly one tile. 

The best default value for each field is probably sixteen. 

integer@46

The integer at offset 46 is non-zero only for type zero.  Type zero only has the values 0, 10, and 100, with 10 being almost 60% of the cases, and 100 being almost 40%.  Fewer that one percent of the values are zero. 

This is most likely maxsize

Ten is the dominant value, so it's the most reasonable default. 

integer@50

The integer at offset 50 is always zero.  For whatever reason it was added, it's obviously not used.  The next value is a float, so it's also possible that this value is a float. 

After all the other fieldnames have been assigned as candidates, the one left over is flags

Since the only value found is zero, that should be the default. 

float@54

The most common value by far is 0.1875; virtually all of type zero and type one slots have this value, and it's the dominant value for type three slots with 95% of the cases.  Of those remaining, over half have the value three, and more than half of the residue have the value zero. 

The only float value is gradient

The example XML shows this only for type three slots.  In actuality, non-zero values occur in all three types. 

The default probably should be 0.1875. 

integer@58

The integer at offset 58 is always zero for type three slots and virtually always zero for type one slots.  For type zero slots, it only has the values zero through nine, with five being the most common by far (zero is fewer than 1% of the cases). 

Behavior.iff STR#130?  Or maybe STR#131? 

The most logical candidate is height

Obviously, the default for type one and three slots is zero.  For type zero slots, zero is almost certainly wrong, so those default values probably should be five. 

integer@62

The integer at offset 62 is always -2 for slot types zero and one.  For slot type three, -2 is the dominant value (over 95% of the cases); in addition, -3 occurs, as well as a scattering of small integers in the range of zero through twelve. 

This is the only integer that has -2 in its range, so it's the candidate for facing

The default probably should be -2. 

integer@66

The integer at offset 66 is always sixteen for types zero and one.  For type three, sixteen also dominates (more than 97% of the cases), but there are a scattering of other values, most notably eight and 24, which are half and half-again of the base value.  Zero occurs in a negilable number of cases. 

This most likely resolution

The most reasonable value is sixteen. 

repeating group
V Offset Size Value
? 0 2 type
? 2 4 X offset
? 6 4 Y offset
? 10 4 alt offset
? 14 4 standing
? 18 4 sitting
? 22 4 ground
? 26 4 rsflags
4 30 4 snap target slot
5 34 4 min proximity
? 38 4 max proximity
? 42 4 optimal proximity
? 46 4 max size
6 50 4 flags
7 54 4 gradient
8 58 4 height
9 62 4 facing
10 66 4 resolution

Here's the repeating group again, with the likely fieldnames filled in. 

Fill in stuff here...

Fill in stuff here...

Fill in stuff here...

Fill in stuff here...

type

Peter sez: Each type of slot is indexed separately, so assuming that the order within a type is the same, these sequences are functionally identical:

	type 0, type 0, type 3, type 3
	type 0, type 3, type 0, type 3
	type 3, type 3, type 0, type 0

Don's words: [Peter's analysis] is correct: each type of slot goes into its own list, and has its own sequence of index numbers.  The SLOT resource contains a list of slots, each which has its own type field, and the slot types can be interleaved in any order.  When they're read in, they're collated into the appropriate list according to their type, so slots of the same type keep their relative order, and each type starts numbering from 0. 

Fill in stuff here...

X offset, Y offset, alt offset

Fill in stuff here...

Fill in stuff here...

Fill in stuff here...

standing, sitting, ground

After a character has been routed to the destination area, these three fields control what the character will do there.  The value of these fields gives a preference of whether the character will remain standing, sit down, or (((get on the floor: lie down?))). 

For example, if standing is one, sitting is 1000, and ground is zero, the character will be strongly encouraged to sit (on a chair, a sofa, or whatever) rather than stand; they will not lie down. 

Fill in stuff here...

Fill in stuff here...

rsflags

Don Hopkins' XML documentation identifies these meanings for the bits:
faceanywhere=-3 (face anywhere) (duplicate; should be -1 instead?) (can also be achieved with 0xFF or 0x100?)
facetowardsobject=-2 (face towards)
faceawayfromobject=-3 (face away) (duplicate; should be -1 instead?)
n=1, ne=2, e=4, se=8, s=16, sw=32, w=64, nw=128 (character can face any directions indicated)
allowanyrotation=256 (signifies that character is not required to face one of the 8 directions after coming to a stop)
absolute=512 (goal coords should not be rotated to object's direction)
facingawayfromobject=1024 (not used, use faceawayfromobject instead)
ignorerooms=2048 (slot can ignore room boundaries)
snaptodirection=4096 (for snapping, if direction of character should be set to direction of object)
randomscoring=8192 (specifically for wandering behavior)
allowfailuretrees=16385 (comes from primitive when route is invoked)
allowdifferentalts=32768 (if start and goal may be at different heights)
useaverageobjectlocation=65536 (use average object location)

Fill in stuff here...

snap target slot

Fill in stuff here...

min proximity, max proximity, optimal proximity

Fill in stuff here...

Fill in stuff here...

Fill in stuff here...

max size

Fill in stuff here...

flags

Fill in stuff here...

gradient

Fill in stuff here...

height

Fill in stuff here...

facing

Fill in stuff here...

resolution

Fill in stuff here...


Reminder: This information is not based on any proprietary knowledge or restricted documentation—it was entirely derived from observation, experiment, and public information, thus it may be inaccurate or incomplete.

Valid XHTML 1.1! Valid CSS!
Copyright © 2001-2008 Dave Baum and Greg Noel. All rights reserved.
The Sims™ is a trademark of Maxis and Electronic Arts.
This page was last modified Tuesday, 19-Apr-2005 13:53:32 UTC.
Made on a Mac
SourceForge