SLUniverse Forums

Tess Whitcroft

Did LL make some change they did not warn us of? I have exactly the same attachments I had lasr week but now I (and lots of others) keep getting this...


[21:48] Tess Whitcroft: Script run-time error
[21:48] Tess Whitcroft: Too Many Listens


Anyone have any ideas?


Tess

Cubey Terra

That's not new. It sounds like a poorly-made script that starts a new listen without checking for and then removing the previous one. Find the person who made that attachment and smack them over the head a couple of times.

__________________
. . . . .
Cubey Terra
Terra Aeronautics @ Abbotts Aerodrome
www.cubeyterra.com

Tess Whitcroft

Problem is there are no new attachments...

O.o

Tess

Chalice Yao

He means that the attachment, on every attach, opens up a new listener without removing the old one. A script only can have 64 concurrent listeners at once..do this: rightclick -> edit the attachment, and in the menu bar on top select tools -> reset scripts in selection. See if that fixes it.

WarKirby Magojiro

Chalice's suggestion will throw up a neat little bandaid. Sadly, it will break every 64th time you put it on. I suggest contacting the creator and telling them (politely) that their coding sucks

__________________

WarKirby Magojiro

I find it best to do listeners in state_entry anyways. And I NEVER, EVER key them. Instead, I use this neat little snippet in my listen event.

listen(integer channel, string name, key id, string message)
{
if(id == llGetOwner() || llGetOwnerKey(id) == llGetOwner())
{
}
}

Eata

llGetOwnerKey(id) == llGetOwner() covers all the checks.

Also it's best to cast llGetOwner to a constant in state entry, saves script memory as well.

Tess Whitcroft

I was thinking that the fact that I had no "new" attachments would be key, but if it can stack up 64 listens before I get the warning then the attachment doesn't need to really be all "that" new. What is the easy way to find out which attachment is doing this? And thanks for the help...

Tess

Mecha Dinosaur

No :/

Do not want.

__________________

WarKirby Magojiro

I agree. How does making it a constant help anything? That means you'll need to reset the script completely on transfer.

Ryozu

That's how I've been doing it, and it works well for scripts that otherwise never get reset.

I treat a full script reset as "First time wearing product."

IE, same concept as the first time you run a newly installed program. Script starts out fresh, and you can do any new owner type things. Such as a read me first notecard.

Also, saving script memory or not, it's always faster to reference a variable than to call a function. Maybe not critically faster, but it just a little.


Also, for those not in the know, every time you LOG IN it counts as attaching your item. (IE fires the attach event in the script)

__________________

Joannah Cramer

There's event fired for change of ownership, so it's not big deal to re-do listen filter and/or update constant(s) when it happens. Much more environment friendly that the listen() which doesn't bother to filter the incoming messages and relies on the LSL runtime routine for that.

Eata

If you use it a lot why not? After all it's not like the compiler is going to do anything sensible with it. No doubt it actually pulls a pointless function call everytime.

Resetting scripts on new owner is good practise. I'm not even sure where you would not want that to happen.

Mecha Dinosaur

I seem to be having issues putting this to words. Resetting a script is fine if it does not have much going on in it. But having a script do expensive processes for a large number of variables that should need only be set once but instead need to be redone each time the entire script is reset requires the cutting off of pinky finger!

CLI/MONO will make this even worse, 64 kb memory means multiple scripts can now be compiled into one script, .

WarKirby Magojiro

good point also. I forgot that.