Second Life Wiki - User contributions [en]

User talk:Terk Resident

2014-09-07T05:36:20Z

Terk Resident: /* LSL style guide */

== LSL style guide ==

We decide long ago we were not going to refight the wars our father's faught. Instead of brother against brother we have decided the wiki is big enough for all of us. You are more than welcome to preach the gospel on your own userpage. Seeing that you have an interest on formatting we can always use help in making sure LSL Portal contributions fit one of the accepted white spacing schemes. We appreciate all the work you put into improving the article, but you have changed the the flavor of the article. I will, if I have time tomorrow work on restoring the more neutral tone of the article while at the same time keeping as much of your sizable contribution intact. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:54, 6 September 2014 (PDT)

Not really looking to fight about anything here.
It's just that the point of the wiki is to help new users and aspiring scripters look for a reference point of information which accurately documents the language. It's not a place to discuss the personal preferences in scripting styles. I'm not some person out on a rampage demanding blood of all those who may format their scripts with an unconventional style, everyone has their own personal preferences. The wiki however is not the place to express those, or at the very least not on an LSL reference page. LSL is a derivative of C, and C based languages interpret code in what is represented with the Allman's style of formatting. That's just how C is. Heck, although K&R has it's roots in the old C manual itself, it even refers to that as being both overly complex for new programmers and a fertile breeding ground for code bugs. Surely you can understand that a documentation wiki tasked with introducing and teaching new users would not do well to be pushing a format that is strongly discouraged by the source documentation of the language LSL is based off?
Does that mean that anything other than that is less viable? Of course not. There are plenty of times where Obsfucated C can have it's purposes, but surely we can agree that place is not on an article helping new users approach their first steps into LSL and instead that's for discussion in personal groups or userpages.
K&R belongs on a wiki or documentation for JS based languages or in your personal scripting projects that aren't posted onto what is supposed to be a documentation for the language. [[User:Terk Resident|Terk Resident]] 20:30, 6 September 2014 (PDT)

If we are going to select any one single style, we would give preference to LL's preferred coding style, after all LL regularly hires from the community. SL is written in C++ and [[Coding_standard#Braces|LL uses a K&R derivative]]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:05, 6 September 2014 (PDT)

