Guild of Maintainers Forum

It is currently 22 Nov 2017, 12:17 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: 27 Jan 2009, 08:39 pm 
Offline
Guild Member
User avatar
Send private message  WWW  Profile

Joined: 03 Jul 2008, 07:55 pm
Posts: 499
Location: California
KI Number: 83543
Caveats
This starts at a basic and generalized level. This is an attempt to give one enough foundation to understand the concepts in the Linden Scripting Language (LSL). It is a simplified tutorial geared toward Second Life. It targets the beginning SL programmer making their first attempt at programming.

Concepts
Programming and Program Languages
A program is a set of instructions that tell a computer what to do. In Second Life (SL) programs are called scripts and programming is often called scripting. In the larger world of computer programming scripts are usually just small programs.

Computers read binary codes, 1’s and 0’s. For humans using binary is difficult. It is much easier for us to write and read 13 or thirteen than 1101b. The ‘b’ denotes a binary number. Therefore we need a language that we can read and write but that can be translated into something the computer can understand. English is ambiguous and computers need precise languages. Many languages have been developed, Fortran, C, C++, Visual Basic, Pascal, LISP, Java, JavaScript and Linden Scripting Language (LSL). LSL is very much like JavaScript with some omissions and additions.

Because the computer reads binary many consider it a ‘code’. Programs are often referred to as code and programming as coding. No matter that we can read the program written in Basic or LSL it is still considered code.

Whatever language is used at some point it has to be translated for use on the computer. In many cases a program is translated and the resulting file is the program we use on our computers, called the application or executable. This is something like translating a book from English to Italian. The translation done for computers is called compiling. That is very simplified but good enough for our use. The big advantage of this type of compiling is it only needs to be done once.

There is also a thing called ‘run time compile’, which is sort of like having a human translator standing around to tell someone what was said. In this case a program is not compiled into new files for use, no Italian book. The human language copy (English book) is used and translated (compiled) each time the program is run. This can make it easier when programs need to change often. The LSL is more of the compiled type of program. We only ever see the human language part. SL takes care of storing and using the resulting computer version. When you close/save a script in SL it forces a compile and saves the computer version.

Variables
Often in programs we need to count things or wait for a specific amount of time. If we write a computer program and tell it to wait 3 minutes we are said to have ‘hard coded’ the time (3 minutes). However, we could tell the computer to wait for X minutes. Now the computer has to look up the value of X and see how long to wait. Somewhere else in the program we could calculate how long to wait and put the result in X. Because X can change, calling it a variable is handy. So, variables are a computer language construct that tells the computer this is something that can change. It knows to go find the value.

Most languages allow one to name variables. So, instead of using ‘X’ I could use something like ‘waitTime’. Many languages have limits on the length of variable names and restrict what the first letter can be. In general start variable names with a letter. Avoid starting with a number or symbol. Use names that mean something and keep them short. That capitol ‘T’ is optional. I do it to make easier reading.

Variables come in types. There are several in LSL; integer, float, string, list, vector, etc. Integers are whole numbers like 1, 2, 3, etc. Floats are real numbers like; 1.2, 3.14, etc. A string contains text, alphanumeric items. More about the others later.

Some languages are strongly typed and others loosely or not typed. Plus some are dynamically or statically typed. This means a variable typed as an integer must hold an integer, a float a float, etc. LSL is strongly and statically typed language. This means variables must be declared before they are used and cannot be changed during run time (while the program is running – it is amazing how often programmers do that dynamic thing).

In a LSL program declarations looks like these:
Code:
   integer waitTime;
   string   AVName = “Nalates”;


In connection with variables is a thing called ‘casting’. When I need to print a string of text and include a number from a variable I run into ‘type’ problems. I need to combine text and numbers, say “I waited for” plus waitTime (in minutes) plus “minutes.” In LSL this is often seen this way;

Code:
llWhisper(0, “I waited for ” + waitTime + “ minutes.”);


This is telling the computer to combine or add together two strings and a variable of type integer. As people we know that four plus 4 is eight but computers don’t work with a mix of numbers and words. They have no idea that four is the same as 4. They see it as a word and a number. So, the computer knows how to combine/add strings/text together, e.g., “I waited for ” + “ minutes.” Results in “I waited for minutes.” But the variable is a problem because it is an integer. So, we need to tell the computer to turn the number into a string and treat it like text. We do that by casting the integer to a string.

Code:
llWhisper(0, “I waited for” + (string) waitTime + “minutes.”);


Placing ‘(string)’ in front of the integer tells the computer how to handle the numeric information and is called casting. We changed its cast but just for this single use. The variable "waitTime" still holds an integer. You will deal with lots of casting in LSL programs.

In most programming manuals combining strings is called concatenation. Depending on the language, the symbol for addition is typically used to denote concatenation. Some languages have special concatenation symbols. LSL uses the ‘+’ symbol for addition and concatenation.

Scope
Variables have scope, which typically means they are local or global. A local variable is only used and can only be seen from within a state or event handlers (more on this later). Global variables can be used and seen from anywhere inside the program. Scope is controlled by where one declares the variable. We’ll come back to scope later.

Program Structure
Just as books have structure and a flow so too do computer programs. Also, just as books and outlines have formatting so too do computer programs.

