Has anyone yet made their own semiglobal group and successfully had an object use it? I'd like to make one for my prison, so any pointers would be appreciated.

I have seen a custom package with BHAV's using a certain group ID. This group ID is not used in the BHAV's inside objects.package. Could this be what you are looking for?

Well they were probably treated a private BHAVs by the game. What sort of BHAV instance numbers did they have?

See the pic:

It seems to me that all you really need for a semiglobal are some BHAVs. The group value should be the 7F000000+CRC24 of the name (which you make GLOBs for in the private objects).

Though I realised after starting this thread that I can't really use this custom semiglobal anyway, because for instance the cell door still needs to use doorglobals and so forth. I am hoping to get away with extending the global group with some new instances. It could be a timebomb waiting to happen if everyone had the same idea, though I suppose it would be no worse than we already have some hacks that clash.

The RTBN route was one idea, but it seems more hassle as in some cases I would have to do some weird juggling with the stack object ID. Globals are far more the "right" solution for the purpose strictly thinking of how they'll be used.

I'm not 100% sure, nbut I think that you need to replace a semiglobal group to make a new one.

Okay, so just "clone" doorglobals and make your own semi-global out of it (call it something like "ijdoorglobals" or whatever).

I tested and made a couple of custom-grouped bhavs and gave them instance number of 0x2000, 0x2001 and so on, and made a private obejct and put a semi global file in this object. And I tried to type in 0x2000 in one line of my private object. The semi global file does recognize this custom group, but the "semi" bhav names don't show up in private bhavs. Could you explain how I can do it more?

Not showing up will be a problem with the tool probably. The BHAV editor has not yet been developed to read in custom semi-global packages. Although they should show up if they are included in the current package.

What is more important is, does the game run them appropriately? No point in asking the tool to make it look like something can be done when it can't

I just tested it a few times, so it may be too ealry for me to be sure, but the game says 'bad gosub tree number' when I clicked my custom pie menu to run that custom semi bhav(which contained just one line of showing "hi" dialog). Am I doing something wrong, maybe?

I think there is probably more to the semiglobal group number than just some random number. You have to hash the name or something. But I don't really understand it.

I am not sure if it is(if it's not please ignore me, Inge), but in my case, I used hash generator of SimPE, and used a custom semiglobal group name "ChristianlovGlobals" 0x7FCD7205. And the semiglobal file looks like recognizing this group name and the game's log also showed it but.. the game says bad gosub blah blah.

I don't really know. It's possible the game's simply not set up for user semis

Could you try making a menu option for the "hi" dialog that runs from a private function? Maybe there's some weird Pie Menu issue there.

Inge, I don't know. I just tried out of my curiosity but I think I can't do it. :bandit:

Dizzy2, thanks a lot, and I tried in several ways but failed. Probably I am doing something very wrong.

EDIT: Dizzy2, could you show us some sample packages? Ah, if you don't have enough time, please just ignore me. Don't mind and thanks a lot.

Okay, I just tried this out myself, and it looks like you can't actually make custom semi-globals unless you change objects.package itself (which is probably not a good idea). Oh well. It would've been nice.

Ah...! Right! It could have been much, much easier and better for us! Thank you for your answer, Dizzy2!

Well, nearly three years later, I am waking this thread to ask if there has been any further development in our knowledge of this? Anyone had custom semiglobals functioning in the game yet?

I had a thought - will the game recognise a custom semiglobal group if it is in a file in the Overrides folder, rather than in Downloads?

Very skeptical. One thing I *HAVE* found which works, however, is to "collide" existing groups. If you abuse a "local" group as a semiglobal, it WILL work. As all local groups only use BHAVs in the range of 0x1XXX, whereas SGs are 0x2XXX, I can collide my "custom" semiglobal over an existing "local", and this appears to work without incident and will not affect the functioning of the underlying local, which seem to entirely ignore the extra 0x2XXX BHAVs in favor of its proper semiglobals.

Oh really? Nice find! I had thought that the game might be a bit sensitive about the wrong numerical range in the wrong type of group, but that's great news.

If you combine arbitrary references into 0x2XXX with "collided" groups, the possibility that another hacker will manage to both pick the same object to collide as a semiglobal (I mean, really, there's, what, a dozen or so of us?), AND manage to collide your instances is very low. Just don't collide Accessory_Pet_ToyStick, I'm using that one.

Excuse my dumbness, but I don't understand what you mean with "collide".
Do you mean including in a cloned object BHAVs with instances 0x2XXX in the 0xFFFFFFFF group? Or are you talking about the 0x7F...... private groups assigned by Maxis to specific objects?

Either cases, how can these "semiglobals" be used by different objects at the same time? How should Inge set up her various "prison" object to be able to access the shared custom semiglobals?

Changing subject slightly, I realized that private BHAV instances can't be greater than 0x17FF; is this true also for semiglobals, perhaps? So that instances greater than 27FF can't be used?

Well, for instance, private BHAVs and BCONs are 0x1XXX in the group "Accessory_Pet_ToyStick", which hashes out to 0x7Fsomethingorother. If I inject 0x2XXX BHAVs into that group, and set my GLOB to "Accessory_Pet_Toystick, I can call those 0x2XXX BHAVs as semiglobals. If I set it to something that does not exist in objects.package and try to hash that, it won't load. I have to use a group that exists in objects.package. Since I don't want to use an existing semiglobal, I can collide into any private objectspace, which is much larger and less prone to conflict, as there are plenty of inert objects that can be collided that simply lack extraneous resources that would interfere (for instance, if I were to use an existing semiglobal, I wouldn't be able to safely touch strings like 0x12F, whereas if I collide an obscure accessory which has no RTBN strings, this won't matter and no one else is likely to want to modify this).

The 0x7F privates assigned to specific objects. 0xFFFFFFFF doesn't work at all and inventing your own 0x7F will not create a working semiglobal.

For instance, you could collide the prison semiglobals onto something like Accessory_Handcuffs or other halfway memorable accessory, and then plop your SGs into the Handcuffs Accessory Group. The handcuffs themselves will ignore this extraneous data and most resources will be free because inert accessories have little or no code. So colliding an accessory yields the most "freespace" with minimal risk of conflict with anything done by the dozen-or-so BHAV hackers that actually exist in the world.

I have not attempted to use an instance creator than 0x07FF in any case, but seems logical that this would occur similarly, if 0x7FF is the limit. The concept of an signed *12* bit integers is weird, though. I would think you'd have to take intentional effort to create signedness again given that masking off the last 4 bits would give unsignedness. Try it and see?

Unfortunately in many cases I still have to create new globals, because I actually need the object to remain a member of its original semiglobal group