Wanted: your top 5 ways to improve scripting

1. Increased memory (optionally)

I have 1000s of objects deployed all over the grid, each with about 8-10 scripts in them. I'd estimate 80-90% of the memory and compute requirements of my objects would be unnecessary if a single script could utilize a little more memory if required (2-3x).
The memory allowance for a script is quicky used up by code for even a moderate complexity script. In order to work around this, one has to divide the code into multiple scripts and communicate between then using llMessageLinked. For objects that deal with money and can be owned by others, that communication must be secure.
Hence, every script needs to devote anywhere from 40%-80% of its memory to code dealing with secure comms with other scripts. In addition to this, limited memory means that the variables/data that has to be persitiently stored by the object must be distributed among many scripts and communicated between them.

The result of this is, in my experience, that code that could be written in a single script with, perhaps double or triple the currently memory allowance, needs to be subdivided into 10-15 scripts (i.e. 10-15x the memory consumption of 1 script) and involves alot of compute overhead in encryption & decryption.

I'd propose a llExpandMemory(integer) that takes a multiplier in the range, say 2-5, that increases the memory available to a script upon executing, by the given factor.
This would likely dramatically reduce the load on most sims (keeping in mind there is currently no limit to the memory an object can utilize, as there is no limit to the number of scripts it can contain)

2. Private script-script messaging within a prim

Some of the above problem would be helped if scripts could invoke something like llMessageScript(<script key> to behave like llMessageLinked but only be received by the script identified by the key.

3. llGiveInventory return/event

There is currently no way to know if an attempt to give an inventory item was sucessful. Perhaps a TRUE/FALSE return code would do the trick, or an event if that fits better with the implementation.

4. llName2Key

Many in-world services deploy sensors that cause sim-load in order to harvest avatar key->name pairs and maintain key databases out of SL. A simple addition like this would eliminate this need and ease any transition to the proposed ability to change surnames.

Why report line numbers in the debugger if you don't have them in the editor? That is just moronic. I'm so sure I'm gonna count down 253 lines.

Oh, and more memory, dialog that can use linked messages, more than 255 characters for the rpc data, and number 1 for me = alternative editor ability. having a run/debug environment outside of game for both platforms would be dandy too.

Basically the worse thing about this scripting environment to me are the tools. No line numbers, no debugger, no object versioning. It's like programming for the sinclair all over again...

Some persistant writable storage mechanism, ie a db object that you could create inside an object and write/read to. I suppose writable notecards too, but I'd like db object too.

Oh, and usage charge for scripting, it is to easy for the blingtards and hacker wannabees to bring a sim to it's knees. having cost for all the cpu/gpu cycles might make them thing twice before they leave their 2000 rotating planets, 20 particle fountains, and 100 sensors searching for love going 24/7.

OMG Why isn't this thread closed yet? I know people who have earned degrees durring this thread's life time. Please people for the sake of all that is good in the world, start a new thread!!!

ummmm...but it was dead for a week - until you bumped it

Ok, just adding to the already existing crowd of suggestions - probably a 'me too', but...

1) storage of some kind (files). The ability to read/write notecards would work great.
2) The ability to adjust avatar/clothing sliders via script. For anti-grief reasons, it'd be fine if this could only be done by scripts that are part of objects attached to that avatar.
3) #include
4) case/switch
5) matrices. 2D arrays, really, but the ability to do matrix math on them would be nice.

Not sure if this has anything to do with scripting but its an idea i had before i went to bed. A friend on SL was asking me about my voice and what it sounded like and i understand there is a way to upload sounds and or voices, but the question I have is really on whether or not it would be possible to get it into your inventory and from there place your "voice" onto your profile page like you would your pic. Of course there would be some concerns with a few residents or people about whether or not they would want to place their voice there however, you could also put in big bold red letters or whatever color letters that "IF you choose to place a voice here understand that anything negative that happens because of this can be reported but will not fall under the liability of Lindan Labs or anything affiliated with Lindan Labs including Second Life" Anyway it was just a thought I had Please e-mail me at [email]PiperH._79@hotmail.com[/email] either way I would love to hear anyones opinion on it. And if it is being considered please notify me via e-mail as well. Thanks, Piper

i only have one idea that i think would work great but not sure how hard it would be to implement (thou i would say it is difficult as im sure you would have done it that way when you made the lsl language) but anyway here goes. two functions , 1 to turn events on llEventOn(integer event),and 2 to turn events off llEventOff(integer event).

I Want llSetObjectPrice();



You can always switch your state to a state without the Event and back to a state With the Event conditionally.

yes i could but its can be pain for certain scripts. is why i think it be a good idea.

I'm very new to SL and haven't tried scripting yet (did something like a 30 second overview so far), but... I'd like to see the scripting language be based on a Python syntax rather than Java/C++. Python is infinitely more readable, and easier to learn.

