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)

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.

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