Just discovered something important about llDie()...

After about a week of trying to figure out why my objects were not getting an important message from a sender object... I've finally figured it out...

After my object sends the message, I have the object set to llDie()... In heavy lag areas, if the object is removed before the other objects hear the message, they will never get it.

I would have thought that if the message was sent before llDie(), it would be heard by everything even if the sender object was removed...

I guess not... I posted this to save people some brain trauma, I also think this should be noted in the wiki's...

- Grant

There have been recent reports of email failing sim-wide.
You might keep an eye on the blog, and try your tests again!

Well it's just llWhisper/llSay/llShout... not E-mail...

But if it's related to that issue, than I will try again...

But what I had to do, was send a message back to the sender that confirms the message was recieved and it can now die.

It's just an issue having llDie() right after a chat send...

llShout(-432, "Message";
llDie();

^^^ if the object dies before the receiver receives the message, it does not get through, sometimes it would report all of the items getting the message(low lag), and sometimes only some items would receive it(quasi lag), and other times no items would receive it(high lag).

That's kind of illogical(the way it's coded), but it happens... It would be better if when message is sent before llDie(), everything should get the message that is listening for it even if the sender object was killed after.

If it is tied to the failing e-mail issue, I'm not sure.

Wow, that's weird. It's as if the listen event gets deleted as the object dies. I think you should report this as a bug.

Tell me about it, it had me going through my code for a straight week, reporting every variable, and when everything did what it was susposed to, I was dumbfounded... Which brought me to the only thing it could be... llDie(), which I was skeptical about, because what it does is illogical... :/

The two calls are probably being triggered at the same time. Just add a llSleep between them (llSleep(0.25); would be good probably) and that will fix it.

It probably has to do with how actions are queued. Communications could very well be placed into a separate queue for sending out, and the llSay/etc commands are just triggering placing that message into the queue to be sent out. Then you are immediately killing the object, before the communications queue resolves.. resulting in the object not being a valid source for a communication when that queue gets around to sending out the message.

But thats just a guess.

Added the sleep and tested in a high lag environment, so far so good...

So should I keep the sleep, or use the confirmation message for deletion?

I think I could just add a 1 second sleep to be safe...

I go with a sleep command in these types of situations. It works really 99.9% of the time if the sleep is 1 second or longer. It's also less work than doing a confirmation message

As the "controller" (the one sending the message) will be doing nothing other than sleeping and then dying there is no compelling reason to not make the sleep longer.

Using confirmation schemes gets tricky and is provably not able to guarantee confirmation (as illustrated by the Two-Army Problem).

I agree.