do you think scripting should be easyer

NO!

Anything easier would be totally useless. When easy people generally mean watered down, which means you have to jump through hoops and make all kinds of contortions to get intermediate/advanced programming done.

In some ways, LSL needs to be broken into maybe 3 different "languages/compilers"...


Easy - Visual Basic, non-typed form of scripting
LSL Current Form
Advanced - C++/Java/Pascal, pointers, classes, etc

(yes, yes, waving hands a lot).

i think 3 tiers is a bit much. 2 tiers would be cool. (on a side note i believe there is a C like language you can use to program your Lego Mindstorm controlers with.) But a tier system won't help people with rotations. Keeping updated documentation on 2+ langauges would confuse people (Is this command for LSL--, LSL or LSL++?). Maybe the solution is just to make an advanced subset of commands for LSL.

If there were to be a more basic language what would it look like and what commands would it have? (Post command lists & interface mockups)

As a long-time C programmer who is only now learning LSL, learning LSL syntax was of course trivial for me. I wish it had more of C's features, such as arrays, pointers, and #includes, but I understand why it does not. For me, the only problem was learning the ll functions.

That, however, does not answer Speel's question, and in fact making LSL more C-like would only complicate learning LSL for non-programmers.

What LSL does need is better documentation. It needs scripting tutorials, and concrete examples. For progammers like myself, these forums are a great way to learn LSL. For a non-programmer, however, the forrums are probably not a great help. The Wiki is a great resource for those who know how to program and have some familiarity with ll functions, but for nonprogrammer newbies, it's also not going to be much help.

What people like Speel need is a place they can go for tutorials on the LSL syntax, and on basic use of the LL functions. That's the best way to make learning LSL easier, IMHO.

The LSL language is very well designed in my opinion. Docs help, but I've found what does exist to be more than suificient... More features = more complexity... As it stand, there is a good balance allowing new users a simplified programming experience while still providing serious developers most of the tools they need.

scripting is already easy. The only part of it that is complex come from it's lack of support for several basic data types, and data structures. . That and missing functions that the sls scripter are incapable of writing. Like llCreatNoteCard. If LL want sls to be easer, ll just need to include more of those wanted functions. And add support for operators, classes, overloading, and including.

I don't think it is possible to simplify sl. If ll did we would end up with some thing like apple script. Witch to be onset I think is a harder, and even more confusing. Because people can read it like english, but it doesn't make any sense to them.

To be onset I think people who cannot program find that it isn't the code they have problems with, as more they do not understand data and or data structures. Or their relations to the priceable of programing. Programing lounges may differ, but the idea behind them stay the same.

If you ask some who doesn't understand how to program to write a script to counter to 100. I would probable end up with a 100 lines of llSay().

Programing is a lunge. It's not anuff to just know the words. They need to under stand the ideas behind the words. to think it can be simplified further is like asking if you can simplify the process of addition or subtraction in math.

The University of Second Life Library in Montara has many scripting examples that people can obtain for free and use to learn how to script in Second Life.

Hank Ramos is right. USL is an invaluable resource. I relied heavily on USL's resources when I first began learning LSL. Not mentioning USL in my response to Speel was a careless omission.

Regarding Speel's question about making LSL "easyer": LSL is about as simple as it can be and still be a useful programming language. I don't know anyone who's become a good programmer by having it spoon fed to them. Good documentation and tutorials are essential, but will only help those willing to put out the effort to learn.

I think LSL could stand to be made easier to use. Like, the 20second email stall should be removed, to point out one example.

As we all know, sending an email through LSL stalls the script for 20 seconds.

Net result: Everyone uses 20+ scripts that communicate via link messages to get around this.

LSL is rife with things like this. I'm sure if we got all the more experienced scripters together we could write volumes about all the hacks/tricks we've used to get around the limitations of LSL.

The other day, a new scripter was asking how the Seburo works. After I started explaining it, I realized how many hoops I had had to jump through to get everything working. This shouldn't be necessary.

But that's just my opinion. I'm told I have a reputation for my willingness to torture LSL to do things that it doesn't want to

In another aspect, LSL could really use a good dose of documentation. How things work, and how they're documented can vary.

For example, llSetAlpha clamps values to [0.1, 1.0], according to the documentation. Recently, llSetAlpha was changed to clamp to [0, 1]. But we can't set alpha to 0 in the build dialog.

Net result: Noone knows what the correct behaviour is.

Viral rezzing is the coolest hack ever.

Francis you nuts??? if we published all of our cool hacks they would FIX THEM. LOL

hmmm i'll chat with you ingame about this sometime...

Interesting thread. If you had to choose a known language as an alternative to LSL, which would it be? I have been dabbling with the idea of a Python engine now and again. Or would you rather time be spent on a LSL3 re-write with suggestions from the users?

Note: These are just some ideas I'm throwing around. No hard plans for anything quite yet.

heh il reply to my own subjext =p well i think the language is pretty straight foward when you look at it but as a beginner like me i think the editor needs some work like for example i would love for it to tell me how the functions work and stuff like that ah maybe im just over my head but thats what i think i think the language is pretty good once you know the ground work

If the language were changed will LSL continue to be supported or will the tons of scripted items in world cease to function? If in the long run it were to help SL i would be all for it. It will most likely put alot of people out of business in world and undoubtedly fill this forum up with people whining about what LL may be smoking. Just look at what happened by changing the forum layout.. imaging if the whole scripting language were changed and broke all existing scripted objects in world? Personally I like LSL and would continue to use it mainly because i have taken the time to learn it, which will NOT benefit me elsewhere. otherwise i wasted a year on a dead language.

