Wanted: your top 5 ways to improve scripting

Let us change state from inside a function, or allow us to return states from a function (maybe mapping them to integers):

integer state_check(integer p)
{
  if(llFrobThing(p) == FROB_FOO) return master;
  if(llFrobThing(p) == FROB_BAR) return slave;
  return default;
}

default
{
  on_rez(integer p)
  {
    integer new_state = state_check(p);
    state new_state;
  }
}

state master
{
}

state slave
{
}

Just one suggestion - an ability for the root prim to manipulate the child prim positions. Preferably relative to one another (in a simplified joint style). This would allow movement of limbs and so on without propagating movement scripts to every prim in an object, and would avoid the need for so much inter-prim communication.

For me personally, having a case statement would be great. PITA writing piles of while/if/for loops to go through different results for things. Would be much nicer, and probably eaiser on lag , to condense this into a CASE type statement.

Just my 2 lindens.

You mentioned object oriented capabilities but said that it was a lot to ask.

No, its not a lot to ask.. the Mono runtime is built to handle object oriented programs, not procedural programs. There are about a million reasons that LSL should go object oriented.

I think that it is actually more work for them to simulate the c-style syntax than it would be for them to make it object-oriented.. all of the LSL functions operate on objects anyway.

I'm sure internally they can do scripting on SL objects in C# RIGHT NOW, they should get that ready and release it for the rest of us.

Maybe I havent read far enough along this thread, but one thing I haven't seen yet that I think would be a great thing to have in LSL is a function to map keys on the keyboard or a game controller as event triggers. I could see a ton of uses for that as far as game and vehicle scripting goes (personally I cant stand using a keyboard for driving, hehe).

Another thing that I'd like that I haven't seen posted yet is more dialog menu options, most notably being able to add a value field to a dialog.

Other than that I'd just be echoing the usually requests; arrays, switch, include, write to notecard, that sort of stuff.

Top Ways to Improve Scripting:

1) Adopt a real scripting language accepted in the market (e.g., ECMA) -- The adoption of SL as a platform could be greatly facilitated by adopting languages people already know how to use for which there's already a large pool of talent.

2) Built in XML / XML query / DOM capabilities -- A lot of the scripts I've seen contain inefficient parsers that read notecards. This is liable to get worse as our scripts reach out to the web. In this day and age, how much time should programmers really spend re-implmenting parsers? Give us a standards based parser in the language.

3) Ability to have shared libraries / scripts -- Without shared libraries and/or scripts and the equivalent of include files we can't really implement any design patterns in SL that would make scripting more efficient and easier to maintain.

4) Ability to develop scripts with offline tools and upload to SL -- Instead of improving in world scripting tools, why not let scripters use the tools we already know and just have SL be able to take them in via some means like remote CVS or Subversion/WEBDAV. That would be a value-add to Linden lab in that they could spend their time on other things. It would be a value add to us so that we can develop code efficiently and really use SL as a platform. Today, SL diminishes our ability to use tools that make us productive.

5) Real storage -- Even if we have to pay for it, real storage would change everything for scripters. It would allow us to use the vital engineering tradeoff of storage for memory, a tool we don't have in our toolbox now and desparately need because of the limited memory SL scripts run in. Imagine the additional innovation if an object could take advantage of group stores of data for sharing between components.

How about when you use the insert drop box in the script editing window it also adds in the example parameters in brackets too.

After 23 pages worth of "top 5 ideas", I wonder whether anyone has learned anything yet ...


It's a matter of manpower at LL, versus a wishlist which grows roughly in proportion to community size, and will continue to do so. Picking any 5 ideas for implementation will accomplish pretty much nothing.

There is only one real solution to this, and that is to open source (at the very least) the dev tools -- the LSL compiler for starters. The community of tool developers can then grow in step with user community growth.

But of course that won't happen because of the prevailing anti-FOSS attitude in LL, plus of course Philip saying that he won't go open-source until he's forced to do so by competition. Sadly, it'll be far too late by then.

Anyway, so much for your top 5 ideas, versus the top 5 thousand ideas people actually want done. Enjoy, whatever is picked. Assuming of course that after being picked, those 5 are actually implemented. Because precedent in this area is not promising, even for ideas in single figures.

I spent a fruitless day yesterday, trying to create a particle script, for a very specific effect. basically, I wanted to set my particle stream, so it was always oriented to the prim, out of which it was coming. Turn the prim, turn the particle stream direction.

Ok, not that difficult, just use the angle start, and angle end, right?

No. Because, it seems that particles are dispatched outwards, along the X and Z co-ordinates, only. I wanted my stream to aim along the Y co-ordinate.

And after much head-scratching, I was clued in by a linden, that it was impossible.

So, my scripting suggestion is to change this. It should not be impossible to aim particles where you want them to go. If I want to aim them along a prim's Y-direction trajectory, I should be able to, without having to resort to DROP, or global co-ordinates.

I want my Y-angle particle stream.

Cobalt, that sounds like a coding bug to me.

And if LL come back with "working as intended, ie. as designed", then it's a design bug. Still a bug.

Either way, it's a silly restriction and deserves to be fixed. I cannot for one minute believe that whoever came up with the particles idea in the first place wanted it to have that arbitrary restriction, given the huge flexibility that they've built into the particles API.

Perhaps a simple code in the script for "No Mod beyond this point" where everything after that marker becomes hidden. This allows for variables to be declared and changed at the beginning of a script while keeping the rest private to the script owner.
I'm not a real scripter but this doesn't seem to hard to implement.


