About LSL concepts and structures.

Ok, I think I have some of the concepts down for LSL, but would like confirmation. My previous programming knowledge helps me to catch on fast, but...


Let's go down the list:

- States:
The idea of states that that when a 'state' is set, it runs the code inside of that named statement. The default statement is normally "default" and will revert when reset.

States are better than global variables & 'if' checks in the following ways:

A state reduces the amount of code a script must run to achieve an effect. It only runs the code from a specific function, and all others are ignored until the state is changed. improves the scripts speed by removing all of the if (x==1) {do this} that it would normally have to check during every cycle of the script.

It also allows you to better seperate your code, making it easier to control, debug, and understand. (once you get used to the idea of states.)

Keep in mind, Global variables are not excluded from being used across states: So they can be used together to achieve some special functions.


- Variables declaration:
Variables declared at the beginning of the script, before default{}, are accessable from anywhere inside the same script, regardless of state or function.

- Explicit Typecasting:
This is just a simple method to use one variable type like another. the variable integer HowMany can be read and used as a string by using (string)HowMany.

- Lists:
LSL does not have arrays, I'm betting because of the memory requirments for them. Instead lists can be used to store data in a sequentially accessable 'one dimensional array'. It begins at 0 and continues up as data is added using an newlist = oldlist + ["oneitem", "anotheritem"] command.


Am I following the concepts here? Just want to make sure I'm not wandering off into my own little world again...

That seems about right to me, right down the list.

This is pretty much accurate. The only thing I'd like to point out is explicit typecasting may occasionally have some unexpected effects, as do conversions from lists via llList2*Whatever*. You would be wise to study some of these conventions if you haven't already.

Otherwise, I'd say you're fairly spot-on here.

You can kluge your own "duct tape" 2-d array by using a comma delimited strings and a function like the following:

string ParseCSV(string strCSV, integer intPos)
{
list lCSV = llCSV2List(strCSV);
string parsed = llList2String(lCSV, intPos);

return parsed;
}

So ParseCSV("Corster Mousehold, data1, data2, data3", 0) would return "Corster Mousehold"
ParseCSV("Corster Mousehold, data1, data2, data3", 1) would return "data1"
etc. etc.

Just make sure when you create your comma-del string that it uses the same data layout throughout.

-cor-

Foolish, check this out, and you may learn something, or be able to add some of your own insights: http://secondlife.com/badgeo/wakka.php?wakka=CrashCourse

Hmmm, FF, I take it you never studied graph theory and deterministic finite automata?
It's easier to think of LL as a DFA (aka FSM - finite state machine).
I had a lengthy explanation here but then found out wikipedia has a good article on them.
http://en.wikipedia.org/wiki/Finite_state_machine

You were wrong. It's not easier...

How about I consider it event driven programming with the feature of 'states' added in?

States can also be used to minimize "event" processing by your script. If you're in a state where your listeners no longer have to listen, or perhaps a state where you are no longer concerned about collisions, then so long as that state doesn't have the handler for that event, you will be minimizing sim impact.

- Ace

So switching to a state that does not have a listen function effectivly turns off that function and saves the resources? Sweet! Is it the same with sensors?

or a listen you cleanly use : llListen Remove()