We have moved!

(pardon our dust)

Sunday, August 06, 2006

What would you like to see LL implement in SL?

Akela Talamasca asked me that question. Here's a fuller answer, focused on technical items.

  • Better interobject communications. Right now, the best, most reliable method is llEmail(). Reliable instant messaging for objects, from objects.
  • Talking to your own objects only: /num speaks on a channel. How about \num to speak on a channel, but only objects owned by you can hear it?
  • Revoke permissions! Let me pop up a list of objects that have successfully requested permissions from me, let me see which objects, where they are and what permissions. Allow me to revoke those permissions.
  • A Stop Animations button!
  • LSL hooks into the IM system. I don't really care to have scripts that can access the content of IMs. But I wouldn't mind seeing a hook that fired when a new IM session opened, or an existing one closed. That would at least give me the option to fire off customised busy messages when I had more than 20, 30, 50 IM tabs running.
  • Finer-grained permissions. Most of the permissions at the moment allow everyone or only me. llAllowInventoryDrop(), as an example, is of extraordinarily limited use.
  • Variable chat distance. Either an option to confine chat to a parcel, and/or an estate setting to modify the range of chat. Perhaps more than 20m. Perhaps less. This would need to be indicated somewhere obvious on the chat bar. Imagine a virtual office, built in SL to allow people to collaborate. Imagine two meetings going on in that little office building - with chat ranges at 20m. Plus a discussion or two outside. The crosstalk would be hellish.
  • Scripted avatars. This would really need a window as a sort of a task manager and a Stop all Avatar Scripts button. Let me script my speech, gestures, movement, and rezzing objects from inventory, if need be. Let me cancel all of that at the touch of a button if it gets out of hand.
  • Find my objects! Where did it go? Where did I drop it? Did I accidentally send that object across the sim? Into the air? Into the ground? If I lost it on my own land, I've got virtually no way to retrieve it. If it's spamming me from some other sim, I've got no way to find it. There's a relational database cluster under the hood. Even if my L$ account is billed for the cost of a fat query.
  • A Help button on the UI - The Help menu has 13 options right now, in categories that are not obvious to the user. Either present a few of the most common (Basic Help, Knowledge Base, Live Help) linked off a single Help button (in addition to the menu, of course) or present a window with the help options groups, and explained, so the user can easily find and select the sort of help that they feel they actually need.
  • Collaborative communication is difficult. Allow each Role in the new group tools to have an optional IM channel. Some roles won't need one. In other cases, more targetted IM channels will help reach the right people, without bothering the rest.
  • Persistent data storage! Even if it's limited to (say) one string, one integer, one key, and one float per script or object. Or limited in size to (say) 1K.
I could go on and on. I probably will later.


  1. All of these are good, and I have one more:

    I'd like to see LSL implement a basic "hashtable"/"dictionary"/"associative list" data type. How many scripting problems would that solve? How many scripts could be made more efficient and less CPU-heavy (i.e. less laggy) with the use of these simple data structures known to any first-year computer science student?

  2. Vortex Saito6:14 PM

    I am a scripter and I can get around in it (I made the Quintzee game) and I am not a first year computer science student (I am a civil engineer), but hash tables ?? What are you talking about ?

  3. Think of it as an array or list, but indexed by arbitrary key values of scalar type instead of by integers. A hashtable is one possible implementation of this type of list, allowing values to be retrieved from the list in roughly constant time, as opposed to time proportional to the size of the list. (In computer science jargon, O(1) as opposed to O(n).) Perhaps the terms "dictionary" or "associative list" are more appropriate.

    Such associative lists can be used to hold key/value pairs for easy lookup, and emulate "structures" or "objects" as found in other languages. My friend Salvador Dalgleish, for instance, has a nifty elephant avatar with real-time setcolor based on color names used in chat, and a data type like this would vastly speed up his script's execution...

  4. I implement rudimentary hashing systems using prims or subsidiary storage scripts. Hardly ideal, but occasionally useful.


Note: Only a member of this blog may post a comment.