Elsewhere, someone mentions how scripts should need permission to make outbound contact (ie. log chats surrepticiously and email them to the creator). OH YES. I'm more concerned for the people who think opening a casino is a good idea and they get cheap slot machines which send a cut back to the scriptor without telling the owner. I came across a box of vendor packages with a NoMod script which immediately asked for Debit Permissions. Unhuh - ain't gonna happen. If I can't see the script (or unless it's a more reputable vendor), I'm not keen on giving a complete stranger permission to drain my $L.
If $L are going to someone who is -not- the owner (or his group), and who is -not- in direct interaction (touching) the object, the owner should make the call (and, to be fair, if the owner says no to a legitimate 'commission' device, said device should be able to tell that and stop working).

Th point:
If someone walked up to your vendor that could not pay money and paid L$1 less than a product, then what?

the script window desparatly needs a search function. even notepad has a search/ find thing. crtl - C into notepad is such a pain. of all the suggestions here, i consider this the mimimum you can do to improve scripting

1) Increase the inbound HTTP response body to 4097 or 6145 bytes.

2) Double the inbound email body size

3) add llHTTPRequestLimitReached() to return TRUE if a call to llHTTPRequest at that time would have returned NULL_KEY because the 20/200sec throttle limit was reached.

4) add new llHTTPRequestWait(...) that behaves like llHTTPRequest but if the call would normally return NULL_KEY due to throttling, instead just waits until the call can be made (throttle lifts).

5) Some way to communicate between scripts that isn't incerceptable from other scripts, so that moddable scripted items don't need to use large amounts of memory and sim processing time encrypting llMessageLink communications. For example, by targeting a script through it's key, or adding a changed() event so that script additions to inventory can be detected and the scripts deleted, or, better still, remove the need to have 20-30 scripts per object by allowing optional increases in script memory (e.g. llExpandMemory(multiplier) upto some larger limit, like 64K)

I'll take any or all of the prior suggestions =)

I'm gonna add...

1. Support for more audio/video formats (avi, mp3, etc.)
2. Turning the email event into a real event instead of running a timer for it
3. Possible additions tollGetPermissions such as the ability to manipulate user inventory with permissions. There is so much I'd like to do with that.
4. llName2Key
5. Might be a can of worms, but the ability for a script to toggle the "For Sale" checkbox would have made life easier on several occasions.

I would love to see the following:

1. As previously stated, a real teleport function
2. A way for scripted objects to communciate for more than the 96 sq.m., etc. This can be done with the instant message function for object-to-avatar, but what about getting a message relayed back to the object (avatar-to-object), or a way to instant message objects (thus we would need an instant message received event), so we could then have object-to-object, avatar-to-object, etc.
3. Name2Key

Hope that makes sense. If not let me know so I can clarify.

1) Ability to have linked library functions so a function declared once in a script in a main prim could be used by any other script in the object.

2) Writing to notecards or some other larger data storage

3) Arrays (even if only 1D)

4) Ability to get input from any key (for game controls)

5) Client side color and alpha fades to reduce server load ie llSmoothFade(float alpha, float fadespeed)

Erase it all and replace it with C++ or something that can be used anywhere and not just in Second Life. Not only will people be learning a new language, but once they make it big here, they can use that same knowledge in the real world and vise-versa!

Heck, you could probaly end up making a Second Life within SL... within another SL... within.. etc

- Jolan

Jolan,

While I like the C++ idea, it wouldn't work well as everyone would have to remake their scripts (a lot of angry SLers is not good!). Well, maybe what you said was a joke, I can't tell

Nah, if we replace it with any other language I'd say we should do it with Python. Its an interperated language like LSL so there's no need for compilers like with C++, yet its still pretty powerful and flexible like C++. Of course swapping out languages would be a bit of a pain because that means unless you make LSL a legacy langauge you'll have alot of broken content. Not to mension angry scripters that will have to learn a whole new coding language.

In response to the several requests asking for storage space along with those asking for email to be an automatic event, those things are counter productive.

The best use of emails is for an object to send an email to itself with a specially labeled subject line referring to what data is contained within. Then as needed the emails can be specifically grab, data parsed for desired info, changes written to string and email resent back to itself.

Considering the email queue holds 12 emails, at 4kb of data each thats a fair ammount of storage space for MOST operations and you can still use the memory that the script itself can maintain. Just leave enough memory available in the main script so that grabbing the email doesnt cause a stack overflow.

The idea here would be to add functionality. Thats why its uploaded to a bytecode b4 its run. The current virtual machine is a little...... well crappy. And no you cant just say get rid of LSL it needs to stay. Simply put getting rid of LSL puts everyone out of commision and then they need to change over and you run into a ton of problems. LSL is uploaded to a bytecode and then run over the virtual machine which is currently LSL2 Virtual Machine. This basically is a lil blah.

I'd rather see extension of scripting to use other languages in conjunction with LSL or create scripts from other languages on top of it. With it uploading to a bytecode this is doable at least the latter of the 2. The switch to mono should allow them to do a bit more even thru just extending LSL. I wouldnt want them to fully replace it ever. LSL in itself is a bit easier to understand and people should be expected to have to relearn a ton of crap. Lotsa ways to improve scripting. The memory limits hurt a bit but they are constraints to prevent over lagging as well as possible limits of the VM so we'll see . I have a feeling LL will do a good job with extending it one way or another.

While this is a kind of cool way to use email, it's just this type of hoop jumping I'm looking to avoid.

Replace LSL with python or lua