Windkeeper was asking about the Objects Function table. Known as the OBJF filetype inside the package of an object, it has the same instance number as the OBJD (Object Data) file it goes with. There should be one OBJF for each tile that makes up the object.

The OBJF is a table listing the BHAVs that should be run when certain things - events - happen in the game. For instance there is somewhere to say what BHAV should be run when a user clicks on an object and picks it up, and one saying what BHAV should be run when a Sim wants to put a bill or his dinner down on your object. If you don't fill in a BHAV number for "Serve meal" then Sims will not be able to serve meals on your object - ie it won't be a table! One useful example of this is cloning a sink, and deleting the BHAV number in the "wash dishes" field. That means your sink will be a proper bathroom basin for personal hygeine only.

The OBJF is a little like the Pie Menu file, in that you can specify a test BHAV that should be run to see if the action BHAV should be run.

All OBJFs would be expected to have at least the Main and Init fields filled in, unless it is the OBJF for the Master of a multi-tile object. Masters are not really in the game, so they don't need to run anything. The entries for each tile's OBJF can point to the same BHAVs unless you want different parts of the object to do and allow different things.

The following list is taken directly from the WIKI here, so credit to whoever put it together in the first place.

0x1: init (The init tree is called whenever an object is reset. This happens when the object is first being placed, and if "Reset" is chosen after an object error.)
0x2: main (The main tree is the initial point of entry for the object's main simulation. Parameters may be passed to main if the "create object" primitive specifies.)
0x3: load (The load tree is called whenever an instance of the object is loaded from a save file. It is only called if the "object version" instance variable is different from the corresponding variable in the object definition.)
0x4: cleanup (The cleanup tree is called whenever an object is about to be deleted, or if a person's interaction with the object had to be aborted.)
0x5: queue skipped (The queue skipped tree is called if an interaction in a person's queue was deleted for any reason.)
0x6: allow intersection (This tree is a last resort hook for object intersection tests. If all the normal intersection tests pass, this tree is called to determine if two objects are allowed to intersect. Parameter 0 is the id of the object that is being tested.)
0x7: wall adjacency changed (This tree is called whenever the wall configuration around an object changed. At that time, the "wall adjacency flags" instance variable will indicate the new configuration.)
0x8: room changed (This tree is called whenever the room id of an object changes. At this time, the "room id" instance variable will contain the new room id.)
0x9: dynamic multi-tile update (If this function is defined for a multi-tile object, the object is "dynamic". This means that any time one is placed, it is joined with any neighboring objects. When the joining takes place, this tree is called for each object in the multi-tile group.)
0xA: placement (This tree is called any time the position of an object changes.)
0xB: pickup (This tree is called when an object is removed from the world (either to be deleted or to be re-placed in the world).)
0xC: user placement (This tree is called when the user clicks to place an object.)
0xD: user pickup (This tree is called just before an object is picked up by the user.)
0xE: level info request (This tree is called when the "level info" button is pressed. May not be used in final game.)
0xF: serving surface (This tree is used by people who are looking for a place to drop food.)
0x10: portal (If this tree is defined for a portal object, then the object may be used to transfer a person from one room to another. If two such objects are part of the same multi-tile group and lie in different rooms, then a person will push the tree to go between the rooms.)
0x11: gardening (If this tree is defined, then the gardener will use it to take care of the plants.)
0x12: wash hands (This tree is used by any person looking to wash hands.)
0x13: prep (This tree is used a person who is trying to prepare food.)
0x14: cook (This tree is used by any person trying to cook food.)
0x15: surface (This tree is used by a person who is looking for a surface on which to place an object.)
0x16: dispose (This tree is used by a person looking to throw away an object.)
0x17: food (This tree is used to eat an object. It is only used by the fridge to transfer control of the person to the food after it is created.)
0x18: pickup from slot (This tree is used by a person to pick up an object.)
0x19: wash dish (This tree is used by a person who is looking to wash a dish.)
0x1A: eating surface (This tree is used by a person who wants to find a surface suitable for eating.)
0x1B: sit (This tree seats a person. If the tree is defined, the game considers the object to be a chair.)
0x1C: stand (If a person is sitting and contained in an object, this tree must be defined so that the person may stand up.)
0x1D: clean (This tree is used by the maid to clean objects.)
0x1E: repair (This tree is used by the repair man to repair objects.)
0x1F: 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.)
0x20: Dry Clothes
0x21: Wash Clothes
0x22: Start Live Mode
0x23: Stop Live Mode
0x24: Link Objects (This tree is called so that the object can set links to the previous and next objects in a doubly-linked list of objects. The first parameter is the ID of the previous object in the chain (or -1 if this is the first object). The second parameter is the ID of the next object in the chain (or -1 if this is the last object).)
0x25: Message Handler (This tree is called when the object receives a broadcast message from the message primitive.)
0x26: Pre Route (This tree handles the transition from the idle-neutral pose, to the locomotion neutral pose (if they are different) at the beginning of a route. An example is of a toddler changing from sitting to crawling pose brefore routing.)
0x27: Post Route (This tree handles the transition from the ilocomotion neutral pose, to the idle-neutral pose (if they are different) at the end of a route. An example is of a toddler changing from crawling to a sitting pose brefore routing.)
0x28: Goal Check (This tree checks if the routing goal is still available. Its called on the object that issues the goto command. For example if a sim is trying to route to a seat, and another sim gets there false, this call can return false, allowing the sim to stop and choose another seat.)
0x29: Reaction Handler (This tree is called from a message handler tree, if the message receiver decides to actually handle the message.)
0x2A: Along Route Callback (This tree is called on the sim once per tile along the route, and can interupt it by returning false. This tree can be used to run idles while the sim is routing.)
0x2B: awareness (This tree is used by objects to advertise that they are interesting things to look at.)
0x2C: reset (Called when object is reset on loading of lot. This should never happen in shipped game.)
0x2D: lookatTarget (Called to choose objects to lookat along a route)
0x2E: Walk Over (When an object is walked over, this tree gets called.)
0x2F: Utility State Change (When a utility changes state, this tree gets called.)
0x30: Set Model by Type (Called to change the model based on a type defined in the game code. The first parameter holds the model 'type'. e.x. Modular stair railing types ( None | Left | Right | Both ).)
0x31: Get Model Type (Called to get the model type as defined by the game code. e.x. Modular stair railing types ( None | Left | Right | Both ).)
0x32: delete (Called before an object is killed.)
0x33: user delete (Called before an object is "deleted" or "sold" by the player, even if the object is not immediately killed.)
0x34: Just Moved In (Called on objects that have been created by moving in a sim that have objects they own from another lot.)
0x35: prevent place in slot (Called on container object during placement test for placing in a slot; return true to prevent placement even when all other tests pass.)
0x36: Global Awareness (Added to make Paul B's life easier.)
0x37: Object Updated by Design Mode (Called when Design mode updates an object, so we can set the correct state on it.)

BIG THANKS, Inge!! I'm reading it through right now!

*Edit* Wow! The first few lines of your post gave me the answer! That sculpture file I showed you in the other post, has 3 bhav functions. Only two are listed in OBJF! And guess what, I’ve been adding the lines of code to the function that is not listed in OBJF! Duh! I just added “My 0x0008” set to 3 into another Init function and it worked like a charm! Now the object can intersect with other objects and sims.

Now back to your post and read it ALL through :D

Glad it's finally sorted :D

I'm trying now to use your method, Inge, but I can't get it to work. I created a new bhav function, called it "allow intersection". Inside there is a single line with "My 0x0008" code. Then in OBJF I selected the line that read "allow intersection" and changed that to instance # of the new bhav function.

I don't have enough information. I don't know if you did that *instead* of setting the flag in the appropriate place. I think if you don't set the flag to allow intersection, it probably won't bother to run your function.

Inside the Allow Intersection function is not the place to set the flag. Instead to test that, put in a line such as "literal value 1 equals? literal value 1 - true - true"

Yes, I did that instead of setting the flag. I'm afraid I don't understand then the reason for making the new bhav function. How would I use it? Only to test if the action is working?

You don't need it if setting the flag in the Init does everything you want. Given your earlier problem and before I knew you were setting the flag in an init that wasn't being used, I suggested you additionally use a BHAV for the Allow Intersection function that would always return True, in case it needed that extra bit of help. We now know it does not.

The reasons you might want to use the Allow Intersection function call from the Object Function table would be if perhaps you wanted to only allow intersection with some Sims (you might test the age of the Sim in there), or you might want something extra to happen when you put the object in the same place as something else, like a dialog saying "Did you know you put the statue into the stove?"

Ah! That was an extra fix to force intersection to work. Got it! Learned a lot today! Thanks for all the help!

Nice info here. This really clears up a lot of mystery. This also explains a lot of strange errors I kept getting from certain experimental mods.

I suppose "Design Mode" is basically the same as "Build" mode when you have sims on the lot.

No I don't think so. "updated by design mode" is the event that happens when the player chooses another of the colour options for an object which is already purchased.

If you have a kitchen counter which is dirty, and you decide to change to another of its colour options, then it would need to remember it had been dirty and put the dirty material back on after you change the colour. The BHAV called by the OBJF for "updated by design mode" would take care of doing that.

Okay, so how do you obtain "Design Mode" if not by using "Buy/Build" mode?

Sorry I was confused by your question. Yes, I meant when you choose a new colour whilst in Buy mode. And it changes to Buy mode from Build mode if you select a non-build object. I wish it wouldn't. Sometimes it is hard to select a curtain instead of the window it is over and it would be nice if you could force it to one or the other via the mode you chose.

This may sound like a stupid question, but I'm very very new at this and just trying to learn how to do things. I uploaded my file in a thread about footprints because I couldn't figure out why the extra tiles I added could be walked through but not intersected with a wall. Sometimes the extra tile can be clicked on but other times it cannot. When I looked at the Obj functions they all linked to the exact same Init with the exact same instructions. The object I cloned was a base game 2 tile wide dresser (basically its 4 tiles because it has the 2 in front which can't be intersected by objects but that Sims can stand on). I made it 3 tiles wide and of course added a footprint for the new tiles. For some reason the tiles that were taken up by the original mesh are clickable and cannot be walked through while the original tiles in front can be walked through and are not clickable. I cloned the objfunctions for the corresponding tiles to create my new tiles but for some reason it didn't get the same result. The bounding mesh has no vertices listed. When I tried to add things to the bounding mesh it caused the game to crash whenever I selected the object.
When I look at the obj functions I see that they call upon something like 0x1001 for the init but I can't figure out where the init thingy has that number in the bhavs. (Does that make sense)? I also can't figure out why the obj functions are completely identical but the tiles behave differently. Any ideas?

First I need to tell you I have *no* knowledge of the intricacies of mesh clickability. There is stuff you can set while meshing to influence that and I can't help you with it the tiniest bit, and it's not within the scope of this thread anyway. You may like to refer this matter to the object creation and repair thread in another forum.

WRT what the OBJf is calling in your object, if you see it calling a BHAV in the 0x1000 range, then it will expect one of two things. Either the OBJf is in the local group 0xFFFFFFFF in which case your BHAV must be contained in the same package and be group 0xFFFFFFFF; or the OBJf is in a numbered group - maybe it is just part of a patch to an existing Maxis object - and in that case it can find the BHAV in objects.package or another package, also in the same numbered group as the OBJf.

Do remember that as well as in the Init BHAV, properties for a tile of an object may be held in its corresponding OBJD. So if you are puzzled why having used the same Init, one tile of an object is behaving differently from another, then check their OBJD settings, and also check with people who understand mesh footprints that you have not specified something unintentionally in your mesh import.

Hmm.. I think some of that went over my head. I really need to look at the file again and be more specific, but right now my computer is being slow.
I forgot to mention that I cloned the corresponding object data files for the tiles as well. The only thing I changed was the position of the footprint in the raw data thingy. So I think its likely that there is something in an external file. I'll have to read up on how to access external files or how to locate where it is linking to something external. Or something.. I wish I could just download all the info into my brain and immediately comprehend it...
Thank you for the reply.