LSL Portal Wiki
Register
Advertisement

Syntax[]

llResetScript();

Causes a script to reset immediately to it's initial state and restarts it.

Returns void

This function doesn't return a result.

Example

Resets the script, when the object is rezzed.

default 
{
	on_rez(integer start_param)
	{
		llResetScript();
	}
}

Remarks

llResetScript() does the following operations in detail:

  • It stops immediately script execution.
  • It clears all pending events for this script. So keep in mind, that any events waiting in the queue are lost and are not raised after the script is restarted.
  • It resets all variables to their default values. Any stored data or modified values in the script are lost.
  • The script switches to the default state, but without raising any state-events like state_exit.
  • The script is restarted and the default state_entry is triggered, if it exists.

Notes

Red exclamation mark iconIf not coded properly, the use of llResetScript() can introduce bugs in the code.

Example: a bow is in the drawn state, but when the script is resetted, the variable containing it's state is set to sheathed. The bow will now behave different in that case, then what it's visible state suggests.

Statements following after llResetScript() will NOT be executed, even if they are within the same block. For further clarification, also if llResetScript() was called within a loop, it will not continue. Anything is aborted within the script as soon it hits llResetScript().

Lightbulb iconllResetScript() is often used in ways what programmers call "fast and dirty coding". Though sometimes, it is not more difficult to avoid it's usage and possible side effects.

Let's have a look at an example showing a very common case, where llResetScript() is used:

key gOwner;

default 
{
	state_entry()
	{
		gOwner = llGetOwnerKey();
	}

	touch_start(integer num_detected)
	{
		if (llDetectedKey(0) == gOwner)
		{
			// do something only, when owner touches me
		}
	}
	
	on_rez(integer start_param)
	{
		llResetScript();
	}
}

This script would contain at line 14 some code, that would be only executed, when the owner touches the object. To save resources and make a script faster, the owners key is stored in the variable gOwner, when the script starts (line 7), so llGetOwnerKey() doesn't need to be called every time. Now, if our script would not contain the lines 18-21, the object would cease working, when the object is given or sold to another person. So someone would think, resetting the script, the next time the object is rezzed is necessary.

In this case though, resetting the script is not really necessary, as a more efficient code could achieve the same:

on_rez(integer start_param)
	{
		gOwner = llGetOwnerKey();
	}

Avoiding llResetScript() has the benefit, that any variables in the script keep their values, as that is necessary in cases where usersettings should be retained. Also, in cases where scripts work with notecards, it helps avoiding to have to re-read them.

An expert would say no, resetting the script every time the object is rezzed is an unnecessary operation. Also the above solutions don't cover other cases, like when an object is sold in-world to another person as original, in which case the owner changes but nothing happens in the script, so the script ceases to work like expected.

A better solution would be, to recognize an owner change, so we replace those lines this time with the following lines:

changed(integer change)
	{
		if (change & CHANGED_OWNER)
		{
			gOwner = llGetOwnerKey();
		}
	}

Just for completeness, i should mention, that for the above simple script, another solution would have worked too. Here is the full script:

default 
{
	touch_start(integer num_detected)
	{
		if (llDetectedKey(0) == llGetOwnerKey())
		{
			// do something only, when owner touches me
		}
	}
}

We got rid of the gOwner variable and that made it possible to eliminate half of the scripts lines. We might call now every time that function, but the additional call is not noticeable and we use less memory.

"I" iconSo, one could ask, why should one not write immediately the last example? The answer is, because many scripters in SL don't have professional coding knowledge and just take scripts and modify them, in which case they might end with code like here shown.

Related Functions

Related Events

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

Platforms

SecondLife (agni), Secondlife (aditi), OpenSimulator

See also[]


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

Advertisement