LSL is styled after C, not Java or C++.

And Python syntax is evil. I probably wouldn't be here if LSL did indentation for nesting, it's just too much of a pain to deal with.

Even when you already know the differences between them, if you aren't overly involved with or interested in those languages, they do tend to look somewhat alike.

Which isn't terribly surprising, since the latter two languages are also descendants of C, and share a lot of its syntax.




That's one of the most common objections to the language, really, and as far as I've seen, only comes from people who've already been indoctrinated with the C family's style. Eric Raymond, who had much the same reaction at first, goes on about it a bit.

Personally, I love python's indentation syntax. I find braces far more of a pain to deal with (both typing and reading them) than indentation.


At any rate... Rowan, what you really want is the second phase of Mono to arrive (as do I), so that you can just use Python directly, instead of making LSL more like it. But seeing how the first phase hasn't yet gone live, it could be awhile.

Being a total newbie to LSL, I can't add a whole lot, but I agree with a number of people, some all the way back from the start of the thread, about case/switch/select (I've heard it called different things).

The lack of an object system in LSL is a huge difference.
The major programming languages I've learned, in order: Basic, COBOL, Algol, Fortran, Pascal, Lisp, APL, Forth, C, Snobol, Modula-2, PL/I, PL/M, REXX, Tcl, Postscript, Smalltalk, Perl, Javascript, SQL, Java... as well as variants and minor languages like Neon, Scheme, DBLI, MUF, Applescript, Ratfor, F-script, Spitbol, and Objective C. About the only class of programming languages I haven't worked in are pure functional languages.

There's something worthwhile noting here: of these languages, only Fortran treats indentation as meaningful, and even it doesn't use it for nesting. Well, I guess maybe Snobol counts, but its only control structure is a branch. Anyway, the point is, it's not just Python-versus-C, its Python-versus-every-other-programming-language-I-know.

My objections to Python nesting are twofold. First, I use indentation to help document my code in ways that conflict with Python's standards. Second, I've already been burned by Python scripts silently corrupted by email... the cut-n-paste objection is not merely theoretical.

Line numbers in the edit window. Why bother reporting the line number in the error message when you can't find the !@!@#@! thing in the edit window? I'm guessing the Lindens have some way to use an external editor. I can't imagine they script using that lame editor.

I really don't mind all the limitations LSL has, there is usual a way to get around them and besides, my projects aren't big enough yet to warrent anything more. But for goodness sakes spend some time on that aweful editor or give us a a way to use an external one easily. (and news flash, copy/paste is not easy)

Integrated XMPP support. That means...
.. IMs use XMPP, allowing IMs into game and out
.. Objects can make use of XMPP features, such as private XML storage
.. An XMPP library API from within LSL that not only allows objects to send XMPP msgs but also to listen for them.
.. A unique object id in form of jabber id (JID) for each object, perhaps [email]dbref@regionref.secondlife.com[/email]/vobject

This could even be taken further by creating an XMPP JEP for script interaction, perhaps a modified Remote Command JEP, allowing objects to be completely controlled external to game. You'd need to secure it, maybe via XML digital signatures and have each account be issued certificates with SL as th cert authority.

And (you saw this coming ) I'd be happy to work on this with you,

xri://=Bill.Barnhill
mailto:xmlarchitect@gmail.com
jid:xmlarchitect@gmail.com

Includable Libraries are #1, I'm so #@$%#$ tired of updating 15 different scripts each time I have a small change in one of my scripts, the alternative of passing messages between scripts is just as tedious, especially since you have to parse the message.

How many times do I have to cut and paste a randRange() function!

Seriously, imagine how much more people could accomplish if they would include standard libraries, rather than having to work some cut and past into their code... currently more complex library functions require re-writing the library to fit the need each time which is the worst since you now have 10 slightly different scripts.

Also, I would imagine a market for good libraries since they wouldn't have to be modifyable to use like they are currently. Also, non-scripters currently have to a) learn how to script, or b) rely on freely available scripts for their build. I can imagine a significant number of applications where someone with very little experience scripting could improve their objects by writting a simple script ontop of a library that handles the heavy lifting.

1. #include files
2. inventory control - change() would be executed on any inventory recieved or changed
from any source and giver & object given would be identfiable.
3. arrays
4. switch statement
5. editor additions - find/replace, adjustable font size for edit window

1. Ability to write to notecards is a must -- either append or generate wholly new ones in lieu of actual appending.

2. Object-to-object communications -- objects can already send IM's via key, there's no reason they couldn't be able to listen for them as well.

3. Arrays and classes -- this is a staple of almost every language, we need them.

4. llSetTexture() can grab images from the web -- since textures come from the asset server (which, as I understand it is a web server), I would love to be able to put web images on a prim.

