Many-prim communications

I need to send messages to about 2,000 prims on my land, evenly distributed amongst the ground.

I havent tried linking them, but IM fairly confident I cannot. The commands neccessary are just to set textures, and make the prims invisible. The changes are only done sparingly, and really meant as a building aid.


I know that llisten()'s add to the sims lag, so I was considering maybe using XML-RPC to "poke" each prim one by one, and then they will internally fetch work orders over http off of a server I run. Is this feasible? Would all of those open xml-rpc channels be just as much lag?

Am I deluding myself, and should I just use llisten?



Thanks!

*moves*

Just use llisten Keep it simple

You're gonna love adding scripts to 2000 prims. Hopefully, you get it right the first time. On the other hand, there might be a better solution to whatever it is you're trying to use the 2000 prims for.

If you're simply showing/hiding, and changing textures as a whole... then you could link the prims into maybe 20 groups of 100 each, and use only 20 total scripts. The root-prim script can then be used to control the texturing of the child prims.

I think listen on an obscure channel is the way to go, you can use llRegionSay to communicate to everything, and they should only introduce lag when data shows up on that chat channel, at least this is my understanding.

Effectively it is these hidden implementation details that I am after. I have no idea if the llistens work off of signals or if there is some polling involved.

Either way, I intend on using a special channel and a keyword at the front, so the listen events shouldn't be continually hit.

I think I will still send commands with a php script on a server though. This way, people could "poke" the objects to poll the php server, but nothing else.

XML-RPC is still more secure with regards to poking the prims though, as in this case its impossible to spy on the comunications (unless you are pcapping the grid )

One thing to consider is the impact of 2K idle scripts, with or without a listen involved. As demonstrated in , every script in running state consumes some CPU, almost as if the scripts are polled to see if there's anything on their event queues.

If you're trying to make some kind of large grid, maybe use particles instead. A few particle generators scattered around, sending round, or stretched-out, particles to each other, might give you the tool you need for your building needs?

THis is the single most shameful piece of sloppy coding in all of SL IMHO.

I've personally written systems like this and there is NO reason a dead script (no pending message subscriptions) should use once cycle of CPU. Not even scripts with listens but with nothing in their qs should take any cpu. There is something shamefully broken there. A single week of work on it could probably get a 3-6 fold increase in script efficency sim wide if anyone would drop the never to be introduced mono and work a bit on the CURRENT product.

But yes 2000 scripts (they don;t even have to have a listen in them!) will send a completely empty class 4 sim into time dilation, Make as many large linked objects as possible. Heck even if you can link just 4 tiles togeather your down to only 500 scripts already using one listen and then llSetLinkPrimitiveParams for each link set.

If only a few of those 2000 prims need to be visible at one time, perhaps you can rez them on demand from a central object and have it listen to the central object for a die command (or die on a time-out)? If none are visible, you'll only have the central object script running.

Lyn