llMessageLinked limits?

Is anyone aware of any limits to the number of scripts that can receive a linked message in a linked object.

So, say the link set has 100 prims and each has a script in it that carries a link_message event handler. A script in the root prim issues a llMessageLinked to LINK_ALL_CHILDREN... are they all guaranteed to receive the message? Will all 100 scripts execute, or might some kind of cap come into effect?

I know, not an everyday situation but if anyone as any experience at these extremes I'd be interested!

The event queue limit is 64 events per script if i recall, so if you are sending one message _to_ whole linkset, all prims are likely to receive it. But doing it the other way (each prim simultaneously sending one message) is likely to clog the event queue(s) of all receivers if your linkset consists of some 60+ prims o.O;

Thanks for your reply Joannah but no, I'm just looking into a problem with sending a single link message to many, many scripts in child prims.

It seems to be good up to around 30 prims but beyond that things get fuzzy.

I've made scripts that send a link message to 70+ prims and never had one dropped. I don't think it'd be a problem with the link messages itself, but possibly something in your script. What are you trying to do? Would you be willing to post the scripts or snippets?

Well, it's a product that I produce that allows you to save several prim states and then recall them later. Having now done some experiments with a 100 prim linkset, and using scripts that report their progress using llSetText, I suspect it maybe an extreme performance issue.

While I ran my test, and as the 100 prims restored a previous state (the saving part was no problem), they all reported fine but the sim script performance dropped from around 40,000 ips to 4,000 ips. It took a long time but it did work eventually. I guess the linkset was being tortured by so many changes all at once that the Asset Server just screamed the whole time. The test prims were all simple cubes, so it can get a lot worse.

The scripts in the child prims save and set every single prim setting that can be set by a script - and the set part does this pretty much with a single statement. The device works fine up to a point but seems to reach some critical mass when applied to too many prims.

Basically, it doesn't scale at all well.

Unless it's crucial to have all changes happen at exactly the same time, you could probably work around it by running a loop that walks through and messages prims in the set individually. Or simply have each restore script execute itself with a delay calculated from number of prim they happen to be in. (you can merge them in smaller 'banks' of prims changing simultaneously this way) Given the side-effects you report, a bit of delay is probably lesser evil than dropping whole sims to its knees... o.O

edit: also, keep in mind SetText enforces full refresh of the whole object when used, while setting individual attributes of a prim doesn't have to have such effect. So 100+ set text calls at the same time = 100x the refresh... with larger object that can choke things quite well, alright.

Thanks, Joannah, I'd also been thinking along the lines of staggering the llMessageLinked instructions - loop for 10, pause, loop for next 10, etc., sort of thing. It still doesn't get away from the fact that triggering multitudes of loaded (and I mean VERY loaded) llSetPrimitiveParams seems to be inherently inefficient.

The llSetText thing was just in there for debugging so that I could be sure each of the child prims was getting, and responding to, its link message, so going forwards that's not an issue. For what it's worth though, all the titles appeared pretty much simultaneously, and after a very long wait while the prims set, they all disappeared simultaneously - and the sim performance recovered immediately.

heh, okay... I've now tried two strategies.

Firstly, spreading the rate at which the Linked Message instructions are sent to the child prims. To be honest this really didn't help a lot. It seems that llSetPrimitiveParams in a large link set is a real performance killer regardless of how many of the prims are being changed. Just one of them really hits the sim's Script Performance hard. Doing them all together or spread out pretty much amounts to the same overall performance hit - the llSetPrimitiveParams requests are probably being queued server side in any case.

My second strategy was to reread the prim's state and then compare it with the saved state to see if it's worth applying. This works great when only a few of the prims are to be changed but isn't going to help if lots of the prims are changing.

A third strategy - and probably the best - would be to compare each individual setting imbedded in the llSetPrimitiveParams setting, but this would be very onerous to code.

I kinda feel that the server side routines are themselves not being very clever, and given the performance hit maybe they should be checking to see if applying the individual changes is actually necessary. I suspect this is the reason for the 0.2 second delay on the llSetPrimitiveParams function - which of course I've completely circumvented by using many scripts and by imbedding all the changes into a single instance.