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!
Systemic Anomaly
Original Poster
#1 Old 10th Jul 2005 at 9:56 PM
Default Advanced Question: RTBN Calls from Inside an Interaction
Does anyone know what magic incantation is required to make an RTBN call from inside the execution tree of an interaction? Is it even possible? All my RTBN calls seem to fail and return FALSE in this context, even if op6=0x02 (push onto my stack) is specified. The same call, when invoked outside of an interaction, works fine.
1 users say thanks for this. (Who?)
Advertisement
Systemic Anomaly
Original Poster
#2 Old 11th Jul 2005 at 5:03 PM Last edited by jase439 : 12th Jul 2005 at 4:47 AM.
On some off chance someone else reads this thread, I discovered that setting op2=0x06 did the trick. I had previously tried setting these bit flags to 0x02 without success, so I'm guessing its bit 2 in this field that does whatever magic I needed.
Inventor
#3 Old 11th Jul 2005 at 5:25 PM
Wow! Nice find!
One horse disagreer of the Apocalypse
#4 Old 11th Jul 2005 at 7:43 PM
What's RTBN?
Fat Obstreperous Jerk
#5 Old 12th Jul 2005 at 12:11 AM Last edited by J. M. Pescado : 12th Jul 2005 at 12:14 AM.
Run Tree By Name. The op2 bits determine a few factors like whether or not you're running it from the global list, the semiglobal list, or the local list strings, and how the arguments are passed. If you set bit 0x01, it should run from the big global list. If you set 0x02, it'll run from the semiglobal STR 0x12Fs, and if you set 0x04, it'll run from the local STRs. If you set 0x10, it'll pass the arguments from the code line, if you set 0x20, it'll pass (I think) from the params. Otherwise, if you set none of these, it'll pass the temp values as your arguments.
Systemic Anomaly
Original Poster
#6 Old 12th Jul 2005 at 4:41 AM Last edited by jase439 : 12th Jul 2005 at 4:53 AM.
The thing that has me perplexed was that the RTBN call was made from a semi-global and the call tree prim string was in the semi-global's STR# 0x12F. I had previously tried passing 0x02 in the flags op to indicate that that lookup should proceed using the semi-globals, but came up empty-handed. Then I happened to notice some code down in the ShoppingRackGlobals that was structured similarly by making a similar RTBN call, however it was passing 0x06 to op2. The significance of needing to have both bits 1 and 2 here is not entirely clear to me, but it worked.

Anyway, the long and short of it: I am not convinced it had anything to do with the fact that I was making the call from an interaction per se. The calling context may have been slightly different and therefore required the extra flag bits to resolve the tree name properly. Semi-globals always manage to get me turned around on my head when it comes to STR# resolution of any kind.

J
One horse disagreer of the Apocalypse
#7 Old 12th Jul 2005 at 8:03 AM
Thanks Pescado
Systemic Anomaly
Original Poster
#8 Old 12th Jul 2005 at 7:42 PM
For the curious (or not)...I went back last night and tried passing 0x06 to op2 on another RTBN call that was failing for me previously from another semi-global interaction, and it worked. Six is my lucky number
Inventor
#9 Old 13th Jul 2005 at 2:54 AM
So op2=0x06 works to make an RTBN call?

I noticed a weird pattern in your finds. op6=0x02 proves false and ends the BHAV. But op2=0x06. Is all this info correct?
Systemic Anomaly
Original Poster
#10 Old 13th Jul 2005 at 5:42 AM
op6 just specifies how you want to call the tree:

0x00 and 0x02 are similiar in that the called behavior runs in the context of the active stack object. The main difference is that op6=0x00 will treat the absence of the "named" function as an expected condition and just returns false whereas 0x02 treats the call as though you were calling a known private function. If it doesn't exist you get an Undefined Transition or Missing Check Tree (I can't recall the specific text) or some such thing.

op2 on the other hand, as JM describes, tells RTBN how to resolve the name of the function you're trying to call and how the params are to be passed to the callee. op2 is the operand of interest here, and op2=0x06 is the lucky set of bits needed to make this call. The value of op6 is tangential to this discussion.

J

PS. op6=0x01 is rarely used (but I tried it once for shitz n giggles) and means "run in My's stack"...it basically acts like Push Interaction and you can use it to "jump contexts" - effectively changing the "My" object to something else. The call is asynchronous, so you can't sit and wait for a return value from this call. It basically just queues up a function call on the stack object to be run later when that the stack objects main loop gets processed. The one caveat here is that a false return when op6=0x01 does NOT mean failure. I think a false return means the action could not be run immediately or something and was queued (possibly an indicator about the stack object's current idle state?) - but I'm not entirely certain. All I know is that true and false are both normal when op6 is 0x01.

Sorry if that is clear as mud.
Inventor
#11 Old 13th Jul 2005 at 5:45 PM
Thanks, jase!

But why do you need to know about making an RTBN call from inside the execution tree of an interaction? Is it just for knowledge purposes, or is it a clue to a new feature in the InTeenimater :hint, hint:?
One horse disagreer of the Apocalypse
#12 Old 21st Oct 2005 at 12:56 PM
Is it not possible to specify which object type holds the code you want to run, to avoid any possibility of having a duplicate BHAV name game-wide?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#13 Old 22nd Oct 2005 at 9:00 AM Last edited by dizzy2 : 22nd Oct 2005 at 9:18 AM.
It looks to me like operand 6 is the mode of the RTBN (0 = push onto Stack Object's stack, 1 = run in my stack, 2 = run in Stack Object's stack). So, either the Stack Object or Me is the ID of the object whose named BHAV you want to perform.

