Talk:LSL3

I'd add the to this the switch/case statement. SInce LSL isn't a run-time scripting language, per se, it should be quite possible to at least allow optimizations for switch(integer) situations and switch(string) would at least allow programming clarity, even if no other optimization was done.

The other proposed changes I listed in the jira also have merit, though perhaps the single most important would be a provision for a common library of functions beyond what LL defines. New functions could be added on a a regular basis after vetting by the community and LL within a cc* namespace. Perhaps a cc.* namespace to make 100% certain of backwards compatability. Saijanai 07:38, 24 February 2008 (PST)

I'm not sure if this has previously been suggested but it would be useful as an add on to dialog menus to be able to request text input from the user though a similar interface perhaps through a function like llGetTextInput would save having to open listeners and essentially break out of the menu to a completely different method of input which is at best a little confusing. I appreciate this would probably need a small addition to the viewer as well, but as a new viewer is under development then perhaps that functionality could be included in preparation. Silky Mesmeriser 09:54, 27 May 2010 (UTC)

Better support for other spoken human languages

Here's a constant in a script for a message in English.

MsgAlreadyGiven = "Not found, perhaps already given out?";

Now, here's the same constant, in French and Italian.

MsgAlreadyGiven = "Pas trouve, peut-etre deja enleve?";
MsgAlreadyGiven = "Non trovato, forse gia dato?";

In French and Italian there, it's wrong, though.

It's wrong because LSL forced me to drop the accents, which creates spelling mistakes, forcing me to look illiterate in a multitude of languages. While that has a certain rakish appeal to it :} if there's another version of LSL, it really needs to be able to handle accents. I know lots of unilingual anglophone programmers will pshaw this idea, but still. Chaz Longstaff 08:25, 24 February 2008

The compiler supports accented characters, the font used by the editor doesn't show them. VWR-3857 -- Strife Onizuka 04:48, 25 February 2008 (PST)

last i checked, characters like ç and ã displayed on the script editor just fine (hell, even stuff like φ, ▅ and ░ show as expected), but when saving it would give an error (often pointing to the wrong point on the script as the source of the error), the solution I found was to use llUnEscapeURL for inputing such characters on the script code (but since it ias afunction, it won't work unles run inside an state), to figure out what is the code to an specific charater, one way would be having a script tel you the escaped version of what it hears and say to it the characters you want the escape code for, then use the returned code on yoru script--TigroSpottystripes Katsu 23:58, 25 February 2008 (PST)

I thought they had that bug fixed ~_~ -- Strife Onizuka 04:42, 26 February 2008 (PST)

Less aggressive/smarter generation of function delays.

Some functions have pointful but painfully long delays attached to them to prevent abuse. But by stalling the script for long periods of time you train people to break the function out into seperate linkmessaged scripts, at which point its alot easier for them to start multiplying them to outright defeat the delay, which creates more load.

I suggest making most of those functions /not/ delay unless they get called twice in a delaylength period of time, in which case the function can silently pause for the remainder of the expected time before carrying on.

Of course it creates situations where otherwise instantaneous functions can be laggy in effect if being called rapidfire with soon-to-be-outdated arguments, but I feel its a much better alternative to what we have now. If its a big enough problem people can load in their own explicit delays. --Elbereth Witte 20:30, 27 June 2009 (UTC)

#DEFINE and #include and #pragma version

1- Sometimes you want to #DEFINE 48k of well-commented code to fit into into a single line you call 33 times with an argument that is a function name (as you can't pass function pointers around), instead of 33 times super-dense nearly identical blocks of code with all the comments removed and only single-letter variable names because it doesn't fit otherwise (believe me, there was no other way). Even if not struggling with the 64k text code limit, it can clarify stuff...

... such as ugly hacks becoming #DEFINE AddOne(v) -~v // having a name for what it does helps A LOT with readability of obscure hacks sprinkled all over 60k files!

2- Imagine the server-side code being the exact same thing with a special line "#" with no code effect, but on viewer side it causes splitting the code into tabs so you can have 30k of library code on one tab and 2k of top-level code you're really editing often on the other. It would clarify. Perhaps make the dividor #include <some name.lsl> and that becomes a tab name.

3- Instead of being bug-for-bug compatible with the past, have "#pragma version 3.5" specify you want all the bug fixes up to 3.5 as you are using a 3.5 specific bug workaround that would be possibly broken in 3.6+. This protects legacy code without having to have new function names(cluttering namespace, kept old functions confuse new coders) or having people copy-paste legacy code with the new checkbox resulting in old workarounds breaking, old removed features being broken, and general user confusion.

Contagious Republic 12:23, 31 March 2011 (PDT)