But what you just linked me specifically says right there NOT to use the "more compact K&R standard"?
Am I misunderstanding you here? Because what you just linked is saying the same thing I was?
[http://i.gyazo.com/adbb7a07442a89a115ef3ea160696cde_1.png The exact section you linked me to]
But anyway, that's besides the point. Viewer Code != LSL Code. We're talking about LSL here, not what the viewer is programmed in. [[User:Terk Resident|Terk Resident]] 22:36, 6 September 2014 (PDT)

User talk:Terk Resident

2014-09-07T05:34:11Z

Terk Resident: /* LSL style guide */

== LSL style guide ==

We decide long ago we were not going to refight the wars our father's faught. Instead of brother against brother we have decided the wiki is big enough for all of us. You are more than welcome to preach the gospel on your own userpage. Seeing that you have an interest on formatting we can always use help in making sure LSL Portal contributions fit one of the accepted white spacing schemes. We appreciate all the work you put into improving the article, but you have changed the the flavor of the article. I will, if I have time tomorrow work on restoring the more neutral tone of the article while at the same time keeping as much of your sizable contribution intact. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:54, 6 September 2014 (PDT)

Not really looking to fight about anything here.
It's just that the point of the wiki is to help new users and aspiring scripters look for a reference point of information which accurately documents the language. It's not a place to discuss the personal preferences in scripting styles. I'm not some person out on a rampage demanding blood of all those who may format their scripts with an unconventional style, everyone has their own personal preferences. The wiki however is not the place to express those, or at the very least not on an LSL reference page. LSL is a derivative of C, and C based languages interpret code in what is represented with the Allman's style of formatting. That's just how C is. Heck, although K&R has it's roots in the old C manual itself, it even refers to that as being both overly complex for new programmers and a fertile breeding ground for code bugs. Surely you can understand that a documentation wiki tasked with introducing and teaching new users would not do well to be pushing a format that is strongly discouraged by the source documentation of the language LSL is based off?
Does that mean that anything other than that is less viable? Of course not. There are plenty of times where Obsfucated C can have it's purposes, but surely we can agree that place is not on an article helping new users approach their first steps into LSL and instead that's for discussion in personal groups or userpages.
K&R belongs on a wiki or documentation for JS based languages or in your personal scripting projects that aren't posted onto what is supposed to be a documentation for the language. [[User:Terk Resident|Terk Resident]] 20:30, 6 September 2014 (PDT)

If we are going to select any one single style, we would give preference to LL's preferred coding style, after all LL regularly hires from the community. SL is written in C++ and [[Coding_standard#Braces|LL uses a K&R derivative]]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:05, 6 September 2014 (PDT)

But what you just linked me specifically says right there NOT to use the "more compact K&R standard"?
Am I misunderstanding you here? Because what you just linked is saying the same thing I was?
[http://i.gyazo.com/adbb7a07442a89a115ef3ea160696cde_1.png The exact section you linked me to] [[User:Terk Resident|Terk Resident]] 22:34, 6 September 2014 (PDT)

User talk:Terk Resident

2014-09-07T05:33:50Z

Terk Resident: /* LSL style guide */

== LSL style guide ==

We decide long ago we were not going to refight the wars our father's faught. Instead of brother against brother we have decided the wiki is big enough for all of us. You are more than welcome to preach the gospel on your own userpage. Seeing that you have an interest on formatting we can always use help in making sure LSL Portal contributions fit one of the accepted white spacing schemes. We appreciate all the work you put into improving the article, but you have changed the the flavor of the article. I will, if I have time tomorrow work on restoring the more neutral tone of the article while at the same time keeping as much of your sizable contribution intact. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:54, 6 September 2014 (PDT)

Not really looking to fight about anything here.
It's just that the point of the wiki is to help new users and aspiring scripters look for a reference point of information which accurately documents the language. It's not a place to discuss the personal preferences in scripting styles. I'm not some person out on a rampage demanding blood of all those who may format their scripts with an unconventional style, everyone has their own personal preferences. The wiki however is not the place to express those, or at the very least not on an LSL reference page. LSL is a derivative of C, and C based languages interpret code in what is represented with the Allman's style of formatting. That's just how C is. Heck, although K&R has it's roots in the old C manual itself, it even refers to that as being both overly complex for new programmers and a fertile breeding ground for code bugs. Surely you can understand that a documentation wiki tasked with introducing and teaching new users would not do well to be pushing a format that is strongly discouraged by the source documentation of the language LSL is based off?
Does that mean that anything other than that is less viable? Of course not. There are plenty of times where Obsfucated C can have it's purposes, but surely we can agree that place is not on an article helping new users approach their first steps into LSL and instead that's for discussion in personal groups or userpages.
K&R belongs on a wiki or documentation for JS based languages or in your personal scripting projects that aren't posted onto what is supposed to be a documentation for the language. [[User:Terk Resident|Terk Resident]] 20:30, 6 September 2014 (PDT)

If we are going to select any one single style, we would give preference to LL's preferred coding style, after all LL regularly hires from the community. SL is written in C++ and [[Coding_standard#Braces|LL uses a K&R derivative]]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:05, 6 September 2014 (PDT)

But what you just linked me specifically says right there NOT to use the "more compact K&R standard"?
Am I misunderstanding you here? Because what you just linked is saying the same thing I was?
[http://i.gyazo.com/adbb7a07442a89a115ef3ea160696cde_1.png The exact section you linked me to]
[[User:Terk Resident|Terk Resident]] 22:30, 6 September 2014 (PDT)

User talk:Terk Resident

2014-09-07T05:32:52Z

Terk Resident: /* LSL style guide */

== LSL style guide ==

We decide long ago we were not going to refight the wars our father's faught. Instead of brother against brother we have decided the wiki is big enough for all of us. You are more than welcome to preach the gospel on your own userpage. Seeing that you have an interest on formatting we can always use help in making sure LSL Portal contributions fit one of the accepted white spacing schemes. We appreciate all the work you put into improving the article, but you have changed the the flavor of the article. I will, if I have time tomorrow work on restoring the more neutral tone of the article while at the same time keeping as much of your sizable contribution intact. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:54, 6 September 2014 (PDT)

Not really looking to fight about anything here.
It's just that the point of the wiki is to help new users and aspiring scripters look for a reference point of information which accurately documents the language. It's not a place to discuss the personal preferences in scripting styles. I'm not some person out on a rampage demanding blood of all those who may format their scripts with an unconventional style, everyone has their own personal preferences. The wiki however is not the place to express those, or at the very least not on an LSL reference page. LSL is a derivative of C, and C based languages interpret code in what is represented with the Allman's style of formatting. That's just how C is. Heck, although K&R has it's roots in the old C manual itself, it even refers to that as being both overly complex for new programmers and a fertile breeding ground for code bugs. Surely you can understand that a documentation wiki tasked with introducing and teaching new users would not do well to be pushing a format that is strongly discouraged by the source documentation of the language LSL is based off?
Does that mean that anything other than that is less viable? Of course not. There are plenty of times where Obsfucated C can have it's purposes, but surely we can agree that place is not on an article helping new users approach their first steps into LSL and instead that's for discussion in personal groups or userpages.
K&R belongs on a wiki or documentation for JS based languages or in your personal scripting projects that aren't posted onto what is supposed to be a documentation for the language. [[User:Terk Resident|Terk Resident]] 20:30, 6 September 2014 (PDT)

If we are going to select any one single style, we would give preference to LL's preferred coding style, after all LL regularly hires from the community. SL is written in C++ and [[Coding_standard#Braces|LL uses a K&R derivative]]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:05, 6 September 2014 (PDT)

But what you just linked me specifically says right there NOT to use the "more compact K&R standard"?
Am I misunderstanding you here? Because what you just linked is saying the same thing I was?
[[File:http://i.gyazo.com/adbb7a07442a89a115ef3ea160696cde_1.png]] [[User:Terk Resident|Terk Resident]] 22:30, 6 September 2014 (PDT)

User talk:Terk Resident

2014-09-07T05:30:12Z

Terk Resident: /* LSL style guide */

== LSL style guide ==

We decide long ago we were not going to refight the wars our father's faught. Instead of brother against brother we have decided the wiki is big enough for all of us. You are more than welcome to preach the gospel on your own userpage. Seeing that you have an interest on formatting we can always use help in making sure LSL Portal contributions fit one of the accepted white spacing schemes. We appreciate all the work you put into improving the article, but you have changed the the flavor of the article. I will, if I have time tomorrow work on restoring the more neutral tone of the article while at the same time keeping as much of your sizable contribution intact. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:54, 6 September 2014 (PDT)

Not really looking to fight about anything here.
It's just that the point of the wiki is to help new users and aspiring scripters look for a reference point of information which accurately documents the language. It's not a place to discuss the personal preferences in scripting styles. I'm not some person out on a rampage demanding blood of all those who may format their scripts with an unconventional style, everyone has their own personal preferences. The wiki however is not the place to express those, or at the very least not on an LSL reference page. LSL is a derivative of C, and C based languages interpret code in what is represented with the Allman's style of formatting. That's just how C is. Heck, although K&R has it's roots in the old C manual itself, it even refers to that as being both overly complex for new programmers and a fertile breeding ground for code bugs. Surely you can understand that a documentation wiki tasked with introducing and teaching new users would not do well to be pushing a format that is strongly discouraged by the source documentation of the language LSL is based off?
Does that mean that anything other than that is less viable? Of course not. There are plenty of times where Obsfucated C can have it's purposes, but surely we can agree that place is not on an article helping new users approach their first steps into LSL and instead that's for discussion in personal groups or userpages.
K&R belongs on a wiki or documentation for JS based languages or in your personal scripting projects that aren't posted onto what is supposed to be a documentation for the language. [[User:Terk Resident|Terk Resident]] 20:30, 6 September 2014 (PDT)

If we are going to select any one single style, we would give preference to LL's preferred coding style, after all LL regularly hires from the community. SL is written in C++ and [[Coding_standard#Braces|LL uses a K&R derivative]]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:05, 6 September 2014 (PDT)

But what you just linked me specifically says right there NOT to use the "more compact K&R standard"? [[User:Terk Resident|Terk Resident]] 22:30, 6 September 2014 (PDT)

User talk:Terk Resident

2014-09-07T04:05:25Z

Terk Resident: /* LSL style guide */

User talk:Terk Resident

2014-09-07T03:30:23Z

Terk Resident: /* LSL style guide */ - Response to Strife

LSL Style Guide

2014-09-07T00:23:57Z

Terk Resident: Fixing category internal links which didn't appear as expected. Replaced with plaintext.

{{LSL Header|ml=*}}{{RightToc}}

Every major open-source project has its own style guide: a '''set of conventions''' (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a '''consistent style'''. These guidelines, referred to collectively as a Style Guide, are not as rigid as the rules required by the language compiler but nonetheless are critical to creating maintainable code. The most critical aspect of a style is that you apply it consistently to the code you write.

Effective programming in [[LSL Portal|LSL]] requires that developers use a disciplined approach towards formatting and other conventions in their scripts.

{{LSL Tip| Applying a style guide to your code does not only help others read your code. '''It helps you as well''', because in future when you return to the code you wrote before, you'll appreciate reading formatted and annotated code.}}

== Use third party editors: ==

There are many [[LSL Alternate Editors|third party editors]] with [[LSL Portal|LSL]] syntax files available. See an example below of what your workflow would look like using an editor that has syntax highlighting and autocomplete and also applies an indent style to your code.

[[File:Pareto_principle_scripting.gif|thumb|700px|center|Writing and fixing scripts takes time and effort. '''Readability is key to being more productive!''' [[LSL_Alternate_Editors|Alternate Editors do help, too.]] ]]

You can see now, that using [[LSL Alternate Editors|third party editors]] has a few advantages over using the editor in the viewers:
* Autocompletion helps you avoid typos.
* Autocompletion sometimes not only does a linear autocompletion as in autocompleting <code>llS</code> to <code>llSay</code> but sometimes works even with fuzzy search by autocompleting <code>llslppf</code> to <code>llSetLinkPrimitiveParamsFast</code>.
* The syntax highlighting file colors the code exactly like the code you see in the official Linden Lab viewer making you not having to learn or adapt to a different coloring scheme.
* Autocompletion might also preformat code with indent styles when autocompleting states, events, conditional clauses etc.

== [http://en.wikipedia.org/wiki/Indent_style Indent styles]: ==

Most people, when they start programming on their own, will have programs that are UGLY to look at - to put it nicely, sometimes mistakenly thinking that such scripts occupy less space when compiled. Such scripts typically look like the following:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''unstyled source code'''
|-
||
<lsl>default {state_entry(){llSay(0,"Hello World.");}}</lsl>
|}

However, that code is difficult to read (or at least to '''follow''') - even more so when one is writing a couple hundred lines program. There are several [http://en.wikipedia.org/wiki/Indent_style indent styles] which are seen throughout various programming languages which are used to make code more readable and easier to work with. LSL is a C based language and as such proper formatting makes use of the Allman style of code as seen below:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''[http://en.wikipedia.org/wiki/Indent_style#Allman_style Allman style] (used in C based languages)'''
|-
||
<lsl>
default
{
state_entry()
{
llSay(0, "Hello World.");
}
}
</lsl>
|}

It should be noted that LSL is resilient and as such will compile even if an incorrect formatting style for the language is used so long as the syntax is correct. This can be useful if you are coming from another language such as JavaScript which makes use of K&R style formatting and can allow for an easier transition to coding in LSL. It is however, good practice to avoid using any other formatting styles other than Allman as doing so will result in code which is obsfucated and harder to read in terms of how LSL is interpreted with parenthesis' and some operators. If good coding habits are important to you or if LSL is your first step into programming, it is strongly suggested you use Allman for your formatting style.

== Naming conventions: ==

There are many naming conventions in Second Life. Only the most used ones will be listed below.

Global Variables (variables used through out the entire program) should be lowercase. For example:

<lsl>
integer index = 0;
string name = "Please set one";
</lsl>

Others prefer to distinguish between global and local variables by prefixing variable names with a character, defining globals in the following manner:

<lsl>
integer gIndex;
string gName = "Please set one";
</lsl>

Constant variables should be in ALL CAPS following the style guide used by Linden Labs. For example:

<lsl>
integer DIALOG_CHANNEL = -517265;
vector RED = <1.0, 0.0, 0.0>;
</lsl>

Arguments used within a [[Category:LSL User-Defined Functions|user defined function]] or one of the standard [[Event|events]] should be named with '''easily readable and meaningful''' names. When using [[Event|events]], please use the standard names as listed here on the official wiki. An [[Event|overview of all events can be found here]]. Below is an example as can be found for the [[Listen|listen event]]:

<lsl>
// ...

listen(integer channel, string name, key id, string message)
{
key OwnerKey = llGetOwner();

if (channel == 1 && id == OwnerKey)
llOwnerSay("Hello Avatar");
}

// ...
</lsl>

== Separating code: ==
Some people put too many function calls on one line. As shown in this example, too many function calls on a single line makes the code hard to read and almost impossible to debug.

<lsl>
list lst;
integer numDigits = 10;

default {
touch_start(integer n) {
integer i;
integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]);
if (!~llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]))
lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1));
llOwnerSay(llList2CSV(lst));
}
}
</lsl>

Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can figure out what the below code does.

<lsl>
list listOfStrings;
integer numDigits = 10;

default
{
touch_start(integer n)
{
key owner = llGetOwner();
key id = llDetectedKey(0);
string name = llDetectedName(0);// or llKey2Name(id)

list nameAsList = llParseString2List(name, [" "], []);
string firstName = llList2String(nameAsList, 0);
string startPart = llToLower(llGetSubString(firstName, 0, numDigits - 1));
integer index = llListFindList(listOfStrings, [startPart]);

// if index is equal to -1
if (index == ERR_GENERIC)
listOfStrings += startPart;

// send a message to the owner, only reaches owner if online and within the same sim
llRegionSayTo(owner, PUBLIC_CHANNEL, llList2CSV(listOfStrings));
}
}
</lsl>

LSL lacks an optimizing compiler. For this reason it may be necessary to balance the two style to get faster, more compact executable code. Line combination optimization should only be done after the code is working & bug free. Improper optimization can lead to wrong results. Always test optimized code thoroughly.

==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

==== [[LSL_Variables|Global Variables]] ====

Global variables define and can contain data which can be written to or read from in multiple events and states within a script.
Here's an example of a simple script which uses global variables to store information in a state_entry event and allow it to be used in a second touch event.
<lsl>
key ownerkey; //Here we start by defining a global variable by the name of "ownerkey" and specify that it stores a key (UUID)

string ownername; //Next we define another global variable which stores the username of the owner of the prim containing this script and specify it is storing a string

integer reportonchannel = 0; //In this case we are defining a global variable which stores the numerical channel we will be using later, but in this case we give it a value at the start.
//As with the last 2, this can be written to but will revert to the specified value when the script is reset.

default
{
state_entry() //This event is triggered when entering the default state (When the script first runs or if moving to the default state from a user state)
{
ownerkey = llGetOwner(); //Stores the key of the owner of the prim containing this script to the "key ownerkey" global variable

ownername = llGetUsername(ownerkey); //Here we use that newly stored key to find the username of the account associated with the key in "key ownerkey"
//Note that since we have already defined ownerkey and ownername as a key and string respectively, we do not need to specify what type of data they store, unlike local variables
}

touch_start(integer num_detected) //This event is triggered when someone click the prim this script contains (If it's on click action is set to touch in the build floater)
{
string ownerkeyasastring = (string)ownerkey; //Let's prepare the key for use in a chat message. llSay requires strings but ownerkey is currently a string.
//Note that this is an inefficent method of preparing data stored in a variable to another type of data.
//Typically this would be done with typecasting in the intended function it is to be used in, but for the purpose of keeping this example easy to follow, I'll use this method.

llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
//When clicked, the prim will speak on the channel specified in "integer reportonchannel" and say the information we found in the previous event.
}
}
</lsl>

==== [[User-defined_functions|User Defined Functions]] ====

[[User-defined_functions|User defined functions]] follow imediatly after global variables in a script and before the default state. [[User-defined_functions|User Defined Functions]] allow for chunks of code that are repeated often throughout a script to be replaced with a one line function that acts in the same way as standard functions (Linden Library Functions).
These are useful when you want to keep your script bloat to a minimum by only having to write that chunk a single time and substitute other instances of it with a single easy line throughout the script.
Here's an example of our earlier script, this time making use of a custom function to replace the functions seen in our state_entry event.
<lsl>
key ownerkey;
string ownername;
integer reportonchannel = 0;

RetrieveOwnerData() //Here we create the user-defined function with the name "RetrieveOwnerData".
{
ownerkey = llGetOwner();
ownername = llGetUsername(ownerkey);
//Notice how we took the contents of our earlier state_entry() and placed it in a function.
//When the new function is called, this code will be ran.
}

default
{
state_entry()
{
RetrieveOwnerData(); //Here we call the function just like we would a normal LL function.
//Using a user-defined variable only once in a script is inefficient and shouldn't be used in place of just putting the code in normally if not being used multiple times.
//As for the point at which you deem it necessary? That's personal preference, but personally I go with if I am repeating code 3 or more times in a script.
}

touch_start(integer num_detected)
{
string ownerkeyasastring = (string)ownerkey;
llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
}
}
</lsl>

==== [[default|Default State]] ====
Next up we create our first [[state]]. This comes after user-defined functions and global variables.
In LSL, a state refers to a the container of events that trigger functions in the script. A script when it first starts will always exist in the initial [[default]] state which is a prerequisite for any LSL script. Scripts can contain multiple states, but only one can be active at any one time and only events that are handled in the active state will trigger functions in the script. A state can only contain one of each event handler (such as [[touch_start|Touch_start]] or [[state_entry|State_entry]]).
See below for an example of a simple script which says hello when clicked for an example of the default state:
<lsl>
default //All LSL scripts must contain a state named "default" and this must be the first state defined in your script.
{
touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the default state!");
}
}
</lsl>

==== [[state|User-Defined States]] ====
Lastly, we include any additional states we want in a script. User-Defined states allow for multiple instances of an event handler while effectively turning off other undesired events.
It should be noted that in most cases, you would want to use [http://lslwiki.net/lslwiki/wakka.php?wakka=condition conditionals] or [[Timer|timers]] in place of a state but the occasional use still does show up time to time.
Below is our previous script used in the default state example with a user-defined state added.
<lsl>
default
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered the default state!");
}
touch_start(integer num_detected)
{
llSay(0,"I was clicked!");
state two; // This instructs the script to switch to "state two" and stop processing events in the default state.
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving the default state!");
}
}

