The Sims (Windows)/Unused Behaviors

This is a sub-page of The Sims (Windows).

Certain modi operandi in The Sims went unused. For the purposes of this sub-page, they are documented by the observed effort in engineering and implementing them in the game, albeit unused. This validation is based on evidence such as reminiscent graphics, animations, and text strings.

Note: Tested this with the original base build (1.0). A small number of the following features were repurposed for different objects and contexts in later expansion packs, not necessarily in the same way as originally intended. These repurposed features will be mentioned in the associated notes.

Sub-Pages

Sim Data Do genes influence skills?

Miscellaneous

Sim Features Stress is counterproductive.

Object Features Try not to urinate at the trees!

Properties

In the visual programming language that handles the behavior of objects in the game, "Expression" is a multi-purpose primitive that performs various logical and mathematical tasks. It can also be understood as the common denominator that provides basic instructions for determining how objects can manifest themselves within the game world. This includes checking their default heights, the types of surfaces they can be placed on (such as counters, floors, and end tables), and other physical properties.

Naturally, not all of these properties are utilized.

Object Placement

Object Heights

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Snapshot	Context
#std heights
16512	undefined
16520	low table	Sets the height of objects so they can be placed in surfaces lower than dining tables, yet higher than the floor. No surfaces in the base game use it, leaving a good share of "low table reaching" animations slip through the cracks. Only the bill object ever references this placement setting in its "init" script, heavily suggesting that the original purpose of "low tables" was to be somewhere Sims would drop hand items (bills included) on. The flag would be repurposed for Hot Date and subsequent expansion packs, where coffee tables were first implemented to the game as a verbatim revival of coffee tables frequently featured in pre-release screen snapshots but inexistent in the final product.	Pictured here are the various types of surface the game can handle; the object previewed over the highlighted tile is the one under the unused low table flag. One out of many samples of 1999 pre-release snapshots picturing coffee tables, where the low table flag may have been used at.	Only the bill object has a primitive that gives them the right conditions to be placed on "low surfaces" that don't exist in the base game. #std heights flag.

Wall Placement

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Snapshot	Context
STR# 229 - wall placement flags
1	wall required on right	Base game wall objects (paintings, toilets...) always face the opposite direction of any walls they're placed at, so these went unused. A similar placement setting would be used for some wall objects in later expansion packs.	Modified object with its wall placement flags manually set as wall required on right.	Alpha-channel graphic of a door, remnant of an old attempt in implementing North/South-facing sprites. wall placement flags
3	wall required on left
4	corner not allowed	You would think that these flags suggest that, at some point in development, certain objects could be snapped out of the tile grid's center, so they could be attached to the corner of tiles on the floor, terrain, walls, and fences. For some reason, though, this placement feature was removed in favor of a programming where objects always snap to the center of the tiles before they can be placed.	Modified object with its wall placement flags manually set as 6: diagonal required. Example of a visual development art by Eric "Irk" Hedman (ca. 1998), suggesting the implementation of 45º sprite rotation for 2D objects.
5	corner required
6	diagonal required	This flag indicates a scrapped concept where certain objects were originally meant to be placed diagonally only. No objects in the game meet this rule because object sprites were only created for placement in four directions, each at a 90-degree angle. There are unused tooltip strings leftover from this concept. There still exist leftover sprites reminiscent of this feature. Visual development arts reflect pre-release iterations where the concept for 45º 2D sprites may have been tested for the game before being ultimately scrapped.

Other

Behavior.IFF — 10 December 1999 14:10

#	RTS	Value	Comment	Snapshot	Context
STR#141 - Data labels
room placement		2	Forbids users from placing objects outside the houses, even though no object in the base game uses this. Repurposed in Hot Date and subsequent expansion packs, as ceiling lamps were first introduced to the game.	Object with its "Expression" myroom placement manually set as 2.	room placement flag.
rotation notches		1	Allows objects to be rotated in eight 45-degree directions, effectively enabling diagonal placement. This feature is technically underutilized rather than unused, for it is the default rotation value assigned to the three-dimensional Sims. Players can observe this when using the "move_objects" cheat code: Sims can be rotated in eight directions, while 2D objects are always limited to four (SW/SE/NE/NW). The existence of this rotation value suggests a potential intention during development to enable diagonal placement for certain objects. This idea is further reinforced by the presence of unused placement flags specifically coded for diagonal positioning. Players can hack objects to achieve 45-degree rotations by altering its "rotation notches" value. However, the missing diagonal sprite ID's will always appear as placeholder tooltips unless extra draw group ID's for the missing graphics are manually created.	Object with its "Expression" myrotation notches manually set to 1.	rotation notches
		4	Sets the rotation of the 2D objects to 180º, consequently always reversing its facing direction.	Object with its "Expression" myrotation notches manually set to 4.
		8	Sets the rotation of 2D objects to 360 degrees which, in practice, manifests itself as an instant turning that does not come across as a rotation at all.
STR#202 - Placement Flags
4	on door	Unused flags for objects meant to intersect doors and window tiles. Do not seem to work.			placement flags
5	on window
7	unused

Other Properties

Object Function

Function	Comment	Snapshot	Context
level info request	This tree is called when the "level info" button is pressed. May not be used in the final game. Calls a given event by the click of the "Level Info" button on the control panel, even though it has been entirely scrapped from the final build, which plays in a much more sandboxy fashion. Is only used in the Steering Committee proto on the five level-based lots, allegedly printing the scenarios' description on the screen.	Scrapped Level Info button in a 1998 pre-release.	level info request function and its developer description.
ui event	This tree is called in the current situation object when an event in the user interface occurs. The first parameter is the type of the event. The second parameter is the id of the event. Suggests an intention in the implementation of certain objects to have specific behaviors as a reaction to certain ui features as the picture-in-picture overlays. Not to be confused with the "ui effect" global primitive.	ui event function and its developer description.

