Wanted: your top 5 ways to improve scripting

Auto-completion/code hints (pop-up suggest menu), external editor usable in windowed mode.

^^

Top on my list is two more arguments to llStartAnimation.

Let me specify an offset and a vector, so it becomes possible to adjust for an avatar that's a bit smaller or larger than average without having to give up and create a separate scripted object and ask the user to sit on it.

Rotating or repositioning the animation should NOT change the facing of the agent. This is just for things like tweaking animations that just don't work right on big or small avatars.

Second I'd like another pseudo-state like default. This would be client-side code. Client-side code couldn't run anything that requires database access, but it should be able to do things like change Omega on attached prims, llParticleSystem params, and so on.

Communication would be through something similar to link messages.

Third, even if you can't create notecards from scripts, I'd like to be able to create them from the object editor. And search-replace would be beaut.

Fourth, if not arrays, an efficient llReplaceListElement that modified the list in place instead of copying it.

Fifth, conditional expressions. llOwnerSay("Your foo flag is " + (fooflag ? "on" : "off") keeps trying to come out of my fingers.

Finally, ignore anything anyone says about removing {} or ; or anything like that from the language. Redundancy is important... but having a function to reformat the script so you could see what the {} think they are would be great.

I use my external editor in windowed mode all the time. What are you talking about?

Okay, after programming in SL for a few months, I have boiled my want list for programming down to one major want. Other things would be nice, but there is one thing I really really want. I want a better way to communicate with outside computers from objects inside SL. If people could do some of their processing outside of SL, the memory, communication, and processor speed would be much less of a restraint on bigger projects. If I can get use out of the processing power of a server I own to help power a project done in SL, there would be so much more efficiency to the things I could possibly attempt in SL. I could run an insanely complicated script on a small peice of land without ever effecting neighbors, not to mention I wouldn't be at the mercy of my neighbors or the fact that your servers have to take care of a 3-D world as well. This one way communication is very limiting.

1) LSL really needs to become object-orientated, the current design just doesn't make sense given the environment it's run in. We also need more access and communication between scripts within the same objects, objects in the same linkset and objects with the same creator and/or owner.

You'd need ways to reference parents and the script itself.

You could even do this with something as annoying as the VB set statement, eg.

object foo = parent;

foo.stretch.x = 10;
foo.colour = <1,1,1>;
foo.script1.var1 = "hello world";
llSay((string)foo.script2.function1("stuff");
foo.rezcopy(llGetPos()+<1,1,1>,<0,0,0>,ZERO_ROTATION,etc);

2) Created objects need to get a handle to their parent, if nothing else this would allow things like listens to have more restrictive filtering, improving both security and sim lag

3) llRezObject() should return the key of the child rather than having to capture it in an object_rez event in a completely separate script with no sensible way for that script to know what's going on.

4) Option for functions to be by value or by reference

5) Ability to create more complex datatypes (eg. struct in C or type in VB)

This is my first time to run into this thread and I really don't have the time and patience to read everything everyone has posted so far. I have something I would like to suggest for the time being.

When you choose an event call from the drop-down menu have it automatically add in the predefined declared parameters. For example:

Instead of inserting "listen" insert "listen(integer channel, string name, key id, string message)" as standard line. There is no reason for people change these standards UNLESS neccessary. Most of the time it is not neccessary to do so. Plus it helps keep things consistent through the majority of example scripts.

Here are my five things and it was hard to narrow to 5. First I just want to say that LL will eventually have to create a more expandable object oriented laguage (which this is not at all, regaurdless of what they say), especially if they are ever to reach it's potential. Right now most likely being wroked on in the background is a way to lease servers to other businesses to make the grid more expandable because LL will not be able to handle all of the growth. No matter how young the company is they need to learn how to manage growth and this is the option they will choose. But this will never be with the current script language. So there will probably be some parallel language in the future. That said:

My top 5 things I want added to the current language:

5) Ability to change clothes and appearance via script:
______________________________________________
I haven't thought this through, you figure out the details, I will learn how to use it after you do.

4) llDropFromAvatar():
______________________
I want to be able to rez objects that atatch and detach from my ave on command. However the current llDetachFromAvatar() command detaches copies of the items into your inv which add much clutter. I would like to just drop them into the grid so that my script can delet them. This could be used to help accomplish #5

3) Script and Notecard Links
__________________________
Links to script and notcards like other have suggested so that editing one file will effect multiple objects.

