llListen() O_O Does it ever stop?

ok im new to LSL, but hardly to programming... and my issue isnt with the function or behavior of the function... lemme try to explain

I made a dance floor... several tiles of it were scripted to take commands from a control module... i didnt know that llMessageLinked existed... so i used llListen() events...
now.. problem is i have a friend who owns an island... and when it was all said and done i rezzed the dance floor on her island to get her opinion and lo and behold... system lag on it was like 0.5 which is horrible for a little 10m2 object and even worse for something that's meant to be tiled 4+ times with like 10-50 avatars hopping around on it... so... i did some research... and found my new best friend: llMessageLinked... oh by the way i had this listen script running in EACH of like 60 tiles lol so i was pumping out the lag...

I rescripted the entire thing using llMessageLinked... and placed a single listen script in the parent prim to listen to the control module using llListen (the control module isnt part of the linked object for concept design reasons)... lemme explain how i fixed all 60 of those scripts because i think this is where the problem started...

i copied the script out of the inventory of one of the tiles... edited it to remove all the llListen functions and to receive link messages instead... i then proceeded to select each tile prim in edit mode, delete the script from it's inventory, and drop in a copy of the new script (which ran perfectly)
i then edited the parent prim and dropped the listen script into it's inventory which ran perfectly...

i tested the control module and sure enough... it was controlling the floor through the relay script in the parent prim... which basically said: incoming llListen message -> send llMessageLinked

nothing fancy, it literally just relay's commands

so i was happy... till i rezzed the floor on her island again... and found i was still at 0.45 on the load list...

here's my theory:

just like when you use llSetText to make the happy little float text we all love... i can delete the script that made it... but the text is still tied to the prim... i could swear this is the case with my script... even though i deleted the script that called the llListen event... the prim is still listening on that channel...

im 99% sure that's the case because deleting 60+ listen scripts should have made more of an impact than just 0.05

i can't imagine that a couple texture animations and set color commands are creating that much lag

so my real question is in 2 parts:
can anyone confirm what i said is true? are the prims still listening and thus creating a ton of lag?
and 2:
if so... *screams and pulls her hair out* how can i make them stop lol

thanks in advance guys ) and don't worry, im not one of those freeloader types who asks for help and doesnt turn around later to share her knowledge i'll take my place among those who call themselves programmers and help the young padua- uh im going into geek mode... gnight everyone

-Raeyan

When you deleted the scripts their llListen events should have been removed along with the script. Someone please correct me if i'm wrong, but llListens arn't a prim setting. They're strickly script related.

Seeing how setting position/rotation/scale in ~10 prims through 5 llSetPrimitiveParams() calls per prim per second can cause overall script time of ~1.0 ms ... i wouldn't be surprised if adjusting colour and texture in ~60 prims caused that sort of load, as long as it's done frequent enough and on server rather than client side.

The listen() filters are script-specific and die along with the scripts... plus if they're set to some rarely used channel (rather than vicinity chat) so they aren't triggered often, their impact isn't really very high... the actual load comes more from processing received listen() input than anything o.O;

I would suggest that you use a rainbow texture and use the texture scroll system.

I’ll dig out the code I made for some color changing lights.

The main thing to remember is that texture scrolling is client side so you need to send chat command every 10 seconds or so. The script then waits a specified time before turning off the scrolling, set it’s position to zero, and then turn it back on.

With this type of system each tile can flash in steps or gradually fade. You can also use different textures to control the pattern. You can also set the repeat to nearly zero so the entire tile is the same color.

Edit: Enable debug mode and turn on "Show updates"

Note also that the event link_message() makes the script an active script. It's less of a strain than listen() but it's still something the scheduler has to check on with each round.

Note also that any script at all, active or not, adds to script time (and thus lag).

Use llSetLinkColor() for color changes. No scripts in child prims nessesary for it.

HTH.

But for things that are constantly changing color you MUST use the texture scroller system or you will add 100's of updates per second.

I've seen what happens then as all the sim sends you is prim updates and you get stuck waiting it for the sim to send avitar updates.