"Running" status of scripts

Not hunnert percent sure what's going on here...I was fooling with a script that would report certain things about rotation etc. It was a lot of spam when the thing got to the rotation I wanted, so when I would walk away from the script, I would clear "running", so the script was dead.

Next day, I logged in. The script was running. I was pretty sure that I had shut it down, but eh age so I shut it down again. Sure enough, next day, it was running and spamming away. So I tried it again, this time certain that I shut it off, but wanting to repeat it, and lo and behold it happened again, since I got a tell from a linden that they had to go and delete the object because of the log activity it was generating. I am SURE I shut it off.

If it had happened once (or rather, when it happened the first time) I assumed sim crash/prior state, whatever. But after repeating it I think that ain't right.

???

After closing hours, they do somthing, and all scripts inworld automatically turn back on (the running box is checked). I complained about this before with no replies. Or if there were any, they weren't from Lindens

Save the script with an error to avoid this.

Good hack Xavier...but I'm dubious as to it being a solution. Is this in fact the intended behavior, that any experimental script should be written in such a way to allow for possible involuntary activation...or you need to break it before you leave it?

If you absolutely need your script to spam stuff at you for debugging purposes or whatever, I have a suggestion that will save you (and more importantly the other people who share the world with you) alot of headache. Most importantly, you won't lose your object and script because people have been complaining about it to the Lindens.

The solution is to make yourself a snooper! (Or you can get one from me for a reasonable price ) This is just a small object with a simple script in it that monitors a selected channel and whispers what it finds to the main (0) channel. The script should be fairly simple, just make sure you have a way to change the channel without having to edit the script every time. Then all you need to do is make sure your debugging/spam messages don't use the main channel and you're set. You can even leave the debugging messages on all the time if you really need to. (This might cause lag though, so maybe not) When you want to hear debugging messages, just plop the snooper on the ground or attach it to your AV and it will start reporting what your script is saying in the private channel. When you leave, put it away and it won't bother anybody while you're gone.

(knowing that tcoz doesn't need the suggestion, but others might) you can also use llSetText to watch variables/debug.

I've noticed that with some objects, the script continues to run even after the Running checkbox is cleared, and even after the code has been commented out. A few weeks back I showed Nada an object with this behavior, and logged it as a bug. I've noticed it again recently; maybe I should log it as a bug again.

Good suggestion Alf, Nada. The issue though was that the object was spamming the logs, not that it was spamming folks (it was on the top floor of my tower, nobody even noticed). If it's on a diff channel, or pumping it out in settext, I think the issue would remain the same. Though from what I know of settext and llspeaks, this might be an effective way to deactivate the script via crashing.

Off = off please

Oh and one other thing; the Reset button. My understanding is this button is the equivalent of a forced save (it flushes and causes a default state entry). But very, very often, when I hit reset, I don't see my "Active" speak from the state_entry; the button appears to do nothing. If I space/backspace the script, and save, I get what I'm looking for. Maybe I just don't know what "reset" actually does.

Sometimes reset works, most of the time it doesn't. I have been having trouble isolating what scripts it works for which it doesn't, but it does seem to be script dependant like scripts with a certain event handler don't get reset properly or something.

Another way to keep broken scripts from running is to put everything in a running state and leave the default empty except for some owner interaction for it to enter the running state (such as a touch from the owner). After the script has been fully tested, you can either remove the default state (and rename running to default etc.) or simply put a state running; line in the state_entry of default.

I generally use this method because my default state usually only has setup stuff anyways and then jumps to a 'real' state once its setup and continues operation from there never going back to the default unless the script is reset.

Another great way would be to uncheck the running switch. Oh wait that doesn't work.

if you are wearing an attachement with a script in it, and you uncheck running box so that it is no longer running, it stops and all is well with LSL. if you detach it, and then re-attach it though, the script will be set to running again... I found this out by having two scripts attached to an object, and i kept having to turn the second one off, so i am not sure if it holds true to items with just single scripts on them, but i would guess it does.

Cory says this bug has been fixed in 0.8 which will be released soon.

I believe the fix affects both scripted objects that sit overnight and detached attachments.