Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Retired Duck
retired moderator
Original Poster
#1 Old 3rd Feb 2006 at 12:49 PM Last edited by Echo : 3rd Mar 2007 at 12:18 PM.
Default Tutorial: Fixing self-referencing objects
Note: This is *not* an introductory level tutorial, but many people experience this problem and there's not much else out there on it. If you do not feel very comfortable hunting around in packages and changing values using SimPE, I suggest you try postponing your particular object and working on one that isn't self referencing. They are by far a majority.

---
Self Referencing Objects

So 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 its 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 the way to fix it.

What's the problem? (The theory)
At some point in its lifecycle, 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". That would work fine, it'd be like me saying "wave to Echo". 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 "wave to Echo", but changing my name to something else. 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 behaviours for any references to the original GUIDs, and change them so they reference 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 referred to.

Now, you need to look at each of the BHAV resources in your package. If you don't have many BHAVs you may have to import them first, but in self referencing objects this is uncommon. (If this is the case with your object, read the section at the end of this post called "Importing semi-globals".)

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 all, 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 your 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.)

Now, say the 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, then 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 post is for people who had the misfortune to pick an object that didn't already contain the necessary BHAVs.

Importing semi-globals
If your object doesn't have many 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.
Screenshots
Advertisement
Lab Assistant
#2 Old 18th Jul 2006 at 3:10 PM
I'd just like to say thank you so much for this tutorial. It is really helping out creating new crops (I'm so proud of myself, lol). But one thing that almost got me; when looking thru the BHAVs in your crops, I almost changed the GUID looking for the harvest basket to be present to my new plant's GUID. Just thought I'd let you know that that can be tricky when you've never hard-edited a BHAV before.
Retired Duck
retired moderator
Original Poster
#3 Old 19th Jul 2006 at 10:51 AM
Yeah, you have to keep an eye out for those, that's why I suggest making the "from > to" table of GUIDs. If it's not in the "from", then you shouldn't need to change it.
Lab Assistant
#4 Old 24th Feb 2008 at 3:09 PM
I've made a replacement Robot Mesh with the servo robot for this months challenge but I'm having problems with it reverting back to the original after it initialize's, I've tried changing the original GUID with the new one, but it still keep's happenning. I've probably got too ahead with myself again. I've followed the tutorial above and realize this can be tricky as there are few different GUID's that I'm not sure about changing that are different from the original. Would appreciate your advice. Thanks angieb.

If at first you don't succeed, try and try again.
Thanks
Ange
Retired Duck
retired moderator
Original Poster
#5 Old 25th Feb 2008 at 9:52 AM
Hi Angie,

I'm not sure what you mean... Do you mean the unstarted servo that comes off the robotics bench? The unstarted servo is an object, but once it gets turned on it turns into a sim, and uses the bodyshop mesh for servosims. If you want to change that as well, then you need to create a default override package for the servo skin.
Lab Assistant
#6 Old 25th Feb 2008 at 10:12 AM
Hi Echo,

I wanted to create a sort of I Robot, one male and one female instead of choosing which sex you want it, as it initializes. I think I've gone too advanced for myself although I would like to learn how to do it if it is possible.
How would I make an override Package? It make's my idea seem easier now knowing that it turns into a sim, I noted the animation in the cres hierarchy and got confused because the actual mesh didn't have any joints I understand now why. Thanks angieb.

If at first you don't succeed, try and try again.
Thanks
Ange
Retired Duck
retired moderator
Original Poster
#7 Old 25th Feb 2008 at 10:47 AM
Override packages are done in bodyshop, so for that part you'd be better to ask over in skinning or bodyshop meshing, but there's a tutorial here on creating regular sim overrides:
http://www.modthesims2.com/showthread.php?t=194390

Not sure how up-to-date it is, since I've only made base override packages once and that was a couple of years ago now.

As for the other parts of your plan, I don't see any reason why your plans would be impossible, but certainly they're a bit tricky.
Lab Assistant
#8 Old 25th Feb 2008 at 4:01 PM
Thanks very much for your help I probably won't have it finished in time to enter it into the challenge but I'll give it a go anyway. Thanks again.

angieb

If at first you don't succeed, try and try again.
Thanks
Ange
Test Subject
#9 Old 26th Apr 2009 at 11:19 AM
i can't find a BHAV with a GUID in it
well at least it doesn't say GUID.
what is about the object instance?

could you please help me?
Retired Duck
retired moderator
Original Poster
#10 Old 26th Apr 2009 at 11:39 AM
What object are you trying to fix?
Test Subject
#11 Old 26th Apr 2009 at 11:50 AM
the remote control car
Retired Duck
retired moderator
Original Poster
#12 Old 26th Apr 2009 at 12:15 PM
The rc car comes in two parts which reference each other. You need to clone both the car itself and the controller.
Test Subject
#13 Old 26th Apr 2009 at 5:19 PM
oh thank you very much!
um where do i find the controller? i've simply used the clone function on the car but i didn't see a controller
Lab Assistant
#14 Old 5th May 2009 at 6:05 PM
"Toy - Remote Control Car" 0x7F419E89
"Toy - Remote Control Car - Joystick" 0x7FF79B62
"Toy - Remote Control Car - Race Marker" 0x7F9670E2
"Toy - Remote Control Car - Reserve Tile" 0x7F419E89

If you need help finding other objects, just go to the Object Data tree in SimPE with the objects.package file from your latest EP/SP loaded in SimPE. Click the Name bar under Resource List to sort the resources in alphabetical order. Then you can look through all of them to find what you need.
Back to top