HUD Heavy link message problem? -

[RedEagle87]

I am developping a heavly scripted HUD using Media on Prim as I mentioned in a previous thread.

The HUD now becomes heavly scripted with more than a 100 scripts.

My problem is that there is a script or 2 that their link_message events not receiving the message at all? even after I debugged it. The flow does not reach after link_message(...) line code

I read the wiki and they say that in some circumstances the following:

• Avoid sending link_messages to large numbers of scripts simultaneously as it can cause lag spike. This most often happens when using the multi-prim LINK_* flags and can cause script execution to slow or halts.
• Avoid sending link_messages to a target faster then they can be handled. Doing so risks filling the event queue and subsequent messages being silently discarded.

Now if that is the case, which I don't know I debugged my code and nothing seems wrong in the logic. Every message is well thought about and is needed.

I have done effective  link marshalling  and de-marshalling if the terms are right (meaning not using LINK_ALL_OTHERS, LINK_SET etc..) constants that broadcast or multicast messages) but just the link numbers of prims directly.

The performance of the HUD enhanced considerably. Per example close bottons on the HUD tabs (instead of sending to all prim) now just send to the concerned ones only)

1) My questions is How I can surpass that, is there another trick , method or function?

knowing that I cannot reduce the number of messages or cancel any feature for that sake. My client won't allow me :)

2) Another question, may seam a poor design decision in the first place. I didnot know How much prims should link in the Object when first linked. Now I need 2 prims more for decoration. If I added 2 more prims the whole link numbers will be ruined and the HUD would stop functioning (because of link marshalling techniques needed in such situations- the prim will be hidden and very small ( and it is tedious to find them).

How I can add 2 more prim and let them have the last numbers ONLY, not ruin the whole link order(Root =1 , child1 = 2 etc..)

I am using the following script from "Creating your  world : The official guide to advanced content creation..." to match the names of the Prims with their corresponding numbers:

//Author Aimee Weber et al.

list gLinkInfo;

default
{
    state_entry()
    {
        gLinkInfo = [];
        integer n = llGetNumberOfPrims();
        if(n==1)
        {
            llOwnerSay("This is a prim not an object");
        }
        else
        {
            integer i;
            for(i = 1; i<=n; i++)
            {
                gLinkInfo +=llGetLinkName(i);
                gLinkInfo += i;
            }
            //llDumpList2String(list src, string seperator)
            llOwnerSay("Prims in this object are: " + llDumpList2String(gLinkInfo, ", "));
        }
       
    }
}

 

[Dora Gustafson]

My candidate is event queue overflow
The queue can hold 64 events Max
If this is the case you will see that some listening script will drop some messages
The cure could be to add different delays (llSleep()) in different talkers

I have used that strategy and I set llSleep(k*llGetLinkNumber());
Where k is a suitable constant

[Innula Zenovka]

You know best, but I really suspect 100 scripts sending link messages round may be overkill.   One script in the root can detect which part of a particular face on a particular prim you've touched, and figure out from that what button you've clicked, and then, knowing that,  it can tell any particular prim in the linkset to do pretty much anything, using llSetLinkPrimitiveParamsFast.  

As to the second question, knowing which link number is which, I would use link names (or descriptions) to read the names of the prims and thus assign their link number to a particular variable.   Then I would stop worrying about what the actual numbers were.  

To give a trivial example, if you do something like this,  you can forget about which link number any particular button is -- so long as it has "red" or "green" or "blue" as its description, so long as you haven't changed the description since the last time you relinked it, the script should know what to do.

 

integer red_button;integer green_button;integer blue_button;find_prims(){	integer max = llGetNumberOfPrims()+1;	while(max--){		string s = llToLower(llStringTrim((string)llGetLinkPrimitiveParams(max,[PRIM_DESC]),STRING_TRIM));		if ("red"==s){			red_button = max;		}		else if ("green"==s){			green_button=max;		}		else if ("blue"==s){			blue_button=max;		}	}}vector colour;default{	state_entry()	{		find_prims();	}	on_rez(integer start_param)	{		find_prims();	}	changed(integer change)	{		if(change & CHANGED_LINK){			find_prims();		}	}	touch_start(integer total_number)	{		integer n = llDetectedLinkNumber(0);		if(n==red_button){			colour = <1.0,0.0,0.0>;		}		else if (n==green_button){			colour = <0.0, 1.0, 0.0>;		}		else if (n==blue_button){			colour = <0.0, 0.0, 1.0>;		}		llSetLinkColor(LINK_SET,colour,ALL_SIDES);	}}

 

[RedEagle87]

Thank you so much for your help.