Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Re: Disable scripts ... or not?

Zi Ree
Mrrrew!
Join date: 25 Feb 2006
Posts: 723
10-26-2006 07:32
Hi Andrew!

Thank you very much for your detailed explanation!I'll try and pass on a little more information I have on this subject.

From: Andrew Linden
Some scripted features such as animation override, particle systems, and llTaretOmega() for static content are state changes that are are set by the script and are then cached by other systems, so they don't necessarily require a running script engine to continue in their current state. However most of them do require a running script engine in order to change their state.

Yes, I'm aware of particles, target omega and floating text being prim attributes rather than script attributes :)

From: Andrew Linden
As to why a rezzer would function in a region while all other scripts in that same region are off... that would be a bug. Given our success at stopping world-wide expansion of a malicious rezzer I'm skeptical that the bug exists[...]

Yep, that's what we were seeing. Two other residents and myself have been watching this particular Beachball thing rezzing objects and offering us inventory, while the grid was put to "No Scripts". We even went as far as going inside the building. I used the "sit on a prim" trick, because the door was not opening right away, but one of the other residents finally managed to open it, even though the grid was "No Scripts". At the same time my Multitool, Earflick and Tail scripts were disabled, the AO still worked.

Location: Emmelia 239, 139

From: Andrew Linden
The command to disable scripts is communicated to the regions via a config file that is ultimately distributed via a tool called dsh which requires a list of hosts on which to operate (called a dsh group). If the list is not correct, missing an entry or two for example, then the missing hosts will not receive the message. An incorrect list is not too surprising because we have > 1000 machines some of which fall offline or come back on after repairs, so if the list were a few days old then it might not properly reflect the status of the grid .

This is an interesting piece of information that explains a couple other things I have seen in the past :)

From: Andrew Linden
So I speculate that perhaps you were seeing scripts operating in the neighboring region, which may have been one running on one of the machines missing from the dsh group.

We were inside the building, right next to the rezzer we were watching.

From: Andrew Linden
I should mention that we now have a script that will generate a fresh dsh group of simulator node machines, and that it is considered good practice to update the list before trying to send out commands to the live grid.

If there is one good thing about grid attacks or crashes then it's the improvements that come out of the resolution :)

From: Andrew Linden
It isn't clear to me how long you watched the rezzing scripts, how long the lockdown had been, or whether they were in the same region as yourself.

We have been hovering around the house and going inside for maybe one hour or more. I'm not quite sure myself anymore since it was so late for me, but I couldn't stop watching and experimenting. In the end, the rezzer just poofed while we were poking it, I guess that was the grid cleanup taking place. We then said good-bye to another and went offline.

So, I hope this information can clarify some open points and maybe even be useful for further investigation.

P.S.: I was just hovering over the spot mentioned here and it's No Script. However my Eartwitch and tail still worked after entering the parcel (flying at 110 m if that makes any difference).
_____________________
Zi!

(SuSE Linux 10.2, Kernel 2.6.13-15, AMD64 3200+, 2GB RAM, NVidia GeForce 7800GS 512MB (AGP), KDE 3.5.5, Second Life 1.13.1 (6) alpha soon beta thingie)

Blog: http://ziree.wordpress.com/ - QAvimator: http://qavimator.org

Second Life Linux Users Group IRC Channel: irc.freenode.org #secondlifelug
Andrew Linden
Linden staff
Join date: 18 Nov 2002
Posts: 692
10-26-2006 13:12
Zi, thanks for the info.

Based on your description about how the door took a long time to open I suspect that you were in a region that had been omitted from the dsh group, and that all scripts were working but that there were so many scripts in the script engine that many were getting descheduled and would appear to not work.

Whether a script will 'work' under heavy script load depends on what the objects are trying to do. For instance, the llListen() system can only process the listen events so fast, so if the chats are comming in faster than they can be processed then some chat events will be dropped as they are pushed off the 'old chat to be processed' buffer.

Touch events, used to open most doors, would eventually get processed, but might take a long time if the script engine is very loaded.