2) Switch statments
___________________
As others have suggest, also allow the break to break out of any loop or control statement

1) **** llDamageDetected() ****
_________________________________
A way for us to handle damage delivered to combat systems, robots, breakable things, etc, in any way that we chose, taking into account the intended damage of a weapon's ammo. This will allow combat systems to play well with regular weapons that aren't made specifically for the system. You could limit damage that weapons do to you object with a simple if statement like

if (llDamageDetected(0) > 50)
{
  damage = 50;
}

else damage = llDamageDetected(0)

This way we could allow other weapons to cause thier intended damage to our objects up to a specific point, or increase the damage taken if we want to. (i.e. if shields are up, the device could take half damage from any weapon, and when shields are down double damage.) This could be very rewarding and I hope it gets considered

1) Switch/Case Statements
2) Ability to Write Notecards
3) Ability to create protected code libraries. Either ability to make procedure calls across scripts or ability to protect part of the code in a single script. Example: I want to create a library to make string localization easy. But data_server() is too slow and doesn't work in a retrieve resource string architecture, since this would cause 2 delays. One to load from a notecard and 2 to pass from the resource script to the main script.
4) Array Support

1) simple arrays, even fixed length will do,
2) a pushed(vector impulse, vector rotational, key pusher) event,
3) llDie() working in attachments,
4) access to avatar appearance through scripts (clothes' texture and color, body parameters, etc),
5) working RPC, even if it is limited to a single registered-by-hand, LL-approved-and-verified domain, pretty please with a sugar cane.

I like that idea, but it don't think it will go though because of it's retalitory nature. Linden's motto when it comes to abuse is "2 wrongs don't make a right". However it would be good for combat zones, it would be nice to know who pushed me so I could come back and kill them.

I would like a feature that showed who was the last person to cause me damage and the last person to push me. That way I know who to kill when I get back to the combat zone, or who to report when they use an Ave disrupter to make me relog.

We really must do something about ave disrupters, and mega high push that is used to make people relog or crash. For devices so clearly against the TOS there is little to nothing being done about them.

Rotating Object (both client side type and Vehicle Engine type) has a issue that bas been preventing me form making certain types of object.

Cannot specify a rotation of say once ever 1 seconds around the Z axis, then an -independant- roation around the X Axis. Currently when you give each axis a rotation value, it appears to sum them together, and then rotate the object based on the sum/direction of the X and Z amounts.

It would be usefull to be able to rotate objects around each axis independently of the other axis'.

[Edit 9-21-05]

Have found a work around for this, but the stability of it is uncertain. Objects i've used the work around on have lasted in service for almost 3 days at this point.

Heres a biggie,
not having to script together little 10 second blips of music., instead, we should be able to upload media files, of any length, paying generally 1-2l per second, and if you say, "well the 10 second limit is to prevent that", then your not really doing a good job preventing it. so, please just save us the hassle of having to make a wav and chunking it into 10 second blips then uploading and scripting it back together....

hinges just need to be made more durable so they dont just fly off when you use them on a car, makes for a more realistic experience.

hmm... oh yeah... please activate those unusable script tags, cant rember the specifics but i made a chart and its annoying when i look at it , have nothing there and cant rember waht it does, not knowing its unusable, or not in effect.

more ability to put doors on vehicles... it'l be a while before this happens..

and last but not least,, MORE PRIMS ON VEHICLES WITH PHYSICS!!!lol... still, i'm being serious.. its like 31 right now and its incredibly annoying.

Ok I heard there was a teleport function but it was broken so now all there is is the sit hack. I was wondering if it would be possible to make a teleport function using the sit hack but with out the required sit permision that way you could just walk in to an area and teleport. You could make this a detect area and have it be limited so people don't go crazy and make sim wide areas and are teleporting every one.

something like: llTeleport(vector offset, float range)

1. Documentation.
2. Hierarchical states.
3. TBD
4. TBD
5. TBD

Since the language uses C syntax, and there's roughly a billion C-like scripting languages out there, I vote to pick one and go for it. Javascript would be my choice because it has a good simple template-based object model that's well suited to handling the relationships between objects in SL.

Most of the "reference" llGet*/llSet* functions could be eliminated, by moving to an object-object equivalence with appropriate serach functions (eg, byname). For example:

llGetInventoryCreator(name) ==> object.inventory.byname(name).creator
llGetCreator() ==> object.creator
llSitTarget(offset, rotation) ==> object.sit_target.offset = offset, object.sit_target.rotation = rotation
llAvatarOnSitTarget() ==> object.sit_target.key
llGetLinkKey(integer l) ==> object.link[l].key
llSetPos(vector pos) ==> object.position = pos
llGetObjectName() ==> object.name
llGetDetectedName(i) ==> object.detected.name
llGetInventoryName(type, index) ==> object.inventory.type[index].name

From: someone

2) Created objects need to get a handle to their parent, if nothing else this would allow things like listens to have more restrictive filtering, improving both security and sim lag

object.rezzer

From: someone

3) llRezObject() should return the key of the child rather than having to capture it in an object_rez event in a completely separate script with no sensible way for that script to know what's going on.

Actually, you can capture it in the same script.

llRezObject(name,pos,rot,...) ==> object.inventory.byname(name).rez(pos,rot,...)

This would let you avoid the name lookup if you already had the index.

object.inventory[index].rez(pos,rot,...)

This would return an object. Since Javascript objects are really untyped associative arrays then the object could start out as simply containing a token for the event, and then have the rest of the members filled in as it gets rezzed.

Your points 4 and 5 would just fall right out...

