Stack object attributes
Once line 0x0 (0) has copied the value in Param 0x0000 to Stack Object ID, the system can then read the attributes from that object. Note that there is no method to read attributes directly from a Param, a Temp or a Literal, ONLY from "Me" or "Stack Object".
That's all that I can give you with such limited information. I might need to DL and inspect the Loan Jar if there is any more specific stuff you require...
Should anyone want to take a look, I'll leave a link to the loan jar Link to loan jar
When a BHAV is called, the system may overwrite things like 'Stack Object ID' and 'My Object ID' with certain values that are determined by the system. So when one BHAV calls another, it automatically - as a precaution - copies the contents of 'Stack Object ID' into 'Param 0' first. The BHAV 'Sub - Calculate Interest' simply copies that value from 'Param 0' back into 'Stack Object ID'.
And because 'Main' has first copied 'My Object ID' into 'Stack Object ID', this is how 'Sub - Calculate Interest' knows which jar it is working with.
Edit to add: Ah yes, ofcourse. That's how this worked...
The Guardian not only determines which options are open, it also *creates* the options in a sense. When a guardian BHAV creates multiple options in a sub-menu pie (using the "[prim 0x0032] Add/Change the Action String" function), each of the options is given a number, depending on the parameter given in the instruction - in this case, Local 0x0000, which is 0 for 0% interest, 1 for 1% interest, et cetera. When you SELECT one of the options, the corresponding number is stored in Param 0, and passed on to the action BHAV.
In the case of a Guardian BHAV and Action BHAV, the system has automatically already set Stack Object ID to the object ID of the specific object - in this case a jar -, so its attributes can be properly addressed.
Here, the Guardian BHAV simply reads the Stack Object's attribute 0x0002 to find out which option it must grey out, and stores it in Local 0x0001. In Local 0x0000, it sets up a loop to cycle through all the menu options. Before actually creating each option, it tests if Local 0x0000 is the same as Local 0x0001. If it is, it runs line 0x4 to create the greyed out option. Otherwise it runs line 0x5 to create a clickable option. (Select each of these two lines and check at the right, you'll see that they're set to different modes...)
As said earlier, the options will be numbered in the order they are created by the Guardian BHAV, regardless which of the [prim 0x0032] lines is used. Once you've picked your option, the Action BHAV will use the number - which was passed on through Param 0 - to set the value of Stack Object's attribute 0x0002, the third attribute of the Jar you selected the option on.
Two options in your test / guardian BHAV :
- you set the Stack object ID to a chosen number for each pie menu (so that later you -the modder- know the number that goes with each pie menu)
- you use a loop in a variable (here it's in local 0) and you add 1 for each pie menu (here it's a little different because it seems to check an attribute 0x02 in line 1 of the BHAV > 'BHAV calculate interest' do the calculation and store it in temp 0, then that temp 0 is probably stored in attribute 0x02 in another BHAV) and store it in Stack Object ID, so that it can be linked to the pie menu string. The modder can't know the number linked to each pie menu string. However, the player can see this numbers because the pie menu string use "§local" (= the current number in the local variable when the specific pie menu string is added). It could go on forever and you would have x pie menus and it would bug the game, but the last line in the BHAV sets a limit : the local 0 can't be a number superior to the value in constant 1001 0x03. When there's no numbers left, the loop is cut, by returning true.
For the two options, as it was said by BoilingOil, the value of the pie menu string clicked by the player (= the current value in Stack object ID) is stored in Param 0. And voilà !
Instead, make a new menu in which you can switch each day on or off. When the interest for today must be calculated, you first check if today has been switched on. If so, then you do the calculation. But if not, then you simply jump straight to the end and exit, assuming that you're done!
Also, don't feel bad about not seeing it before. When I was first confronted with the need to set up dynamic pie menus and sub-menus, I was totally baffled as well. But once I realized what was going on (with some help of other known modders, of course), I soon set up some rather complicated menus myself. You should look at my "Spawn Objects" and "Need Freak" mods for some interesting examples.
Need Freak is especially heinous, because at no point anywhere in the process, it seems to be clear what option is being created. Look for example at the BHAVs "Setup - TEST" and "Sub - Setup - TEST". I know that together, they create over 90% of the entire pie menu and its sub-structures, but I find it extremely tough to figure out what I'm doing there, and I'm the one who MADE that!
@ankoyume You're right... I missed the step of putting the value in the Stack Object ID before calling the MakeAction primitive. Thank you for completing me on that part.