Wanted: your top 5 ways to improve scripting

Sorry im new to LSL so not sure if this can be done already, ive searched and cant see it

Embeddable SQL statements, mmmm now thats a turn on for me

And not as sexy,
Arrays, IsNumeric (Only thing .NET is good for ), and Select Case

Probably been said a million times..

Arrays.
Arrays.
Arrays.

I don't need notecards.. I have php servers

Arrays. Lists just don't cut it.
Object-Oriented LSL. I don't really care if you go all out, making everything an object, but having to call llListLength() instead of my_list.length is pretty stupid... And if you're not willing to do that:
A C#/.NET IL Library for LSL functions. Let us use our own languages. VB/C#/J#/ANYTHING that compiles to .NET IL will be able to use this library. This also eliminates some gripes about replacing LSL with Python, etc.
Blocking calls. Some things would just be easier to handle syncronously, such as notecard reading. The dataserver is fast enough that it the small slowdown could be justifiable to some.
Better intra-grid communication. Self-explanitory.

I don't know if Linden's are keeping up with this thread, but;

1: Make scripting a "certified" vocation. A scripter would need to demonstrate proficiency and take X hours a month of continuing education. These certified scripters would have their scripts UUID entered into a database that could be accessed from the 'About Land' window. Land owners could allow "No Scripts", "All Scripts", or "Certified Scripts".

This would allow novices to build scripts and sell them, but also allow landowners to reject potentially lag inducing scripts. And buyers would probably purchase certified scripts to avoid the possibility of having their items turned off by land-owners.

2: LL needs to create scripting standards. A scripter (or anyone) could take thier item to a "test" station to see how much 'lag/delay/server load' it induces. A script would get a rating of 1-100 as it applies to a 512m2 piece of land. No responsible land owner would go above 100 'script units' fo every 512m2 piece of land they own on a sim. "script units" could be viewed in the edit window for ANYONE to see.

Textures ned to be rated too, but that is another thread.

I got my own agenda of course. So rather than try to endorse selected items from those who've already made suggestions, I'll just list my own:

1. A bigger scripting footprint. Not dramatically, but....come on, the C64 had 64K, and the CP/M machines that predated it could be expanded to 64K some years prior to the arrival of the C64.If some of you don't know what I'm talking about, its because I'm referencing tech thats nearly 30 years old.

2. Better intersim comms. The predominance of physical functions in lsl that are useless for anything but vehicles is indicative of the original commitment to vehicles in SL. Yet vehicles are only marginally usefull in spite of this richness and all that it implies, because vehicles (especially if they carry any passengers), become unstable at sim edges. C'mon, guys, admit its a problem, face it head on, and fix it.

3. Writable notecards. Without persistent memory (read mass storage), whats the point of programming at all? If you are tempted to say vehicles, see #2 above. I too have a php server I could use (several in fact), but I tend to shy away from elitist solutions.

4. Scriptable cameras. In a world where people can fly, its absurd you cant put a camera on an object and send it somewhere unattended to take photographs. Sure it might cause a few social problems - but such problems are a part of life. Should I rip out my eyes to prevent myself from seeing anything objectionable? I think not. A decent analogue of real optics would be nice, but I'd settle for a flexible, scripted camera.

5. A truly usefull map/navigation API with support for both teleport of avs and relocation of objects to the destination.

Thats my five bucks worth - off to investigate why I cant log in.

Hmmm this is gonna be easy...

1. llHTTPRequestExt
- the only thing I need to implement SOAP is the ability to set a custom HTTP header. Give us the option to pass in a list of strings or some such to set the headers

2. IM between objects - others have mentioned this. I have nothing to add.

3. Saving to notecards - ditto

4. llAllowObjectGive() and llGiveObjectInventory() - let me give an inventory item to another object

5. llDownloadScript, llDownloadNotecard - I give you the same parameters as http request, a few seconds later you give me (either the object or the owner depending on a bit switch) the result as either a notecard or a script.

Ok, I lied... I got one more...

6. Give me a way to persist a whole object as a document outside of SL, and upload it back in. Scripts, textures, other objects, notecards, positions, links, the whole kit and kaboodle.

Then give me an offline editor.

1- llString2NotecardLine(notecard, string, integer);
2- Allow llGetLandOwnerAt() to return group name.
3- llSetLandParcelName(string); and llSetLandParcelDesc(string);
4- llSetLandSalePrice(key, integer);
5- llGetLandParcelPrice(vector, integer);

a script-only option for prim type: puppet

puppets use sim-side resources to manage an avatar. We'd need new script commands to load shapes and clothes, and a way to get the key of the puppet so we can do all the animations and stuff - the sim should automatically accept any requests for control.

Eventually we might even add a fun function to allow the script to change the focus location for the eyes...

Of course, this prim type would consume far more resources than a regular prim - and its parcel prim cost should reflect this. I don't know what the appropriate count should be, but it feels like it should be in the 200-300 prim count range economically to parcel owners - I imagine the sim cost of simulating a partial client is going to be somewhere between 300 and 500 prims, however...

Give me this and watch what I build...

We have llSetTimerEvent and llSleep
I'd like to add a specialized timer event I call:
integer llWait( float seconds )
and
llCancelWait( integer wait_number )

Many times I want an easy to write delay that:
A) is cancellable with llCancelWait()
B) will allow subsequent scripts and events to run during the timeframe of it's delay
C) just runs once
D) is easy to add (this could be done with timers but doing it that way complicates matters --- especially when more than one timeframe is needed)

I'd predict that a maximum number of waiting code segments would be necessary
with a run time error on "Too Many Waits" appearing if the rule is broken

The waiting code would be executed asap after the waiting period has passed.

I have no idea whether these would be my top 5 without thinking about it for a bit longer, but here are some that I would like to see:

1) Larger (dynamic) script memory footprint. 32k, 64k, separate code and data sizes, library functions using private stack space, etc.
2) Better direct object<->object private communications. Basically, like linkmessages, but with keys instead of link numbers and would work grid-wide.
3) A user database system. Basically, give users the ability to do simple key/value data tables, but stored in a SQL database. Here's a rundown of functions:

llDBMakeTable("MyTable",permissions);
llDBDropTable("MyTable";
iHandle = llDBOpenTable(kOwner,"MyTable"; // allows for shared tables
llDBPutRecord(iHandle,"key","data";
iQueryID = llDBGetRecord(iHandle,"key"; // Calls dataserver event
llDBDeleteRecord(iHandle,"key";
iQueryID = llDBGetRecordIndex(iHandle,iRecordNum);
iQueryID = llDBGetFirstRecord(iHandle);
iQueryID = llDBGetLastRecord(iHandle);
iQueryID = llDBGetNextRecord(iHandle);
iQueryID = llDBGetPreviousRecord(iHandle);

It doesn't have to be part of the asset cluster, just on a separate database cluster.

4) Compiler optimizations.
5) Switch/Case statement.

There are quite a few more, I am sure, but those come to mind just spending 5 minutes thinking about it.

I've asked LL for an update on what their plans are with regards to some of the key ideas mentioned in this topic. You can read their response (when it is posted) at this link.

Well it's only been 2.5 years since this thread was originally made, but i'd still like to put in a voice for implementing simple arrays in LSL. Being only able to change part of fixed length data by replace/copy mechanics which at least doubles memory requirements... that's beyond retarded.

Being able to supply link to data (pointers or references) rather than only being able to pass by value... would be quite amazing, too.