LSL "Wish I had known"s

Someone recently asked me to create an LSL tutorial for new scripters.

As part of this tutorial, I want to compile a list of questions and answers that experienced scripters wish they had known when they were still learning.

Anyone have any such things they wish they had known early on in their experience with LSL? (Might there be a better place to ask for this sort of feedback?)

Any responses would be greatly appreciated.

I wish that I had known about creating subscripts and telling them to do things via link messages. That is the first step towards effective scripting.

Mine is that I wish I had known to stay away from rotation math.

There's a "stuff you _can't_ do with LSL sticky" around here somewhere.

I wish someone would describe the syntax and the "norms" for tabs and spaces, etc., better for someone who has had no programming knowledge besides BASIC (line 1250 needs to read END!!!)

A

My first thought on seeing your question was, "I wish I had understood 'states' earlier; how they can be used, their purpose"

...and then, having come from a procedural programming background, I thought, "No, I wish I'd understood asynchronous events earlier as this would have saved me much heartache"

...but having just read Ordinal's reply, I think I too would have to go with "creating subscripts and telling them to do things via link messages."

well, all of the above really

I wish I had known Substrings, Linked Messages and User-Made Events. Those all helped greatly improve my scripting skill. And also the difference between !=,== and = made a big difference too

1st and foremost on the list:

I wish I had known that there was going to be so much sleep I would sacrifice because of damned scripting.

that llSleep is a bloated function.

states, yes lots of states, and examples that are more than a simple door opening script.

that timers still run their tick when the script is disabled. lost 2 hours of work when an object didn't live for the 60 seconds it was supposed to.

and the warpPos script.

that states suck, you have to make shure you clean up all loose ends and then start them right back up again in the next state

and then if you expand into real world you soon find out theres no such thing thing as hard state, just soft ones using variables (as in lua and C)


let me elaborate on this abit more



or

And that reminded me of the one thing I really wish I would have understood in the beginning:

How to use integer tests INSTEAD of state changes.

So far, the three good reasons I've used states:

1. To handle events differently(some of the time it's impossible to 'if' effectively in an event)

2. To enable or disable pie menu options in different states(ex: the pie menu option, pay, or touch.. is only available when the active script state has an event handler for the associated events).

3. When using states help make the code easier to read. (a very complex event procedure is very complex to maintain.)

I wish that I had known that the parameters in the function call did not have to match by name the parameters in any associated event, they only had to match by type, and that you don't declare the type within the function call!

This is an incredibly basic piece of understanding that I think we take for granted, but when I started out with no scripting experience I found it to be a great frustration to understand how things worked, I had a sudden moment of great clarity and elation when someone told me this

States I find very useful when two or more complex event behaviour types are required in one script.

And even if the conditional test is relatively straightforward, sometimes it's just more efficient to use a state. For example, I'd use separate states for conditional blocks of code which are executed frequently but the condition changes infrequently, so that the condition wouldn't need to be evaluated each time through. That is, assuming there isn't too much other code which would be adversely affected by creating a whole new state.

Exactly.

Simple INTEGER switch examples do not do justice to the benefits that 'states' can offer.

I have a product with a complex series of dialog options, and the functionality that is called for some of the buttons is completely divorced from the main code and is subject to its own timers. By farming this code out to state(s) I can:

1) easily decide whether make this functionality avaliable or not, and therefore create different versions of the product using the same core code. The Special Edition has Feature1, whereas Standard Edition doesn't. A simple matter of whether to make a state avaliable or not.

2) Add further development evolutions to the product without the risk of breaking the core code, which has been tested and is stable. Just add a new state and make the dialog button execute the code in it.

3) Code maintenace and bug fixing is more effcient as I can quickly and precisely isolate the whereabouts that changes are needed, or at least where to start looking.

Of course any duplicated code within the various states is promoted to a user-defined function, and the states call that function.

Generally (but with some exceptions) the only duplicated code within the states is the 'on_rez' event, which resets the script.

So, yes, I wish I'd learnt earlier about the many *advantages* that states can offer.

They work for me...

Seems that some have percieved that states are being attacked. Only the misuse of states. Such as I did as a noob to have multiple touch events. A lot of new people still do that and it is pointed out at least once a week in the forum here.