state two
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered state two!");
}

touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the second state!");
state default; // This instructs the script to switch back to the default state and stop processing events in "state two".
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving state two!");
}
}
</lsl>

Take great care when changing states in a script! Changing a state during an if or some loops can have adverse effects! Make sure to read up on [[state|states]] for more information.

LSL Style Guide

2014-09-07T00:13:05Z

Terk Resident: Accidentally wiped the page with last edit. Fixed it and included the intended edit. Sorry!

{{LSL Header|ml=*}}{{RightToc}}

Every major open-source project has its own style guide: a '''set of conventions''' (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a '''consistent style'''. These guidelines, referred to collectively as a Style Guide, are not as rigid as the rules required by the language compiler but nonetheless are critical to creating maintainable code. The most critical aspect of a style is that you apply it consistently to the code you write.

Effective programming in [[LSL Portal|LSL]] requires that developers use a disciplined approach towards formatting and other conventions in their scripts.

{{LSL Tip| Applying a style guide to your code does not only help others read your code. '''It helps you as well''', because in future when you return to the code you wrote before, you'll appreciate reading formatted and annotated code.}}

== Use third party editors: ==

There are many [[LSL Alternate Editors|third party editors]] with [[LSL Portal|LSL]] syntax files available. See an example below of what your workflow would look like using an editor that has syntax highlighting and autocomplete and also applies an indent style to your code.

[[File:Pareto_principle_scripting.gif|thumb|700px|center|Writing and fixing scripts takes time and effort. '''Readability is key to being more productive!''' [[LSL_Alternate_Editors|Alternate Editors do help, too.]] ]]

You can see now, that using [[LSL Alternate Editors|third party editors]] has a few advantages over using the editor in the viewers:
* Autocompletion helps you avoid typos.
* Autocompletion sometimes not only does a linear autocompletion as in autocompleting <code>llS</code> to <code>llSay</code> but sometimes works even with fuzzy search by autocompleting <code>llslppf</code> to <code>llSetLinkPrimitiveParamsFast</code>.
* The syntax highlighting file colors the code exactly like the code you see in the official Linden Lab viewer making you not having to learn or adapt to a different coloring scheme.
* Autocompletion might also preformat code with indent styles when autocompleting states, events, conditional clauses etc.

== [http://en.wikipedia.org/wiki/Indent_style Indent styles]: ==

Most people, when they start programming on their own, will have programs that are UGLY to look at - to put it nicely, sometimes mistakenly thinking that such scripts occupy less space when compiled. Such scripts typically look like the following:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''unstyled source code'''
|-
||
<lsl>default {state_entry(){llSay(0,"Hello World.");}}</lsl>
|}

However, that code is difficult to read (or at least to '''follow''') - even more so when one is writing a couple hundred lines program. There are several [http://en.wikipedia.org/wiki/Indent_style indent styles] which are seen throughout various programming languages which are used to make code more readable and easier to work with. LSL is a C based language and as such proper formatting makes use of the Allman style of code as seen below:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''[http://en.wikipedia.org/wiki/Indent_style#Allman_style Allman style] (used in C based languages)'''
|-
||
<lsl>
default
{
state_entry()
{
llSay(0, "Hello World.");
}
}
</lsl>
|}

It should be noted that LSL is resilient and as such will compile even if an incorrect formatting style for the language is used so long as the syntax is correct. This can be useful if you are coming from another language such as JavaScript which makes use of K&R style formatting and can allow for an easier transition to coding in LSL. It is however, good practice to avoid using any other formatting styles other than Allman as doing so will result in code which is obsfucated and harder to read in terms of how LSL is interpreted with parenthesis' and some operators. If good coding habits are important to you or if LSL is your first step into programming, it is strongly suggested you use Allman for your formatting style.

== Naming conventions: ==

There are many naming conventions in Second Life. Only the most used ones will be listed below.

Global Variables (variables used through out the entire program) should be lowercase. For example:

<lsl>
integer index = 0;
string name = "Please set one";
</lsl>

Others prefer to distinguish between global and local variables by prefixing variable names with a character, defining globals in the following manner:

<lsl>
integer gIndex;
string gName = "Please set one";
</lsl>

Constant variables should be in ALL CAPS following the style guide used by Linden Labs. For example:

<lsl>
integer DIALOG_CHANNEL = -517265;
vector RED = <1.0, 0.0, 0.0>;
</lsl>

Arguments used within a [[Category:LSL User-Defined Functions|user defined function]] or one of the standard [[Event|events]] should be named with '''easily readable and meaningful''' names. When using [[Event|events]], please use the standard names as listed here on the official wiki. An [[Event|overview of all events can be found here]]. Below is an example as can be found for the [[Listen|listen event]]:

<lsl>
// ...

listen(integer channel, string name, key id, string message)
{
key OwnerKey = llGetOwner();

if (channel == 1 && id == OwnerKey)
llOwnerSay("Hello Avatar");
}

// ...
</lsl>

== Separating code: ==
Some people put too many function calls on one line. As shown in this example, too many function calls on a single line makes the code hard to read and almost impossible to debug.

<lsl>
list lst;
integer numDigits = 10;

default {
touch_start(integer n) {
integer i;
integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]);
if (!~llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]))
lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1));
llOwnerSay(llList2CSV(lst));
}
}
</lsl>

Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can figure out what the below code does.

