unpredictive detach event behaviour?

Im currently pretty lost on what to do. Im working on a HUD which automatically sets itself up depending on which items are attached.

this works beautifully for attaching, but when I detach, nothing happens. I know the system itself works since I can just type /313 PART_DETACH and it will work.
but when I do an llWhisper() inside the object that is being detached, no message is heard.
HOWEVER: when I whisper on channel 0, I see the message pop up in chat.

I thought the script might be too large (400+ lines after all..) so I created another script just for that purpose, its <10 lines and simply does the same as the other would do. still nothing.

is there any magic trick to getting this to work, or is it just hideously inconsistent and I better use a different way of working it? (the alternative would be a timer checking for the presence of objects, something Id rather avoid due to lag issues. that or have a refresh button on the HUD, but the plan was to handle it automatically)

You may have to be more precise than saying 'inside the object', for example, your problem may be due to the fact that a prim cannot hear itself. The more usual way to communicate within an object is to use link messages. An individual prim can receive its own link messages.

The detach() event is not guaranteed to fire off before the item gets removed from the sim. In many cases it does not until the next time it's rezzed. It's a race condition.

See this JIRA for more info:

http://jira.secondlife.com/browse/SVC-1961

Need more info >.> What code are you using when detaching and using for the HUD to detect that its you that removed some one not some one else.

If you are using llGetOwner for detection I dont believe it will work. I had an issue when I first started scripting when creating a HUD for a weapon where I was using llGetOwner for verification and well. The object doesnt own the object. You do. So if you type the order, it will work but not when you press the corrisponding HUD button. Just a wild stab in the dark there >.>

If your listen handler depends on llGetOwnerKey, that is right, it doesn't work out so well. You will usually end up the object's own key as its reported owner at detach time.

hm that does sound like its my problem right there then, as indeed, I use llGetOwnerKey() to ensure only accessories by the same owner will interact with the HUD. thanks for pointing this out, I hope this gets fixed some time

edit:
I think I just found a workaround. Ill simply change the system to store/replace object keys from a list (its only a maximum of 3 keys), and check whether _id shows up in this list when a detach event occurs. and from my brief tests, it seems like llWhisper() does get through from the detach event all the time, so I should be good in that respect. nevertheless I might include a small refresh button to re-check the currently attached objects, incase something gets stuck

I'm not sure it can be fixed The trouble is that the listen handler will be checking the object's owner after it's been detached, so the information isn't there to check (owner==uuid is the normal result for an object that isn't in the region).

yeah I found a workaround!

the program now runs as follows:

- attachment attaches, sends "PART_ATTACH" as whisper
- HUD picks up "PART_ATTACH"
- HUD enters attachment key into appropriate list position
- HUD sets itself up

incase of a detach:
- object whispers "PART_DETACH" before detaching
- HUD picks up "PART_DETACH"
- HUD checks if detaching part was previously attached
- if yes: HUD removes detached part from list, sets itself up

this means the system doesnt need to be revamped completely, and the initial if (llGetOwnerKey(id) == llGetOwner) check just needed to be expanded by a simple list find check