Wanted: your top 5 ways to improve scripting

Instead of the C++ include format, which just dumps the code into the program, I'd like the java import instead, which allows you to use methods and variables from the code you imported, without physically dumping the code into what you are currently coding (at compile-time).

In the example you post, you assume that the object_rez() event handler gets called even if the rez failed. My assumption is that it doesn't.

Even eiasier ^_^

default
{
    touch_start()
    {
        llRezObject("foo");
        llSetTimerEvent(rezTimeout);
    }
    object_rez()
    {
        llSetTimerEvent(0);
        llSay(0,"Object rezzed successfully.");
    }
    timer()
    {
        llSetTimerEvent(0);
        llSay(0,"Object didn't rez.");
    }
}

However, isn't it already possible to get an object ID and manipulate it that way? If so, then there should be a way to get the keys of the currently selected objects , and once you have that handle, to manipulate them.

Urm, currently no access to LSL docs, so I can't verify.

An object has no idea that you have it selected in edit mode . If you have the key to an object (getting it is possible with a sensor, or manualy getting it), there are ways to manipulate it externally (via script) but they're kinda confusing, one way would be to have the object your trying to manipulate be physical, and have another scripted object act upon it using llPushObject()... This is probobally quite error-prone however, and force/pushing don't work very accurately for objects with a large amount of mass.

==Chris

Oops... pressed 'Send' button twice.

We've looked at a lot of the detailed concrete changes in this thread. I'd like to take a broad big-picture view and look at the language itself.

The SL graphical and MMORPG engine is the best I've ever seen. The dynamic content loading, and the quality of the graphics and physics are staggering.

In parallel, the stunning artistic creativity in the world is evident everywhere one looks.

Still, there is something missing, which could loosely be defined as 'active content', and more precisely as scripting.

Dynamic worlds represent the future of the MMORPG genre. They simplify content generation and allow players to generate the content that they want. But it's not enough that the world looks awesome, it has to live and breathe, and this is where scripting comes in.

Lsl script is a powerful, highly-optimized language based on C. For developers it is fairly easy to pick it up and use it to mold the world.

To enhance content-production, I think we really need to make scripting accessible to non-developers. It's nice to have non-developers ask for our help, but it would be nicer to have some great Active worlds to explore!

To enable the generation of active content by non-devs, I strongly recommend planning to introduce in the medium-term an LSL scripting language based no longer on C but on a high-level scripting language such as vbscript or Python.

Examples of implicit changes in such a migration:
- no requirement to terminate lines with ";"
- drop the case-sensitivity
- replace braces with end-if type block-terminators which are more intuitive to read for non-devs

I understand that this is not something to be done immediately, because there are plenty of higher-priority things, and because introducing loose-typing, for example, increases the demands on the runtime.

However, high-level languages are the future, and the first game to provide both this incredible dynamic content-generation graphics/MMORPG engine and a high-level scripting language easy to use and understand by newbie non-devs is going to take off explosively.

ZHugh

Zhugh:

I have posted elsewhere that some interface for non coders to start codign would be good. A simplified version of the language that built regular LSL script was a suggestion, as well as some wizards to generate the code.

However, please, please do NOT turn LSL into LSBasic. Thanks.

There are GREAT reasons for case sensitivity. If you don't want it use llToUpper

Using ; at the end of a line allows greater FREEDOM in the layout of the code - line breaks don't matter so code can be arranged in a more readable manner (long if and for statements for example)

endif and other block enders are UGLY and LESS readable. Once you know what a { does and a } does then you can pick them out of the code far, far easier than searching for end statements. Brackets actually add a graphical feel to the organization of code which helps a great deal in writing clean, efficient code and is even more helpful in bug testing such code.

Also languages like C and Java ARE high level languages. And there are many, very good reasons why they are written the way they are. And none of those reasons involve making it harder to use or learn.

Gotta agree with Ama here -- there's a reason C's basic syntax has been widely adopted into other languages.

How would you construct a particle system in this proposed LSLBasic? There are routinely 20 parameters in the particle lists, and there's no way you're fitting that on one line. You're gonna make me type a backslash or something every time I want to hit Enter?

The fact is that C, C++, Java and Perl, all of which share some basic syntax rules, make up over 63% of all projects at Sourceforge, compared to 5% combined for VB and JavaScript.

I looked over this again and that wasn't really your point but it's kind of interesting anyway, so I'll leave it in.

I realize I'm biased in that I already know how to program, but I like the fact that any random person can't come into SL and immediately put together complicated scripts.