<lsl>
list listOfStrings;
integer numDigits = 10;

default
{
touch_start(integer n)
{
key owner = llGetOwner();
key id = llDetectedKey(0);
string name = llDetectedName(0);// or llKey2Name(id)

list nameAsList = llParseString2List(name, [" "], []);
string firstName = llList2String(nameAsList, 0);
string startPart = llToLower(llGetSubString(firstName, 0, numDigits - 1));
integer index = llListFindList(listOfStrings, [startPart]);

// if index is equal to -1
if (index == ERR_GENERIC)
listOfStrings += startPart;

// send a message to the owner, only reaches owner if online and within the same sim
llRegionSayTo(owner, PUBLIC_CHANNEL, llList2CSV(listOfStrings));
}
}
</lsl>

LSL lacks an optimizing compiler. For this reason it may be necessary to balance the two style to get faster, more compact executable code. Line combination optimization should only be done after the code is working & bug free. Improper optimization can lead to wrong results. Always test optimized code thoroughly.

==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

==== [[LSL_Variables|Global Variables]] ====

Global variables define and can contain data which can be written to or read from in multiple events and states within a script.
Here's an example of a simple script which uses global variables to store information in a state_entry event and allow it to be used in a second touch event.
<lsl>
key ownerkey; //Here we start by defining a global variable by the name of "ownerkey" and specify that it stores a key (UUID)

string ownername; //Next we define another global variable which stores the username of the owner of the prim containing this script and specify it is storing a string

integer reportonchannel = 0; //In this case we are defining a global variable which stores the numerical channel we will be using later, but in this case we give it a value at the start.
//As with the last 2, this can be written to but will revert to the specified value when the script is reset.

default
{
state_entry() //This event is triggered when entering the default state (When the script first runs or if moving to the default state from a user state)
{
ownerkey = llGetOwner(); //Stores the key of the owner of the prim containing this script to the "key ownerkey" global variable

ownername = llGetUsername(ownerkey); //Here we use that newly stored key to find the username of the account associated with the key in "key ownerkey"
//Note that since we have already defined ownerkey and ownername as a key and string respectively, we do not need to specify what type of data they store, unlike local variables
}

touch_start(integer num_detected) //This event is triggered when someone click the prim this script contains (If it's on click action is set to touch in the build floater)
{
string ownerkeyasastring = (string)ownerkey; //Let's prepare the key for use in a chat message. llSay requires strings but ownerkey is currently a string.
//Note that this is an inefficent method of preparing data stored in a variable to another type of data.
//Typically this would be done with typecasting in the intended function it is to be used in, but for the purpose of keeping this example easy to follow, I'll use this method.

llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
//When clicked, the prim will speak on the channel specified in "integer reportonchannel" and say the information we found in the previous event.
}
}
</lsl>

==== [[User-defined_functions|User Defined Functions]] ====

[[User-defined_functions|User defined functions]] follow imediatly after global variables in a script and before the default state. [[User-defined_functions|User Defined Functions]] allow for chunks of code that are repeated often throughout a script to be replaced with a one line function that acts in the same way as standard functions (Linden Library Functions).
These are useful when you want to keep your script bloat to a minimum by only having to write that chunk a single time and substitute other instances of it with a single easy line throughout the script.
Here's an example of our earlier script, this time making use of a custom function to replace the functions seen in our state_entry event.
<lsl>
key ownerkey;
string ownername;
integer reportonchannel = 0;

RetrieveOwnerData() //Here we create the user-defined function with the name "RetrieveOwnerData".
{
ownerkey = llGetOwner();
ownername = llGetUsername(ownerkey);
//Notice how we took the contents of our earlier state_entry() and placed it in a function.
//When the new function is called, this code will be ran.
}

default
{
state_entry()
{
RetrieveOwnerData(); //Here we call the function just like we would a normal LL function.
//Using a user-defined variable only once in a script is inefficient and shouldn't be used in place of just putting the code in normally if not being used multiple times.
//As for the point at which you deem it necessary? That's personal preference, but personally I go with if I am repeating code 3 or more times in a script.
}

touch_start(integer num_detected)
{
string ownerkeyasastring = (string)ownerkey;
llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
}
}
</lsl>

==== [[default|Default State]] ====
Next up we create our first [[state]]. This comes after user-defined functions and global variables.
In LSL, a state refers to a the container of events that trigger functions in the script. A script when it first starts will always exist in the initial [[default]] state which is a prerequisite for any LSL script. Scripts can contain multiple states, but only one can be active at any one time and only events that are handled in the active state will trigger functions in the script. A state can only contain one of each [[Category:LSL_Events|event handler]] (such as [[touch_start|Touch_start]] or [[state_entry|State_entry]]).
See below for an example of a simple script which says hello when clicked for an example of the default state:
<lsl>
default //All LSL scripts must contain a state named "default" and this must be the first state defined in your script.
{
touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the default state!");
}
}
</lsl>

==== [[state|User-Defined States]] ====
Lastly, we include any additional states we want in a script. User-Defined states allow for multiple instances of an [[Category:LSL_Events|event handler]] while effectively turning off other undesired events.
It should be noted that in most cases, you would want to use [http://lslwiki.net/lslwiki/wakka.php?wakka=condition conditionals] or [[Timer|timers]] in place of a state but the occasional use still does show up time to time.
Below is our previous script used in the default state example with a user-defined state added.
<lsl>
default
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered the default state!");
}
touch_start(integer num_detected)
{
llSay(0,"I was clicked!");
state two; // This instructs the script to switch to "state two" and stop processing events in the default state.
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving the default state!");
}
}

state two
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered state two!");
}

touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the second state!");
state default; // This instructs the script to switch back to the default state and stop processing events in "state two".
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving state two!");
}
}
</lsl>

Take great care when changing states in a script! Changing a state during an if or some loops can have adverse effects! Make sure to read up on [[state|states]] for more information.

LSL Style Guide

