Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Slippery When Wet
Original Poster
#1 Old 8th Nov 2008 at 11:50 AM
Default More to learn about BHAV's
Ever wondered how you could pass the temps as parameters?
Thought not


This is from EA code.
In JobDataSchoolGlobals 0x7FBE051B
the first 3 nodes of BHAV 0x2016 'Grade - Update'

0000 : 2039 : 01 : 0001 : FFFC : 1238000A00000A00000A000001000000
[semi 0x2039] Grade - Normalize (1 arg: grade=My person data 0x0038 (School Grade))

0001 : 0002 : 00 : 0002 : FFFC : 02000000000519080000000000000000
[prim 0x0002] Expression (Local 0x0002 (start grade) := Temp 0x0000)

0002 : 2037 : 01 : 0012 : FFFC : FFFFFFFFFFFFFFFF0000000000000000
[semi 0x2037] Calculate Grade (1 arg: current grade=????)

This last node is showing Calculate Grade (unknown operands).
It looks as though Temp0 should be passed as the first param to 0x2037.
So here, I think it actually is using the Temps as parameters???


This thread was a few years ago, but those 'unknown but repeatable values' that I couldn't figure out *might* have been temps.
http://www.modthesims2.com/showthread.php?t=117411

I probably didn't think of comparing the parameter array to the temp array at the time. Seems kinda pointless as they are available anyway.
Advertisement
Retired Duck
retired moderator
#2 Old 8th Nov 2008 at 12:02 PM
Hmm... You've got me a teensy bit confused about what you mean here...

The way you pass temps as parameters is the same as the way you pass any other value, just change the data owner to 0x08 (or 0x0B if you want Temp[temp]).

Temps are stack level variables, which means that if you change them in one function (A), then that function (A) calls another function (B), then the temps will have the same values in (B) as they did in (A). If (B) changes the values in the temps and then returns, those values will stay changed in (A).

The last line you have there (with all the FFs in the operands list and the ???? in the translation) is, I believe, a substitution feature. From what I recall reading, setting the operands all to FF means 'substitute in the values originally passed into this function'. It's a kind of "pass through" short hand.
Slippery When Wet
Original Poster
#3 Old 8th Nov 2008 at 12:16 PM
Yep, I was more than a teensy bit confused when I read that too
The thread that I pointed to, was data collected when I was last modding.
I worked with Peter to update some of the functions that were displaying incorrectly in SimPE.
I know about the other ways you would normally pass params.

