Method two will be added tomorrow.  Check Back!

Method I

The first method, and possibly the most simple, is followed by creating an off/on script and adding the script to the object inventory.  As always I begin by showing you the whole script.

string script2kill = "ScriptName";

default
{
	state_entry()
	{
		llOwnerSay("Off/On Script Initialized");
	}
	touch_start(integer total_number)
	{
		integer curState = llGetScriptState(script2kill);
		if(curState==TRUE){
			llSetScriptState(script2kill, FALSE);
		}else if(curState == FALSE){
			llSetScriptState(script2kill,TRUE);
		}
	}
}

Now as you know I like to use global variables, this allows me to change data without having to sort through the script in hopes of finding my variable.  While this isn’t such a bad thing in a small script such as this, it helps out an amazing amount later down the road.  Line 01 is the global variable script2kill, now you can change ScriptName to whatever you want, but it must be the name of the script you want to kill when you touch the object.

string script2kill = "ScriptName";

Being that we’re using llSetScriptState, the variable type of script2kill must be a string, and therefore must be encompassed in double quotes.  HOWEVER, and this is a big one, well not really, but anyhow, according to the LSL wiki, “While this function can be used to stop any script, it can only be used to start scripts which were stopped by an llSetScriptState function call.”  Therefore assuming you’re script has already been started, you can kill and restart it at any time.

The state_entry event isn’t anything special, by now you should know that state_entry is required, therefore I just used llOwnerSay to let you know that the script is actually ready.  You can simply remove line 09 altogether and leave it blank.  For me I like to know my scripts are ready.

The magic for this method really starts in the touch_start event.

	touch_start(integer total_number)
	{
		integer curState = llGetScriptState(script2kill);
		if(curState==TRUE){
			llSetScriptState(script2kill, FALSE);
		}else if(curState == FALSE){
			llSetScriptState(script2kill,TRUE);
		}
	}

Line 11 sets a local variable that I can refer too.  llGetScriptState() receives a string variable and returns an integer.  Therefore we can use the script2kill global we set for the functions string, and we can store the functions result as our own variable, for use in llSetScriptState().  Since curState is set every time you touch the object, this script checks your script2kill to see if its off, and if it is, then it does the exact opposite.    You have to use an if…else statement because if not, then you’ll keep turning off a script that’s already off.  If you’re confused let me clarify this a little for you.

Line 12 uses the logical binary operator to compare two values.  In more simplistic terms, it simply sees if one variable is the exact same as the other.  Therefore, since llGetScriptState returns an integer (TRUE or FALSE), we compare it to yet another integer.  If it is on, since a user has touched it then llSetScriptState will kill it.  If the curState is not true, if the logic says no, then we jump down to line 14 and completely skip turning off the script.

INFO: If you haven't figured it out yet, FALSE means off, and TRUE means on!

Line 14 checks if curState (assigned a value by line 11) is false.  If the logical binary operator says everything is okay then the script turns on the other script via llSetScriptState.

Additionally you can setup the on/off script to only respond to your touch or receive commands from an external script via llListen.  The possibilities are endless, yet its usage is somewhat limited also.  For instance, by turning off a script that has already used llSetText, you do not remove the text.  You would need to reset the text back to empty by passing an empty string variable to llSetText within your on/off script.

If you experience any issues with downloads please be patient and try again in a few hours.

On the end-user side of things, the box required the buyer to touch it, and being that there was large yellow letters telling them to do so, I didn’t think this would have been an issue. Obviously I didn’t consider the language barrier, nor the younger ages that apparently couldn’t read yet. This is fixed, and will only require the user to rez the box. As a safety measure, if the user was to rez the box and something glitched out, then the user can still touch it to contact the server.

The product script now contains a fool-proof self-contained algorithm… not that big of a deal though. I’ve just secluded the HTTP portion of the script to a central server object that I OWN. The product box only sends data, via llEmail to the server object, that I can translate or use how I see fit. In doing that, it will allow me to optimize the data insertion process on the actual HTTP server.

I may be optimizing my RL download system for end-users and sell it later on, but as for now, that’s a lot of work

View the tutorial here.