2014-09-07T00:09:02Z

Terk Resident: /* User-Defined States */ Nope. Actually fixing it now. Note to self - use show preview and don't just assume an edit fixed the issue.

==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

==== [[LSL_Variables|Global Variables]] ====

Global variables define and can contain data which can be written to or read from in multiple events and states within a script.
Here's an example of a simple script which uses global variables to store information in a state_entry event and allow it to be used in a second touch event.
<lsl>
key ownerkey; //Here we start by defining a global variable by the name of "ownerkey" and specify that it stores a key (UUID)

string ownername; //Next we define another global variable which stores the username of the owner of the prim containing this script and specify it is storing a string

integer reportonchannel = 0; //In this case we are defining a global variable which stores the numerical channel we will be using later, but in this case we give it a value at the start.
//As with the last 2, this can be written to but will revert to the specified value when the script is reset.

default
{
state_entry() //This event is triggered when entering the default state (When the script first runs or if moving to the default state from a user state)
{
ownerkey = llGetOwner(); //Stores the key of the owner of the prim containing this script to the "key ownerkey" global variable

ownername = llGetUsername(ownerkey); //Here we use that newly stored key to find the username of the account associated with the key in "key ownerkey"
//Note that since we have already defined ownerkey and ownername as a key and string respectively, we do not need to specify what type of data they store, unlike local variables
}

touch_start(integer num_detected) //This event is triggered when someone click the prim this script contains (If it's on click action is set to touch in the build floater)
{
string ownerkeyasastring = (string)ownerkey; //Let's prepare the key for use in a chat message. llSay requires strings but ownerkey is currently a string.
//Note that this is an inefficent method of preparing data stored in a variable to another type of data.
//Typically this would be done with typecasting in the intended function it is to be used in, but for the purpose of keeping this example easy to follow, I'll use this method.

llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
//When clicked, the prim will speak on the channel specified in "integer reportonchannel" and say the information we found in the previous event.
}
}
</lsl>

==== [[User-defined_functions|User Defined Functions]] ====

[[User-defined_functions|User defined functions]] follow imediatly after global variables in a script and before the default state. [[User-defined_functions|User Defined Functions]] allow for chunks of code that are repeated often throughout a script to be replaced with a one line function that acts in the same way as standard functions (Linden Library Functions).
These are useful when you want to keep your script bloat to a minimum by only having to write that chunk a single time and substitute other instances of it with a single easy line throughout the script.
Here's an example of our earlier script, this time making use of a custom function to replace the functions seen in our state_entry event.
<lsl>
key ownerkey;
string ownername;
integer reportonchannel = 0;

RetrieveOwnerData() //Here we create the user-defined function with the name "RetrieveOwnerData".
{
ownerkey = llGetOwner();
ownername = llGetUsername(ownerkey);
//Notice how we took the contents of our earlier state_entry() and placed it in a function.
//When the new function is called, this code will be ran.
}

default
{
state_entry()
{
RetrieveOwnerData(); //Here we call the function just like we would a normal LL function.
//Using a user-defined variable only once in a script is inefficient and shouldn't be used in place of just putting the code in normally if not being used multiple times.
//As for the point at which you deem it necessary? That's personal preference, but personally I go with if I am repeating code 3 or more times in a script.
}

touch_start(integer num_detected)
{
string ownerkeyasastring = (string)ownerkey;
llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
}
}
</lsl>

==== [[default|Default State]] ====
Next up we create our first [[state]]. This comes after user-defined functions and global variables.
In LSL, a state refers to a the container of events that trigger functions in the script. A script when it first starts will always exist in the initial [[default]] state which is a prerequisite for any LSL script. Scripts can contain multiple states, but only one can be active at any one time and only events that are handled in the active state will trigger functions in the script. A state can only contain one of each [[Category:LSL_Events|event handler]] (such as [[touch_start|Touch_start]] or [[state_entry|State_entry]]).
See below for an example of a simple script which says hello when clicked for an example of the default state:
<lsl>
default //All LSL scripts must contain a state named "default" and this must be the first state defined in your script.
{
touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the default state!");
}
}
</lsl>

==== [[state|User-Defined States]] ====
Lastly, we include any additional states we want in a script. User-Defined states allow for multiple instances of an [[Category:LSL_Events|event handler]] while effectively turning off other undesired events.
It should be noted that in most cases, you would want to use [http://lslwiki.net/lslwiki/wakka.php?wakka=condition conditionals] or [[Timer|timers]] in place of a state but the occasional use still does show up time to time.
Below is our previous script used in the default state example with a user-defined state added.
<lsl>
default
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered the default state!");
}
touch_start(integer num_detected)
{
llSay(0,"I was clicked!");
state two; // This instructs the script to switch to "state two" and stop processing events in the default state.
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving the default state!");
}
}

state two
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered state two!");
}

touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the second state!");
state default; // This instructs the script to switch back to the default state and stop processing events in "state two".
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving state two!");
}
}
</lsl>

Take great care when changing states in a script! Changing a state during an if or some loops can have adverse effects! Make sure to read up on [[state|states]] for more information.

LSL Style Guide

2014-09-07T00:05:39Z

Terk Resident: Fixing a derp on the internal link to the conditionals category.

==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

==== [[LSL_Variables|Global Variables]] ====

Global variables define and can contain data which can be written to or read from in multiple events and states within a script.
Here's an example of a simple script which uses global variables to store information in a state_entry event and allow it to be used in a second touch event.
<lsl>
key ownerkey; //Here we start by defining a global variable by the name of "ownerkey" and specify that it stores a key (UUID)

string ownername; //Next we define another global variable which stores the username of the owner of the prim containing this script and specify it is storing a string

integer reportonchannel = 0; //In this case we are defining a global variable which stores the numerical channel we will be using later, but in this case we give it a value at the start.
//As with the last 2, this can be written to but will revert to the specified value when the script is reset.

default
{
state_entry() //This event is triggered when entering the default state (When the script first runs or if moving to the default state from a user state)
{
ownerkey = llGetOwner(); //Stores the key of the owner of the prim containing this script to the "key ownerkey" global variable

ownername = llGetUsername(ownerkey); //Here we use that newly stored key to find the username of the account associated with the key in "key ownerkey"
//Note that since we have already defined ownerkey and ownername as a key and string respectively, we do not need to specify what type of data they store, unlike local variables
}

touch_start(integer num_detected) //This event is triggered when someone click the prim this script contains (If it's on click action is set to touch in the build floater)
{
string ownerkeyasastring = (string)ownerkey; //Let's prepare the key for use in a chat message. llSay requires strings but ownerkey is currently a string.
//Note that this is an inefficent method of preparing data stored in a variable to another type of data.
//Typically this would be done with typecasting in the intended function it is to be used in, but for the purpose of keeping this example easy to follow, I'll use this method.

llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
//When clicked, the prim will speak on the channel specified in "integer reportonchannel" and say the information we found in the previous event.
}
}
</lsl>

==== [[User-defined_functions|User Defined Functions]] ====

[[User-defined_functions|User defined functions]] follow imediatly after global variables in a script and before the default state. [[User-defined_functions|User Defined Functions]] allow for chunks of code that are repeated often throughout a script to be replaced with a one line function that acts in the same way as standard functions (Linden Library Functions).
These are useful when you want to keep your script bloat to a minimum by only having to write that chunk a single time and substitute other instances of it with a single easy line throughout the script.
Here's an example of our earlier script, this time making use of a custom function to replace the functions seen in our state_entry event.
<lsl>
key ownerkey;
string ownername;
integer reportonchannel = 0;

RetrieveOwnerData() //Here we create the user-defined function with the name "RetrieveOwnerData".
{
ownerkey = llGetOwner();
ownername = llGetUsername(ownerkey);
//Notice how we took the contents of our earlier state_entry() and placed it in a function.
//When the new function is called, this code will be ran.
}

default
{
state_entry()
{
RetrieveOwnerData(); //Here we call the function just like we would a normal LL function.
//Using a user-defined variable only once in a script is inefficient and shouldn't be used in place of just putting the code in normally if not being used multiple times.
//As for the point at which you deem it necessary? That's personal preference, but personally I go with if I am repeating code 3 or more times in a script.
}

touch_start(integer num_detected)
{
string ownerkeyasastring = (string)ownerkey;
llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
}
}
</lsl>