The first parameter to that bhav is actually the sims mood. So if that did get passed on to BHAV 2037 (which alters your grade depending on whther you've done your homework)... then homework has never done anything since the base game.
2037 is expecting the sims current grade, not their mood.
Fat Obstreperous Jerk
#4 Old 10th Nov 2008 at 10:31 AM
As far as I can tell, calling a function with "FFFFFFFFFFFFFFFF0000000000000000" results in the Arguments of the first function stored in 09 0X 00, etc, to be passed into the called function as the corresponding 09 0X 00s. That seems to be the observed behavior of other "FFFFFFFFFFFFFFFF" calls. Passing temps as arguments is observed in non-0x10 RTBNs, though. I refuse to refer to this business as "parameters". My functions do not have parameters! They have ARGUMENTS...and they ALWAYS WIN THEM!

Grant me the serenity to accept the things I cannot change, the courage to change the things I cannot accept, and the wisdom to hide the bodies of those I had to kill because they pissed me off.
One horse disagreer of the Apocalypse
#5 Old 10th Nov 2008 at 11:04 AM
ROFL! (insert random post-too-short qualifying rubbish here...)

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Slippery When Wet
Original Poster
#6 Old 10th Nov 2008 at 3:01 PM
Well, I'll stick with using param as we all use SimPE and this thread is confusing enough as it is to start adding more

Pes, what do you mean by a 'non-0x10 RTBN'?
I take it you mean Op2 with flag 0x10 set?

I think the current info is that if Op2 has a flag 0x20 set, then callers parameters are passed. Peter is updating the RTBN wizard now to cope with the trees listed above 0xFF (flag 0x40). So now would be a good time to get this info to him if it's not already known.

If you mean that the called function accesses it's arguments via Temp[], then that's a given for any call isn't it? What I'm saying is that the value stored in the Temp0 from the previous call is actually being accessed via Param0.

Do you have any examples to point to in the EA code where Op's 0 to 7 holding FF is causing the callers arguments to be passed?
The above *is* from EA code, and it is not doing that.

If you want to pass the callers parameters, then unless things have changed since NL, you should be setting Op12 to 0x02, NV to 1, and ensuring Ops 0 thru 7 do not all contain FF.

I think it was the FF's and 00's being interpreted in SimPE as 'callers parameters' that made me work out what was actually happening. I tried to use it and it didn't work.

Another example of the FF's and 00's passing the temps as parameters can be seen in
'Function - Portal - SG' of DoorGlobalsNew.
It's own first arg is the 'Start Room ID'.
It calls Global 0x116, which uses it's first param as though it were an object ID. (Rooms are not objects as far as I know.)
Immediately preceding this call, Temp0 does in fact get the 'control' object ID of the door assigned to it.

Most of the time when the Op's are "FFFFFFFFFFFFFFFF0000000000000000" the function is expecting no arguments.

I'm not sure whether the game engine copies the temps to the params, or it's just that the temp[] and param[] pointers are the same for the call.
One horse disagreer of the Apocalypse
#7 Old 10th Nov 2008 at 3:40 PM
And can the called BHAV actually alter the values of those variables directly?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Slippery When Wet
Original Poster
#8 Old 10th Nov 2008 at 4:09 PM
BHAV's modify their params and temps in lots of code, but I've not tested whether modifying the param in this case also changes the temp.
One horse disagreer of the Apocalypse
#9 Old 10th Nov 2008 at 6:54 PM
Well I know the temps can be modified at any level with scope in both directions, but I was thinking of params that are passed other than by temp or in the normal operand boxes - ie "caller's params". Are changes still private?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Slippery When Wet
Original Poster
#10 Old 10th Nov 2008 at 7:54 PM
I sure hope so

I can't remember if I checked 3 years ago. If I did check and found they were suddenly not private then I'm sure I would have wrote that in the thread.

I *do* remember that you could only pass up to 8 params with "callers params".

I'm hoping that the "FFFFFFFFFFFFFFFF0000000000000000" means to copy the required temps to the params. If this works with more than 8, then custom objects could then override the 'portal' functions, and still pass the parameters through to the semi.
Retired Duck
retired moderator
#11 Old 11th Nov 2008 at 10:12 AM
Yep, regular parameters are definitely pass-by-value. Changing the value of temps carries between functions because they live outside the stack, but params are definitely inside the stack. Thoroughly confused by the FFFF+ thing though!
The ModFather
retired moderator
#12 Old 11th Nov 2008 at 10:53 AM
As Tuna remembers, two year ago I had to face the problem of the 9 parameters used by the Portal function; back then, I was creating the auto-light stairs, that automatically turn on the light whenever the Postal function is called, and turns them off when the Portal function ends.
I have examined today what I did two years ago, and I'm even more puzzled...

- In the OBJF, the Portal function calls my private BHAV, that in turns calls the semiglobal Portal BHAV with Op's ""FFFFFFFFFFFFFFFF0000000000000000". Basically, I don't pass any parameter to the Semiglobal! Not explicitly, anyway; the "FFFF..." thing is unclear to me (I always thought it meant "no parameters have to be passed").
- The semiglobal Portal declares to use 9 parameters in total, while only the last one (Param 0x0008, "Moving Foot") is actually used.
- When the Semiglobal performs the check "Param 0x0008 == 0x0000?", it expects only two possible values, 0 and 1, and then forces the value to 1 in any case ("Param 0x0008 := Literal 0x0001").
- Param 0x0008 (always Literal 1) is then stored into the sim's "My Interaction Data Field #1".

I don't know what the Interaction Data Field #1 is, and I still don't know where the semiglobal Portal reads the initial value of the Param 0x0008 (consider that while it's true that I called the Semiglobal using the ""FFFFFFFFFFFFFFFF0000000000000000" operands, MY private portal function is called from within the OBJF, where's there's no place to put operands...


I only know that I agree with Echo about the TEMPs being shared (without any need to "pass" them) back and forth with the entire interaction tree.

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
Fat Obstreperous Jerk
#13 Old 11th Nov 2008 at 12:37 PM
I've encountered similar usages of "FFFFFFFFFFFFFFFF0000000000000000": A function is called from something like a TTAB, which immediately calls another function that expects arguments, yet no arguments are explicitly supplied. As no temps are manipulated, these arguments cannot be getting passed through temps, yet the called function clearly receives them, or it would have barfed messily. Clearly, these arguments are passed along. If anyone still cares the next time I encounter this, I'll post a specific example, but I don't recall an exact example offhand.

Grant me the serenity to accept the things I cannot change, the courage to change the things I cannot accept, and the wisdom to hide the bodies of those I had to kill because they pissed me off.
The ModFather
retired moderator
#14 Old 11th Nov 2008 at 12:40 PM Last edited by Numenor : 11th Nov 2008 at 12:57 PM.
The JobDataGlobals 0x2016 and 0x2037 mentioned by Tunaisafish are good example: the 0x2016 calls the 0x2037 with the "FFFF...." operands, and then the 0x2037 "magically" knows the value of Param 0x0000.

For sure, the Param 0 is NOT passed using the Temp0, because the Temp0 is set, nor read by this BHAV (in detail, the Temp0 is set to the value of Param0, "Current Grade", and then increased or decreased depending on the existance of unfinished homeworks; then the Temp0 is returned to the caller BHAV).

However, the "FFFF..." can't just mean "pass all the parameters", because - as noted by Tuna - the 0x2016 uses two params: Prm0="Good Mood", Prm1="Late?" (boolean); but the 0x2037 uses only one param: Prm0="Current Grade".

So, the question is: where is stored the "current grade", so easily read by semiglobal 0x2037 as Param0?
Perhaps the "FFFF..." means "Pass the entire environment of the current 'My Object' ", as opposed to pass something from the current 'Stack Object'?

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
Fat Obstreperous Jerk
#15 Old 12th Nov 2008 at 4:00 AM
Quote: Originally posted by Numenor
However, the "FFFF..." can't just mean "pass all the parameters", because - as noted by Tuna - the 0x2016 uses two params: Prm0="Good Mood", Prm1="Late?" (boolean); but the 0x2037 uses only one param: Prm0="Current Grade".
Doesn't necessarily mean anything: it's perfectly acceptable to call a BHAV with more arguments than are actually required: The extra arguments are ignored.

So while 2016 may have 2 arguments, 2037 only has one argument, so the extra arguments are ignored. Sometimes a function is called with "useless" arguments, in that the function has argument variables, but the arguments are simply ignored and the variables used for stomping, such as push-with-arguments, where the arguments of the push are stored in the argument variables, but the function itself does not actually use them for anything other than stomping.

Grant me the serenity to accept the things I cannot change, the courage to change the things I cannot accept, and the wisdom to hide the bodies of those I had to kill because they pissed me off.
The ModFather
retired moderator
#16 Old 12th Nov 2008 at 10:52 AM
Right, there's no law that forbids to pass 2 arguments when the called BHAV only needs one; but then, the called BHAV should use at least the first argument passed, and in this case it does NOT use it (passed: "Good Mood", used: "Current Grade"; apart from the labels, the values are too different to be the same argument).

I'm still convinced that the "FFFF..." might mean silently pass some values read from the sim, and not from the stack object.

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
Retired Duck
retired moderator
#17 Old 12th Nov 2008 at 11:29 AM
Could it be related to the parameters that a sim passes to an interaction when they initiate it? That is,
param0 == the target object
param1 == the value of temp 0 when the guard was run?
Slippery When Wet
Original Poster
#18 Old 12th Nov 2008 at 12:28 PM
Quote: Originally posted by Numenor
So, the question is: where is stored the "current grade", so easily read by semiglobal 0x2037 as Param0?

The 'normalised grade' is stored in local2 and temp0.
It is this normalised grade that is getting passed, not the grade from the sim.*

Quote: Originally posted by Numenor
Perhaps the "FFFF..." means "Pass the entire environment of the current 'My Object' ", as opposed to pass something from the current 'Stack Object'?


Not sure exactly what it means, but I in both cases I have looked at recently where "FFFF..." is used to pass a used parameter, the relevant value has been stored in temp0 before the call, and read via param0 after.

Writing a test object for this again is on my TODO list.
In the meantime if anyone does come across 'FFFF...' being used to pass parameters I'd like to see them


* If the actual sims grade was passed in stead of the normalised one, then the grade freezing bug that Inge recently made a fix for would never have happened. normalise turns F- into F+. (D-, D+) into D. (C-,C+) into C. etc...
The ModFather
retired moderator
#19 Old 12th Nov 2008 at 2:35 PM
Quote: Originally posted by tunaisafish
The 'normalised grade' is stored in local2 and temp0.
It is this normalised grade that is getting passed, not the grade from the sim.*

This is interesting; this means that the value used as a base by semiglobal 0x2037 is taken from another BHAV, not from a source external to the running tree. But are you sure? I have to take a look at Inge's fix.


Quote:
in both cases I have looked at recently where "FFFF..." is used to pass a used parameter, the relevant value has been stored in temp0 before the call, and read via param0 after.

You mean "Temp0 := [relevant value]" in the caller, and then "[Local X] := Param0" in the callee, resulting in [Local X] storing exactly the [relevant value]?

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
One horse disagreer of the Apocalypse
#20 Old 12th Nov 2008 at 3:16 PM
You won't learn anything from my fix - I just made it return false both ways on line 0 :P

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Slippery When Wet
Original Poster
#21 Old 12th Nov 2008 at 4:29 PM
Quote: Originally posted by Echo
Could it be related to the parameters that a sim passes to an interaction when they initiate it?

I take it that was in response to Pescado post? "I've encountered similar usages..."
Very good thinking
If that's true then it would be another example of the temp0 theory.
I'll keep a lookout for those interactions now too.

Quote: Originally posted by Numenor
This is interesting; this means that the value used as a base by semiglobal 0x2037 is taken from another BHAV, not from a source external to the running tree. But are you sure? I have to take a look at Inge's fix.


Yep, in 2016 the first line is a "Get into T0" type. It's in the first post here.
Grade - Normalize (My school grade). I can't see how else 2037 would always manage to get the current grade from anywhere else and subtract the one from it. I'm working on a mod in that group now so it's all fresh.

Quote: Originally posted by Numenor
You mean "Temp0 := [relevant value]" in the caller, and then "[Local X] := Param0" in the callee, resulting in [Local X] storing exactly the [relevant value]?


Logically the same, yes.
Slippery When Wet
Original Poster
#22 Old 14th Nov 2008 at 5:03 AM
It's true. the "FFFF..." *does* use Temps as parameters

I found some examples of the "FFFF..." passing arguments this way in the hottub subqueue's. Each hottub's 0x1014 and 0x1016 are just one node and use 'FFFF...' to pass the magical args to the semiglobals.

What I did.
Changed the sunken hottub to pass param0 to param2 explicitly, and changed the raised hottub to pass temps 0 to 2.
Result, a broken sunken hottub (error'd on cuddle)
The raised hottub worked fine. All the way up to woohoo, kiss/makout etc.

Just in case I got them muddled up, or the labels for sunken/raised were wrong; I changed the sunken hottub to also use the temps explicitly.
Both hottubs worked fine ingame.
This second testfile is attached.

Notes:
On the unchanged hottub in the testfile (the lovetub), the NV is different for the two 'FFFF...' calls . So perhaps NV does not matter?

The BHAV to BHAV thread.
The truth table lines where kill=1 needs rechecking. ('kill' is what I labelled the 'FF' in Ops 0 to 7. So instead of killing the parameters, it was overwriting them with values from temps.

From that thread in the last post...
Quote: Originally posted by pljones
There are too many variables for my liking, too. ArgC and Kill are going to interact somehow.


Peter was right
Attached files:
File Type: zip  Experimental_hottub_subqueue.zip (386 Bytes, 2 downloads) - View custom content
The ModFather
retired moderator
#23 Old 14th Nov 2008 at 6:47 PM Last edited by Numenor : 14th Nov 2008 at 6:59 PM.
Bingo! Erm.. not for your test mod anyway (I had NO errors while using it).

Since your package was not helpful, I created myself a test object for the purpose, and the results seem incontrovertible to me: when calling a BHAV with the "FFFF" operands, each and every existing Temp is passed to the callee BHAV as Param (Param0 is set to the value of the Temp0, Param1 to the Temp1 etc.).

I'm attaching the test object, the three error logs and a "Results.txt" in a more readable form. Please note that the TEST1 is the less important: look for TEST2 and 3.

Now that we've settled with this result (compliments Tunaisafish for guessing it), someone please explain me WHAT should we do with it
I mean, when the callee BHAV is invoked, all the Params contain the values of the Temps, but the Temps are already available for the BHAV to use it: no need to read them from the Params!.
So, is this only a (useless) side effect or am I overlooking an interesting usage of this "FFFF" technique?


EDIT:
Quote: Originally posted by Echo
Could it be related to the parameters that a sim passes to an interaction when they initiate it? That is,
param0 == the target object
param1 == the value of temp 0 when the guard was run?

My TEST1 has a Guardian that sets the values for all the Temps, and then the Action is executed, immediately reaching a Break Point.
According to your post, I should have:
- Param0 = Target object = the ObjectID of my test object (i.e. 183); but in the log, Param0 is zero.
- Param1 = The value set in the Guardian for Temp0 = 17; but in the log it's 19...
I don't understand whether my BHAVs should meet some requirements, so to obtain the result you mention; or the information you provide are inzaccurate (which is hard to believe ).
Attached files:
File Type: rar  ErrorLogs.rar (33.3 KB, 2 downloads) - View custom content
File Type: rar  Numenor_FFFF-Test-object.rar (2.3 KB, 1 downloads) - View custom content
File Type: txt  TestResults.txt (1.9 KB, 3 downloads)

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
Slippery When Wet
Original Poster
#24 Old 15th Nov 2008 at 8:36 AM
Numenor, Echo was refering to what happens when you build a dynamic menu in the guardian, using 'Add/Change the Action String'. see Ebruere's notes in this thread

I just found out about there only being 8 temps
I tried to edit your object and got errors when assigning to anything above temp7.
So we can't use this technique to edit & pass more than 8 arguments unless we also edit the called BHAV too.

Quote: Originally posted by Numenor
Now that we've settled with this result (compliments Tunaisafish for guessing it), someone please explain me WHAT should we do with it
I mean, when the callee BHAV is invoked, all the Params contain the values of the Temps, but the Temps are already available for the BHAV to use it: no need to read them from the Params!.
So, is this only a (useless) side effect or am I overlooking an interesting usage of this "FFFF" technique?


The FFFF is doing a little more than we know. Not sure where it copies the param8+ values from. eg. the "Moving Foot" example above for one. I didn't see anything obvious jump out from looking at the error logs :/

If moddng an object that calls another with the FFFF, we now know to avoid accidental stomping on the temps. Calling a function that would return a value in T0 for example, would have given us bugs and headaches trying to solve.

It also shows us that the game engine is doing more than we know when calling interactions and entry points. The arguments that are passed as params are fairly well known. The arguments that are passed as temps are not. eg. the subqueue file above shows that the hottub params are ignored totally. No side-effect involved here, the arguments were all supllied in the temps by design.
The ModFather
retired moderator
#25 Old 15th Nov 2008 at 10:27 AM
As for passing more than 8 values to the called BHAV, consieder that:
- Most of the BHAVs of my test object are declared to use 15 Params, and the game didn't complain about it; however, the log shows the values of 14 Params only.
- The called BHAV can surely read the values of up to 8 Params explicitely passed, plus it can read the 8 Temps: 16 values in total available for the called BHAV to work with. For our modding purposes, it's quite enough; but still this doesn't explain where the Maxis-made BHAVs read values such as the "Moving Foot".

I've finally started my Journal. Information only, no questions.

My latest activity: CEP 9.2.0! - AnyGameStarter 2.1.1 (UPD) - Scriptorium v.2.2f - Photo & Plaques hide with walls - Magazine Rack (UPD) - Animated Windows Hack (UPD) - Custom Instrument Hack (UPD) - Drivable Cars Without Nightlife (UPD) - Courtesy Lights (FIX) - Custom Fence-Arches - Painting-TV - Smarter Lights (UPD)


I *DON'T* accept requests, sorry.
Page 1 of 2
Back to top