I use states on a regular basis. Had to go back and look but the most I have used so far was 9 different states in one script.

Again, STATE'S ARE COOL!

Misuse of states because I didn't understand integer tests for touches isn't.

I agree with the remarks about the importance of using states well vs. integer controls. Each has its place. Good examples of how to use each would be helpful.

I also wish I had understood better how to program asynchronously using a bunch of scripts that each perform unique functions and communicate vis linked messages. For example, I sometimes use a script just to hold all the various messages and feedback I want to display driven by a MySay function in the other scripts that just send a symbol representing the string. In any project of any complexity, you're going to run into the 16K limit real fast and knowing how to break up the project into smaller pieces (scripts) ahead of time is essential.

I also wish I had understood better the limitations of a language that can only pass parameters by value and does not use pointers. When you're trying to pass fairly long strings or lists that are constantly getting re-copied, you can use up your precious 16K real fast. Advice and hacks about how to minimize memory usage would be helpful.

A good summary or appendix of the various resources available for learning lsl would also be great.

heyas;


some important startup information:


1: listeners are evil.
include how to kill listeners when and where needed. and not to listen to channel 0. and how to use gestures to replace hard-to-remember channel commands.


2: child rotations are fubar.
point to lex neva's explanation and workaround (link in my signature).


3: no, you just CANT write to a notecard.
'nuff said.


4: "inherent" prim properties, and how to get rid of them.
include a StopIt! or Scrubber script.