==== [[default|Default State]] ====
Next up we create our first [[state]]. This comes after user-defined functions and global variables.
In LSL, a state refers to a the container of events that trigger functions in the script. A script when it first starts will always exist in the initial [[default]] state which is a prerequisite for any LSL script. Scripts can contain multiple states, but only one can be active at any one time and only events that are handled in the active state will trigger functions in the script. A state can only contain one of each [[Category:LSL_Events|event handler]] (such as [[touch_start|Touch_start]] or [[state_entry|State_entry]]).
See below for an example of a simple script which says hello when clicked for an example of the default state:
<lsl>
default //All LSL scripts must contain a state named "default" and this must be the first state defined in your script.
{
touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the default state!");
}
}
</lsl>

==== [[state|User-Defined States]] ====
Lastly, we include any additional states we want in a script. User-Defined states allow for multiple instances of an [[Category:LSL_Events|event handler]] while effectively turning off other undesired events.
It should be noted that in most cases, you would want to use [[Category:LSL_Conditional|Conditionals]] or [[Timer|timers]] in place of a state but the occasional use still does show up time to time.
Below is our previous script used in the default state example with a user-defined state added.
<lsl>
default
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered the default state!");
}
touch_start(integer num_detected)
{
llSay(0,"I was clicked!");
state two; // This instructs the script to switch to "state two" and stop processing events in the default state.
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving the default state!");
}
}

state two
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered state two!");
}

touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the second state!");
state default; // This instructs the script to switch back to the default state and stop processing events in "state two".
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving state two!");
}
}
</lsl>

Take great care when changing states in a script! Changing a state during an if or some loops can have adverse effects! Make sure to read up on [[state|states]] for more information.

LSL Style Guide

2014-09-06T23:58:42Z

Terk Resident: /* Script Structure */ Expanded on stub section on the structure of a script. Included LSL examples walking through the 4 sections of any script.

{{LSL Header|ml=*}}{{RightToc}}

Every major open-source project has its own style guide: a '''set of conventions''' (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a '''consistent style'''. These guidelines, referred to collectively as a Style Guide, are not as rigid as the rules required by the language compiler but nonetheless are critical to creating maintainable code. The most critical aspect of a style is that you apply it consistently to the code you write.

Effective programming in [[LSL Portal|LSL]] requires that developers use a disciplined approach towards formatting and other conventions in their scripts.

{{LSL Tip| Applying a style guide to your code does not only help others read your code. '''It helps you as well''', because in future when you return to the code you wrote before, you'll appreciate reading formatted and annotated code.}}

== Use third party editors: ==

There are many [[LSL Alternate Editors|third party editors]] with [[LSL Portal|LSL]] syntax files available. See an example below of what your workflow would look like using an editor that has syntax highlighting and autocomplete and also applies an indent style to your code.

[[File:Pareto_principle_scripting.gif|thumb|700px|center|Writing and fixing scripts takes time and effort. '''Readability is key to being more productive!''' [[LSL_Alternate_Editors|Alternate Editors do help, too.]] ]]

You can see now, that using [[LSL Alternate Editors|third party editors]] has a few advantages over using the editor in the viewers:
* Autocompletion helps you avoid typos.
* Autocompletion sometimes not only does a linear autocompletion as in autocompleting <code>llS</code> to <code>llSay</code> but sometimes works even with fuzzy search by autocompleting <code>llslppf</code> to <code>llSetLinkPrimitiveParamsFast</code>.
* The syntax highlighting file colors the code exactly like the code you see in the official Linden Lab viewer making you not having to learn or adapt to a different coloring scheme.
* Autocompletion might also preformat code with indent styles when autocompleting states, events, conditional clauses etc.

== [http://en.wikipedia.org/wiki/Indent_style Indent styles]: ==

Most people, when they start programming on their own, will have programs that are UGLY to look at - to put it nicely, sometimes mistakenly thinking that such scripts occupy less space when compiled. Such scripts typically look like the following:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''unstyled source code'''
|-
||
<lsl>default {state_entry(){llSay(0,"Hello World.");}}</lsl>
|}

However, that code is difficult to read (or at least to '''follow''') - even more so when one is writing a couple hundred lines program. There are several [http://en.wikipedia.org/wiki/Indent_style indent styles] which are seen throughout various programming languages which are used to make code more readable and easier to work with. LSL is a C based language and as such proper formatting makes use of the Allman style of code as seen below:

{| width="100%" {{Prettytable}}
|- {{Hl2}}
! '''[http://en.wikipedia.org/wiki/Indent_style#Allman_style Allman style] (used in C based languages)'''
|-
||
<lsl>
default
{
state_entry()
{
llSay(0, "Hello World.");
}
}
</lsl>
|}

It should be noted that LSL is resilient and as such will compile even if an incorrect formatting style for the language is used so long as the syntax is correct. This can be useful if you are coming from another language such as JavaScript which makes use of K&R style formatting and can allow for an easier transition to coding in LSL. It is however, good practice to avoid using any other formatting styles other than Allman as doing so will result in code which is obsfucated and harder to read in terms of how LSL is interpreted with parenthesis' and some operators. If good coding habits are important to you or if LSL is your first step into programming, it is strongly suggested you use Allman for your formatting style.

== Naming conventions: ==

There are many naming conventions in Second Life. Only the most used ones will be listed below.

Global Variables (variables used through out the entire program) should be lowercase. For example:

<lsl>
integer index = 0;
string name = "Please set one";
</lsl>

Others prefer to distinguish between global and local variables by prefixing variable names with a character, defining globals in the following manner:

<lsl>
integer gIndex;
string gName = "Please set one";
</lsl>

Constant variables should be in ALL CAPS following the style guide used by Linden Labs. For example:

<lsl>
integer DIALOG_CHANNEL = -517265;
vector RED = <1.0, 0.0, 0.0>;
</lsl>

Arguments used within a [[Category:LSL User-Defined Functions|user defined function]] or one of the standard [[Event|events]] should be named with '''easily readable and meaningful''' names. When using [[Event|events]], please use the standard names as listed here on the official wiki. An [[Event|overview of all events can be found here]]. Below is an example as can be found for the [[Listen|listen event]]:

<lsl>
// ...

listen(integer channel, string name, key id, string message)
{
key OwnerKey = llGetOwner();

if (channel == 1 && id == OwnerKey)
llOwnerSay("Hello Avatar");
}

// ...
</lsl>

== Separating code: ==
Some people put too many function calls on one line. As shown in this example, too many function calls on a single line makes the code hard to read and almost impossible to debug.

<lsl>
list lst;
integer numDigits = 10;

default {
touch_start(integer n) {
integer i;
integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]);
if (!~llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]))
lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1));
llOwnerSay(llList2CSV(lst));
}
}
</lsl>

Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can figure out what the below code does.

<lsl>
list listOfStrings;
integer numDigits = 10;

default
{
touch_start(integer n)
{
key owner = llGetOwner();
key id = llDetectedKey(0);
string name = llDetectedName(0);// or llKey2Name(id)

list nameAsList = llParseString2List(name, [" "], []);
string firstName = llList2String(nameAsList, 0);
string startPart = llToLower(llGetSubString(firstName, 0, numDigits - 1));
integer index = llListFindList(listOfStrings, [startPart]);

// if index is equal to -1
if (index == ERR_GENERIC)
listOfStrings += startPart;

// send a message to the owner, only reaches owner if online and within the same sim
llRegionSayTo(owner, PUBLIC_CHANNEL, llList2CSV(listOfStrings));
}
}
</lsl>

LSL lacks an optimizing compiler. For this reason it may be necessary to balance the two style to get faster, more compact executable code. Line combination optimization should only be done after the code is working & bug free. Improper optimization can lead to wrong results. Always test optimized code thoroughly.

==Script Structure==
LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:

==== [[LSL_Variables|Global Variables]] ====

Global variables define and can contain data which can be written to or read from in multiple events and states within a script.
Here's an example of a simple script which uses global variables to store information in a state_entry event and allow it to be used in a second touch event.
<lsl>
key ownerkey; //Here we start by defining a global variable by the name of "ownerkey" and specify that it stores a key (UUID)

string ownername; //Next we define another global variable which stores the username of the owner of the prim containing this script and specify it is storing a string

integer reportonchannel = 0; //In this case we are defining a global variable which stores the numerical channel we will be using later, but in this case we give it a value at the start.
//As with the last 2, this can be written to but will revert to the specified value when the script is reset.

