LSL Functions you would like to see

Heh. I don't post much.

After a few talks with Ben Linden, and going over some code ideas in my head, I figured I'd sound off a few things I've found slightly lacking in LSL (to the best of my knowledge) that would likely majorly help some scripters.

So, here I go. Feel free to comment on others' ideas and post as many of your own as you like. But please, keep flaming to a Fire Code-friendly level. Smoking is optional.

llSetWaypoint(string sim, vector pos)
Set a typical red-line waypoint at the desired position without having to bother with handing the player about fifteen Landmarks and (probably) forcing them to double-click them as well. Might be good to add a new permission line for this argument as well - PERMISSION_WAYPOINT would suffice.

Useage: Sim-wide or inter-sim race tracks utilizing "buoys" of sorts instantly come to mind. I'm sure others and advertising purposes do as well.

llReturnItem(key pest)
Returns desired item of key pest, to the item's owner, from land you own. No frills here, that's just what it should do - and after a slight chat with Ben, it seems it wasn't in.

Useage: I don't know about the rest of you, but I personally know many people (myself included!) that rent land from other Residents - be it apartments for the landless, a small lease from a friendly sim owner (which I do), or otherwise. One erksome thing about permissions is the fact that the owner only has access to them and, well - giving them to players that don't own the land could also be bad.