For one thing, it gives good scripters a skill to market. For another, we have enough trouble with griefers already using 'complicated' C-style syntax.

I think the best thing to encourage people to learn scripting would be a tutorial website. I've learned the basics of more than one language this way, with a few walkthroughs and such.

They could print out the lessons, jump into SL and have at it. I realize classes are offered as well, but trying to explain the intricacies of LSL one line at a time through chat is annoying at best and confusing at worst. Not to mention the fact that it's a lot easier to follow a prominent link to an online tutorial than to schedule time online for a class sometime later today.

Okay, now I'm just rambling. But I am intrigued and may even try to work up a basic intro web page on my own time, as I think it could be really valuable.

Sorry if I come off rude, I'm half-arguing with myself here.

Mark, I don't agree with your premise that scripting should be hard in order to provide job security for scripters. People with the temperment and training of programmers will be able to handle greater complexity and greater levels of abstraction, regardless of the complexity or simplicity of the language.

And as a programmer with a C/C++/Java/Perl background, I ain't 'fraid o' no braces.

I do however share your distaste for BASIC. Python is another matter entirely, though: the syntax is the best compromise between simplicity and flexibility I've seen yet. You could do a heck of a lot worse than Python as a basis for the langauge (and the license for Python is liberal enough that LL could incorporate the real, official Python interpreter into their code). JavaScript/JScript is another surprisingly simple/powerful dynamic language.

Meanwhile, to answer the question that started this thread 'way back when:

1) Better string manipulation, including regexes, and the equivalent of Perl's split(), join(), substr(), s///, and tr///.

2) Arrays, with the equivalent of Perl's push(), pop(), shift(), unshift(), splice(), map(), and grep().

3) Associative arrays (like Perl hashes, or Python dictionaries)

4) Shared modules, or code libraries

5) Exception handling, including user-defined exceptions

6) the ability to do "hidden chat" commands like we use for gestures: e.g., when I type "/myobject do something", it should trigger an event in the script attached to "myobject", and pass "do something" as an argument to the event handler.

I'll condense mine to the top three:

Some kind of data storage (writing to a Notcard or similar).

llSetLocalPos, llSetLocalRot and llSetLocalxxx to only move/rotate/etc. one prim in a linked set (so we can have moving car wheels, books that can open, etc.)

Select/Switch statement.

Well, if we don't have consensus here (and clearly we don't) then lsl C is here to stay. However, I'm going to treat the replies point by point:

> Mark, I don't agree with your premise that scripting should
> be hard in order to provide job security for scripters.

Right

> Python is another matter entirely, though: the syntax is the
> best compromise between simplicity and flexibility I've
> seen yet.

Right again. Python is awesome.

> How would you construct a particle system in this proposed
> LSLBasic? There are routinely 20 parameters in the particle
> lists

MyParticleSystem = new ParticleSystem
MyParticleSystem.color = Red
MyParticleSystem.someVector = <2,5,1>
MyParticleSystem.Go

This is actually a good example of the advantages of OOP over procedural languages such as C, specifically in this case:
- easy to provide suitable defaults for newbies
- and an associated very gentle learning curve

> There are GREAT reasons for case sensitivity.

Not for variable names. Case-sensitivity means you can do the following:

integer Height=5;
integer height=2;

I think we agree that this does not increase clarity and readability? Removing case sensitivity makes life easier for newbies without removing any useful expert functionality.

> Once you know what a { does and a }

Ah, but newbies dont. It's one more thing to learn.

> Also languages like C and Java ARE high level languages

Well, it's all relative innit? Compared to machine code, assembler seems high level. After all, assembler has functions, loops, variables, macros and stuff. It's actually quite powerful, and runs quickly. What more could you possibly need? And then, compared to Rational Rose, Python is code-monkey stuff.

You gotta pick the level that is right for the application.

WOAH there. Thats OOP that your talking about? Yeah thats not part of what you mentioned in your first post. I LOVE OOP languages. And I would love it if LSL was OOP.

Taking away the ; is pointless and way more harmful than good. How hard is it to learn that you must end a statement with ; ? Sentances in most languages end in punctuation. It is a common concept. The punctuation for C,C++, JAVA and LSL is the semi-colon. Its not a big deal and taking it away makes alot of code impossible to read.



And it is easier to learn than endif endwhile endevent end whatever else, which newbies also don't know. And much, much easier to use once you do learn it.

I am fairly sure that it is not relative, that there is a concrete definition that categorizes C,C++,JAVA, BASIC, Python, Rational Rose and more as High Level while assembly is not high level.