default
{
state_entry() //This event is triggered when entering the default state (When the script first runs or if moving to the default state from a user state)
{
ownerkey = llGetOwner(); //Stores the key of the owner of the prim containing this script to the "key ownerkey" global variable

ownername = llGetUsername(ownerkey); //Here we use that newly stored key to find the username of the account associated with the key in "key ownerkey"
//Note that since we have already defined ownerkey and ownername as a key and string respectively, we do not need to specify what type of data they store, unlike local variables
}

touch_start(integer num_detected) //This event is triggered when someone click the prim this script contains (If it's on click action is set to touch in the build floater)
{
string ownerkeyasastring = (string)ownerkey; //Let's prepare the key for use in a chat message. llSay requires strings but ownerkey is currently a string.
//Note that this is an inefficent method of preparing data stored in a variable to another type of data.
//Typically this would be done with typecasting in the intended function it is to be used in, but for the purpose of keeping this example easy to follow, I'll use this method.

llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
//When clicked, the prim will speak on the channel specified in "integer reportonchannel" and say the information we found in the previous event.
}
}
</lsl>

==== [[User-defined_functions|User Defined Functions]] ====

[[User-defined_functions|User defined functions]] follow imediatly after global variables in a script and before the default state. [[User-defined_functions|User Defined Functions]] allow for chunks of code that are repeated often throughout a script to be replaced with a one line function that acts in the same way as standard functions (Linden Library Functions).
These are useful when you want to keep your script bloat to a minimum by only having to write that chunk a single time and substitute other instances of it with a single easy line throughout the script.
Here's an example of our earlier script, this time making use of a custom function to replace the functions seen in our state_entry event.
<lsl>
key ownerkey;
string ownername;
integer reportonchannel = 0;

RetrieveOwnerData() //Here we create the user-defined function with the name "RetrieveOwnerData".
{
ownerkey = llGetOwner();
ownername = llGetUsername(ownerkey);
//Notice how we took the contents of our earlier state_entry() and placed it in a function.
//When the new function is called, this code will be ran.
}

default
{
state_entry()
{
RetrieveOwnerData(); //Here we call the function just like we would a normal LL function.
//Using a user-defined variable only once in a script is inefficient and shouldn't be used in place of just putting the code in normally if not being used multiple times.
//As for the point at which you deem it necessary? That's personal preference, but personally I go with if I am repeating code 3 or more times in a script.
}

touch_start(integer num_detected)
{
string ownerkeyasastring = (string)ownerkey;
llSay(reportonchannel,"I am owned by "+ownername+" and their UUID is "+ownerkeyasastring);
}
}
</lsl>

==== [[default|Default State]] ====
Next up we create our first [[state]]. This comes after user-defined functions and global variables.
In LSL, a state refers to a the container of events that trigger functions in the script. A script when it first starts will always exist in the initial [[default]] state which is a prerequisite for any LSL script. Scripts can contain multiple states, but only one can be active at any one time and only events that are handled in the active state will trigger functions in the script. A state can only contain one of each [[Category:LSL_Events|event handler]] (such as [[touch_start|Touch_start]] or [[state_entry|State_entry]]).
See below for an example of a simple script which says hello when clicked for an example of the default state:
<lsl>
default //All LSL scripts must contain a state named "default" and this must be the first state defined in your script.
{
touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the default state!");
}
}
</lsl>

==== [[state|User-Defined States]] ====
Lastly, we include any additional states we want in a script. User-Defined states allow for multiple instances of an [[Category:LSL_Events|event handler]] while effectively turning off other undesired events.
It should be noted that in most cases, you would want to use [[Conditionals|Category:LSL_Conditional]] or [[Timer|timers]] in place of a state but the occasional use still does show up time to time.
Below is our previous script used in the default state example with a user-defined state added.
<lsl>
default
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered the default state!");
}
touch_start(integer num_detected)
{
llSay(0,"I was clicked!");
state two; // This instructs the script to switch to "state two" and stop processing events in the default state.
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving the default state!");
}
}

state two
{
state_entry() //This event is triggered when we are entering from another state
{
llSay(0,"I have entered state two!");
}

touch_start(integer num_detected)
{
llSay(0,"I was clicked! I'm in the second state!");
state default; // This instructs the script to switch back to the default state and stop processing events in "state two".
}

state_exit() //This event is triggered when we are changing to another state
{
llSay(0,"I am leaving state two!");
}
}
</lsl>

Take great care when changing states in a script! Changing a state during an if or some loops can have adverse effects! Make sure to read up on [[state|states]] for more information.

LSL Style Guide

2014-09-06T22:44:52Z

Terk Resident: /* LSL Portal Style */ - The point of this article is introducing new users to proper formatting. Not to make a case for your personal favoured style being on the wiki when C has established norms.

LSL Style Guide

2014-09-06T22:13:46Z

Terk Resident: /* Indent styles: */ - Reworded section on resilience to incorrect formats to be more neutral in tone.

LSL Style Guide

2014-09-06T16:53:44Z

Terk Resident: /* Indent styles: */ - LSL is a C based language. Let's not try pretend that writing it as if it was JS based is equally valid, regardless of some people are in the habit of writing JS or not.

LlList2String

2014-08-31T00:20:08Z

Terk Resident: Undo revision 1174262 Although this is indeed useful information. It should instead be added to the section in LSL List on iteration. Covering iteration is not relevant to this function.

{{LSL_Function
|inject-2={{LSL_Function/list/element|src|index|string|nf=*|return={{HoverText|null string|null string: ""}}}}
|func_id=188|func_sleep=0.0|func_energy=10.0
|func=llList2String|return_type=string|p1_type=list|p1_name=src|p2_type=integer|p2_name=index
|func_footnote
|func_desc
|return_text=that is at {{LSLP|index}} in {{LSLP|src}}.
|spec
|caveats=*When using this function to typecast a list element to a string it will truncated float based types to 6 decimal places.
|constants
|examples=<lsl>//This code demonstrates the differences in typecasting in LSL (and demonstrates how to use the llList2* functions).
// Best viewed in Chat History (ctrl-h)
default
{
state_entry()
{
list my_list = ["a", "0xFF", "0xFF.FF", "1.0e3", 1, 2.0, <1,2,3>, <1,2,3,4>, llGetOwner()];
integer i = 0;
integer end = llGetListLength(my_list);
for (; i<end; ++i)
{
llOwnerSay("string=" + llList2String(my_list,i)
+ "\n integer=" + (string)llList2Integer(my_list,i) + " OR " +(string)((integer)llList2String(my_list,i))
+ "\n float=" + (string)llList2Float(my_list,i) + " OR " +(string)((float)llList2String(my_list,i))
+ "\n vector=" + (string)llList2Vector(my_list,i) + " OR " +(string)((vector)llList2String(my_list,i))
+ "\n rot=" + (string)llList2Rot(my_list,i) + " OR " +(string)((rotation)llList2String(my_list,i))
+ "\n key=" + (string)llList2Key(my_list,i) + " OR " +(string)((key)llList2String(my_list,i)) );
}
}
}</lsl>
|helpers
|also_functions={{LSL DefineRow||[[llDumpList2String]]|}}
{{LSL DefineRow||[[llGetListEntryType]]|}}
{{LSL DefineRow||[[llList2Float]]|}}
{{LSL DefineRow||[[llList2Integer]]|}}
{{LSL DefineRow||[[llList2Key]]|}}
|also_events
|also_tests
|also_articles
|notes=*If you wish to extract a string from a list that you know will contain only a single item (for example if you extract a single entry from a list using [[llList2List|llList2List()]]), then instead of using <code>llList2String(myList, 0)</code> you may wish to considering using the more efficient <code>(string)myList</code> as it will produce the same result for single-entry lists with less memory usage due to eliminating a function-call.
*To convert a string of hexadecimal notation to integer, call [[llList2Integer]] and it will automatically cast the value as decimal integer. To convert that integer back to a string of hexadecimal notation, use a user function like [[hex]].
|permission
|cat1=List
|cat2
|cat3
|cat4
}}

3D Radar

2014-08-05T16:50:39Z

Terk Resident: /* Scan Ball Script */

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into the scan balls too!
integer key_rem_chan = -49222879;

