llSetScriptState(string name, integer run);

Sets the running state of a script in the same prim, identified by the parameter name. The state is specified by the parameter run.


string name
any string value or string variable, that contains the name of the script to be modified
integer run
an integer variable or integer value, which is either TRUE (for running) or FALSE (for not running)

Returns void

This function doesn't return a result.


Sets the running state of all scripts in the same prim to not running, when the owner says "/99 standby".

		llListen(99, "", llGetOwner(), "");

	listen(integer channel, string name, key id, string message)
		if (llToLower(message) == "standby")
			integer i;
			string ScriptName;
			for ( i = 0; i < llGetInventoryNumber(INVENTORY_SCRIPT); i++ )
				ScriptName = llGetInventoryName(INVENTORY_SCRIPT, i);
				llSetScriptState(ScriptName, FALSE);


This function looks up, if the named script exists in the same prim. Is that the case, it sets its running state to running, when TRUE was given as 2nd parameter or to not running otherwise.

When a script has already the defined running state, nothing happens.


The function does not return any value, so it's not possible to check, if the operation was successful.

When the named script does not exist, the error message Could not find script is send to the DEBUG_CHANNEL.

The function will fail, when a script is not running, because it has crashed. It's not possible to set a script to running, that has crashed. There is currently no function to ask the state of a script, if it might have been crashed or that would reset a crashed script.

The function will fail, when a script has been send via llGiveInventory() to the prim. This is a good thing, as it limits possibilities of abuse and security issues. An exception to that are scripts that are explicitly send via the authorization mechanism of llSetRemoteScriptAccessPin() and llRemoteLoadScriptPin().

When set to not running, the named script might not be suspended immediately, but only on the next time slice it would get to run. This is typical for multi-threaded systems, where code is allowed to run in chunks for a limited time, before switching to the next thread. To avoid that any code after calling this function is run, add a llSleep() call after this function.

Related Functions

Related Events

  • state_entry - Is the first event raised, after a script reset


SecondLife (agni), Secondlife (aditi), OpenSimulator

See alsoEdit

  Icon-edit-22x22 Read comments or write a new one!    

Community content is available under CC-BY-SA unless otherwise noted.