An really, enough hijacking of this thread. Start a thread in Scripting or somewhere about how to make LSL more accessable to newbies.

> Taking away the ; is pointless and way more harmful than
> good. How hard is it to learn that you must end a
> statement with ; ?

The problem with semicolons is that if you do:

llSay(0, "Java is actually C++ without pointers"
llSay(0, "albeit with interfaces added";
llSay(0, "And C++ is a derivative of C );
llSay(0, "Java is a derivative of C" );

.. that the syntax errors will be given for line 2, whereas the actual error is on line 1. Newbies take a long time to learn this. I bet you spent a good bit of time the first time you wrote an F77 program trying to work out why you were getting an error on line 50 and eventually finding a missing ; a few lines earlier...

Similary, if you miss out a " in a piece of text, you get the syntax error much later, because the compiler is not line-sensitive. There's an error on line 3 but it wont be trapped till line 4 where it will give an "undeclared variable" error for the variable "Java".



The thread is called "Wanted: your top 5 ways to improve scripting". I think this is an appropriate place.

Just to clarify, I wasn't plugging procedural languages over OOP -- I'm all about OOP.

I was just saying C-STYLE syntax, which you can also find in Java, which is OOP, is the most common and in my mind the best balance of ease and power.

100% in favor of C syntax and OOP. Flash used to have this janky, overly-verbose non-C-like language. Then Macromedia figured out programmers would find it more attractive if it already resembled the language damn near every programmer knows: C. Now it's basically ECMAScript (a.k.a. JavaScript).

Terse syntax is the way to go when you are going to spend a long time coding. Lots of unnecessarily long words and syntactic elements clutter it up. Also redundant crap the compiler can figure out for itself, which is one thing I didn't like about Pascal.

Anyway, here's my new five...

1. BIGGER HEAP
   
2. Search and Search/Replace capabilities in the editor (pleeeease)
   
3. Array hashes
   
4. Direct access to arrays, i.e. myList(4) instead of llList2Vector(myList,4)
   
5. OOP
   

Another feature that could greatly enhance scripting would be default parameter values and function overrides.

I'l love to call llRezObject without a rotation parameter so that the object rezes with it's prior rotation just like it would if you drag-n-dropped it into the world.

The naming convention, or lack thereof, for all the functions and constants are a mess. Now, that can't be changed willy-nilly because it would break old scripts like crazy... BUT, if we can get a total overhaul of the script language, there's no reason there can't be several versions of LSL available to users. Just pick the version number you want to use when you make a new script.

Heres a few new things I want:

llGetRegionCornerOf(string regionName);

llGetRegionNameOf(vector regionCorner);

Some of these have been said but I just want to cast my vote for them

- arrays
- smaller datatypes, byte and bool perhaps, packing things in and out of strings/rotations/whatever is a kludge
- more heap of course
- switch statement
- search/replace in the editor

1. multidimensional arrays
2. multiple timers
3. methods to modify prim attributes (cut, dimple, hollow, material, etc)
4. custom AV animations
5. more environmental information:
- position of the moon (or is it always opposite sun?)
- current light level
- ability to detect sounds played and who played them
- current vertical height relative to ground or object, whichever comes first
- ability to detect edge of world before going off (or a flag to bounce off the edge)
- AV eye, mouth, ear, nose, hand, foot, etc relative positions/rotations

I'd like the last one, for example, so I could script a pair of eye glasses to resize with the AV's head, and reposition with eyes, ears, and nose.

1. Something that can return objects once they're over non-script land.
llSetStatus( RETURN_TO_OWNER_IF_OVER_NO_SCRIPT, TRUE);
or even better
llSetPosIfNoScript( vector pos );
2. Pointers & Passing by reference
3. llWriteNodeCard()
4. llPlayMod() and llPlayMP3()
5. A way to communicate better between objects (like make them able to receive IMs from other objects/people and the Internet)

Not quite scripting, but related - a better in-game editor. emacs please

Regular expressions for llListen(), sensors, etc.

If full regular expressions are too complicated, wildcards would be useful.

To be a bit pedantic, wildcards are a form of regular expression.

(Token computer scientist now signing off.)

I'll see your pedantry and raise you a gratuitious display of code-fu.

I think Carnildo means to distinguish between the simple kind of pattern matching we see for filenames ("foo.*" and full-bore, Perl-style regular expresions (/^foo+\.(?:jpe?g|gif|bmp)$/i).

Apparently some people consider the latter to be less readable. Go figure.

If we do just get basic wildcards (and I'd be happy with either one), I'd at least like a way of making wildcard matches case-insensitive. Perhaps even make that the default.