default
{

touch_start(integer total_number)
{
if (Scan)
{
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else
{
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}

sensor(integer iNum)
{
integer p = 0;
for (p = 0; p < iNum; ++p)
{
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1)
{
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}

listen(integer c, string name, key id, string msg)
{
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}
</lsl>

==Scan Ball Script==
Place this script in a prim and make sure to name it "scan ball". Then place the prim into the inventory of the Scanner/Rezzer.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command
{ //(Right channel, right message and from radar owned by same owner)
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:30:09Z

Terk Resident: /* Scan Ball Script */ Breaking up a comment into two lines

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into the scan balls too!
integer key_rem_chan = -49222879;

default
{

touch_start(integer total_number)
{
if (Scan)
{
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else
{
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}

sensor(integer iNum)
{
integer p = 0;
for (p = 0; p < iNum; ++p)
{
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1)
{
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}

listen(integer c, string name, key id, string msg)
{
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}
</lsl>

==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command
{ //(Right channel, right message and from radar owned by same owner)
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:28:52Z

Terk Resident: /* Scan Ball Script */ - Removed line of code that names the object. According to the rezzer script, this prim should already be named and the name has no effect on the operation of the script.

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into the scan balls too!
integer key_rem_chan = -49222879;

default
{

touch_start(integer total_number)
{
if (Scan)
{
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else
{
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}

sensor(integer iNum)
{
integer p = 0;
for (p = 0; p < iNum; ++p)
{
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1)
{
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}

listen(integer c, string name, key id, string msg)
{
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}
</lsl>

==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command (Right channel, right message and from radar owned by same owner)
{
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:27:53Z

Terk Resident: /* Scanner/Rezzer Script */ - Improved readability and removed redundant code

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into the scan balls too!
integer key_rem_chan = -49222879;

default
{

touch_start(integer total_number)
{
if (Scan)
{
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else
{
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}

sensor(integer iNum)
{
integer p = 0;
for (p = 0; p < iNum; ++p)
{
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1)
{
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}

listen(integer c, string name, key id, string msg)
{
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}
</lsl>

==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
llSetObjectName("scan ball"); //Renames the object to "scan ball"
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command (Right channel, right message and from radar owned by same owner)
{
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:22:41Z

Terk Resident: /* Scan Ball Script */ Improved readability and removed some redundant code (actually did it properly this time)

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into
//the scan balls too!
integer key_rem_chan = -49222879;
default {
state_entry() {
llSetObjectName("3D Radar");
}
touch_start(integer total_number) {
if (Scan) {
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else {
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}
sensor(integer iNum) {
integer p = 0;
for (p = 0; p < iNum; ++p) {
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1) {
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}
listen(integer c, string name, key id, string msg) {
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}

</lsl>
==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
llSetObjectName("scan ball"); //Renames the object to "scan ball"
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command (Right channel, right message and from radar owned by same owner)
{
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:20:39Z

Terk Resident: Undo revision 1192566 by Terk Resident (Talk) - Derp, accidentally wiped a section

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into
//the scan balls too!
integer key_rem_chan = -49222879;
default {
state_entry() {
llSetObjectName("3D Radar");
}
touch_start(integer total_number) {
if (Scan) {
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else {
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}
sensor(integer iNum) {
integer p = 0;
for (p = 0; p < iNum; ++p) {
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1) {
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}
listen(integer c, string name, key id, string msg) {
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}

</lsl>
==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
default {
state_entry() {
llSetObjectName("scan ball");
}
on_rez(integer start_param) {
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}
listen(integer c, string n, key id, string msg) {
if (c == die_chan && msg == "die") {
key owner = llGetOwner();
if (owner == llDetectedOwner(0)) {
llDie();
}
}
else {
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}
sensor(integer n) {
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}
no_sensor() {
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}

3D Radar

2014-08-05T16:19:01Z

Terk Resident: /* Scan Ball Script */ Improved readability and removed some redundant code

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into
//the scan balls too!
integer key_rem_chan = -49222879;
default {
state_entry() {
llSetObjectName("3D Radar");
}
touch_start(integer total_number) {
if (Scan) {
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else {
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}
sensor(integer iNum) {
integer p = 0;
for (p = 0; p < iNum; ++p) {
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1) {
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}
listen(integer c, string name, key id, string msg) {
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}

</lsl>
string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
key owner;

default
{

state_entry()
{
llSetObjectName("scan ball"); //Renames the object to "scan ball"
owner = llGetOwner(); // Lets check to see what the key of the owner of the object is and save it for later
}

on_rez(integer start_param)
{
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}

listen(integer c, string n, key id, string msg)
{
if (c == die_chan && msg == "die" && owner == llDetectedOwner(0)) //Lets check to see if the message we heard matches all the criteria for the kill command (Right channel, right message and from radar owned by same owner)
{
llDie();
}

else
{
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}

sensor(integer n)
{
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}

no_sensor()
{
llRegionSay(key_rem_chan, avKey);
llDie();
}
}

3D Radar

2014-08-05T15:36:41Z

Terk Resident: /* Scan Ball Script */ - Fixed broken and badly implemented if statement before running llDie() on the scan ball.

{{LSL Header}}

*[[User:Jesse_Barnett|Click Here]] To see my page and more of my scripts

==Scripts have been corrected and working properly now==

Rezzes a ball for each avatar in range. Each ball tracks it's on AV and displays distance.

==Scanner/Rezzer Script==
Place this script in a prim along with the scan ball. When touched it will scan the surrounding area and rezz a ball for each avatar.

Suggestion: Create a sphere with a diameter of 2 meters. Set transparency about 60. Create another sphere about 0.05 diameter, color a dark color and put it in the center of the large prim. Select small prim 1st and then large prim and link them. This will give you a center point to reference. The scan ball script is set to scan for it's avatar to a range of 96 meters.

This formula: vector avDivPos = (avPos - rPos) * 0.010417; Takes the (avatars position - position of scanner) & multiplies by (radius of the distance you want the balls to go(2 meter sphere = 1 meter radius)/scan range(96meters)):

1/96 = approximately 0.010417.

<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:43:28"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

integer Scan = TRUE;
string avKey;
integer list_pos;
list key_list;
integer key_chan; //Key channel is generated randomly and passed to the scan ball
integer die_chan = -9423753; //Hey pick your own channels and be sure to paste them into
//the scan balls too!
integer key_rem_chan = -49222879;
default {
state_entry() {
llSetObjectName("3D Radar");
}
touch_start(integer total_number) {
if (Scan) {
llSensorRepeat("", "", AGENT, 96, PI, 1);
key_list =[];
llListen(key_rem_chan, "", "", "");
llOwnerSay("on");
Scan = FALSE;
}
else {
llSensorRemove();
llRegionSay(die_chan, "die");
llOwnerSay("off");
Scan = TRUE;
}
}
sensor(integer iNum) {
integer p = 0;
for (p = 0; p < iNum; ++p) {
avKey = llDetectedKey(p);
list_pos = llListFindList(key_list, (list)avKey);
if (list_pos == -1) {
key_list += (list) avKey;
key_chan = (integer) llFrand(-1000000) - 1000000;
llRezObject("scan ball", llGetPos(), ZERO_VECTOR, ZERO_ROTATION, key_chan);
llSleep(.25);
llRegionSay(key_chan, avKey);
}
}
}
listen(integer c, string name, key id, string msg) {
integer r = llListFindList(key_list,[(key)msg]);
key_list = llDeleteSubList(key_list, r, r);
}
}

</lsl>
==Scan Ball Script==
Place this script in a prim and then place the prim into the inventory of the Scanner/Rezzer. It will automatically name itself.

Suggestion; Create a sphere prim of 0.05 diameter with glow set about .80.
<lsl>
//////////////////////////////////////////////////////////////////////////////////////////////////////
// 3D Radar 2.5
// "Oct 15 2008", "18:44:36"
// Creator: Jesse Barnett
// Released into the Public Domain
//////////////////////////////////////////////////////////////////////////////////////////////////////

string avName;
integer avDistance;
key avKey;
integer avListen;
integer key_chan;
integer die_chan = -9423753;
integer key_rem_chan = -49222879;
vector avPos;
vector rPos;
default {
state_entry() {
llSetObjectName("scan ball");
}
on_rez(integer start_param) {
rPos = llGetPos();
key_chan = start_param;
llListen(die_chan, "", "", "");
avListen = llListen(key_chan, "", "", "");
}
listen(integer c, string n, key id, string msg) {
if (c == die_chan && msg == "die") {
key owner = llGetOwner();
if (owner == llDetectedOwner(0)) {
llDie();
}
}
else {
avKey = (key) msg;
avName = llKey2Name(avKey);
llSensorRepeat("", avKey, AGENT, 96, PI, 1.0);
llListenRemove(avListen);
}
}
sensor(integer n) {
avPos = llDetectedPos(0);
vector avDivPos = (avPos - rPos) / (96 / 1); //Scan range/Radius of large sphere
avDistance = (integer) llVecDist(rPos, llDetectedPos(0));
llSetPos(rPos + avDivPos);
llSetText(avName + "[" + (string) avDistance + "]", <1, 1, 1 >, 1);
}
no_sensor() {
llRegionSay(key_rem_chan, avKey);
llDie();
}
}
</lsl>
{{LSLC|Library|3D Radar}}