DISCLAIMERThis is NOT a tutorial; it is intended to help average-experienced object creators performing specific tasks, or to give users a deeper in-sight on specific modding-related subjects. So, don't expect to find step-by-step explanations, to be performed "blindly". Please DO NOT REPOST the following info, or part of them, on other sites.

CREDITS: Some of the following information can be found scattered on the various forums, but special credits go to Kopperman for having collected and organized them, and for having provided a lot of additional info, by experimenting on the various partitions. Kopperman will mantain this thread, adding new information as he gathers them; and will answer to questions about the subject of this article.


SUMMARY
This article will try and give a detailed in-sight on the various parameters that affects the behaviour and exterior look of the "Partitions", i.e. those build elements that can be creating using the "Wall tool": walls, fences and fence-arches.

This InfoCenter article is also provided in PDF format. To view it, we strongly suggest to download the Foxisoft PFD Viewer: it's free and small, less than 1Mb!

PART 1 - AN INTRODUCTION TO PARTITIONS

The Partitions are defined in several text files, located into [gamedir]\EA Games\The Sims 2\TSData\Res\Catalog\Scripts. Actually, each EP has its own "script" folder, that contains the same text files; all these text files are read when the game starts, though, so far, only the files in the base-game folder actually contain partitions definitions.

These files are:

• Walls.txt, that defines walls, including poolwalls, deckskirts, foundation walls and the like.
• Fence.txt. that defines fences (but read important note below)
• FenceArch.txt, that thefines the "Fence-Arches": there is only one in the game (the "Linking Logs Trellis Archway"), that is like a fence, and can be built like a fence, but looks like an arch and the sims can pass under it.

NOTE: unlike the walls and the fence-arches, the fences are actually treated by the game as objects: they are defined by a bunch of "Fence XML" files included in the "catpatterns.bundle.package", which is located in the TSData\Res\Catalog\Patterns folder. Nevertheless, the "Fence.txt" does contain a fence definition (only one), that is supposed to be the default fall-back fence definition to be used by the game when it can't find the right fence definition.

NOTE: the "Half Walls" introduced with the Nightlife expansion are fences: they are defined by the "Fence XML" files contained in the Nighlife "catpatterns.bundle.package"

Partitions can be warped, stretched, squeezed, on the vertical axis. The only limits being that a partition can not be compressed to less then 4 clicks high. That makes the smallest floor height also 4 clicks or as some have come to measure one section of modular stairs.
Partitions considered walls (precisely, "load bearing partitions", i.e. partitions that can bear a floor/roof over them) can be built up to one square from the edge of your lot. Walls running parellel to to lot edge seem to be limited to two squares from the edge itself, but in reality it is limited due to the inner edge of the outer square. The outer edge of your lot can not be raised or lowered. it is locked in the position it is in. Fences, halfwalls, non-load bearing partitions can be built in this last square with the "moveobjects on" cheat. Later you will see that you can make a fence load bearing, and that you can still build the fence to the edge of the lot, but you will still be unable to actually place any floor tiles on the second floor or higher at the edge. So far, no workaround has been found to solve this problem.


Since the Fence.txt contains only one not-in-catalog default fence, and the FenceArch.txt contains only one arch definition, we will concentrate on the Walls.txt, that is the most interesting file. But never forget that the game consider all the named txt files as one (including the ones located in the EP game folders): this means, for instance, that the same ID number assigned to a wall cannot be assigned to a fence or a fence arch.



PART 2 - THE PARTITIONS DEFINED IN THE "WALLS.TXT"

Here is a list of parameters that can be adjusted from within the Walls.txt file, and the meaning of each of them.

CatalogTextResource. Don't play with this. It doesn't do anything but give you information when you click on the tool in the game.

Wall n. You have to assign a new number for each new wall, fence or fence arch you want to make. It must be unique, between 1 and 255. Remember all partitions in the game share the same number space, so you can't duplicate for a wall a number that is already being used for fences, or fence arches.

HINT: The wall #1 is the standard wall, the most used one. We know, by now, that the wall number must be unique within all the walls and fences (-arches); therefore, if you create a new custom fence with SimPE, and assign it GUID 1, it will override the standard wall: in other words, you'll be able to replace the standard wall with a custom one. Use with caution, though! And remember that a lot created using such a fence (and the fence itself) cannot be shared with other users.

DefaultPattern. This is the name of the wall treatment that you want to be placed on your partition when it is first created. It must be a name found in the wallPatterns.txt, not in the material base. If you are comfortable with SimPE, then you can look up the the material base and create your own entry in the wallpattern.txt; and then use your custom wall patterns as the default wall treatment for your custom wall.

WallThickness. Accepted values are either "standard" (what the regular wall looks like) or "none". Please note that "none" doesn't really mean that the wall has no thickness at all; it is rather the thickness of glass, or of the lattice around the deck. Use in conjunction with blocksLight false (see below) and you can get interesting screen-like effects.

