Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Detach event not getting through

Maya Remblai
The one with pink hair.
Join date: 25 Mar 2006
Posts: 434
03-22-2009 21:03
This is driving me nuts and I have no idea why it's not working! Here's the set up: I have an avatar that can carry an object. If it's NOT carrying something, it flaps its wings when it runs. If it IS carrying something, it doesn't flap its wings. The carryable object is scripted to send a simple message to a seperate attachment when it's attached or detached. Debug messages show that it is, indeed, sending these messages. Here's where things stop working though: The AO script that listens for these messages is only hearing the "attached" message, and not the "detached" one.

Here's the object's script:

attach( key id )
{
if (id)
{
llWhisper(-642, "Holding";);
}
else
{
llSay(-642, "Detached";);
}
}

Here's where the AO listens for a report from the object:

listen(integer channel, string name, key id, string msg)
{
if (llGetOwnerKey(id) == llGetOwner())
{
if (msg == "Holding";)
{
helditem = TRUE;
}

if (msg == "Detach";)
{
helditem = FALSE;
}

And where it changes the running action according to the helditem integer:

if (animstate == "Running";)
{
if (aostate != 2)
{
StopAll();
llStartAnimation(run);
aostate = 2;

if (helditem)
{
llWhisper(-742,"fold";);
}

if (!helditem)
{
llWhisper(-742,"unfold";);
}
}
}


No matter what I do, the detach message is never recognized by the AO script. I've tried different types of if statements, Mono/not Mono, etc, and it just doesn't work. The helditem integer always gets stuck on TRUE even when the command for making it FALSE has been sent. Any ideas?
Jim Gustafson
Registered User
Join date: 6 Feb 2007
Posts: 84
03-22-2009 23:05
It's just a typo, first you say "Detached" but you listen for "Detach"

Jim
Viktoria Dovgal
Join date: 29 Jul 2007
Posts: 3,593
03-22-2009 23:06
This difference might be your whole problem.

llSay(-642, "Detached";);

...

if (msg == "Detach";)

Always the little things that get in the way when you stare at things for too long!
Te Tenjin
Registered User
Join date: 1 Aug 2007
Posts: 4
03-23-2009 03:41
Here's where llOwnerSay() comes in handy.

Make sure the attach event handler is actually firing by placing an "llOwnerSay("attach event: " + (string)id);" at the start.

in the listen event of your AO, an "llOwnerSay(msg);" will tell you the event is firing and what it hears.
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
03-23-2009 11:01
Note also that detach event handlers may not get much time to execute. It is suggested that you not do anything lengthy in your handler. This is obviously a pretty short bit of functionality, but who knows exactly how much can be done. It might be better to simply set a boolean flag and then do any necessary processing on the next 'on_rez' event if possible.

See the note at the bottom of http://www.lslwiki.net/lslwiki/wakka.php?wakka=attach
Maya Remblai
The one with pink hair.
Join date: 25 Mar 2006
Posts: 434
03-23-2009 15:31
Jim: That typo is only in the forum post, my mistake. I copied and pasted the command between the actual scripts.

Te: I did that. Like I said in my original post, debug messages like that show that the messages ARE being sent, but the AO script isn't listening to the second one.

Hewee: My experience shows that the attach event can handle a surprising amount of scripting. My avatars that use deformers execute an undeform command when the object containing the AO is detached, which means playing as many as 10 animations or so. The object sending this command IS sending it, the problem is the listening script isn't hearing it. Unless LL just really messed up the ability to detect a detach event, time isn't the issue.

As for an on_rez event, the held object can send the "held" message, but that message already gets through with just an attach event, so I don't see the point. I need a way to inform the AO script when the object is DEREZED, not rezed, that's my problem. Can on_rez detect derezzing?
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
03-23-2009 15:46
From: Maya Remblai
As for an on_rez event, the held object can send the "held" message, but that message already gets through with just an attach event, so I don't see the point. I need a way to inform the AO script when the object is DEREZED, not rezed, that's my problem. Can on_rez detect derezzing?

What is your definition of derez? There are only two ways to "derez" something and that is take it back into inventory or delete it. You could easily know when whatever command is issued to detach or delete. If it involves manually selecting the object and deleting/detaching then you would have to go with some kind of timed message or query (Are you still there?). Or if it is part of a linkset then the change/link event would fire and you could use that.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime.
From: someone
I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
Maya Remblai
The one with pink hair.
Join date: 25 Mar 2006
Posts: 434
03-23-2009 20:35
Jesse: By derez I just mean detaching the object, not anything else. I should have been more clear, sorry. I considered a timed "are you there?" sort of thing, but that probably wouldn't be fast enough to be useful without making a very fast timer, which in an avatar script I prefer not to have too many timers or listens. And this isn't a linkset we're talking about - you can tell by the fact that I'm using listens and llSay. It's two seperate objects that need to be able to communicate, and they do for the first message, just not the second.

It may be the only way I can get around this is to have another script in the same linkset as the AO that handles the checking, and then link messages the AO about what it should be doing. I'm not inworld at the moment, I'll have to try it later. It seems a round about way of doing things though, I hate it when the simple method is too complicated for SL to deal with. :p