Wall Adjacency Flags

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Snapshot	Context
STR# 208 - wall adjacency flags
2	wall in front = 3	These flags' original purpose is the modification of an object's property in case there's a wall in front or behind them. In fact, the staircase objects use similar flags for the means of removing their rails on adjacent walls in their left or right side. Later expansion packs repurposed the unused ID's for objects as awnings.	wall adjacency flags only see use in the stair objects: if they're placed next to a wall, their adjacent rail is then removed.	wall adjacency flags
3	wall behind = 4

Movement

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Context
STR# 203 - Movement Flags
0	sims can move it	At some point, Sims might have been able to somehow rearrange the objects in the house at their will, under unknown circumstances. In normal gameplay, players can only move objects via "Hand Tool". Sees shy use in The Sims Online as the payphone object (somewhat loosely) references it in a "ClearFlag" expression in its "init" script, preventing Sims from moving it, if the engine allowed them to do so.	movement flags
2	self propelled

Statuses

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Context
STR# 142 - flags for flag field
0	unused		flags
7	unused
STR# 214 - Flags for Flag Field 2
0	CanBreak	Older mechanics for setting different deterioration states for an object — electronics, house plants, the aquarium etc. Final objects handle their dirty/broken statuses under more complex Private scripting trees they carry independently.	flag field 2 In the object constant database, an obsolete temperature is listed.
1	CanDie
6	Fixable
11	CanGetDirty
12	ContributesToAsthetic (sic)
3	ObstructsView
4	Floats	Suggests an intention in development in implementing a number of items that could drift indefinitely or be placed over the water, either by swimming pool or artificial pond tiles.
8	GeneratesHeat	May refer to older mechanics for a temperature system in the game. No objects use this flag. Objects that, by definition, could have find it handy (as fireplaces, stoves...) have, instead, Private scripting trees that simply set how they increase the lot's "Room" motive score, without any explicit remark on how "warm" the room gets. Earlier in development, the unused object constant "temperature" — which would allegedly benefit itself from items that "generate heat" — may have been intended to play a big part in simulation, but it's irrelevant in gameplay, as no object is coded to check the objects' "temperature" value.
9	CanBeLighted	"GeneratesLight" is used, instead.

Miscellaneous

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Context
#visitor schedule
16394	Walk By	Exact purpose unknown; it might refer to an old flag for handling arriving neighbors.	#visitor schedule
#Children Grades
17408	A+	Certain object events call flags that check or change the school grades for child Sims. These are never used.	#Children Grades
17409	A
17410	A-
17411	B+
17413	B-
17414	C+
17417	D+
17418	D
17419	D-
17421	F #2
17422	F #3
#Global Tuning
16642	dislike	Adjust two Sims' relationships to "Hate". In the final game, friendly and romantic relationships are noteworthy events in gameplay signified by the help system and graphics ( and ), while extremely low relationship scores among Sims don't heavily impact gameplay save for a number of hostile interactions that the player has access to in this context. The final game has an unused sprite for the "Hate" relationship status: .	#Global Tuning
16643	Hate
16645	Tile Distance for Shoo	Might refer to early mechanics that handle the distance allowed for two Sims to be in the bathroom without one asking the other to go away in case their privacy is disturbed.
#category
17152	unknown	Unused flags belonging to an old object categorizing convention that objects such as beds and showers still have in their "init" scripts as early remnants. At one point, it might have been used to trigger certain events in case one object of their respective kind was found in the house.	#category
17153	phone
17154	level
17155	job
17160	column

(Source: LUCPIX)

Primitives

Behavior.IFF — 10 December 1999 14:10

#	RTS	Comment	Context
STR# 139 - Primitives
21	show string	An early "dialog" equivalent. It used to somehow print raw texts attached to an object's data on the screen as pop-up windows and/or tooltips etc. Contrary to "dialog", this primitive does not have any options to add indexed "_BMP" images close to the printed text, or any other special features. Only old, unused trees indexed in the stove and fridge objects use this primitive.	show string
38	~unused	Headline" is also the filename prefix for scrapped sprites that warned players about the Sims' feelings, so this primitive might be an early equivalent of "set balloon".	"Set Headline", ~unused as its string.
39			"Show, Hide" primitive, ~unused as its string.
40			"Run Typed Tree", ~unused as its string.

(Source: LUCPIX)

Primitive Features

user event

Sample of a Small PIP window.

user event

Once applied to the script for a given object, the "user event" primitive coordinates and displays some of the features that visually signify important Sim events, as the animated Picture-in-Picture overlay. Even though the engine can handle "Small", "Medium" and "Large" windows fine, the objects in game only use the latter two.

(Source: LUCPIX)

Unused OBJD and OBJf Entries

Putting these together because the OBJf is basically an extension of the OBJD. And if we keep putting an extension on the previous extension, the table will be a big circle. Many OBJD entries are unused in favor of the OBJf (and, indeed internal notes discourage using the OBJD in place of the OBJf). If no OBJf is associated with an object, the game will use the OBJD values. Some of the earliest made objects were never updated to have an OBJf. For this reason, the technically-unused-but-exists-as-a-functional-fallback OBJD entries won't be included. Most aren't even interesting.

• version_2 - Never set to anything other than 0. version_1 is always set to 138.
• sale price - This is never used. The game calculates the sale price from the buy price and the initial and daily depreciation values.
• shadow brightness - Does not seem to work.
• level info request - This button does not exist in the final game. If it did, objects could react to it.

(Original research: Leo Gruen)