a wierd behavior...

I have a script that just stopped receiving listens. I setup the listen in onrez, and it was running fine for a couple of days. I don't do a llListenRemove and the owner didn't change etc. The script didn't crash as it still responds to touch events, it just stopped receiving Listen messages. Anyone ever see anything like this or have ideas on what it might be?

Why did you setup the listen in the on_rez() event? A listen event that's just setup and left to listen all the time should be setup in the state_entry(). If you reset your script at some point, the listen is removed, and when the script is reset, since it's not rezzing, the on_rez() is not executed, (but the state_entry() is). Try moving the initial listen setup from the on_rez() to the state_entry(). I can't think of any valid reason for a listen to be initialized in an on_rez() event.

weird scripting = weird behavior

if you cant see the source theres any possible filer to skip the listen effects.

Well, if you do it in on_rez, you get called when the object changes to a different owner and you get called if the object goes back into inventory and back out again. State_Entry is not called on a subsequent re-rez and as far as I know, wouldn't be called if you took an item that had state_entry called already and then gave it to someone else and they rezzed it. And, the script was not reset, as the data would be deleted and it was still there based on touch event processing. Just the listens went away.

One little thing I keep around is a little script that just listens to DEBUG_CHANNEL and IMs me what it hears. Sometimes that can clear up mysterious things like this that happen when I'm not around.

That's a good idea. Can you actually listen on the debug_channel? I didn't realize that. I will put one out and see if I can catch it next time it happens. Thanks!

It doesn't seem to work consistently but it's worked enough times to be useful.

I tested it a couple of months ago and the only thing to watch for is a weird, non standard listen distance of about 20 meters for debug messages.

If you're looking to give/sell it to someone else, the proper way to do it is like this...

integer handle;

default
{
    on_rez (integer foo)
    {
        llResetScript();
    }
    state_entry()
    {
        handle = llListen (0, "", llGetOwner(), "");        
    }
    
    listen (integer channel, string name, key id, string message)
    {
        // blah blah
    }
}

That way, when the script is rezzed, (or re-rezzed by a new owner), then the script will reset and re-read who the owner is, any subsequent references to the owner will be the one who rezzed it. This is standard practice for scripts that need to reference the object owner. With the script reset being called each time the object is rezzed, state_entry() is always called when the item is rezzed.

The only uses I've ever seen for on_rez() events are resetting a script, resetting another script, or passing a variable to a script. The way your written, if the script is reset, the listen is removed, and not set back up because on_rez() is FALSE. It could also be used to display information once on rez, but it's not typically scene, although I'm sure that's been done too.