NOTE: After building a wall that has thickness none, applying (in game) a different wallpaper will make the wall lose the transparency.

MayChangeSurface. True or False. A no brainer here: if true you can recolor with the wall treatment tool, if false you can't.

MayAttachObjects. True or False. Seemingly a no brainer, but actually it doesn't work to let you attach objects to non-wall partitions. This parameter seems to have only one purpose, to let the user attach wall-mounted objects, windows and doors to foundation walls. In any case, you can not attach objects to the wall if the game feels you shouldn't for some reason. Thus if you want to attach objects to the foundation wall, the best solution is to use the "moveObjects on" cheat. But for windows and doors the situation is different, because windows and doors will not cut the proper hole in your wall if the moveObjects cheat is used to force the door or window there. Therefore, if you are planning to use windows and doors on foundation walls, you need to change the "MayAttachObjects" parameter to "true".

HINT: Even if you turn this option to "true" for foundation walls, you will still be unable to attach doors and window as long as you have foundation flooring. So remove this and you will be able to use the exposed portions of your foundation just like any other wall. Deleting a portion of the foundation wall and adding a normal wall won't help. It is the fact that the game considers anything under foundation flooring to be underground and thus unable to have windows and doors. Removing the flooring is the best, and really only option.

MayCutAway. True or False. If set to "true", the wall will be cut away to let you see inside (you need to set the game view to "walls down" or "auto", for the cutting away to work, obviously).

RequiresFlatBottom. True or False. Very useful option. When set to "true", walls tend to level the ground they are being placed on. Set to false and you now have easy walls that conform to your terrain.

RequiresFlatTop. True or False. Usually your tops are flat anyway. But in the case of wanting to build new walls under various curved roofs made using the ConstrainFloorElevation cheat, then you will need to have this set to false.

NOTE: Setting to true the RequiresFlatBottom and/or the RequiresFlatTop lets you create fairly interesting slanted walls, very useful in conjunction with advanced building tecniques. But please be sure to read the last note in Part 4 (sharing lots containing custom walls)
NOTE: Using doors and windows on slanted walls is always affected by a known issue: the "wallmask" (i.e. the "hole" cut by the window in the wall) gets slanted, too, while the window is not; as a consequence, the hole won't align any more to the window.

Submersible. True or False. Wether you can place the wall in water. Not just for pools: have this true so you can build little castles under your lakes.

mayPlaceDiagonally. True or False. Default is true. Lets you place diagonally as well as straight. A side note on diagonals here. You may have noticed in your game that you get an error now and again saying can't build diagonally. This is because partitions can not intersect each other except on the grid square corners. Because of the way grids are layed out, it is possible that two diagonals will not meet up at the corners and thus you won't be able to place the partition there. You will just have to make small adjustments in your plans. Nothing can be done about this. Second side note, for those that plan everything out before hand. Diagonal partition sections are approximately 1.4 times as long as the straight sections.

VerticalSpan. Accepted values are: "floorToFloor", "floorToRoof", "fixedHeight", "floorToFloorBasedCeiling".

FloorToFloor is the default and what you see most the time.
FloorToRoof is what is used when making dormers and adding roofs with the roof tool: it isn't very useful for the roofs made using the ConstrainFloorElevation cheat.
FloorToFloorBasedCeiling. This makes the wall end flush with the underside of the floor above it as opposed to flush with the top of the floor above it. Use it to keep strange lines from appearing in your beautiful roofs due to the walls below it, especially with CFE-made roofs.
FixedHeight. I played with this for a long time and it really isn't an option except for Maxis fences. The fixedHeight just doesn't have any parameters itself and can not be used to make various halfwalls 1\4 walls, etc. Maybe one day, when we learn to create new partition meshes, it will be more useful. It also will not change the height of fences. Nor can you expect a fence of fixed height made to be load bearing to have a floor at the fixed height. The floor will be the default 16 clicks high. You will have to lower it yourself.

BlocksPlacement. True or False. It doesn't actually block placement so much as determines whether it affects placement of objects on the same level as the partition. If false then you can place objects where you please even in the middle of the partition. If true then the partition is taken into account on where you can place the item. Some items will be allowed to be placed right up to the partition some may not be allowed within 2 squares. Yes a minor distinction between this and blocking the placement of objects, but an important distinction for those the use cheats heavily when building.

BearsLoad. True or False. Determines whether you can place something on the floor above it. Normally true for walls, false for fences. Some new interesting possibilites with fences may arise with allowing them to bear loads. A fence can be made to bear loads in the fence.txt by simply creating a new fence and then filling in the model info. You can then turn on or off whatever options you want for that fence type. A new fence type will be created in fence tools, it won't effect the maxis fence itself.

BlocksLight. True or False. Quite self-explanatory: when set to "false", the partition will allow the light to pass through. Use this in conjuntion with wallThickness and wallPattern to create interesting effects. Basically wallThickness none and blocksLight false gives you a transparency effect, wherever the wallPattern doesn't cover the wall.

