This information is related to SVC-602.
After some extensive testing I have a lot of information, but it is confusing to say the least. I am posting this as critical because I really believe this to be at the core of many IM related problems, and if the cause turns out to be TCP/IP related then it could explain many other otherwise unexplained glitches in SL.
Using the llInstantMessage command, when sending IM's to an avatar in a different region I am able to reproduce at will the following patterns:
Pattern #1: If the object name length + the message length = 85 characters, the IM fails to arrive. Using a script, I started with an object name of 1 character and a message length of 84 characters, and sequenced incrementally to an object name of 84 characters and a message length of 1 character. Each time the length of the two totaled 85 characters the IM failed to reach the avatar (with rare exceptions, noted below), while message and/or name lengths on either side of this total got through 100% of the time.
Pattern #2: Unfortunately, the 85 character total is not a hard and fast rule. After losing my connection and reconnecting to SL, running the same test produced identical results except for one thing: This time the "magic number" for producing failed IM's was 86 characters.
Pattern #3: In addition to the two patterns listed above, tests from several days ago done by myself and verified by another resident showed that 23 character object names combined with 64 character messages did not arrive, indicating at that time the magic number was 87 characters. Maybe this slight difference in the magic number is related to which login server you get? Just a guess.
Pattern #4: Once in a while, a message that according to the above patterns should not have gotten through did get through. When it did, the object name was usually a multiple of 12 characters (or very close to it).
Pattern #5: Avatar position seems to play a role. If the avatar receiving the messages is in the same region as the object sending them, the messages usually got through. However, I was able to find at least 2 places where I could stand in one position and receive every message, but then move 1 meter further away and would start missing the messages with the magic number of characters. One position that was very repeatable was: 166,55 OK, 167,55 not OK. This is with the sending object at 28,63.
This may be more information than you need to know, but I wanted to give as complete a picture as I can, hoping that some of the patterns will help track down the culprit.
string OBJECT_STRING = ".................................................................................................................................";
default
{
state_entry()
{
llSay(0, "Touch me to start the IM test."
;}
touch_start(integer total_number)
{
key UUID = llGetOwner(); //Or insert your favorite UUID here
string object_name;
string msg;
integer x = 0;
integer y;
while (x < 86)
{
object_name = object_name + "l";
llSetObjectName(object_name);
llSleep(3.0);
llSay(0,"Object name length: " + (string)llStringLength(llGetObjectName()));
llInstantMessage(UUID,"New name length: " + (string)llStringLength(llGetObjectName()));
llSleep(0.5);
msg = llGetSubString(OBJECT_STRING,0,85 - x);
while (y < 4)
{
llInstantMessage(UUID,"Next count: " + (string)llStringLength(msg));
llSleep(0.5);
llInstantMessage(UUID,msg);
msg = llDeleteSubString(msg,-1,-1);
llSleep(0.5);
y++;
}
y = 0;
x++;
}
}
}