Operand 2 is the flags (bit 0 = global STR#, bit 1 = semi-global STR#, bit 4 = specify params, bit 5 = use current params).

If bit 0 and 1 are clear, then the STR# is private.

Bit 3 seems to relate to the Idle system (clear = idle, set = non-idle), but I have no idea what it does.

EDIT: Okay, I think that's sorted it. (Fixing disaSim2...)
One horse disagreer of the Apocalypse
#14 Old 22nd Oct 2005 at 9:16 AM
I know you can specify exactly where to get the string from, but it seems having got the BHAV name from the string, there is no further way of saying which object to start looking for that BHAV on. Running in current stack you could more or less take for granted - it's just a call to be executed like any other BHAV that might have been local or semiglobal.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#15 Old 22nd Oct 2005 at 9:22 AM
Quote: Originally posted by Inge Jones
... there is no further way of saying which object to start looking for that BHAV on.


The way of saying that is what the value of Stack Object or Me is before you perform the RTBN. If you "run in Stack Object's stack", that will perform the behavior of the object whose ID is currently in Stack Object (whose name is found in the STR#).
One horse disagreer of the Apocalypse
#16 Old 22nd Oct 2005 at 9:27 AM
Dizzy are you sure? That's not what I would normally understand from that terminology - although it's always possible the phrase is being used to use something different than I would mean by it. For example, I have always thought "running in my stack" meant running (anything) as part of my process, not running a method stored on me.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#17 Old 22nd Oct 2005 at 9:35 AM
I can only infer what I'm seeing in the objects.package itself. Right now, that code is telling me that this is how it works. *shrug*
One horse disagreer of the Apocalypse
#18 Old 22nd Oct 2005 at 9:40 AM
Well perhaps it does, and it's just confusingly expressed. I've posted a question to Tom in the hopes he has further light to shed.

On the other hand, if anyone reading this thread has actually made a mod and found themselves being able to successfully specify which object to obtain the BHAV (not the string) from, I'd love to hear. The true test would be to name two CT BHAVs exaxtly the same name but have them doing different things so you can tell if the right one ran. I could try that myself sometime I suppose.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#19 Old 22nd Oct 2005 at 10:29 AM
I think you're getting confused between the "stack" and the "Stack Object ID" (which are two completely different things). Let me think of a better way to describe this...

Operand 6:

0 = push onto the stack used by Stack Object ID
1 = run in the stack used by the "Me" object (aka My Object ID)
2 = run in the stack used by Stack Object ID

(The "stack" refers to the actual stack itself, and "Stack Object ID" refers to the generic parameter variable which unfortunately was called "Stack Object").
One horse disagreer of the Apocalypse
#20 Old 22nd Oct 2005 at 10:57 AM
I feel sure we're saying the same thing, ie I am used to the "stack" meaning the current process itself, with each function/method/BHAV call being a push onto the stack, and the return of the call being a pop from the stack. That is why you can set the Stack Object to be something different in a called BHAV and it returns to what it was before when that BHAV returns.

But I cannot see any connection between this, and what object actually owns the method/BHAV. For example, in some OO languages you would call a method on another object by <objectID>.<method> but it would still run as part of the process owned by your current "stack" or process, which can be owned by a completely different object.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#21 Old 22nd Oct 2005 at 2:27 PM Last edited by dizzy2 : 22nd Oct 2005 at 2:34 PM.
I think I see what you're asking. The "owner" object for the "method" being called is determined at runtime. When you compose the behavior, you either assign Stack Object ID to some object ID value or simply use the Me object ID, then do the RTBN.

In the case of the Stack Object ID, this is usually the result of a previous Set to Next or is passed to the behavior in a parameter (or something like that), and in the case of the Me object, this can be any Person object on the current lot that is interacting with the object that is performing the RTBN.
One horse disagreer of the Apocalypse
#22 Old 22nd Oct 2005 at 2:33 PM
I see. Well the call is not particularly useful then, because I wouldn't want to have to change the stack object just to find the code, having already set it to the object I want the code to act *upon*

Looks like I am just going to have to define my own global BHAVs after all. I'm starting at 0x900 so that shouldn't clash with anything. I hope BHAVs in that range will run when I come to test it...

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Field Researcher
#23 Old 22nd Oct 2005 at 2:37 PM
Quote: Originally posted by Inge Jones
I see. Well the call is not particularly useful then, because I wouldn't want to have to change the stack object just to find the code, having already set it to the object I want the code to act *upon*


Are you sure you understand what I'm saying? Because I have no freakin' idea what you're talking about.
One horse disagreer of the Apocalypse
#24 Old 22nd Oct 2005 at 2:51 PM
Probably not, but such are the limitations of the human language. Now if we were speaking a computer language, we could probably run a diff on the two of us and see which bits weren't calling the same parsing routines :D

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
One horse disagreer of the Apocalypse
#25 Old 23rd Oct 2005 at 9:29 AM
Ok, Tom says the BHAV is found on the Stack Object, so *if* that was what you were trying to say, then I understood you correctly. It's still annoying to have to change Stack Obj ID at the last moment though, under some circumstances - although at least one of the things I would be wanting to use RTBN for it's ideal to do that as I would be wanting it set to that anyway. And besides, now we can use more flexible parameters to the calls, I can always stuff the object I did want as Stack Obj into one of those.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Locked thread | Locked by: CynicalChick Reason: Locked by request
Page 1 of 3
Back to top