LSL Wishlist.. Top 3 JIRAs only..

Similar to Meade's thread on what LL can do to LSL *to enable us* to be more efficient (and despite the tangents there, that's what the thread is about), I'm wondering what people would like for *NEW FUNCTIONALITY* in LSL.

Just the top 3 please, with JIRAs if you have 'em..

Mine:
http://jira.secondlife.com/browse/SVC-1479: New llFunction: like llMoveToTarget but with more damping control.

http://jira.secondlife.com/browse/SVC-2266: add llGetTextureResolution please!

http://jira.secondlife.com/browse/SVC-1224: add llParcelSay, please!

llTraceLine(): for ray casting; SVC-2654. A million uses.

llSetLinkParticleSystem(): Does what you think.

llGetOtherPrimParams( key prim, list params ): Would return prim parameters for a prim not in the script's link set. I keep needing this to help make my devices aware of the environment - I actually do care whether that thing I just collided with was yellow or blue.

[EDIT]llTeleportAgent(): How did I forget this... replace llSetLinkParticleSystem if you must have only three options.

Well how anyone can not say

llTeleport(agent);

--

Multiple timers in one script!

as in

timer variableName = new timer(10);


variableName(){


}


--

A way to fully set and control a prim and it's actions from another script.

Baaaaaad idea! I don't want every griefer in SL teleporting me to his private dungeon somewhere.


You can already fake this ....

integer count;
default
{
state_entry()
{
llSetTimerEvent(5);
}

timer()
{
     //Do stuff every 5 seconds
     if(count%4 == FALSE)
     {
          //Do different stuff every 20 seconds
     }
     ++count;
}

ETA: Besides, this is supposed to be a list of JIRAs.

Well.. Only because we get nagged if we have a favorite idea and don't JIRA it so I figured I'd both ask for favorites and maybe encourage people to JIRA them up if they hadn't yet.

Personally, I think I'd be happier to see any effort to increase LSL functionality diverted into making SL in general actually supply the functionality it's supposed to have already.

And it appears that my own favourite, llGetLinkPrimitiveParams, is now more than a twinkle in LL's eye.

The thought that flew into my head just now - prompted by Seven's thread - was about some sort of "in-world" mass data storage system.

I think Argent has suggested that a number of times in the past, possibly in Meade's thread, too. I'm sure there's a jira for it but am having a hard time tracking it down.

get link prim params

teleport agent

name 2 key

(I'm too lazy to look up jira's, just like LL =) and teleport could easily be limited similar to map destination)

or you could swap out teleport agent for an animation end event, or at least a changed animation state, which I personally think would be more useful)

This one's probably worth a whole thread of it's own..

llTeleport would need a new permissions bit..
- owner gets it granted without a blue popup
- objects owned by the land owner (deeded?) get it granted if it's to the same region
- sitters get it granted automatically if it's to the same region
- sitters get a popup if it's to a different region
- non-owner/non-sitters get a popup
- llTeleports to a different region have the permission revoked once the TP happens ('cept for owner)
- the popup would need to include the destination region name.

/me thinks that's the only way to do it so it's helpful to everybody but griefers.

"File": that's the word I was looking for! Possibly a bit outré.

Ah, yes... with those restrictions it could be quite useful, I agree. I would be very uneasy if you could force a TP on someone.... except for in-region TPs, perhaps. After all, we can do WarpPos "TPs" within a region now without asking permission.

Restrict it to the landowner. Restrict it to one teleport per 30 seconds, with intermediate teleport requests completely ignored.

http://jira.secondlife.com/browse/SVC-1406 - Non-volatile storage for meta-information.
http://jira.secondlife.com/browse/SVC-212 - llTeleportAgent()
http://jira.secondlife.com/browse/SVC-5131 - llSetEffectiveLinkNumber()

oh dear god no... popups? at that point you're no better of than map destination as far as number of clicks... and inter region is where you really need it. please kill me first.

Yeh, the whole argument about popups has been made in the JIRA. llTeleportAgent has to be automatic for landowners, with a timeout period and maybe other safeties like a working cancel that also blocks further requests from that object (maybe via the mute list).

might as well be renamed to llStealSomeoneElsesWork(key prim, list params);

besides how do you extract the color from the uid of a surface texture?

Just give to teleport to their own objects and those of the land owner.

Another one that's just ocurred to me is the slice for boxes, cylinders and er... whatever else uses it. https://jira.secondlife.com/browse/MISC-2847

/me adds "objects owned by the land owner (deeded?) get it granted if it's to the same region" to her previous post.

If there's no pop-ups, it'll end up either being a griefer tool or annoyingly hobbled. IMO, the best way to get LL on board with llTeleport is to look at it from all angles and come up with a plan to show that it will both be mostly-useless to griefers and helpful to non-griefers.

Why "the same region"?

If you can't be repeat-teleported, it's no more useful as a griefing tool cross-region as in the same region.

If you CAN be repeat-teleported, it's MORE useful as a griefing tool within the same region, because the teleport is too quick to cancel.

meh I think it's enough to require interaction, and be limited to landowner/wearer.

I'll second slice, and while they're at it fix prim torture between types

There are too many uses of llTeleportAgent that wouldn't be possible if you couldn't use it from a sensor. If it requires "interaction" it's not much of an improvement over WarpMove and llMapDestination.

Yeah; but we've got that already in the viewer -- the prim is rendered. And I don't, but I do care about the underlying color. Hey, maybe it's not general use, but it's something I need frequently. At the moment I have to chat it. I admit it's not a thoroughly thought out proposal, that's why I haven't JIRAed it.

llUpdateNotecard(line, text) ;

If "line" exceeds current number of lines in card, simply appends new line. If number of lines exceeds some max, function silently fails.

Yes, I know LL's argument about having to create new assets every time a notecard is touched. I don't think that problem is unsolvable.

It would be a simple solution to many needs for nonvolatile storage, as well.