5. HTTP requests -- I dislike the model being discussed, but it's currently better than having nothing.

Those are my Top-5 wants, ordered by how I'd want them implemented.

EDIT: For those wanting the ability to include libraries, let me point out that object-to-object communictions would emulate this almost perfectly, if not preferably. The biggest difference would be instead of having one large file with all your code, you would have many small files with small bits of your code running simultaneously. With #include, if you changed something in your library that affected fifteen different, running scripts across the grid, you'd need to go to each one and restart them all. With O2O communications, you would only need to restart one script.

In a distributed environment like SL, this kind of programming (seems to me) more ideal than #include -- mind you, in a perfect world, I'd like both. However, given the choice, O2O communications would be a preferable first choice since it's inclined toward a model like SL.

1-> Database
2-> Classes & class libraries
3-> http request
4-> Better object2object communication(Something like naming-notify service)
5-> If you implement first four, i will tell you the fifth.

1. Object to object communications. The current system leaves something to be desired, and I frequently work with systems that require communication between unlinked prims.
2. Includes. This would make me very, very happy.
3. Well, that's all my ideas right now, really. I'll edit with more as I get them.

Update, many months later...

1. Search and replace in the editor.
2. Include or call a function from a library script, rather than just using link messages.
3. Shared non-volatile storage (say, for example, property lists on a prim).
4. Collections (eg, associative arrays) that can be passed by reference.
5. Explicit control over animation attributes (priority, speed, and scope).

If an object is attached to an avatar there is no reliable way for a script within that object to attach it somewhere else on the avatar. I found a work-around but at least 10% of the time it doesn't work because the Attach event is so unpredictable since it seems to be inhibited by asset server lag.

The main workaround people have found for sheathing weapons takes up two attachment slots: one for an invisible version of the weapon and one for the visible version. The visibility switches between them to simulate the weapon being "equipped." However this is kludgy and there's no good excuse why LSL shouldn't support moving an object to a different attachment position, and recalling its proper rotation for that position once it gets there (currently, detaching and then attaching to a different position manually still results in the object remaining rotated as it was in the first position : /).

Also, clearly, scripted objects "remember" their variables even after being put into inventory and then back into the world. Where is this memory kept? It would be really awesome if this memory could be "saved" into a little binary "save file" or "preferences file" that the object could then reference to later. Or make it be able to save a state to a notecard or load a state from a notecard, if that would be possible. Something -- anything.

Ability to view the "checksum" of any object, i.e. its total number of bytes that it takes up, and to view this for any object, even those that others are using (with their permission). This would allow more roleplaying to go on, since people could see if something had been modified on a weapon (to ensure fairness in combat). Also would be nice to look at the checksum of ones own objects to distinguish more easily between ones in which some modification has been made.

AND PLEASE, MAKE OUT-BOUND COMMUNICATIONS FROM OBJECTS REQUIRE PERMISSION!!! I cannot emphasize this enough... it is really troubling that an object can "call home" without my permission. Before it sends any IMs to non-owner entities, or HTTP / XML stuff, any object should HAVE to ask for permission to do so. I don't want to accidentally equip some freebie only to later find out that it was recording all my chat and e-mailing it to someone, or that an object was reporting my location to someone, etc. I'm frankly shocked that LSL allows this currently. It really has nothing to do with paranoia and everything to do with privacy. I find this to be much more important than asking for permission to animate ones avatar or to attach.

Lastly, for a scripting language that deals primarily with objects, LSL is ironically non-object-oriented... it would be nice if there could be "soft-linked" groups of objects that are linked "mentally" but not "physically," with objects being able to act (programming-wise) as "objects" (At least to an extent.) This would reduce a ton of lag by cutting a lot of unneccesary channel-chatter and reducing the number of lazy and abusive llListen calls. Really, any greater degree of ability to pass _values_ directly between objects would be welcomed, but I'm sure you already know this since everyone's saying it.

- Gistya Eusebio

PS -- Oh I forgot. Also, please make key-mapping totally scriptable. Vehicles, weapons, and so much more could really use this, and its pretty surprising the control of this aspect is so limited in SL to begin with (FKeys is not enough, things start to use overlapping ones and it gets really annoying; /whatevers are not enough either).

This is very good suggestion also:

Well this may be redundant, but I think the number 1 way to improve scripting for me would be the no-outside-push parcel flag.

Well, that and stop freezing objects when someone right clicks them. This is somewhat more easily detectable so it's not as bad.

I've got so many great ideas for games that involve physical objects. As long as people can undetectably subvert physics, there's little reason to develop them.

Sure I guess you could still make them for people to play for fun (with no prizes for winning), but even that's no fun when someone can get a super high score with a simple push script.

I'd like to see a version of llRezObject that takes a list for the parameter argument instead of an integer so that we can pass multiple parameters while rezing.