I've determined that if I enable LL's Teen WooHoo, then I can't drive to a community lot. The icon just fades away. If I disable teen woohoo, then driving to a community lot works. This is in OFB with NL and UNI all installed. The problem occurs on a home business lot in Bluewater Valley. That's basically as far as I've gotten.

Should I just report the problem and do nothing? I'd rather try to figure out what's going on, if that makes sense. I'm a software engineer with many years experience, and I've dabbled from time to time with trying to write Sims 2 hacks, and I wrote a few for Sims 1, so it's not impossible that I might be able to figure out more about what's going on.

But even then, does it make more sense to investigate whether or not teen woohoo might be interacting with some other hack by removing all the other hacks and seeing? (It's late and I'm on my way to bed or I've had tried that one already). Or does it make more sense to make a copy of the waterbed package and start removing BHAVs to see which one might be causing the problem?

Or what? I'm willing to spend some time working on narrowing this problem down, but I'm wondering if someone with tons of experience could make some suggestions about overall approach....

I have SimPE -- and I'm mostly capable of being dangerous with it at this time.

I should add that if I remove All hacks, then driving to community works. And I tried deleting/replacing the car. I tried resetting the car. I tried using a taxi. I don't have but maybe 10 or so actual hacks installed.

---------------

I decided to stay up a bit longer and run the obvious experiment of removing all other hacks. And it started working. So, unless someone has a better idea, I guess it's just a simple binary search tomorrow to figure out what hack is interacting with Teen WooHoo to cause this problem. I should have tried that before I posted.

Do you have the latest version of that hack?

Yeah. I've got the 6f OFB version.

I don't see how it could matter, but I was trying to make changes to the BHAVs in it, using SimPE, but the first thing I tried was to revert back to the original, straight from the downloaded zip file. Still, it seems suspicious to me that I was mucking with it and that now I'm experiencing troubles with it. This was the first time I'd tried driving to a community lot in weeks, so I have no idea if there was a problem before I started trying to make changes to the BHAVs. But wouldn't reverting back to the original, straight from the downloaded zip file, undo any damage I could have caused?

I disabled all the packages that Clean Installer flagged as red, plus all the packages that the Sims 2 flagged with a yellow triangle and an exclamation mark, leaving, of those, only Teen WooHoo enabled, and it still fails. Makes me wonder if I really saw it work when used all by itself last night, but I'm basically certain that I did. Still, the first thing I'll do when I get home tonight is to reverify that. And then it's time for a binary search to find which non-obvious packages need to be installed to make Teen WooHoo fail. I only have about 1,900, so it shouldn't take more than 10 tries to isolate it, assuming that there's only one involved.

Are you sure you restored it from the archive? Try deleting the package and replacing it with the copy from it's archive.

I even went so far as to go to the Inteenimator site, redownload the Teens WooHoo from there, and replace my copy with that one. I currently have the conflict narrowed down to two or more package files out of a group of 269. I'll soon have the culprits pinpointed!

---------------------

Now down to 51 files, but I have to go back to work now. Sigh.

About half of those 51 files have names something like "character_segment_for_upload_xxxxxxxxxx.sim". Are those legit? I think there were also some "lot_segment_for_upload" files, but I forget their extension.

Anyway, it's gonna be interesting to see which packages are conflicting with Teen WooHoo -- and why!

I found some packages that just out-and-out made Teen WooHoo fail, but the packages looked corrupted; things like MAIN and INIT that didn't point to anything that SimPE could digest. So I took them out.

But -- there's still a problem and it's apparently load order related. If I rename Teen WooHoo to start with "__", so that it sorts to the front of the directory listing, then everything works, otherwise not.

So I'm going to consider this thread as handled -- and will open a new one asking about possible information concerning load order dependencies...

Files in the downloads folder are opened in alphabetical order, folders coming before files in the same folder. Once a resource is loaded once, it's not loaded again.

So this would mean that if A.package redefines a global BHAV, and B.package also redefines the same global BHAV, that the one in B is what get used, yes? And the same with semi-globals from the same semi-global file?

I noticed this morning that I have crammyboys nude packages renamed to start with zCboy, and I vaguely recall having done that because I read somewhere to do that because it *had* to load last if package xxxx was also being used. But I can't remember what "xxxx" was, nor can I find anything mentioning the problem. Sigh.

But I don't think the problem had anything to do with crammyboys stuff. It was still loading last, even while Teen WooHoo was screwing up.

Wouldn't it be luverly to have some code that would scan the download directory and subdirectories, read in the package files -- and show which globals and semi-globals were being redefined and, especially, which ones were being re-redefined, plus, of course, the file names of the packages doing it?

If there's some documentation about how to read a package file, I could probably manage to write this myself...

That's being worked on here: http://ambertation.de/simpeforum/viewtopic.php?t=2891.

That sounds like it'll be Very Nice and much more powerful that what I had in mind, but it also sounds like it's gonna take a bit. For another couple of hours work I can have code that will do the very little thing of finding conflicting BHAVs and identifying them -- and I really, really want that ability. So, I think I'll plow on ahead. I threw together a bit of Delphi code this morning which can properly identify the BHAVs in one package. It should be almost trivial to go the next step of scanning for and reading multiple packages, then displaying the conflicts.

I basically have a program that will find BHAV conflicts, but I have a slight confusion. From what I read in echo's excellent tutorial on BHAVs, an opcode in the range of 1000-1FFF is a local. And mostly that makes sense to me from the data I'm seeing as I scan package files. But.....

With minor exceptions, all of the BHAVs in that opcode range also have a Group ID of 0xFFFFFFFF. But occasionally I run across one with a different Group ID. For example, both Teen WooHoo and Community Aging have a BHAV with Group ID = 0x7F07FBBC, Instance ID (opcode) = ox103A, and a description of "CT- Young Enough For Pregnancy?".

Those don't fit the pattern and so I'm confused. Are they truly locals? Or are things with opcodes in the range of 1000-1FFF only globals if-and-only-if the Group ID = 0xFFFFFFFF? Or does the Group ID of 0x7F07FBBC signify something else entirely that I'm missing?

I *think* I am just a handful of minor details away from having this little program be able to identify BHAV conflicts.

The range 0x1000-0x1F00 is local to the object in it's group. A group of 0xFFFFFFFF will be given a randomly-generated, nonconflicting group id when the game loads (these are stored in groups.cache). If it already has a group it will override the corrisponding resource for one of Maxis' objects (all of which already have group ids). All resource with the exception of the one's dealing with meshes and textures (which use 0x1C000000) use 0xFFFFFFFF for custom objects.

Ah ha! So, if I'm properly understanding this, a BHAV with Group ID = 0x7F07FBBC, Instance ID = 0x103A, will override the *local* BHAV 0x103A for whatever object has Group ID 0x7F07FBBC. Yes?

And, I'd assume, there's a way to trace the Group ID back to the associated object, such as to know from whence it came?

Thank you so much, btw, for your help. I know this little program isn't going to set the Sims Modding world on fire, but it is definitely helping me get my toes wet, plus it will at least be somewhat useful while we await that much nicer plugin that you mentioned.

Right.In the next release, you'll be able to clone objects in OW using their group id (Group 0x7F07FBBC is the Age Controller)

I now have a little program that will find and report global and semi-global BHAV conflicts. Is this worth sharing? If so, where would I find out how to go about that?

This is the forum: http://www.modthesims2.com/forumdisplay.php?f=4.

I would like to chime in on this. What you describe here is something I've long accepted as truth (indeed I was one of the first people asserting this observation as fact), and most of the modding community now accepts the "alphabetical load ordering" theory as fact. However, something recently surfaced during the InTeenimater OFB beta that made me dig a little bit deeper into this and now leads me to believe this is not universally true and is potentially the source of many headaches for many people who may have hundreds - even thousands - of mods in their game.

After careful analysis using a number of file IO tools, I discovered that the game loads package files in the same sequence as the underlying file system sees them. On Windows XP or Windows 2000 running an NTFS file system, files are always indexed alphabetically with subfolders appearing after (not before). In essence it is "breadth-first" traversal of the directory structure and then alphabetical by file. Indeed this is exactly the same order that we have all come to expect with respect to package load ordering. I would say, that this holds for the large majority of Sims 2 players (fortunately!)

However, one of my beta testers experienced a phenomenon that nobody else on the test team could replicate: their InTeenimater flavor paks were being loaded BEFORE the core InTeenimater packages (flavor paks are add-ons/extensions to InTeen that are designed to augment the base feature set and intended to load after the core package files). This is despite the fact that the flavor paks follow alphabetically AFTER the core packages. Naturally, I assumed this would be sufficient. Indeed many authors assume this, as there are a whole host of mods that start with 'z' in their name to ensure late loading.

I wrote a little program (attached), which enumerates the directory structure in the same order that the game "sees" the files. What I observed may surprise you:

With the exception of the one beta tester I mention, everyone (including myself) experienced identical alphabetical ordering:

ME_MindControlMirror.package
InSIMenator (UV) v2.3 DEST Edition.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package
InTeenimater_F.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_FlavorPak_SameSexPregnancy.package

Not surprisingly, each one of these testers have an NTFS file system running on Windows XP. NTFS is the default file system for all new Windows XP installations.

However, the one beta tester I mentioned, running a FAT32 file system, experienced this ordering:

InSIMenator (UV) v2.3 DEST Edition.package
ME_MindControlMirror.package
InTeenimater_FlavorPak_SameSexPregnancy.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAdultTeens.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_F.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package

Indeed, this is the EXACT sequence in which the files were physically written to the hard disk. As you can see, the files are "almost" alphabetical within their respective groups (the core InTeenimater files are mostly sorted, for instance, with the exception of the F package)...but the flavor paks PRECEDE the core InTeenimater files. As it turns out, InTeenimater_F happens to be the first file in the zip file that I distributed to the beta testers, hence the reason it appears first in this list as well. This user installed Merola's Mind Control mirror AFTER the InSIMenator, placing it 2nd instead of first in this listing.

Only FAT32 systems appear to exhibit this phenomenon. For my InTeenimater users this is not likely a huge issue, since most people will install the flavor paks AFTER the core program. But if someone unpacks them in the opposite order, they will have HUGE problems (jump bugs, crashes, missing menu options, etc.)

As an additional test, I had this person delete the flavor paks and then recopy them back into their Downloads folder and run the utility. This is the order that those files then appeared:

InSIMenator (UV) v2.3 DEST Edition.package
ME_MindControlMirror.package
InTeenimater_F.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_FlavorPak_SameSexPregnancy.package

In this configuration, the user no longer experienced crashes or jump bugs, and it was evident that the InTeenimater was functioning normally again.

Placing the flavor paks in a subfolder also proved to be an effective means of ensuring that they loaded after the files in the root, again suggesting that sub folders are processed *after* the files in the current directory.

This news throws an obvious wrinkle into the equation for those of us with inter-dependent mods that require correct load ordering in order to function properly. We should have a care that those users who are running Win98/ME and those upgrading from 98 to XP, are likely to have FAT32 file systems and that we cannot rely on alphabetical package naming to ensure proper load ordering on these systems!

J

Moving to the modding discussion forum.

I think that will not given a random generated ID. In fact the 0xFFFFFFFF will be translated as the Name Reference hash ID, if no Name Reference is found in the package, will be translated as a hash based in the name of the package.
anyway, i'm not completely sure, but makes more sense.

Just to clarify -- the above means that the first one wins? (At least on NTFS, as Jase points out.) So if I want to make sure certain packages get loaded first, I could put them in a subfolder called "aaa"?

Yes that is the way that FAT32 works, FAT32 is an extension of FAT16 (DOS anyone?) FAT32(16) and everyother FAT files system places the files in the order that they were originally written to the disk. If this issue is popping up in WinXP FAT32 then you will see this problem in Windows ME, and 98SE as well. If people are still using those Operating Systems.

As a side note to this Mac OSX users may run into the same issues as the Kernel of the Mac OS is Free BSD and if I remember correctly Linux still uses a form of the FAT file system.

One way to overcome this propblem is to Defrag the FAT32 partition and tell it to put the files in Alphabetical order. If I remember correctly windows defrag will do this automagically.

Um... I think it's the opposite. The last one 'wins' and any mods that are prefixed with a z will override everything else, in the case of NTFS.

I think when jadax said that the resource doesn't get loaded again, they are considering each package a resource. I could be wrong. :confused: But if it were the opposite, with any resources that get loaded first taking precedence, then it wouldn't make sense for modders who purposefully prefix their mods with a 'z' since those would load last, as per jase's explanation.


And thanks so much jase for analyzing and clarifying this. I'll now have to put a warning for any of my mods that require a specific order. I don't care what other people say, you are more than just awesome, you are fabulous! Kittens be damned!

Ste

PS. I forgot to mention that dizzy already had a tool to check for conflicts between hacks and GUIDs over here. Not to rain on your parade or anything. I'm sure we could all use more/better/fancier tools to do these things. I've been using dizzy's tool for a while now, and it is definitely useful. But I would love to see how your tool would work.

Sorry. Inside the downloads folder, they cascade (last wins). Anything loaded in the downloads foldern isn't loaded from the program folder.

No, dizzy's tool doesn't check for global BHAV conflicts, it only checks for GUID conflicts. These are very different things. I would ***LOVE*** a global BHAV conflict scanner.