Stumped on Set to next and Proxy GUID with lead object

[Argon]

Instead of using CT trees like the "popular" custom instrument hack, I wanted to create something that just works(tm) without having to modify any other garbage in the instrument group. So I decided to try and use Proxy/Fallback GUIDs, and I have most of it working at this point. Practice appears to work just fine, but Perform is throwing a hissy fit when I try and set up the band controller to use proxy guids as well. Before I started work on the band controller, sounds would play during perform for the normal maxis instruments, but custom ones would be silent.

The part that's stumping me is how to do a set to next object with proxy guid, and check to see if it's the lead object. Error log attached but I forget what I did and remember it being  too many iterations error before. Any advice on how to write BHAV "Instrument - Set to next by proxy" would be wonderful.

[J. M. Pescado]

The part that's stumping me is how to do a set to next object with proxy guid, and check to see if it's the lead object. Error log attached but I forget what I did and remember it being  too many iterations error before. Any advice on how to write BHAV "Instrument - Set to next by proxy" would be wonderful.

There is no way to do a specific set-to-next in this way. Proxy GUID is the "Fallback" that occurs when the original source GUID is not available, such as a custom object which has been deleted, and the "proxy" is what it becomes when this occurs. While it is visible to the BHAV code, it is not typically used and not reliable, as CC creators often clone an object and either fail to change it to their new GUID when they should (such as when a wildly different object is created that has no real relation to the original), or change it unnecessarily on an uncategorized object, rendering the object permanently unidentifiable internally. The only way to identify an object by proxy GUID is to set-to-next using some superset (category, if the object is categorized, but this usually makes it unnecessary, unless you're trying to find an esoteric example of a non-compliant categoy member, like vampire coffins in the bed category), or, failing that "all objects" or "all objects of category 0".

As for how to identify it is the lead object, the lead object will always have stack object's 0x13 (04 13 00) equal to the stack object (0A 00 00 or 04 0B 00). If this criteria is not met, the object is not the lead object. You can directly jump to the lead object by following the SO's 0x13 pointer, but I suggest not doing this inside a set-to-next, as this will likely take you to either an object you already visited, or an object you would encounter later, causing either skipping, duplication, or endless looping, depending on whether or not you cache your original position.

Set-To-Next By Proxy, however, does not exist as far as I know.

All in all, instruments are an unholy mess. Some objects are categorized, some are identified only by GUID, with a hodgepodge of code delocalized and actually handled in the semiglobal.

[Argon]

right, I know there wasn't a set to next proxy guid, what I tried doing was something like set to next object with wants category and then testing the stack object's proxy guid 1 and 2. There's something wrong with the way I'm going about doing it but I'm not entirely sure what it is, I'll mess around with it and see if I can get it working again.

[Inge]

Are you entering the digits the right way round?  Pay special attention to which is proxy guid 1 and 2, and also the 2nd pair of digits in each field must be in the operand box ahead of the first.

[J. M. Pescado]

Don't forget that the GUID must be entered bass-ackwards because Sims 2 BHAV codes are little-endian. So if you had GUID 0x01234567, it would be entered in set-to-next-by-GUID as "67 45 34 12 84 0A 00 00". The 67 45 would then be Proxy GUID 1.

[Inge]

Ok so that was the grown-up way of saying it

[Argon]

Yes I know all about little-endian, but I have all the guids entered into a behavior constant. It works perfectly for the first half (in the music globals, testing to see if an object is a proxy of one from the list) so endian-ness is not the problem. The problem I'm having is setting up the logic for setting to the next object and determining if the proxy guid matches.

I have it set up like this:
BHAV "Instrument - Is Param1 by Proxy?"

Param 0 is the stack object
Param 1 is the type of instrument we want to check
   Constant 2 - Guitar (uni, career, ls; there is a check for each)
   Constant 3 - Bass
   Constant 4 - Drums
   Constant 5 - Piano
   Constant 6 - Violin
   Constant 7 - synth
Param 2 determines if the lead object guid tree should be used instead by passing Constant 1

That part works fine, I'm having problems with this:
BHAV "Instrument - Set to next by proxy"
Temp 0: Param 0 (passed value from the object list)
Set to next object with wants category in Temp 0 (the values in the constant list are the values in the want category field from the object definitions)
Instrument - Is Param1 by Proxy? Param 0 = Stack Object ID, Param1 = Param 0 (parameter passed to this bhav, instrument value), Param2 = 0


Instrument - Is Param1 by Proxy? Param 0 = Stack Object ID, Param1 = Param 0 (parameter passed to this bhav, instrument value), Param2 = Constant 1 (check for lead object proxy guid instead)


On top of that now I'm getting a "an error occured in object Controller - Band"; "error: reference to tree tree parameter when no parameter exists." as the result of some tweaking to try and get the stupid thing working but I don't remember what I did. I have the arguments on the bhavs set correctly but it would really help if someone looked at it my attachment so I can figure out what I'm doing wrong and specifically how to fix it.

[J. M. Pescado]

I'm certain you've done something horrid and unnecessarily Byzantine. I don't even think you need to resort to proxy-GUID identification for pianos and guitars. Since they have multiple objects, I'm sure they're a category.

[Argon]

I know pianos have a category but the guitars, bass, drums, violin, and synth certainly do not unless they're defined in some obscure location. I looked at both the Category and Category2 bcons and the only one I could find was for the pianos. The check for the seasons career guitar was kludged on top of the existing globals with another guid check, they did the same thing in LS.

[Argon]

How can I fix the reference to tree tree parameter when no parameter exists error?

[J. M. Pescado]

Don't access a Local or Param without defining it in the header (and supplying an actual argument).

[Argon]

I have them defined and pass the values I need when I'm calling it. I'm not using any local values, unless temp 0 counts. I really don't understand it.

[Inge]

You need to upload your error log too, that's the best way to get very quickly to the seat of the problem and see what line triggered it.

[Argon]

It's the same error as the one in the original log inside the zip on the first attachment, so I didn't think it'd make much difference posting a new one but here it is anyway.

[Inge]

I didn't know you included it in the first zip cos I didn't download that one.

Ok your problem with that particular error is Stack Object is zero - ie no stack object, and yet you are testing Stack Object's room.  I think your problem may be line 6 where you "set to next".   I am not familiar with the use of set to next by proxy, but whatever it's meant to be doing it's not setting the value of Stack Object, which I think you were hoping it was.  Either get it setting stack object, or change to testing the room (in line 7) of what it actually is setting.

[Argon]

"Band - Notify Waitng Sims' is unchanged from the maxis code with the exception of changing the original set to next lines to the bhav I wrote named "Instrument - Set to next by proxy". So the problem would exist there and I'm wondering how to fix it.

[Inge]

Well I have followed the chain of calls and I can't see it setting a temp with the return value.  It appears to set stack object, but of course stack object is always popped when you return.  Normally with those type of calls you'd have something in Temp 0 to assign into stack object (which you'd have to do explicitly before testing its room).  I need to look at how Maxis used the call originally.  Can you give me the instance and group number of the BHAV you used as your example?

Oh - can I assume you didn't actually have a piano on the lot you were testing in?  If you did then of course I am wondering why it didn't throw an error on that line too.

Later: ok I found the original Band notify waiting sims.  The huge difference is that in the original, stack object is being set to something that can have its room tested.   What I do in this situation is I change the set to next "object of type" to just plain set to next "object", and then test the proxy GUID of each object found, looping back round till I find one that matches that proxy.  Then break out of the loop, with your Stack Object set to that matching object.

[Argon]

Ah, that's what the problem was I didn't know you had to store the value in temp and assign it in the main bhav. It's working wonderfully now, thanks Inge!

[Inge]

Good!