This section was prompted by an email about pedestrian portals in Downtown lots; my buyable pedestrian portal wasn't showing up there in Buy mode. Nor should it, because Downtown has its own pedestrian markers, just as Vacation Island, Studio Town and other visiting lots do, and these different portals/markers should not end up on the wrong lot. The car portal, on the other hand, is common to all. The Downtown portals were easily made buyable, but neither IFF Pencil nor Maxis provided the means to set the buyable flags for Vacation Island and higher. For once, Mac users had the advantage: version 1.1.1 of IFFSnooper has very many new features, including the setting of buyable flags for all lot types up to and including Magic Town.
Not everyone has access to a Mac, it looks as though IFF Pencil has had its final update (although maybe the extra flags can be made visible by editing its parsing script - but I lack the knowledge) and so categorizing buyables for higher expansion packs promises to be a matter of hex-editing by hand. Which, if you know where to look, is quite easy; Doctoring the stats is a howto for changing career and interests which chiefly involves counting down the bytes. Nothing has to be added, it's a simple matter of locating the byte and changing it from "00" to something else. At which point I should add that the buyable flags work with double bytes, so it's a question of locating the right byte pair, and the smaller value comes first, so "9" is written "09 00" and not "00 09", and the bytes are in hex, so "9" is our decimal nine, but "10" equals sixteen, and the numbers include letters.
First, an explanation of the category system. In the original Sims, it was possible to buy objects and materials in Buy and Build mode. Each mode had its categories: Build mode divided its goods up in walls, floors, windows etc. while Buy mode had two ways to present the wares: either by room type, subdivided into functions (ie. "Bedroom | Decoration") or directly by function. The latter way of sorting goods was evidently more convenient - I prefer buyables classfied as chairs, plumbing etc., and who decides what belongs in a bedroom anyway? - but as there were only eight headings for any categorization, certain things got lumped together (notably, beds were included in "Seating") and the list of objects under each function became very, very long.
The room and function categories in residential-lot Buy mode.
So, in Hot Date, a subsort was introduced: in the function sort, there were now five sub-functions. Why not eight sub-functions, you may ask? Presumably for consistency with the Hot Date Downtown sorting system, and maybe to leave room for later expansions. With the latest two expansion packs, the function "Misc" was given two more subfunctions, "Pets" and "Magic". And with that, the bar was filled, because the eighth position was already occupied by the infinity sign that signifies "All".
The Misc. subfunction with all expansion packs installed.
The Downtown sort uses the categorization method for lots other than Sim homes. This method is a step backwards, as again goods are categorized by "room" rather than by their function (for "room", read Shopping, Dining, Outdoors etc.) and subcategorized by function. Fortunately (though some people may feel it only confuses matters) one item can turn up in several "rooms". This form of categorization is also used for Vacation Island, the Unleashed "community" lots, Studio Town and Magic Town. Residential lots, whether in the expanded Unleashed neighbourhood or high up in Magic Town, still use the old Simsville categorization: eight rooms with eight functions, or eight functions with five to seven subfunctions.
Categories in the Downtown, Vacation, Magic Town and Studio lots.
Putting an object in a category works as follows: fill in a value at the relevant byte. This byte is found by counting down from the start of the OBJD block. In the average hex editor, it's a question of scrolling down until the string "OBJD" appears in the column to the right of the hex screen, walking over the object's name string with the cursor and hopping to the first "00" after the string's terminating zero; that is the first byte in the first double byte. (No need to start counting at zero here.) Hop to the third "00": that's the first part of the second double byte. For the sake of convenience, I'm going to count each byte pair as one, so byte 97 means the 193rd byte (97 x 2 - 1). The second byte in the pair won't need editing, as the value to fill in is never high enough to require two bytes. The Build value differs from the Buy value in not being a binary progression - rather than being 1, 2, 4, 8, the Build categories are simply numbered 1 to 7 - but it is assigned in the same way.
(Because I'm never exactly sure which byte is the terminating zero, I use another method: the object's GUID is in byte pairs 14 and 15. One starts to recognize object GUIDs after a while, especially when they contain one's own magic cookie, so I hop to the GUID and then count from 15 onward.)
All double bytes pertaining to categories are:
The Build/Buy toggle makes no difference in practice; I opened a tree object from the Build category "plants", and its Build/Buy toggle was set to Buy value. I presume the game checks whether it's the Build or Buy bytes that have a value, and only resorts to the toggle when both types are filled. Or maybe, like the "sale price" field, it's ignored altogether.
The values for the Room and Function bytes can be found in Making objects buyable. In the same spirit, these are the Build and Function subsort values:
| Flag | Description | Dec. value | Hex value | Flag | Description | Dec. value | Hex value |
|---|---|---|---|---|---|---|---|
| Subsort | 1 | 1 | 1 | Build | Pool | 7 | 7 |
| Subsort | 2 | 2 | 2 | Build | Walls/fences | 6 | 6 |
| Subsort | 3 | 4 | 4 | Build | Stairs | 3 | 3 |
| Subsort | 4 | 8 | 8 | Build | Fireplaces | 5 | 5 |
| Subsort | 5 | 16 | 10 | Build | Plants | 4 | 4 |
| Subsort | 6 | 32 | 20 | Build | Doors | 1 | 1 |
| Subsort | 7 | 64 | 40 | Build | Windows | 2 | 2 |
| Subsort | 8 | 128 | 80 |
Wallpaper, floor tiles and roofs are not in this list; they have no OBJD block and are accessed in a different way.
The names of the sorts in the five types of non-residential lot are:
| Lot | sort 1 | sort 2 | sort 3 | sort 4 | sort 5 |
|---|---|---|---|---|---|
| Downtown | Dining | Shops | Outdoors | Street | Misc. |
| Vacation Island | Lodging | Shops | Recreation | Amenities | Misc. |
| Old Town | Food | Shops | Outdoors | Street | Misc. |
| Studio Town | Food | Shops | Studio | Spa | Misc. |
| Magic Town | Food | Shops | Magico | Outdoors | Misc. |
The Downtown, Vacation, Old Town, Studio Town and Magic Town sorts all work on the same principle: there are five types, with the values 1, 2, 4, 8 and 128, and the value in the categorization byte is the added value of any sorts the object is to be available in. Listing all combinations:
Each sort opens into eight functions: the original eight functions of the normal catalogue, though with different graphics. So, as well as filling in a value for the non-residential subsort, the buyable object must be assigned a Function category. If both Room and Function have a value, the object will also be buyable on ordinary lots. If only the function is filled, it will only appear on non-residential lots.
With this information and a hex editor, it should now be possible to make any object buyable on any type of lot.
Note! I've read somewhere that an object categorized for a given
expansion pack will crash in an installation without that expansion pack,
so objects categorized for Magic Town should crash in SS, those categorized
in Studio Town would crash in UL, those categorized for Vacation Island would
crash in HD andsoforth. However, I've found that UL, at least, can handle
categorizations up to Magic Town. It is possible that other-lot categorizations
can cause problems in Deluxe/HD, and quite likely that they will do so
HP/LL/The Sims, where the internal coding is different and non-residential
lots didn't exist yet.