Talk:LSL Useful Function WishList

Useful/Joke Functions

I have been noticing that some of the "feature request" functions are here only as documentation of a funny idea someone had. IMHO these joke functions (and some are really funny, don't get me wrong,) should be organized into a different category/page. That would allow for less clutter and make it more likely that useful suggestions would be seen by the eyes of those who have tha ability to implement them. Does anyone else concur or disagree? Cron Stardust 15:52, 4 March 2007 (PST)

I really really don't like joke functions. I don't think they should be on the wiki at all. It's not that I don't appreciate humor, it's just that I don't want LL wasting their time processing requests for joke functions. If we treat things like a joke, then LL will not take the wiki seriously; the effect will be a loss of influence. Strife Onizuka 21:04, 4 March 2007 (PST)

That was why I suggested a different page/template for them. No-one can prevent them being added, but why have them dilute this space when they can be put in a slightly different category. :D Cron Stardust 21:29, 4 March 2007 (PST)

I'll make up a new modifier-template, it's not a time consuming task. Or maybe, make it a mode of the request template. Strife Onizuka 22:28, 4 March 2007 (PST)

My "llPizza" is nearly both. If we had to remove humor to achieve better focus I'm all for it. However I would welcome the idea of two separate areas. We are talking about a program with an easter egg of "hippos". I think humor is a huge part of Second Life.Blueman Steele

I agree... I just read through all of the requests and there are quite a few jokes and a lot of requests duplicating functions that already exist. Should we clean this up in the hopes that the folks at LL will take a more serious look at the requests that remain?GC Continental

Sad fact is that many of the functions being requested are not jokes but stupid ideals. Maybe we should make a Stupid function category and flag them as such. --Destiny Niles 14:20, 9 July 2008 (PDT)

If you're sure it's stupid, it's okay to just remove it. There's always the history if anyone disagrees with your opinion. JS Uralia 20:08, 12 March 2009 (UTC)

Should llGet... be in the same category as "llG..."

If you look under "G" in the list you will see that they are all llGet... functions. Seeing as how most of the functions starting with llG are llGet functions in LSL then why not separate them completely or in a sub category. In addition should we do this to llSet... functions? --TxMasterG Ping 17:28, 20 June 2007 (PDT)

Links to PJIRA

I am for cleaning some of the functions up as far as duplicate functions go (I don't mind joke requests since some valid changes can start from joking about issues). I do think every function listed should have a feature request on the PJIRA and a link between the two. Is it possible to put something easy in the template to create this connection? I'm just going to add links where I can find them.

I annotated from letters 'A'-'N' and 'T'-'Z' but not the Other (non-function name) category below to which I placed some more proposed enhancements. JS Uralia 19:56, 12 March 2009 (UTC)

Rules for Posting

I am thinking we should add one rule for posting: only functions that can not be implemented in LSL, or would be very difficult to implement in LSL, or would be significantly faster if it was added as a function, should be asked for. This means, don't ask for a function such as llGetOwnerName(), as it is possible to just do llKey2Name(llGetOwner()). However, while it is possible, asking for a SHA1 or SHA2 hash would be reasonable for two reasons: first, it is difficult to write code for them; and second, the speed of SHA in LSL is incredibly slow. Asking for the ability to call "someList[5]" would be acceptable, as there is no way to write a function to do that in LSL. This is only and idea - and I'd like to hear comments on what others think. -Xaviar Czervik 23:35, 22 November 2007 (PST)

backwards-compatible ways to save typing or be more like C or Javascript

(1) compound declarations, "integer i, j;" (2) declaration initialization, "integer i=1;" (3) Brackets for list index access, "l[5]=5;" (4) a pragma which offers synonyms for functions without the "ll" and/or their C or Javascript short common names, if any; (5) double precision floating point; (6) long integers; and Mephistopheles Thalheimer suggests also: (7) function overloads; and (8) classes. JS Uralia 16:19, 11 March 2009 (UTC)

Each one of these would require significant time for development and even more for QA and making sure we didn't break existing scripts. LSL is a crufty and dangerous language. In fact just today we were addressing a bug where some scripts changed behavior because of a change in the compiler flags for the project. If we spend significant time on scripting in SL it will probably be towards implementing a better language and not tacking on extensions to the core language of LSL. - Kelly Linden 22:58, 20 October 2010 (UTC)

1, 5, 6 & 7 are manageable. Don't we already have 2? 3 would require a huge amount of work. 4 I don't know enough about, 8 would be a major rewrite. I agree with Kelly however. It's time to invest in a language that doesn't... -- Strife ^{(talk|contribs)} 04:21, 21 October 2010 (UTC)

lslplus on sourceforge and rotation library bounty

http://lslplus.sourceforge.net/ was just mentioned in Babbage's office hour. Also, I've offered a standing offer of L$5000 for enhancements to the rotation library. JS Uralia 16:46, 11 March 2009 (UTC)

llGetLinkNumberOfSides

Function: integer llGetLinkNumberOfSides( integer link_number );

Returns an integer that is the number of faces (or sides) of the linked prim link_number

• integer link_number – Link number (0: unlinked, 1: root prim, >1: child prims)

This usefull function would be a great to have as an addition to, and to be used with the llGetLinkPrimitiveParams function.

--Misty Wulluf 08:56, 1 April 2010 (UTC)

I believe this is on agni now. - Kelly Linden 22:51, 20 October 2010 (UTC)