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)