Something like this would be great for simulating non-linear space (like, say, the house in Heinlein's "He Built a Crooked House", creating stepping disks, and so on.

There's no point in making it do its own detecting, you can use the existing detect functions and make this like llSetPos()...:

llTeleport(key agent, vector pos, rotation rot);

Alternatively, you could make the function target-based. You'd need the key/UUID of an object in the same sim that would call:

llTeleportTarget(vector offset, rotation rot);

Then:

llTeleport(key agent, key target);

So your code could look like:

key target = NULL_KEY;
key root = NULL_KEY;
integer disks_left = 6;
integer control_chan;
integer controller;
string DISK = "Stepping Disk";

default
{
    state_entry()
    {
        llTeleportTarget(<0,0,0.1>,ZERO_ROTATION);
    }

    on_rez(integer param)
    {
        if(param == 0)
        {
            root = llGetKey();
            control_chan = (integer)(llFrand(900000)+100000);
            llWhisper(0, "Starting a new "+DISK+" loop, you have " + ((integer)disks_left-1) + " disks left in this stack");
            state waiting;
        }
        else
        {
            control_chan = param;
            controller = llListen(control_chan, "", NULL_KEY, "");
        }
    }

    listen(integer chan, string name, key id, string msg)
    {
        llListenRemove(controller);
        list l = llCSV2List(msg);
        disks_left = llList2Integer(l, 0);
        root = llList2Key(l, 1);
        if(disks_left == 0)
            target = root;
        state waiting;
    }
}

state waiting
{
    state_entry()
    {
        if(target == NULL_KEY)
            llSetText("Touch to set this disk in place",<1,0,0>,1);
        else
            llSetText("Touch to teleport",<0,1,0>,1);
    }

    touch(integer num)
    {
        if(target == NULL_KEY)
            state creating;
        else
        {
             integer i;

             for(i = 0; i < num; i++)
                 llTeleport(llDetectedKey(i), target);
         }
    }
}

state creating
{
    state_entry()
    {
        llSetText("", ZERO_VECTOR, 0);
        llRezObject(DISK, llGetPos() + <0,0,0.1>, ZERO_VECTOR, ZERO_ROTATION, control_chan);
    }

    object_rez(key id)
    {
        target = id;
        string thing = lKey2name(id);
        llSay(control_chan,llList2CSV([disks_left - 1, root]));
        llGiveInventory(id,thing);
        string next = "next";
        if(disks_left <= 1) next = "last";
        llWhisper(0, "Take this "+thing+" to the "+next+" point in the ring.");

        state waiting;
    }
}

Mine are mostly word processor-style convenience options but nevermind.
1. Switch/Case
2. Find/replace/replace all
3. Save script to hard disk as txt/new file format (creator only)
4. Load script from hard disk (maybe lsl/sls file format?)
5. A reset button that tells you when the object has been reset (like in the save box where it says "save complete", etc., it could say, "reset complete" or some other similar thing.

I also think that it would be better if LSL was C++ based but thats just an opinion and I don't mind at the moment.

"You silly twisted boy" -- Moriarty.

At least give us JS-style objects. They'd do for structures, arrays, everything... make lists lists of objects, which they almost already are, and an extra "object" type.

object o = llList2Object([ "a", 3, <0,0,1>]);

llOwnerSay((string)o[0]) ==> "a"
llOwnerSay((string)o[1]) ==> "3"
llOwnerSay((string)o[2]) ==> "<0,0,1>"

The object is an associative array, so o[0] and o.0 and o["0"] are all the same thing. Though the compiler doesn't have to actually compile the "virtual" conversions...

Also:

o = llList2ObjectTagged(["position",<0,0,0.1>,"rotation",ZERO_ROTATION]);
...
llSitTarget(o.position, o.rotation);

Or:

o.part_start_alpha = 0
o.part_end_alpha = 1
...
llParticleSystemObject(o);

1. I don't know if there is an option for this or not, but when you're updating a lot of scripts in a complex object it's often difficult to focus on some of the prims. How about a way to list the prims in an object (say, by name/type/size to help disambiguate them) and let you shift-select a group of them and drop an updated script in all at once?

2. llStartAnimationOffset(string anim, vector pos, rotation rot); -- Different animations often have different offsets, and if you're trying to transition between one and another you can't just play games with the sit point to make them work together. Add this option to gestures as well.

3. llFilterAnimation(string anim, integer mask); -- This would let you mix and match upper-body and lower-body animations, significantly increasing the flexibility of the animation system. This filter could be applied to a running animation or before the animation is started, so you could (for example) interrupt a seated pose with a typing or waving gesture, or switch the typing animation so it ran "one-handed" when you're holding a weapon. Mask would be something like (ANIM_FILTER_HEAD|ANIM_FILTER_SPINE|ANIM_FILTER_LEFTARM|ANIM_FILTER_RIGHTARM)...

4. llSetTextureSaturation(integer sides, float saturation, float contrast); -- You can tint light textures but not dark ones. If you could adjust the saturation and contrast of the texture you could use this to get a lot more variety in buildings and avatars without adding bunched of laggy textures to download.

5. I'd also really like to know if llList2CSV and llCSV2List are guaranteed inverse operations... and if not, make them so. The CSV format itself is completely invertible, but llList2CSV and llCSV2List don't seem to generate invertible lists... in particular llList2CSV([1,"a",<0,0,1>]) should produce something like '1,a,"<0,0,1>"' rather than implicitly quoting "," inside "<>".

1. Edit Script in external Editor (would write script to temp file, start configurable editor, read back script when editor closes/readback button is pressed)
2. Access to scripts in items in your inventory without having to rez them
3. Script command line where scripters can interactively use the commands that make sense without an object (like Sensors, or Listens to other channels)
4. Ability to monitor the values of variables of a running script for debugging
5. Ability to disable silent failures of all the functions that do that

Small stuff:
6. Multi-line comments
7. Ability to remove all listens on a channel without having to know the handle

Unrealistic, but nice to have stuff:
9. Script Simulator as a separate offline program (to avoid lag or objects flying out of sight or stuff like that)
9. First Class Functions (for that matter a completely Lisp-derived LSL would be nice )

Oh, I was supposed to stop at 5? Well, LSL just has too many flaws for that, especially the environment (editor,...).

I expect this may have come up before, and I'm too late for 1.7 but I'll post anyway:

Object-orientated scripting:
This isn't quite like object-orientated in the usual sense, but rather in a more SL specific sense. We already know what an object is, a primitive or collection of primitives linked together, so what is object orientated scripting then?
Basically objects would have defined in them methods (perhaps just normal functions with the key-word 'public' in front?), these can be called upon by other scripts which are referencing the object, as well as a constructor (perhaps just a function with the key-name 'Constructor'?). A note however is that when creating objects it would use the object's inventory name, so scripts would need to be recompiled into byte code when the object is renamed.

For example, I have a spawn object which creates a bowl of fruit. It does this like so:
FruitBowl bowl1 = new FruitBowl (position);
In this statement the first 'FruitBowl' defines the variable type (a fruit bowl object), bowl1 is the variable name, while new FruitBowl() calls upon any script within the object to create it's variables, returning a reference, while position is a variable passed to the script used for initial set-up.

Now that's I've defined a FruitBowl variable I'd be able to act upon it using pre-defined methods (preceeded by ll - double lowercase L) or methods defined in it's script, such as:
bowl1.eatFruit ("apple";

Directly affecting the object, without the use of restrictive or cumbersome link messages.

Object variable type
Not directly related to the above but in a similar vein. Basically the variable type "Object" would encompass all other variable types (in the same way you can put any type of data into a list, except it would also encorporate lists). In this way a function can be made to accept any data type passed to it, and with a series of appropriate isInteger() functions to test what that data type is then we can do useful things with it, using casting to be extra sure.

List objects in group
An option to list all objects in a linked group, including their link number so you don't have to guess! Also a display which will number each face of an object would be sweet, since after rotating and hacking an object to bits it's hard to work out where some effects will be applied. Similarly an arrow showing where particles will originate.

Simpler dialogues?
Surely dialogues need not be so complex? I mean having to create a listen command and so on seems rather a bit too much, sure a dialogue can simply be created, and if it is clicked it will trigger the dialog () event in it's parent object (pointed to with an object id stored in the dialog box itself).
A lot of the time I find myself removing superfluous listens just out of tidy habbit, but it seems like I shouldn't really have to.

1. Passive (ie. non-polling) method for scripts to pass information to each other, even if this is only within the same sim. (So, something like a llInstantMessage() function and instantmessage() event, as long as scripts remain non-active when waiting for the event, much the same way a linked message is a 'passive' event.) Or, just make llListen() calls on non-zero channels passive. (For that matter, why on earth does waiting on a listen() or timer() even poll (ie. make the script active)? Just wake up the durn script when the event happens, eh.)

2. Permanent long-term storage of some kind. (A function to over-write or append to a notecard in the inventory would be awesome.)

3. Multi-dimensional arrays in a more C-like fashion. (I'd love to do away with strided lists altogether.)

4. Separate "phsics" channels for a given object. In the same way chat on non-zero channels does not interact or interfere with chat on channel zero, I'd like to be able to decide whether a given object interacts physically with other objects, avatars, the ground, gravity, etc., yet still use physics LSL calls to animate it. (I guess you could call this a more selective form of being phantom, too.) Uses? I'd love to make a physical train, elevator, or other object (using physics for a more real-looking effect, and the ability to transport non-sitting avatars) without having to worry about some jerk dropping a nuke next to the thing and blowing it off the sim.

5. Some method for prompting an avatar to sit. Sure, you can prompt the AV to start the sit animation (or any animation for that matter.) But making it look like they're sitting in the right place, or attaching them to a non-physical object so you can move both the object and avatar without using physical movement calls just ain't happening right now.

6. (Yeah, I know they only asked for 5. If (4) above is out of the question: Ability to make llSetPos and llSetRot commands "look" more physical. (ie. ability to, for example, stretch an llSetPos call out over 10 seconds-- with the object being moved appearing to move from the starting point to the end point smoothly over 10 seconds instead of just jumping there, as occurs now... also with the ability to set a lead-in and lead-out "acceleration" so there aren't sudden starts and stops. Heck, this effect ought to be something that could be entirely client-side.) And if you do this, make a llSetPosAndRot function so we can both move and rotate smoothly over a given time.

7. Ability to set 'phantom' attribute on individual prims instead of the whole object. And it would be even more cool if llVolumeDetect would still work on a phantom child-prim linked to a non-phantom root prim.

8. (Because I'm on a roll. And would love this, but would also never expect to ever see it happen.) Optional Vim-like keybindings and functions for the script editor. (like search and replace). Also some method for interacting either with an in-SL or external-to-SL code revision control system would be awesome.

being a newb scripter /builder so far

how about cobbling up an external "simulator" build
tool? Again, users can build to their hearts' content on their
local machines without logging in and using universal SL machine
resources. They pop online to squirt/synch their scripts and
objects. this has the disadvantage of cutting down on
socializing opportunities, but maybe allow IM's only while in 'simulator mode'

this way we can create textures and items and test them on a virtual sim before we pay the fees to upload them only to fin dout somethign tiney is borked on it

i dont like spending my $L and finding the texture is broken or such

This is an excellent idea for many reasons, not least of which if you screw up and crash the sim or grid it won't affect anyone else. Perhaps what they could do is make a cut down client+mini-sim in one separate package, so you can still use SL normally for chat or whatever.

OTOH, it's a bad idea if the rumours about LL wanting to licence the SL server product to other companies are true, as this would be an easy way to get a free server with a little bit of hacking