Echo's SimStuff Header

Fixing self referencing objects

You've created a wonderful new mesh object that looks great in game, but for some unaccountable reason, it doesn't work right your new GUIDs. If you leave the old GUIDs in place and let your object overwrite the existing object in game, it works fine. What the???

There's a good chance that the object you cloned is self-referencing, that is, somewhere in it's behaviours it does something based on a hard coded GUID. By changing the GUID you've stopped the object from working. The technique for fixing this has been around for a long time, but tends to be described on an object-by-object basis. This tutorial is a very generalized explaination of the problem and a few ways to fix it. This is *not* an introductory level tutorial; if do not feel comfortable hunting around in files and changing values using SimPE, I suggest you try postponing your particular object and working on one that isn't self referencing. There are by far a majority.

What's the problem? (The theory)
Basically, at some point your object is refering to itself in a sort of third person. Say an object has the guid 0x11111111, and at some point there's a command saying "look for the object with the guid 0x11111111", or "make sure that this is the object with the guid 0x11111111", or something like that. That would work fine, it's like me saying "and then Echo went down the street". I'm refering to myself by name, but so long as I keep that name people will still know what I'm talking about.

But when you create a clone of the object, you change the guid. So now your object has a guid of, say, 0x22222222, but the code's still looking for an object with the guid 0x11111111. It'd be like me saying "and then Echo went down the street", but changing my name to something else, say "Narcissus". There would be a lot of confusion, which is why your objects start doing crazy or unexpected things.

What's the solution (The practice)
The short of it is that you have to look through all your object's behaviour for any references to the original GUIDs, and change them so they now use the new GUIDs. Depending on the object, this can be relatively easy or extremely hard.

The first thing you'll want to do is make up a table showing which new GUIDs replaced which old GUIDs. So for the example above, it would be:
0x11111111 > 0x22222222
This is even more important if you have an object with multiple GUIDs, because you have to make sure that the right part of the object is being refered to.

Now, you need to look at each of the BHAV resources in your package. If you don't have any BHAVs, you'll probably have to import them first, but in self referencing objects this is uncommon. Nevertheless, I'll explain this process at the end of the document.

When you open a BHAV resource, you will see a list of commands in boxes down the left hand side of the plugin window. Each of these commands tells your sim or your object to do something in particular. Look over them, you're looking for commands that have a GUID listed in them. These commands often (but not always) begin with "Set to Next" or "Test Object Type". Here's an example of one in the wedding arch:

At this point you need to look up your table of old and new GUIDs, and find which one the command is referencing. In the above image, it was the GUID 0x2C92CDB3. Use the table to find what GUID you replaced it with, so you can put it in the BHAV. (If the GUID is not one from your original object, it is best to leave it as it is. It's probably looking for another object in game which it needs to function.)

Say your new GUID was 0x12345678. Break this up into pairs of numbers: 12, 34, 56, 78. Now reverse them: 78, 56, 34, 12. On the right hand side of your screen is a set of small text boxes labeled "operands". Enter these four numbers, in order, in the first four of these boxes. If you look at the description of the command now, you should see that the GUID has changed to match your own.

Commit these changes, then keep searching through the BHAVs. If there's one reference, there's a good chance there will be others. You'll need to find them all to get the object to work correctly.

When all the BHAVs have been fixed, save the object and try it again in game. Hopefully, it works. :) If not, the object is even more complicated than this and probably needs a lot more attention to get it to work. :(

That's it! The rest of this stuff is for people who had the misfortune to pick an object that didn't already contain the BHAVs.

Importing semi-globals
If your object doesn't have any BHAV files, you may need to import them from the semi global library.In most cases, self-referencing objects don't use semi-global libraries very much, but the details are here in case.

The first thing you need to do is find out which semi-global library your object uses. Open the GLOB file in your object, and look at the value in the "Name" field. That is the name of your semi-global library. Now go to the Tools menu, and select "Object Tools" > "Import Semi-globals". A window will open up. In the drop down menu at the top of this window, find the name of the semi-global library, and press "scan". You will get a list of the contents of this semi-global library.

The brute force way to get the affected files is to import every BHAV file at once. Keep in mind that doing this will stop your object from being affected by most global hacks that would normally affect the object, as well as making the package very big. However, it's the most sure way of getting the thing to work. To do this, just hit "import" and start hunting as described above.

The more elegant way of doing this involves finding those BHAV files that need to be changed, then tracing their call path back to an entrance behaviour and importing everything along that path. This can be very time consuming and is less certain to work, but also means that patches and hacks are more likely to affect your objects, that your object more likely to be compatible with different EPs, and that the file size will be much smaller.

Entrance behaviours are starting points in your object. They can be called by the game directly, like "Function - Init", or called by user actions through pie menus, called "Interactions". (CT functions can be entrance functions as well, as they can be called by other objects in game). These entrance behaviours often call other behaviours while they are running. If you need to change a behaviour that is called by an entrance function, you need to import both of them. In fact, you have to import all the behaviours that call the modified behaviour, and all the behaviours that call them, and so on all the way back to the entrance behaviours. This can get very confusing and messy, but is generally not necessary. In most cases, references by GUID are either kept local, or are very close to entrance behaviours.

This site is not endorsed by or affiliated with Electronic Arts, or its licensors. Trademarks are the property of their respective owners. Game content and materials copyright Electronic Arts Inc. and its licensors. All Rights Reserved.