View Full Version : Wait for notify leading to routing failure?
4th Mar 2011, 5:24 AM
At the end of an interaction, I want the Sim to route to a particular position (e.g. to the mailbox) regardless how or why the interaction ends.
The Sim has a X% chance of "failure" (based upon body skill) which forces the Sim to quit the interaction...similar to when the Sim gets too scared to jump off the diving board. When this happens (or motives drop too low), the Sim goes through the exit protocols for the interaction which conclude with the Sim routing.
When the I cancel the interaction, however, all of the exit protocols work except for the routing. It's as if the act of canceling the interaction carries over to the canceling of the routing. Could this be the case?
The bhav is a bit lengthy but here's the gist:
30: [global 0x0119] Wait For Notify (2 args: Ticks=0x0000, Allow Push?=0x0000) (T:31, F:29)
31: Stop Sim animation (T:32 F:32)
32: Get rid of the props (T:33 F:33)
33: Set the destination as the Stack Object (T:34 F:34)
34: [prim 0x001B] Go To Relative Position (Location: On top of, Direction: Same direction, no failure trees: True, allow different altitudes: True) (T:T F:T)
Nodes 30-33 work, but node 34 seems to be ignored whenever the interaction is manually ended.
Is there something obvious I'm missing? Am I doing something that's stupid? Is there a work-around?
5th Mar 2011, 3:20 AM
What's happening when you say "Set the destination as the Stack Object"? Is continuing blindly on going to work if it fails? And are you playing with testing cheats?
5th Mar 2011, 3:46 AM
[prim 0x0002] Expression (Stack Object ID 0x0000 := Local 0x0004), where Local 4 gets its value from Temp 0 using a slight modification of your "Get in Temp 0 - ID - Closest whatever" bhav. (Instead of passing in the Sim's object ID, I'm passing the wave effect's object ID to get the closest beach portal ID. This way I can tell the Sim to route out of the ocean when done surfing without having a pile-up with multiple surfers swimming to the same portal.) I get the portal object ID earlier in the bhav, shortly after the Sim finds the unoccupied wave effect object.
Yes, I've got testing cheats on. I can set the false route on that node to Error though.
ETA: I don't get an error on the false route on that node.
ETA2: I'm attaching the package if it will help. The "Interaction - Surf" bhav is admittedly a bit long, despite my efforts to branch off parts into other bhavs. I've actually mislabeled the node numbers in my simplified version. My nodes aren't sorted, as their current order makes more sense to me.
As-is, the Wait for Notify bhav is node 47. Sorted, it's node 65. The Standard Exit did not seem to be clearing the "In Use" flag properly, so that's why there is the manual flag clearing.
9th Mar 2011, 8:27 AM
I've done some more testing. I've set the "Go to Relative Position" node to return Error on false and successfully got the expected error for when the node returns Error. It seems that the "Wait For Notify" indeed forces a return "False" for the rest of the bhav (or at least on routing nodes). Thinking perhaps that this would resolve itself once the tree has terminated (judging by the way the action in the Sim's action queue remains X'd), I created a new bhav which would be a wrapper for the surfing interaction's bhav and which would re-instruct the Sim to route. Sadly this was without any apparent success. It seems no matter what I do, any post-"Wait for Notify" routing is going to be automatically canceled.
Would pushing a separate "Swim Away" interaction (possibly even located in a separate .package file -- I'm that desperate :lol: ) whose sole purpose is routing onto the Sim resolve this? The main "surfing" interaction should be considered concluded and, hopefully, routing sanity would return.
I'm a little uncertain what should be the operands for the [prim 0x000D] Push Interaction. (I understand the Interaction would be the number of the interaction in the TTAB.) I keep getting either "No stack object present when required" or "Object referred to must be a person" errors.
At this point in the surfing interaction, the Stack Object is normally the beach portal. So I use [prim 0x0002] Expression (Stack Object ID 0x0000 := My person data 0x001F (neighbor id)) then [prim 0x0002] Expression (Local 0x0006 := My 0x000B (object id)) for [prim 0x000D] Push Interaction (Target: Stack Object, Object: Local 0x0006, Interaction: Literal 0x0001, maximum priority, Icon object: Local 0x0006, Icon index: Literal 0x0000). Am I barking up the wrong tree with the whole "Push Interaction" idea?
My plan is to push the interaction only if the "Go To Relative Position" node returns false, as that should be the only time it would be needed. I wish I could pass the id of the portal onto the other bhav so that I wouldn't have to find it again. (I initially find it even before the Sim begins to route to the water to get rid of the slight lag that takes place while searching for it.)
(If I'm not making any sense, it's because I should have gone to bed several hours ago. -.- )
ETA: Instead of passing the ID to the next bhav, perhaps I could store it on an attribute inside the self-interaction?
12th Mar 2011, 5:47 AM
If the "Go To Relative Position" returns false, that means that for some reason or another your sim was unable to get to that location. Either that location is blocked by something, or your sim was, and pushing more interactions is unlikely to fix the problem... One thing you might try is changing the "Go To" target so that instead of "on top of" it's "in front of" or some such. If that still doesn't work, you might need to stick in a "Go To Routing Slot (global 0x0008)" to get the sim to move out of the way of whatever is blocking it.
12th Mar 2011, 8:10 AM
The "Go To Routing Slot" also returns False. What confuses me is that routing works when the interaction ends via "Wipe Out," which bypasses the "Wait for Notify" node. The only difference between ending the interaction by "Wipe Out" versus canceling the interaction should be the animations. I don't understand why something would be blocking the Sim in one case but not the other. It couldn't be that the NPC is in the way because the NPC is deleted before the Sim's routing starts. The Sim couldn't still be stuck on the cart because that gets deleted with the NPC; thus the Sim would be gone too. Even if it was a matter of the Sim being in the ocean (i.e. "locked tiles" or something), there is still the question of why it works for the Wipe Outs.
Here is the most recent code with an error log. (If it helps, the wave object is Local 0x0, the NPC is Local 0x1, the cart is Local 0x2, the surfboard is Local 0x3, and the portal is Local 0x4.)
Again, thank you so much for your help. :)
12th Mar 2011, 9:32 AM
Unfortunately I can't test it, because I don't think I have the right EPs set up at the moment, but here's something to consider. At the moment, your BHAV has pretty much every line set to continue to the next line, regardless of whether it returns true or false. That's not really a good idea when you're developing. The only time you should point both true AND false to continue is if you are confident that it doesn't matter whether the line actually succeeds or not (like running an animation or starting an effect - they're eye candy but they won't break subsequent code). I can see several lines which, if they failed, could cause all subsequent lines to fail. For example, if:
[prim 0x0012] Remove Object Instance (Stack Object, return immediately: False, cleanup all: True)
failed, then the object would still exist, potentially blocking the sim's path. Or if this line failed:
[prim 0x002E] Snap (slot number 0x0001, from slot in temp 1: False, ask person to move: False, TEST ONLY: False)
then the sim would (presumably) still be stuck inside the object and therefore unable to route away from it.
In those circumstances, it looks like the later line is the one causing the error, when it was actually something which happened quite a while before hand. It might be a good idea to go through, and for any commands which have the potential to break subsequent commands if they fail, point the false target to error. Then try it out and see if any of them actually are breaking.
13th Mar 2011, 12:21 AM
I've cleaned up my loop a bit (I had some redundancy/less than efficient or logical decision-making regarding when to Wipe Out vs when to check for "Exit Skill Object?"). I kept the same return settings for animations (since I recall reading from somewhere that they occasionally return false for some unknown reason) and various evaluations (e.g. value-oriented or logical, "should I be paddling?" type). Just about everything else now has a "Return Error" for their false path. Yet it still only breaks on the routing when the interaction is terminated manually. Is there anything else here that could have the potential to break subsequent commands?
vBulletin v3.0.14, Copyright ©2000-2013, Jelsoft Enterprises Ltd.