I'm fond of C.

They better not break the old scripts.

Gripes:
16k isn't enough for pass by value
lists are hard to work with
dataserver events are a pain

solution for dataserver events:
new event type
timeout(list request)
where "request" would be what exactly was requested and which event it was requested in.
now say you were calling for a line from a notecard. it would pause the script untill the data came back or the timeout was reached where upon the event would exit and a timeout would be added to the front of the event stack. There would also be a function for setting the timeout period.
Same sort of thing could be done with all inputs for scripts from listens to dialogs.

I agree. We still need llWaitForMessage

Xylor

Current LSL code would, of course, continue to be supported.



16k is a pretty rough limitation, agreed. At the same time, its a waste of memory for scripts that do simple things. Taking a closer look at memory allocation for scripts would probably be worthwhile.



Agreed. Runtime type checking so that C-style array manipulators could be used are on my to-do list down the road, once I'm done wacking a few more bugs. I'd like to implement multidimensional arrays while I'm at it; we'll see how it goes.





Hmm yes, useful. We'll see. =)

This is the right answer.

Re: LSL3... yes. An OO layer and ability to do direct inter-script function calls in addition to link messages would be dandy. Also multidimensional arrays that can be accessed directly within syntax, so we can be done with the llList2_ functions.

I don't know whether you would want it strongly typed or not. There are valid arguments for both ways. I will say that direct, in-syntax support for arbitrarily complex hashtables is one thing that makes me enjoy PHP more than Java.

edit: Someone suggested removing the ll prefix on all API calls. DON'T DO THIS. Some of us have built wrappers around API calls that use the same name minus ll.

a thought just crossed my mind; what you could do is make a function called llWaitForDataServer(key queryid, float timeout); It would sit and peek at the event stack for the requested queryid for dataserver events (and remove the event from the stack if found and return it's string). This way you could call...

string nm=llWaitForDataServer(llGetNotecardLine("monkey",4),5.0);

i think if it failes it should return a double EOF (EOF + EOF).

All and all it doesn't sound all that complicated and wouldn't require script re-writes. It's not pretty but it does the job (hack).

One odd advantage of this is you could get dataserver results back in a different order then they were requested or came back in. I'm kind of hard pressed to come up with a good reason besides maybe prioritising results to maybe feed out to a server over XML-RPC. (store the keys and run the llWaitForDataServer() in a different order then they were requested)


I agree, i have enough trouble naming variables and functions i don't want to have to dodge LL functions too.

Don,

I like what you are saying

I'd love to be able to use Ruby instead of LSL, but I suspect it's a little too esoteric for most people.

I would love to have a language-agnostic approach implemented. LSL already runs on a VM, so... if they release the bytecode specs we can write our own compilers and stuff.

Not easier, I think LSL is pretty well designed overall, fitting its purpose of being accessible (loosely typed, simplified syntax, goal related i.e. how do I change colour type functions, readable). However I would disagree for the need for OO, thats at least another level removed from where we are now. We dont have projects/needs that absolutely require OO just yet. First we need to catch up with things typically taken for granted in C, multidimensional list type structure (vector preferably) , aggregates (struct), pointers and references.

Take away the events and LSL is essentially procedural. Given time to mature and for the userbase to learn how to use it properly, the next step then becomes OO, not surprisingyl this is how C++ developed.

ECMAScript has already been proven in an "embedded-like" environment by millions of developers, and is designed to be easy to learn and use for basic purposes, while at the same time providing advanced capabilities to those who seek them.

It's also a waste of memory when we have to create 3 or 4 scripts, and all of the code to do communications between them. This problem grows worse as more complexity is needed. Each extra script that is added to a system requires more and more communications overhead, eventually to the point that the majority of your script code is spent on communications with the linked scripts.

For example, I have a script that would probably fit in 20k of memory, but I had to split it into two scripts, which each consume nearly all of their 16k of memory due to the overhead of the asynchronous communications between them. If I add anything else to the script, I will probably have to re-design it to take three scripts.

What we need is the ability for the compiler to scale memory allocation to the size of the script. I recognize this is probably not simple to implement, but there needs to be some kind of way to expand memory use without the cheap hacky workaround of adding more scripts and asynchronous communications.

If the script-writer could specifiy the code size, with some sort of incentive to choose frugally, we could be on our way to building some really awesome things in SL without spending most of our time on memory work-arounds.

This alone would make me a lifetime member of the Don Linden fan club =)

I cant help thinking that all the stuff that we're asking for already exists in tons of mature languages around the world. Why spend manpower trying to reinvent the wheel? I could be wrong but at a guess it's probably *much* faster to take an existing script engine (Lua, Python, Perl, anything really as long as its already widely used and fairly easy to sandbox), and sandbox it.

There's a few methods to sandbox scripts. Given a little time and motiviation, you could even sandbox C++: filter it to remove all #includes, remove pointers, remove a bit more, and suddenly the potential loopholes are reduced by 98%. Throw the engine into beta for a bit and stop the other loopholes, throw it into prod and get rid of the rest.

For a language such as Lua which was written specifically for use in Game Engine scripting, putting it in a sandbox is easy. By default a Lua script has no access to any library calls at all, cant even print to the screen, then you can expose function calls to it from your program, one by one, according to the functionality you want to provide it.

Add a function to kill any script that exceeds a certain memory usage, put each script in its own thread, and you've already got a decent sandbox languaged after about 8-16 hours work.

You can probably do the same with Python or Perl or Java or anything really. Doesnt matter too much which is chosen, as long as its a fairly robust, mature language with a decent feature set.

Azelda