HasLightMap. True or False. I can think of no good reason to turn off the light map for your wall. But this will do that. Lighting will no longer effect the way the wall looks.

NotRendered. This has no options. If you add it to your wall then the wall just will not be rendered. It won't be there visually. This means you can't attach things to it, nor can you change the surface treatment. It still will be there in all other ways, to include blocking placement, blocking sims from passing through it, casting shadow, blocking light, bearing loads. That is unless you change those options also...

DeleteTool. Accepted values: "Partition", "roof", "levelRoom", "modularStairs". You can only choose one, so don't go adding them all hoping that you can delete partitions with any tool you like. I have found it useful to change the deletion tool from "levelRoom" to "partition" under the foundation walls to allow easy basement modification. Makes for horrible foundation deletion though. You have to delete each wall individually if you make that modification.

RequiresSupportUnderneath. True or False. Sort of a funny option. Set it to "false" and you no longer get the error that it requires support underneath; nevertheless, if you do not have the squares letting you know that a floor would be supported there, it won't let you build. Still, set it to false and you don't have to add all those floor tiles before you can build a wall across the gaps.

ThumbnailResource. The Instance number (in hex) of the thumbnail associated to the wall type. The game store all the graphics, including the wall tool thumbnails, in the big "ui.package", located in the Res\UI folder. The graphics associated to your custom wall must be into the ui.package: this means that you can't create a custom icon for it (unless you edit the ui.package!).

CatalogTextIndex. The reference for the text to be used as description for the partition tool; all the text references are included in the Build.package, located in Res\Text.

BuildTipIndices. The reference for the text to be used as building tips; these tips are also included in the Build.package (instance 0x91).

NotInCatalog. Add this to you partition if you don't want it to show up in your tool catalog: useful, for instance, if you are just making a new pool wall, so you don't want the wall itself to show up in your catalog, just the pool tool.


PART 3 - SHARING CUSTOM WALLS

This is a very important point, because - as explained - creating a custom wall or editing an existing one requires modifying a game file, the walls.txt.
Sharing a custom wall is only useful if you want other users to use it to build their lots: if you are only planning to share a lot containing custom walls, then read part 4.
First of all, when sharing a custom wall, you must be sure to assign a unique wall number to it. To do so, check the Custom Wall Repository, in order to see which numbers are already taken; and then you should reply to the Repository in order to inform everyone of the numbers taken by you.
When you upload your custom wall, you have to give information about its installation: explain in the most detailed way as possible the steps required for the users to find and edit the walls.txt; don't forget to remind users to create a backup copy of the walls.txt before doing anything!


PART 4 - SHARING LOTS CONTAINING CUSTOM WALLS
You might think that when you share a lot containing custom walls, everyone that downloads your lot must edit its walls.txt in order for the lot to be correctly displayed. This, in most cases, is not true.
Many of the parameters listed in section 2 only affects the building phase, and are not used by the game to display the lot.
For instance, if you edit the "MayAttachObjects" and the "MayChangeSurface" in order to apply some sconces and a wallpaper to a basement wall, who downloads your lot will see the sconces and the wallpaper even with the original Maxis walls.txt.
Obviously, this method works only if you edit a wall already existing in the walls.txt: if you create a brand new wall, with its own custom wall number, downloaders need to edit the custom wall accordingly!
Therefore, when creating a lot that you want to share, if possible, create your "special effects" by editing a Maxis wall; only if this is not possible, then you should create a new wall.
When is it not possible to use this tecnique? When your "special effects" requires editing a parameter that is read by the game every time it displays the lot; for instance: wallThickness, mayCutAway, blocksLight, hasLightMap, notRendered. If your wall uses a custom settings for these parameters, you have no choice but to create a new wall, with its unique wall number, and share it with the lot.
In most of the other cases, you can just edit an existing Maxis wall, build your lot and share it, without asking the downloaders to do anything to their walls.txt file.

NOTE: in most cases, a lot built with the requiresFlatTop and the requiresFlatBottom doesn't need to create a custom wall: you can just edit the default wall in your own walls.txt. But in some cases, especially when the roof is bent using the ConstrainFloorElevation cheat, the wall underneath the roof may get flattened (thus creating a visible hole) when the lot is packaged and shared.
The same happens when the slanted wall has objects attached to it: the game engine needs to know where to place an item and so checks the wall and all the properties of the wall for proper placement. In doing so it might decide that the requiresFlatTop true in the users wall.txt should be honored and it flattens out the wall for you.
A good solution is to share the lot leaving the slanted walls free from objects and windows: doing so, the risk of flattened walls are reduced to minimum.

OTHER USEFUL RESOURCES

Modding Infocenter Index - Comprehensive list of all the InfoCenter threads
Custom Wall Repository - If you are going to share your custom wall, check here for the numbers already taken by other users.