I sent mail about this some time ago, but the mysterious Flags?? field in the BHAV section appears to be a version tag. It's easy enough to verify since the BHAV versions are all dumped out in the log files and they match the values in this field.

Anyway, it appears to be used when comparing BHAVS against those that have been overridden by mods in the Downloads folder. For instance, in my mod I modified one of the global BHAVs. This BHAV was based on the original Sims 2. It had a version field of 0x0018. Then the EP came out which modified this function. It shipped with a version field of 0x001A. At load time, the game ignored my antiquated version in favor of the version that shipped in the EP. It was easy enough to fix of course, just by bringing my BHAV up to date and changing the version field to 0x001A to match.

Interestingly (well, sadly really) - this version field doesn't appear to work "across/between mods". That is, if Mod A implements a BHAV and gives it Version 1 and Mod B implements the same BHAV and gives it Version 2, the load order cannot be guaranteed in this case. Sadly, Maxis has gone with an "alphabetical last man in wins" to their content load ordering. I was hoping to use the version field to provide polymorphic callbacks which would allow mods to interact and play nicely with one another. But it only works if you can forcibly control the load ordering by naming your package files such that the mod containing V2 alphabetically appears after V1 - making this approach sort of pointless as a general mechanism.

It appears the only real way to have module A call module B in a generic sense is to use the ill documented Run Tree By Name. I have not been successful calling this routine in practice, although Maxis does it everywhere. Anyway, I digress...

The other interesting thing to note is that on some BHAV's, the version field has the high bit set. I have no idea what the purpose of this bit flag is, but as far as doing version comparisons, this bit appears to be ignored. That is 0x8002 will trump 0x0001.

Anyway. Hope this is useful to someone. Maybe we can get this field name updated in the BHAV editor soon?

J

Pretty certain, Quaxi. My mod was initially timestamped at least two-weeks newer than the objects.package file that shipped with the EP. It was never getting invoked until I updated the version field. It's easy enough to verify empirically though - just do a few log dumps and compare the versions that appear in the output with the "flags??" field with the respective BHAVs.

We can look at a couple of examples here. Here's one call stack dump (this particular dump is from the objects.package file that shipped in the original Sims 2, not the EP):

Frame 5:
Stack Object id: 163
Stack Object name: Controller - Pregnancy
Node: 27
Tree: id 4124 name 'Interaction - Labor Pains' version -32738
from Controller_Pregnancy
Prim state: 0
Params: Locals: 0 0 -1 0 0 0
Frame 4:
Stack Object id: 138
Stack Object name: N001_User00163 - Jennifer
Node: 5
Tree: id 281 name 'Wait For Notify' version 7
from global
Prim state: 1
Params: 0 1 Locals:
Frame 3:
Stack Object id: 138
Stack Object name: N001_User00163 - Jennifer
Node: 1
Tree: id 8282 name 'Function - Main - Check Queue' version 45
from PersonGlobals
Prim state: 0
Params: Locals: 163

If we look at the BHAV's for these we find the flags?? field is:

Interaction - Labor Pains (0x7F1D0F49:0x101C) - Flags?? = 0x801E (-32738) // no idea what the high bit here signifies
Wait For Notify (0x7FD46CD0:0x119) - Flags?? = 0x0007 (7)
Function - Main - Check Queue (0x7F01EC29:0x205A) Flags?? = 0x002D (45)

Anyway, this is straight forward enough...

I've also verified the alphabetical load ordering of mods in the Downloads folder (I can't say if this holds for other package files though).

For example, consider the following: In my mod (the InTeenimater), I have two package files A.package and B.package. Both of them define the same custom global BHAV's in the 0x500 range. The implementation supplied in the A package contains break points and nothing else. The version supplied in the B package contains the actual implementations of these methods. This permits module A to call into module B (which it does). You can timestamp these files however you'd like, but B will always trump A - which is exactly what I want in my particular case. However, if you rename A.package to C.package, then C will load over B and you'll get break points firing - every time. Even if the version field in B is > than that in C, C.package will always be triumphant here :(

It's regrettable that the load order of mods in the Downloads folder is dependent on the name of the file. Oh well...

J