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)

I wish you had pinged me after you replied here--I don't have this page on my universal watchlist for some reason. The benefit of removing the low-hanging cruft and danger of LSL far outweighs disenfranchising all those who have learned to use it. The threat of C#, which has a "object" structure full of namespace conflicts with prim objects, has prevented a lot of very low-hanging LSL progress for years. If such changes are not truly backwards compatible, if QA doesn't catch that fact then a roll-out will, and they can be reverted, but I doubt that will be necessary. These are not huge feature additions, and as modular changes or rolled together they should be easy to QA and roll out. If you compare LSL scripter time saved to the amount of time it would take to provide these improvements, are they really still significant? JS Uralia 07:15, 27 October 2010 (UTC)

Define "huge additions"

For me a "huge addition" would be anything that requires A) adding more than 50 lines of code. A huge addition would be something that includes B) changes to existing code in multiple places. With regards to LSL it would be something that involves C) adding more then one object to the compiler tree. With LSO it would be anything that D) requires the addition of a new bytecode. Most of your suggestions violate at least one of these. 3 & 8 violate A, B, C & D. 4, 5 & 6 violate A, B & D. 7 violates A & B. There hasn't been a new LSO bytecode in 6 years (I've tried to get them to add a few but with no success, like an unsigned right-shift operator >>>), so don't count on the likely hood of anything that requires one. #1 is likely the only one that is truly trivial. -- Strife ^{(talk|contribs)} 16:44, 27 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)

4 would be, for example, a token in a LSL comment that would allow the use of "int" for "integer", and functions such as sprintf() from the C standard libraries and Javascript. JS Uralia 07:15, 27 October 2010 (UTC)

In my opinion 1, 2, & 4 are trivial to implement in the compiler or viewer editor. 3, 5, 6 and maybe even 7 could be written in LSL or bytecode and inserted as macros by the compiler or editor. Albeit 5 & 6 might be limited. 3 & 7 could be tricky. Not the most efficient way but, it help out scripters now, leaving room for the additions to be incorporated into LSL itself later. If fact, just implementing a macro markup syntax would allow all of this and much more. Once the macro capability is in place, the residents can implement their own reusable (good time to add simple little includes too) parsing scripts. All this could happen as a script preprocessor at the editor and/or compiler levels, without changing LSL a bit. As a bonus, the macro language could continue to useful with future languages if/when added to SL. - FalconZip Zerbino 21:13, 6 November 2010 (UTC)

Boolean precidence pragma

Thanks everyone. I continue to believe that all of these are well worth it. We need a pragma to switch ||/&& precidence. See [1]. JS Uralia 00:29, 11 December 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)