In computer programs formatting is typically only for people. It is done just to make it easier for humans to read programs. As you advance you will see why formatting can help avoid mistakes. The punctuation in the program serves the same purpose for the computer. The ‘;’ and ‘{}’ and ‘()’ tell the program what goes together and how.

Computer programs have structure or parts. Most have a main body and supporting parts. The parts are often called subroutines, functions, procedures, modules, classes, objects, and the list goes on. In LSL the main part of the program is called the Default State. This Default State is where the computer begins reading and following instructions. Every LSL program must have a default state.

States
LSL has states, which is an addition to its language not seen in JavaScript. It is very handy in virtual worlds and is a big part of LSL programming. Think of a state as a light on or off or a door open or closed. When we touch a light in an ‘on’ state we would likely want it to turn off. The use of states makes this easier to program. LSL makes extensive use of states. Each state has its own block of program code and can be thought of as a separate program… well almost.

Events
An event is computer speak for something happening. Things like mouse clicks, an AV colliding with a wall, a prim rez’ing, something added to a prim’s contents, prims moving, a message arriving, and other things. Often our programs will need to do something when an event happens, i.e., open a door, turn a light on, etc. Events fit inside states. One could have a ‘touch’ event in the ON state (written to turn the light off) and another in the OFF state (to turn it on). The program will have a section or block of code that is run when an event fires this block of code is called the event handler.

Flow Control
Sometimes we need to do something like read each line in a note card until we have read the last line. When we do not know how many lines there are or even if we do, we need some way to tell the program when to stop reading. If we just tell it to read, read, and read we read three lines. What if there are 4 lines of text in the note card? This is where flow control comes in. Flow control is about the flow of program execution, i.e., do this until this or do this for this many times. These controls in LSL are; for, if, while, do-while, jump, return, and states. A text example using what is called pseudo code is;
Code:
While( is more there? ) { do reads and save the info here. }

The ‘while’ command tells the computer to do whatever is inside the ‘{}’ brackets as long as the statement inside the ‘()” is true (or yes). Once it is no longer true the computer moves on to the next command/instruction.

Functions
Functions are the work horses of LSL. There are built in functions like llWhisper() and we can write our own functions. Think about what llWhisper() has to do. We give it a channel and string of text and it gets the text into the chat window so it can be seen. It scrolls the text already there, adds ours and if the chat dialog is closed, places it in a translucent box and scrolls it across our screen and to then makes it disappear after so many seconds. There is a lot of computer code telling it how to do that. But we just need to write the a little bit code to call the function and LL has written the rest for us. All the built-in functions start with ‘ll’ (2 lower case ‘L’s). Any functions we write CANNOT start with double L’s.

We might write a function that simulates rolling dice, say rollDice(). We could use a random number generator and set it to give us a number from 1 to 6 and tell it to use 2 or more dice. Then in the program each time we needed to roll dice we could call our function and avoid repeatedly writing the ‘roll dice’ code contained in the function again and again. LSL has hundreds of built in functions.
Reference: http://wiki.secondlife.com/wiki/LSL_Portal - Open Resource no login to read


Identifying Program Parts
Here is an example program with the parts labeled.

Code:
Global declaration      string myGreeting = “Hello”;
Initial State           default {
Event                        touch_start(integer a)     {
Command                      state hello;
Close event                   }
Close state             }
 
User State            state hello {
Event                   state_entry()     {
Command                        llOwnerSay(myGreeting);
Command                        state default;
Close event              }

Event                  state_exit()     {
Command                        llOwnerSay("Goodbye");
Close event              }
Close state         }


The order of the states is not important in LSL. The script/program will always start in default. In this program the program will sit in the default state waiting for a touch (mouse click) event. Once touched it will switch to the ‘hello’ state and find the ‘state_entry’ event. This event takes control (usually said to have fired) when the program first enters the state. It will then tell the owner ‘Hello’ using the myGreeting variable and switch back to the default state to wait for another touch. Except when the program leaves the ‘hello’ state it fires an ‘exit’ event. This is caught by the ‘state_exit’ event handler and says ‘goodbye’ then continues on to the default state.

This is a rather contrived situation to show how states and events work. It also shows how formatting helps to make the parts more easy to see. Notice the two events in the ‘hello’ state.


End Part 1 – I have a few more things to add to the lesson as I get time.
Use this thread for questions on Part 1 Concepts

_________________
Guild Master Nalates Urriah - GoC
Nalates Urriah is my SL and OSGrid name - MOULagain: Nal KI#oo o83 543 - Nalates KI#111451
Support: Devokan Trust - Myst Style Stories Across Worlds
Support: OpenUru.org - Myst/Uru Open Source Resources


Top
 
PostPosted: 28 Feb 2009, 10:26 am 
Offline
Send private message  Profile

Joined: 12 Nov 2007, 02:59 am
Posts: 1796
KI Number: 0
Good explanation, Nalates, with some helpful analogies. It's got me thinking I could try this.

_________________
Devokan forum: Myst/Uru inspired projects and stories
OpenUru.org: tools and resources for open source Uru


Top
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group  
Myst and Uru are © of Cyan Worlds Inc. All rights reserved.
Images from Myst Online: Uru Live are used by permission of Cyan Worlds.