Wierd llInstantMessage problem

Ok, here's one for ya:

I am writing a security system, and it can notify multiple users of events which occur. I have myself and an alt set to be notified of detected users.

Everything works fine, we both get notified. Except, for some odd reason, only ONE of us gets the following IM:

Security Panel Notifier: NORTH Sensor: Detected UNKNOWN User "Natasia Vuckovic"

All other messages are getting through fine. I have both myself and the alt logged in, watching both screens. I can clear my detection list, meaning it will re-send all the detections again, and every time that particular message makes it to myself, but not to the alt. Sometimes this particular detection comes in different places among the list, but still doesn't make it to my alt.

Besides a very obscure bug in SL's instant messaging, does anyone have any ideas? I just happen to catch this one -- I wonder how many other IM's from objects don't make it through on a consistent basis?

I did create a new object, and put a script in it to send that message to my alt, and it makes it everytime.

?

I'm guessing the bug is in your script. Try swapping owners with your alt to see what happens, or swapping avatar keys so that all IM sends go to one key (so you get doubles).

Or maybe just hard-code your alt's key into that IM which fails, and include a DEBUG_CHANNEL chat to see if the script even gets there.

If the IMs are very rapid-fire... try logging the owner account out, then see if the message comes through to your alt. Could be your router not switching the traffic properly in certain rapid-fire situations.

That particular resident has left the area so I can't do any more testing of the problem.

Before she left, though, I did add a llOwnerSay line right before the llInstantMessage line, showing me the UUID the message is being sent to, and the message being sent. It told me the IM was sent to both users, with correct UUID's. It also showed the same for all the other IM's going out. The UUID's were the same, and those messages made it. That being the case, I don't see how it could be the script.

But you do have a good idea. I tested the message by creating a new object and hard coding the message, which worked. I will try hard coding it into the actual object that is sending the "missing" message and see what happens.

Yeah, without seeing the scripts, it is unlikely we can give you an answer. I have a lot of objects which send IMs to multiple people, and have yet to not receive them.

I've experienced random dropped IMs in scripts that I've written. I'm not sure what causes it though. Sometimes an IM will send, and then sometimes it won't, I haven't been able to figure out what causes it.

try inserting a short delay between IM's.. just a guess, but maybe the rapid succession is what's causing it. I'm guessing you're using a for loop.. just add a 2 second sleep to it and see if that cures it.

Did that. In fact, I have found that if I do not use a sleep after a llRegionSay delivery is very unreliable. So I use a sleep after IM's also.

It may have been a weird mute problem. I have removed every item in my mute list. We will see if that fixed it. If it does, the fact that I was using the Able edition of the viewer for a while might be tied into the mystery.

This kinda sucks... if someone is going to come into the SL forums to ask about a problem, it's good to state upfront that they're not using the standard client/viewer software.

Ok, here is what I have discovered (with the stock 1.18.0 (6) viewer and an empty mute list):

Another message was consistently not making it to my alt, but making it to me just fine. This was not intermittent, it was every time for this one particular message.

As per a previous forum poster suggestion, I hard coded the UUID's and the message, by simply adding 4 lines to the default state's state_entry(). These 4 lines were the 2 hard coded llInstantMessage lines and a llSleep(2.0) following each. Same result: My alt never received the message, I did.

Then I changed the message being sent (left the hard coded UUID's alone). It started working. After some experimentation, I discovered my alt would not receive the message only if it was 64 characters long! 63 or 65 characters were fine, those messages got through. This was very repeatable.

The script sending this was in a child prim. I tried sending the 64 character message from the parent prim, and it got through just fine. I thought I had a JIRA issue at this point.

I created 2 new objects, linked them, and experimented. I could not reproduce the problem. 64 character messages were getting through fine from both prims.

So, in my original object, I stopped all the scripts, copied them into my new parent object, started them running/reset them, and still could not repeat the problem.

I went back to my original object, restarted/reset all the scripts, and the problem was gone. 64 characters messages from the child prim were now getting through.

I have a feeling at some point in time 64 character IM's from the child prim will stop working again, and I will try to further narrow this down. In the meantime, anyone experiencing IM's from objects not getting through should experiment, keeping the 64 character messages from child prims thought in mind.

Comments?

I expect that the child prim was somehow set to a weird state. Some internal SL flag that we can't detect.

I've had similar issues with an attachment. If I reset the script or edit the code while it's attached, it won't perform a particular function. It shows it's working but the function just does nothing. Detaching and re-attaching it lets it work again.

I can now reproduce it. It turns out the prim's name has to be 23 characters in order to reproduce the problem.

Everyone try this:

Create an object. Name it 12345678901234567890123 or any other 23 character name.

Put the following script in it. Touch it. I am willing to bet you receive all three messages (most of the time), but the other person receives only the first and third ones (most of the time).

EDIT: After multiple tests, I find the middle message gets through once in a while, but about 80% of the time it does not. I went to a different region and tried it - same results.

Please let me know the results.

default
{
touch_start(integer total_number)
{
llOwnerSay("Touched.";
llInstantMessage((key)"<INSERT YOUR UUID HERE>","123456789012345678901234567890123456789012345678901234567890123";
llSleep(1.0);
llInstantMessage((key)"<INSERT YOUR UUID HERE>","1234567890123456789012345678901234567890123456789012345678901234";
llSleep(1.0);
llInstantMessage((key)"<INSERT YOUR UUID HERE>","12345678901234567890123456789012345678901234567890123456789012345";
llSleep(1.0);
llInstantMessage((key)"<INSERT SOMEONE ELSE'S UUID HERE>","123456789012345678901234567890123456789012345678901234567890123";
llSleep(1.0);
llInstantMessage((key)"<INSERT SOMEONE ELSES UUID HERE>","1234567890123456789012345678901234567890123456789012345678901234";
llSleep(1.0);
llInstantMessage((key)"<INSERT SOMEONE ELSES UUID HERE>","12345678901234567890123456789012345678901234567890123456789012345";
llSleep(1.0);
}
}

Kinda replicated it, except the 64char IM would go to neither my alt nor me. And the child prim name seems to trigger it if it is the length of "Security Panel Notifier" (23chars) but doesn't have to be exactly that text. With names of a different length, all behaves as expected. Can switch from "good" to "bad" behavior just by changing the name, without having to reset the script. Very odd indeed.

Thanks for testing that for me. You are right, the 23 character name is the key. I just tried it in an unlinked prim, and got the same results. So child prims have nothing to do with it.

This definitely sounds like a JIRA issue to me. And I am hoping that once the root cause is found, that it will be at the heart of other IM problems too.