So, through intelligent useage of a call like llReturnItem (if routed through things like llGetOwner to make sure the "pest" item's owner isn't a resident of, let's say, an apartment complex) - renters would be able to remove "trash" items on their leased property that litterers leave behind... without having to bug the complex owner every single time. Of course, such a script would be run within a prim/linked mesh owned by the land owner.

Almost forgot: This would somewhat eliminate the need to set all your prims (irritatingly?) to a specified group. This is an additional plus largely for intra-group grief, just as it is for returning specific items.

llCounter(int type, float range, float refreshRate) (and if necessary, a float for detecting again)
Another very commonly used format of script, counters come in every shape and size imaginable - from simple visitor lists to more complex stuffs like detecting how many objects are in a cookiejar. While by no means difficult to write, a consolidation of this sort of code into a new sensor type would be quite favorable.

Why, you ask? Simply put, I find it slightly difficult to the newbie scripter to have them program the intricate for loops, sensor detection, and list/string comparisons necessary to output just a simple visitor list that counts desired items/players/whatever only once. I also find it slightly laggy if it forces the useage of llSensorRepeat (blessedly, though - llVolumeDetect also does the job). Therefore, I'm suggesting this as a solution both to make coding easier for the newbie or advanced scripter AND far less cumbersome in the Second Life world.

The suggested script, perhaps coupled with llCounterList (or merely the return of a string for the desired item names), would merely set a detector to pick up anything that has not already been detected. When a new item/avatar of desired type comes in range, the script returns a value (perhaps calls the sensor command? ) and Does Stuff (tm), but otherwise remains completely inert to everything else in the field. I doubt this would be an easy task to make into a passive script until a new key flies by - but as far as cutting down unnecessary lag and removing the need to use llVolumeDetect prims over very large areas... this might help in a pinch.

Oh, and for those wondering. float refreshRate would be used to set the amount of time before the sucker dumps the entire list and starts over from scratch. I'm sure you all can think of some intelligent uses of this, including things like average visitors per day.

Oh yes, and while I'm at it, can I have an llCaffeLatte too?

Edit: If necessary, bump this to the Feature Suggestions forum. It just seemed more in-character here.

I would like to see classes enabled.
I would also like to see see a way to pass more information between a reed object and the script that resed it.
I would like to see a way for none linked object to talk together with out using public channels.
I'd like to see a script that can talk directly to a user.
I'd like to see a function that coverts global position to local position, and local position to global position.
I'd like to see ways to change values on a object, but only for specific people. Or at least the transparency of an object.
I'd like llSitTarget to except values after the user is sitting, and have those values take effect before they're standing.
I'd like a command to draw object in player's view. Much like weapons are drawn in most fps games.
I'd like to be able to create my own buttons at the bottom of the screen. Like the unsit button.
I'd like a functions to read and write from the desc field of an object.

From the "LSL" section of my "demands" list.

llGetScriptName -- get the inventory name of the current script
llSetFlags(list flags) - set this object for sale, copyable, etc.
llListenOnce - like llListen, but only calls the listen() event a single time.
llGetTimeT - an LSL function to get time_t from the sim.
list llGetPrimitiveParams() - inverse of llSetPrimitiveParams
string llGetParcelStreamURL(vector pos) -- gets the URL of the stream, returns "" if the URL has been blocked by owner (after that functionality has actually been implemented, of course.)
fix llSetParcelStreamURL -- currently, it doesn't change an already playing stream.
improve llDialog -- at least 6 buttons, please.
outgoing XML-RPC using a standard permissions file on the server as with Flash.

integer llDetectedTouchFace() -- determines which face was touched?
Better yet:
vector llDetectedTouchCoordinates(integer face) -- XY coordinates touched ON the face

- a complete set of functions to return the parcel/simulator usage statistics in About Land > Objects.
- basic XML markup to assemble an image on the client, to basically do what XyText does.

fully scriptable XML UI with fast data path to communicate between scripts on the client and server.

- ative support for multidim arrays

Finish llTakeCamera and llReleaseCamera, to allow for repositioning of camera position and target in realtime
set camera FoV/zoom. (make sure to actually ask for permissions first!)

fully scriptable avatar-as-prim, able to be animated.

the ability to manipulate ground position directly -- (LAND_BRUSH_SIZE_TINY?)

llInventoryCopy -- when we get folders in object contents, it'd be nice to be able to make a vendor that had a folder containing an "about" notecard and a landmark, that copied them into the folder of the script for sale, then sold the folder, removing the two objects afterwards. This would help to save room in potentially very crowded vendors.

llGiveInventoryFolder -- give a folder from within inventory.

llInventoryRename -- rename objects in inventory
have the dataserver return everything in someone's Profile.
release LSL bytecode specifications & add a way to upload precompiled binaries.

full RegEx string parsing

let us have something like "integer llDoesTheOwnerHaveThisCallingCard(key id)" so that we can see if the owner has the calling card of the indicated user.

integer llGetLinkNumberTotal() - gets the TOTAL size of the current linkset.

mechanism for a script to get the number of inventory items in a CHILD object's inventory.

vector llSetWaypoint(vector pos) -- set a waypoint to coordinates in global coords.
vector llRegionName2RegionCorner(string name) -- determine the global coords of a sim by name.

Good points. Let me reinforce these two given snippets with current solutions, since they're not quite cumbersome enough, IMO, to require a script yet.

First, I'm not sure llListenOnce would precisely be required since it only requires two more lines to do what you wanted. Namely:

integer g_listener;

default
{
state_entry()
{
g_listener = llListen(0,"","",""); //Example listener
}
listen(integer chan, string name, key id, striing msg)
{
llListenRemove(g_listener); //may be llListenerRemove...
}
}

Additionally, I believe there's a variable in the current time feature of the hovertext clock example script that gets sim time... unless I'm missing something on what you intended?

Also, let me clarify. The biggest reason I see something like llCounter (or similar) as being good scripts to consolidate in LSL is merely because the process is very cumbersome to script in some instances (multiple for loops, for example). While I like the suggestion, if it only needs two additional lines of code to do what you needed, please understand that the idea is readily easy enough to do already, IMHO. If it, on the other hand, requires 10+ additional lines, something far more intricate to create, or very complex code above two lines... by all means, share.

And thank you for the responses. So far, better than I expected.

llReturnItem(key pest)
I had this idea also, for the same reason that it would make automatic cleanup bots possible.

llCounter(int type, float range, float refreshRate)
I'm not sure if it's a good idea to start going down the road of having LL spend time imlementing methods of conveinence, while many methods still do not exist which are gating our ability to do things at all.

I'd say as long as something is possible to do now without an ugly hack, it should be put at a low priority for refactoring while other features which are impossible to work-around, or very ugly hacks to work-around are implemented (such as persistent storage, arrays, outbound RPC, etc).

I would like to see classes enabled.
This would require an overhaul of the language. Considering things like a simple indexed array datatype is not present in the language, I don't expect LSL to be reinvented to be OO anytime soon.

I would also like to see see a way to pass more information between a reed object and the script that resed it.
When you rez something, you can establish a reference for communication through the object_rez event handler (you'll recieve the key). from there, you can use that to open up communication with say/shout or email back and forth.

Admittedly, it's not elegant, but it is possible. =)

I would like to see a way for none linked object to talk together with out using public channels.
Have the two objects email each other. The delay makes this troublesome though. We need to keep bugging LL for a way to do this without such a big delay.

I'd like to see a script that can talk directly to a user.
What's wrong with llInstantMessage()?

I'd like to see a function that coverts global position to local position, and local position to global position.
I've seen people write these. You may want to start a new thread specifically about this to query the community. Maybe they're using a look-up table, which admittedly would not be a good solution with how fast things are growing.

I'd like to see ways to change values on a object, but only for specific people. Or at least the transparency of an object.
llSetPrimitiveParams()? Need more detail.

I'd like llSitTarget to except values after the user is sitting, and have those values take effect before they're standing.
I wonder if this would break multi-seat scripts? These days I'd highly suggest not modifying the behavior of existing functions, or it *will* break existing scripts. A new function should be used for any major behavior changes.

I'd like a command to draw object in player's view. Much like weapons are drawn in most fps games.
There's a setting in preferences, under the Options tab, "Show Avatar in Mouselook" which does what I think you're asking for here.

I'd like to be able to create my own buttons at the bottom of the screen. Like the unsit button.
Agreed. This needs to be implemented very carefully though.

I'd like a functions to read and write from the desc field of an object.
Agreed. We need persistent storage.

llSetFlags(list flags) - set this object for sale, copyable, etc.
Great idea. I'd suggest naming it llSetObjectFlags(), to differentiate it from llSetLandFlags(), which is also needed Also we need llGetObjectFlags() and llGetLandFlags().

list llGetPrimitiveParams() - inverse of llSetPrimitiveParams
As long as it's done in a way that prevents people from making xerox machines. Therefore, it'd probably would only work on prims that you own.

improve llDialog -- at least 6 buttons, please.
Six is a good number. This could be a good compromise for those of us who eagarly await a more robust 2d widgets API.

Also a very simple text input requester would be nice (like Javascript's prompt() method)

outgoing XML-RPC using a standard permissions file on the server as with Flash.
If this isn't implemented soon, then persistent storage needs to be.

release LSL bytecode specifications & add a way to upload precompiled binaries.
I'd love to see this; even if it required some form of special developer registration and SDK (as is done with cell phone software dev in many cases).

etc
All the rest are great suggestions which I have nothing more to add to =)

Yes, I'm aware that there's really little reason to add llListenOnce. It would only be for the sake of completeness. We're talking, "well guys, SL runs at 80fps on pretty much the slowest computer anyone has these days, it's so stable, the only crashes that we've heard of in weeks were when someone's computer was actually ON FIRE... nobody's even bothering to post in Feature Suggestions anymore... yeah, let's do that llListenOnce thing!"

time_t is UNIX time -- the number of seconds elapsed since 12:00AM, January 1st, 1970. It's a 32-bit integer and will roll over at 03:14:07AM, January 19th, 2038. Currently, all the LSL time functions MUST reference it to determine their result, but there isn't a direct way to call it. I know a few people who have wished it was available, but no such luck.

This would break my stuff. Better to add an llMoveSitTarget.



I've always imagined that it'd be great if we could render and receive input from a windowed HTML page.



I want inline assembly. I don't need an optimizer. Hand-optimized assembly in the right hands will still beat optimizing compilers. Hand-code assembly where you need speed. Leave the rest unoptomized.

But, my list is:
- Allow script to hook into the buy() event. The pay semantics are such a hack. And it's an inelegant one.
- llAvatarName2Key()
- llBase16toBase64() (Yes, I know we can write this ourselves, and I have, but it's slooow)
- llWrite2Notecard (I think the horse moved)
- llDontCrashMyScriptForNoReason( TRUE );
- llDontBorkOnSimCrossing( TRUE )
- llBehaveJustLikeYouDidInVersion( string versionNumber )
- and other bug fixes....

llMakeScriptPretty()
llMakeProjectDesignPretty(integer working)
==Chris

Yup. Easiest way to implement a solution to llDialog.

We can simulate Catherine's llDetectedTouchCoordinates(integer face) already via mouselook....

------------------------------------------
I'd like:

-- Adding frequency to the sound playing functions.

-- Ability to import a picture into the world via an external server.

-- Real arrays and hashes with direct calling and setting.

-- Direct keystroke access: allows one to (with permissions) detect when a specified keystroke was pressed.

-- To add to the llTakeCamera bit, allow a script (again, with permissions) to lock out the normal camera controls.

-- An eval function: This function treats the argument like a LSL program and executes it returning the return value of the last statement executed.

I just want things one step at a time...

1. Persistent Storage
llList2Notecard
llNotecard2List
...or...
Some kind of inworld database access

2. Ability to draw text on a prim face.

Catherine, there is a very good reason for me suggesting llListenOnce to you the other day.
Actually, I think it should even be the default behavior.
Listeners can lag the crap out of a sim, and most people are not aware of it.
A lot of people even have poorly coded scripts that are adding new listeners with each use, instead of just putting it in state entry.
Something as simple as a voice activated door or lamp should not be allowed to hurt simulator performance.
What I would like:

llDetectedScale(integer i) - obvious, aint it
llAddToLandBanList(key agent or string name) - adds someone to the land ban list
llGetPrims() - returns the number of prims for this object
llDetectedPrims(integer i) - returns the number of prims for the detected object
llDetectedTextures(integer i) - returns the number of textures for the detected object
llDetectedTextureSize(integer i, integer face) - or something like that
Basically I just want to have better and more automated control over what people are doing in my mall or apartment.

HI Francis Chung

object_rez passes an integer. Not a key. It is possible to use as a hack. But ya it's a pain.

llInstantMessage() is only one way. And it's only text.

I've started a thread about converting local to global position. No response yet.

llSetPrimitiveParams() Allows a script to set a value in a primitive. But that value is change for every one. I'd like to be able to change values in primitive for one user. ie. There are two user in a sim. One is inside a small box. So his name is inside person. and another is out side, so i'll call him outside guy. inside person can't see him self because there is a box around him. Outside guy can't see inside person ether. If I put a sensor inside the box. I can user llSetPrimitiveParams() to set the box outer walls transparent. So inside person can see him self. But then outside guy also can see inside the box. I'd like to be able to make the wall transparent for inside person, but not outside guy.
ya not a big deal. But what if I wanted to set up a game like strategy, battle ship.

yes there is a mouse look view. I think it is possible to trigger it in a script. What I'd like to to do is attach object to the camera. I"m talking graphical displays. chrome is an important element used in most games. in Zelda there is a life meter. IN q3a the chromo would be the weapons display, witch show what weapon their using, how much ammo is left, the amount of armor they have, life, top score, and their score. In a poker game the cards in their hand. Wouldn't it be great to be able to display the car speed, gear, engine rpm. Just like they do in any 3d racing game?

[/B]

Have you opened your thread recently?

Kurt,

I don't know what you're talking about? To what are you referring?

Global coordinates can be trivially derived by using llGetRegionCorner() + llGetPos().

Eggy,

Adding llListenOnce is kind of a silly solution to listeners lagging a sim. The solution should be to fix listeners so they don't lag the sim. There's no good reason that adding a listener should lag the sim.

Things i would like to see...
integer llListenOnce so i can be lazy.
llDetectedSize or scale don't matter...
llDetectedPrimTotal
llDetectedTouchFace
llGetLinkNumberTotal
llCompatibilityMode( string versionNumber ) same as llBehaveJustLikeYouDidInVersion; could be useful unlikely to be added.
llAvatarName2Key I want, I want
llGetTimeT so i don't have to think.
llReturnItem(key object) This would require a permission PERMISSION_RETURN_OJECTS as this could otherwise be used to return an owners objects. This should only work for land owners and on prims owned by the script owner. IE so both the land owner and object owner can use the function. Group officers could also accept the permission request as well.

llSetPrimAttibute*(integer flag, X value)
llGetPrimAttibute*(integer flag)
because there are times when you only want to set 1 attribute.
where * would be Rot, Float, Integer, Vector and X is the appropriate type
llInventoryRename
LSL bytecode specs

These should require user to be logged in.
website upload access This would allow you to upload items to your inventory from outside of SL. More importantly it would support any type of inventory (compiled and uncompiled scripts).
xml access to inventory list
website commands for manipulating inventory
https://inventory.secondlife.com/manage?command=emptytrash
https://inventory.secondlife.com/manage?command=move&from=inventory|notecards&to=inventory|trash
https://inventory.secondlife.com/manage?command=getscript&location=inventory|scripts|i'm%20a%20script
basicly i want the ability to make an inventory management program outside of SL and synch it. (better yet make a folder extention for explorer so i can play with it there mohohahaha)


things rumoured to happen:

llGetPrimitiveParams
new flags for llSetPrimitiveParams
more build tool freedom (less tourcher required)

thoughts:
they will never implement a function for converting sim names into global cordinants as that would allow people to brute for island locations. hmm that sounds like an idea...

[/B]

Not really. Simple: Just dont add islands to the LSL-accessable simulator list.

Anything that triggers events will lag a sim. Timers cause massive amounts of lag not because they are timers but simply because they are triggering an event on a regular basis. Ditto for listeners, sensors and collisions, etc.
Listeners are especially nasty because when you talk, everything in a 20m radius that has a listener in it will trigger an event, and you can have up to 64 listeners in a script, while you can only run one timer.
I dont know what goes on behind the scenes when an event is triggered, but I imagine its not really broken.
Perhaps it could be optimized a little. I dont really see what's so computationally intensive in calling an event handler either.

Shameless bump. Keep on talkin'.

Also re, Eggy: Regarding listeners, I do personally have a question - largely because many people have differing opinions on just how pernicious they are. Specifically:

1) Do listeners only page events specific to the desired channel/key/name/message if selected as such, or do they fire off every time a person begins chatting incessantly?

Simply put, do listeners filter in certain ways to save face? I might need to check this myself via seeing if it calls itself "ACTIVE" the moment I speak.

2) Against sensors, which are more painful to a sim, assuming the former? I know I use linked messages these days in bulk.

3) I would like to formally request that there be a one listener/prim (or per script) limitation, simply because of the exponential listener problem. It would also be wise if people would start using the following for their current listener scripts:

integer g_listener //Define the listener integer

default
{

touch_start(integer total_number)
{
if(llDetectedKey() == llGetOwner()
{
 llListenRemove(g_listener)
g_listener = llListen(0,"","",""); //Add desired listener here
llSetTimerEvent(60.0);
}
}
timer()
{
llSetTimerEvent(0.0);
llListenRemove(g_listener)
}
//Etc...

}

Simply put, this starts one (solamente) listener when touched, and shuts the listener off when not in use for over a minute (remember to put llSetTimerEvent(60.0) in the listen call for the desired action!). I would be very happy if more people used this code, because it makes idle listeners obsolete and, conversely, a simple touch isn't so hard to start it again.

Also, is it possible to have a script not detect certain things (ie. if I have a detector with a 96m radius set to one avatar and he doesn't show, does the detector list all things and refute them or just wait until the avatar shows up)? If so, this is why I suggested llCounter - to selectively stop detecting avatars from the event queue to save sim FPS!

This is not correct. Chat in SL is implemented with a sim-wide circular buffer. Each active listener walks the chat buffer to check for matches. So, every listener is individually matched against every single chat message. This is sub optimal. An example of a simple optimization is to use multiple buffers, and insert into the appropriate queue depending on the hash of the chat channel.

In the initial stages of design, it was assumed that there would be a lot of chat, but few listeners. This hasn't turned out to be the case.

How 'bout adding llDWIM()? This would solve a lot of my scripting problems.

Even if they did optimize lesson. There would still be the problem that any one can intercept those message.

I would also like to see some sort of command that would allow one avatar to egsist in the same space as another avatar. collision between two avatars while standing can integer with all kind of animations. If we want to see more interactive aspect in sl. This is some thing that will have to be implemented. UNless people want to have to res an object ever-time they want to hold hands.

Why not just let llAttachToAvatar work with other avatars?

Piggie-back rides, three-legged races, siamese SL twins, attachments for couples, bondage (!), multi-avatar "Avatars" (like Chinese dragons or the two-Av horse), drop-kick animations... with the permissions, of course.

Are we seeing possibilities here?

(Edit: llAvatar2Hinge for a few of the ideas listed, please )

Human pyramids... "Crack the Whip"... an SL trapeze (sp) act... Congo lines...