5: shortcut notations.
like n++; or ON = !ON; or... actually, i dont know any other ones. (if you're talking non-programmer scripting newbies, like me.)


6: that there is a 'jump' or 'goto' command in lsl.
i've seen it before, but i don't remember how it works.


7: general lag-lessening principles.
how to construct scripts responsibly.

yes, I think that's a common beginner mistake, trying to use states for everything. I did that at first. But later it became clear states are really only needed under some circumstances, rather than being the preferred way to write scripts.

I use states religiously, often when they don't even have to be used, because it separates unlike functionality rather than trying to interleave it. It also gives me good opportunity in huds to randomize channels (listens are scrubbed on state changes, so in creating the new listen each time a dialog is spawned and I switch to its handler I can randomize channels easily).

I've come to rely on them for things that just started getting out of hand if I tried to manage them with conditional variables, and also for debugging. In a complicated state doing many if/else switches on different potential behaviors, in order to conclude what went wrong I have to know the state of all variables in the system at the time an undesired behavior occurred. If I have compartmentalized functionality in states, the complexity of the picture I am looking at is orders of magnitude less.

This really shows up the most in the speed at which new functionality can be hooked in as well, and as another benefit how easily components from one script are plunked out and reused in other similarely architected scripts.

I am doing this considerably more often these days, and I would say that if there is one important guide it is "have a well-documented and consistent internal API" (in other words, "do not just use whatever link message format seems appropriate at the time whenever you introduce a new function". I wish that I had appreciated this when first starting to use multiple scripts; it is not too much of an issue when there are only a few things you wish them to do, but expanding a system quickly becomes unmanageable, let alone if it comes to interacting with other people's scripts.

Incidentally, from what I have seen the most popular method seems to be to use the integer parameter as a "channel" to determine which scripts should respond, either by unique integer or using a bitfield (I have heard it explicitly referred to as the channel of a link message). Information as to what should then be done is passed through the string parameter. But that is a rather bare and basic description.

i avoid states if i can, but yes you do have to use them ... sorry i didnt get that far

yes use a state if you need different events for different things, one common thing i use them for is default as a loading state (for options list's html whatever) then move on to a running state for the products main operation

yes use a state if you want to flip on or off operations in a pie menu, this is about the only way to do it

llDialog, well i tend to make my menus super simple so i can recycle the basic functionality, the buttons aye usually defined as i need them tru a (user defined) function "dialog([1,2,3]);" and the dialogs them selves are usually canned in a notecard, 1 per line cause its simple to index and load... all your formatting is done in the llDialog function (newline ect)

is it better than states? it is easier to comprehend for everyone when using states, but your also starting, stopping, starting, and stopping a listener every state change

also its near impossible to be multiuser for public gadgets, ie a rss reader, with multiple feeds, stories, and users

(note: on this one the rss xml data is pre-converted with php to plain text on my webserver)

using states for each website and have multiuser support would be a nightmare, totally random access, xmass tree listeners blinking on and off, user data vs current dialog, does the blue unicorn match the moons mass? aaack!!!

variables and indexing to the rescue, its pretty easy flow control and data management

also "soft variable based states" do not have to be integer switches, you can use any form of variable

cant remember that 0 = loading 1 = running and 2 = save use a string and loading, running, and save

use lists and llListFindList, this is super, 1 if statement all possible clauses and if you learn how to stride a list (ll function or not) all data needed in 1 place, 1 state, minimal code

then if your getting into frameworks, functions, and dynamic input, uograding and maintaining should be no problem if properly commented (cause you start using the same code blocks as you develop them and just outlining flow to get those bocks to work in the order you want)

Yep. Let it be known that infinite sleep loops can lag a sim. Use timers instead.

Per the old wiki:
"Conclusion:
Both these scripts (global variable versus states) perform the same basic function, but one will run more efficiently than the other: Example 1, using states, because it doesn't have to ever check anything. Nothing needs to be compared, and no variables need to have their values set. By using states rather than a variable, the script's logic path is linear--it just does one thing after another. In Example 2, the logic path branches, as the script checks and resets the values of its variable."

No way!!!!! (first let me point out again that I do use states)

States

integer runs = 1;
integer on = TRUE;

default
{
	state_entry()
	{
		if(runs < 100){
			llSetAlpha(1.0, ALL_SIDES);
			runs++;
			state other;
		}
		else
		{
			llOwnerSay((string)llGetTime());
			llSetAlpha(1.0, ALL_SIDES);
		}
	}
	touch_start(integer total_number)
	{
		runs = 1;
		llResetScript();
	}

}
state other
{
	state_entry()
	{
		llSetAlpha(0.0, ALL_SIDES);
		state default;
	}

}

Global Variable

integer runs = 1;
integer on = TRUE;

default
{
	state_entry()
	{
		while(runs < 100){
			if(on == TRUE)
			{
				llSetAlpha(1.0, ALL_SIDES);
				on = FALSE;
				runs++;
			}
			else
			{
				llSetAlpha(0.0, ALL_SIDES);
				on = TRUE;
			}
		}
		llOwnerSay((string)llGetTime());
		llSetAlpha(1.0, ALL_SIDES);
	}
	touch_start(integer total_number)
	{
		runs = 1;
		llResetScript();
	}
}

These return these results with 3 runs each to account for lag variations:

[10:53] States: 9.779517
[10:53] States: 9.802948
[10:53] States: 13.233719
[10:53] Global Variable: 1.759344
[10:53] Global Variable: 1.759748
[10:53] Global Variable: 1.760079

This doesn't particularly surprise me that a "stateful" version takes significantly longer to run because there is considerable overhead involved in a "context switch" some of which have been added over the years (e.g. clearing event queues on state switch).

To beat a drum that I have often, "state" in LSL is poorly named; I read it as "change to another set of active event handlers" which is much closer to the actual effect. The more conventional use of "state" in software is "the collected condition of all active data" is often best handled by global variables. This doesn't mean that all state can be best encoded in a single LSL "state" just that you should see if you can elegantly capture your intent in a single state, particularly if you are new to LSL.

I can see over half that have replyed here have forgot what the word "NEW" means....

....and some are getting off topic to... in another "STATE" of mind

------ With that out of my system ----->

Most helpfull as I can see to learn for NEW scripters, beside what have been mentioned(And forgive me for the posts I simply skipped reading) is the use of IF/ELSE/ELSE IF.

And Listeners might not always be good but usefull to learn from.

The use of and creation of dialogs

Channels

And the litle known and used fact that information can be stored in descriptionfield for later use.

-->> THIS FORUM <<-- is a must for a new scripter.

-Remember guys not all NEW scriptors come with a programmers background. For some its just amazing to make a box rotate....dig deep and look for that first script of yours in SL and tell me it didnt rotate or have SetText in it