Second Life Wiki - User contributions [en]

Talk:LlDialog

2016-07-02T21:14:20Z

Pedro Oval: /* Concurreny issue in first code sample (edited) */ More <lsl> tag replacement

== Button Length Issues ==
Telling an end user that the max length of a button label is 24 bytes ... well, not overly helpful. But there is the problem of what what characters translate to how many bytes. Still, is there any way we can give examples of characters?

[[User:Chaz Longstaff|Chaz Longstaff]] 05:18, 27 November 2009 (UTC)

: Can you use a function like this to find long strings? Then the user will not have to guess what button is bad Somebody check my work please, I am sleepy as always.
<source lang="lsl2">integer GetStringBytes(string s) {
list chopped = llParseString2List(llEscapeURL("*" + s), ["%"], []);
return llStringLength((string)chopped) - llGetListLength(chopped) - 1;
}</source>
:--[[User:Cerise Sorbet|Cerise Sorbet]] 10:03, 27 November 2009 (UTC)
:: I was too sleepy. Maybe this time. --[[User:Cerise Sorbet|Cerise Sorbet]] 11:06, 27 November 2009 (UTC)
:: Maybe this one will be more nice to memory? --[[User:Cerise Sorbet|Cerise Sorbet]] 13:03, 27 November 2009 (UTC)
<source lang="lsl2">integer GetStringBytes2(string s) {
s = llEscapeURL(s);
integer i = 0;
integer j;
for (j = llStringLength(s); j > -1; j--)
i += (llGetSubString(s, j, j) == "%");
return llStringLength(s) - i - i;
}</source>
----
Strife, Chaz here. Most ordinary users in SL, and most user documentation in SL, refer to dialog boxes in SL as menus. While that may be as technically inaccurate as referring to a tomato as a vegetable, people don't look for tomatoes in between the apples and bananas at their green grocer (grin), and they are going to come here looking for info on menus, not dialogue boxes. I think we need to at least acknowledge the word menu, even if we do correct them about its usage right away. (I also dislike how people use the word less when they should be using fewer, but that is also just the way it is, sadly :} )[[User:Chaz Longstaff|Chaz Longstaff]] 18:17, 15 July 2008 (PDT)

:Very good point. I'll also keep a lookout for improper uses of "less". -- [[User:Strife Onizuka|Strife Onizuka]] 18:32, 15 July 2008 (PDT)

The Wiki mentions that clicking on a button causes the value to be chatted on the specified channel, but doesn't clarify whether it's simply said(llSay) or shouted(llShout). It does mention that errors will be shouted on the Debug Channel, but I think it's important to clarify this within the Wiki.
--{{User|Deimos Damone}}

:I have reworded the applicable caveat to clarify the functionality. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:49, 15 October 2008 (PDT)

It may be worth including some explicit explanation of the difference between bytes and unicode characters, especially since the inworld error messages somewhat ambiguously talk about characters, when in fact referring to bytes. -- [[User:Tali Rosca|Tali Rosca]] 10:45, 15 October 2008 (PDT)

:Many functions use byte limits and not character limits. I think it would be better to make the word "byte" a link to a (new?) subsection of the [[string]] article where that can be better addressed. It would be inappropriate to duplicate this information on multiple articles, it would end up clogging the articles. That said, I'll try to find the best method for presenting this information; as you point out the current caveat is inadequate and more information is needed. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:49, 15 October 2008 (PDT)

::I agree that the actual explanation shouldn't be here, but a link should be fairly prominent, since this is the most likely place people will run into the difference. [[User:Tali Rosca|Tali Rosca]] 12:03, 15 October 2008 (PDT)

the current suggested function for "safely" truncating button text length is not safe... it can break across a multibyte character -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])

: It says it "can be used to truncate the string without giving an error". Can you produce any errors due to button length or otherwise, when using it? Usually, if LSL in general, and llBase64ToString in particular in this case, finds an incorrect or incomplete UTF-8 character, it will replace that character with a question mark, and no error will be given. Is that not what you see?
: Thanks for fixing the number, by the way. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 14:13, 2 July 2016 (PDT)

== Multiple dialogs tips ==

It may worth mention in tips.

Sending multiple dialogs in a row to one avatar may be inappropriate. In old viewer it creates stack of messages in notification area, which complicates reading other things. In viewer version 2 (as of 16/Sep/2010) newer dialogs replace unanswered dialogs from the same object, so any information and chance to react is lost.

If you need to present more than 12 options, add buttons for browsing option pages (see [[SimpleDialogMenuSystem]]).

If dialogs are not requested by user, but rather are triggered by some events, you may want to either queue further events or discard them until the first dialog will be answered, or at least throttle them. In any case, if you are sending many dialogs, there should be an option to stop them. (Making user mute your object is bad because he may then forget to unmute it when he will want to interact with the object again).

If you just need to report something that does not require an answer, consider using other means of communication. Though, you may still want to send one dialog to draw user's attention.

[[User:Wicked Winslet|Wicked Winslet]] 12:25, 16 September 2010 (UTC)

== Example ==

the first example is very likely to stop working over time with a "too many listens" error in a multi-user environment. Cause: any user that clicks on the object will generate a new listen handle, but only the last one is saved, so only the last one is closed. any user (including the current) that touches the prim before the current user has clicked on a dialog response (or within 60seconds if they do not, or click cancel on the dialog) will cause the current open listen handle to advance, and the previous one will never be closed. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 12:03, 13 January 2013 (PST)
:: I suspect the prim will have died long before that LOL. But you have a point [[User:Omei Qunhua|Omei Qunhua]] 13:47, 13 January 2013 (PST)

:: In fact it would have to be clicked by 65 different users all choosing to ignore the dialog. A subsequent listen using the same filters as a previous is assigned to the same handle. (Thanks Pedro and Innula) [[User:Omei Qunhua|Omei Qunhua]] 10:30, 14 January 2013 (PST)

Also in the first example, the call to llDialog() happens before the listen is created. In my experience it's possible for this to result in a situation where the dialog is shown to the user and, if they click fast enough, the reply is lost. Might it be a good idea to do it the other way round? [[User:Antony Fairport|Antony Fairport]] 05:29, 16 January 2013 (PST)

:: Wow, you type fast! I couldn't even move my mouse onto the dialog window that fast. Anyway I changed it. Example #2 had the same remote possibility of accumulating active listeners, I believe. [[User:Omei Qunhua|Omei Qunhua]] 08:10, 16 January 2013 (PST)

::: Admittedly it's unlikely to be an issue with that actual example but it's possible that a dialog that spawns a dialog that spawns a dialog... (etc) will have someone camping on a button and a reply can get missed. So I was just thinking it might be an idea to encourage starting the listen fist. [[User:Antony Fairport|Antony Fairport]] 08:25, 16 January 2013 (PST)

== Where's order_buttons? ==
Didn't there used to be an example of that very useful helper function, order_buttons(), on this page? Unless there was a particular reason for removing it, I think it would be good to have it back. [[User:Innula Zenovka|Innula Zenovka]] 11:27, 18 February 2013 (PST)
: It's back, a name collision hid it. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 12:11, 18 February 2013 (PST)

== Concurreny issue in first code sample (edited) ==

The first code sample has the following fundamental problem (as can be easily demonstrated): at any point in time there can be '''multiple''' listeners attached because any number of users can click on the prim. But the script sample has only '''one''' global variable to keep track of it. Result: The last user to click on the prim "wins" in the sense that whoever closes the dialog first will remove his listener. All other listeners will remain active.

The obvious mediation is
# either to introduce a more sophisticated listener tracking (and most likely some form of polling in a regular timer event)
# or to keep it simple and introduce a single static listener, omitting the need for a timer event altogether.

I personally opt for the latter. If there are no objections I can make those changes. Proposal:

<source lang="lsl2">
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
state_entry()
{
// Set up a listener for potential llDialog() calls
// it might seem like a waste at this stage, but overall it is way more efficient
// than trying to track listeners on a per-user basis
gListener = llListen(-99, "", NULL_KEY, "");
}

touch_start(integer total_number)
{
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
}
}
</source>

Btw, the same fundamental flaw is present in the tutorial https://wiki.secondlife.com/wiki/Dialog_Menus .

Edit: the second code sample contains the flaw, too

--[[User:LovingAndRejected Resident|LovingAndRejected Resident]] 05:37, 13 November 2013 (PST)

: I'm not seeing where the multiple listens will come from given that the touch event (in the first sample on this page) removes any previous listen. [[User:Antony Fairport|Antony Fairport]] 08:42, 13 November 2013 (PST)
: Agreed. llListenRemove(gListener) will close any pre-existing instance of gListener. Because a dialog box will never self-cancel and we have no way to detect whether a user has clicked "Ignore", it is necessary to include a timer that will remove the listen handle as well.[[User:Rolig Loon|Rolig Loon]] 09:06 13 November 2013 (PST)
: Your understanding of the examples is incomplete. As written, they do close any possible open listeners before registering another. Note the first line within the touch_start() event handler of the first example, which is commented to that effect, and the call to close_menu() in the second.
: Your proposed change goes against the preferred practice of only opening a listener when required and then closing it immediately afterwards. The (still present under Mono) overhead involved with each and every open listener on a sim should be considered by the scripter. [[User:LepreKhaun Resident|LepreKhaun Resident]] 09:24, 13 November 2013 (PST)
:Ahhh, I now see that there '''is''' a problem with the page though! It does imply that listeners are being registered by the '''llDialog();''' call by not explicitly stating that the function merely opens a dialog menu and it is '''llListen();''' which opens the listener. That is confusing and should be corrected imo. [[User:LepreKhaun Resident|LepreKhaun Resident]] 10:38, 13 November 2013 (PST)

I agree that my initial analysis was wrong in that the wiki code will remove the listener for a previously created listener belonging to another user in the touch event. Therefore the issue of multiple open listeners will not occur. Instead the dialog will go dumb on the other users. If people think that is acceptable for sample code I retract my motion to change it. [[User:LovingAndRejected Resident|LovingAndRejected Resident]] 11:40, 13 November 2013 (PST)

Multi-user concurrency is a big annoying issue complicated by the limit on resources (listens & memory), it's not easy to do so most systems just don't allow it. If you don't mind insecurity and instability, concurrency can be quite easy. Listen-concurrency is really too specialized and complex a topic for llDialog, it really needs it's own page. It might be fun, I'll look into writing about how to do it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:54, 13 November 2013 (PST)

:what strife said as far as concurrency being hairy. If you check out the helper function [[User:Void_Singer/Functions#uDlgBtnPagList]] that I added to the page a while back, you'll see that one way to avoid the concurrency issue is to ignore the conventional wisdom about closing listens, and fitering them in the listen, and instead use a single always on listen, and filter by user key as provided from within the listen event... it's not ideal in all ways (I don't recommend it for mass use of multiple objects in a single area) but it does make unlimited concurrency possible on a single listen. It also results in needing to do more script work per request to filter, but if you need concurrency, it is an option. knowing Strife, it'll be torn apart and something even better will be created from it = D -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 14:21, 14 November 2013 (PST)

::That's a great solution for static content. I really like it. You could use something besides spaces to store more complex state info. I was thinking something more complex, tailored listens and release them as needed. The advantage of tailored listens is that you don't have to worry about parsing 3rd party messages but it comes at a slight performance cost of having to track listen handles. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:14, 14 November 2013 (PST)

== False ignore buttons ==

The article says, "If a button is named <code>["Ignore"]</code>, it will behave like the small <code>["Ignore"]</code> button of the menu". I just tested that, and it didn't happen for me. Is it viewer-dependent? I'm on Firestorm 4.6.5. --[[User:Brilliand Resident|Brilliand Resident]] 20:06, 18 August 2014 (PDT)

: This was fixed in 2012, with [[Release Notes/Second Life Release/3.3.1|SL viewer 3.3.1]] and third party viewers based on it. The issue was {{Jira|STORM-1718}}. Some viewers, especially those that keep a V1-style interface (Singularity, Cool VL), could still have the old behavior and should be tested. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 20:35, 18 August 2014 (PDT)

:: Documented. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:21, 20 August 2014 (PDT)

Talk:LlDialog

2016-07-02T21:13:06Z

Pedro Oval: /* Button Length Issues */ Reply to Void (and replace obsolete <lsl> tags while on it)

== Button Length Issues ==
Telling an end user that the max length of a button label is 24 bytes ... well, not overly helpful. But there is the problem of what what characters translate to how many bytes. Still, is there any way we can give examples of characters?

[[User:Chaz Longstaff|Chaz Longstaff]] 05:18, 27 November 2009 (UTC)

: Can you use a function like this to find long strings? Then the user will not have to guess what button is bad Somebody check my work please, I am sleepy as always.
<source lang="lsl2">integer GetStringBytes(string s) {
list chopped = llParseString2List(llEscapeURL("*" + s), ["%"], []);
return llStringLength((string)chopped) - llGetListLength(chopped) - 1;
}</source>
:--[[User:Cerise Sorbet|Cerise Sorbet]] 10:03, 27 November 2009 (UTC)
:: I was too sleepy. Maybe this time. --[[User:Cerise Sorbet|Cerise Sorbet]] 11:06, 27 November 2009 (UTC)
:: Maybe this one will be more nice to memory? --[[User:Cerise Sorbet|Cerise Sorbet]] 13:03, 27 November 2009 (UTC)
<source lang="lsl2">integer GetStringBytes2(string s) {
s = llEscapeURL(s);
integer i = 0;
integer j;
for (j = llStringLength(s); j > -1; j--)
i += (llGetSubString(s, j, j) == "%");
return llStringLength(s) - i - i;
}</source>
----
Strife, Chaz here. Most ordinary users in SL, and most user documentation in SL, refer to dialog boxes in SL as menus. While that may be as technically inaccurate as referring to a tomato as a vegetable, people don't look for tomatoes in between the apples and bananas at their green grocer (grin), and they are going to come here looking for info on menus, not dialogue boxes. I think we need to at least acknowledge the word menu, even if we do correct them about its usage right away. (I also dislike how people use the word less when they should be using fewer, but that is also just the way it is, sadly :} )[[User:Chaz Longstaff|Chaz Longstaff]] 18:17, 15 July 2008 (PDT)

:Very good point. I'll also keep a lookout for improper uses of "less". -- [[User:Strife Onizuka|Strife Onizuka]] 18:32, 15 July 2008 (PDT)

The Wiki mentions that clicking on a button causes the value to be chatted on the specified channel, but doesn't clarify whether it's simply said(llSay) or shouted(llShout). It does mention that errors will be shouted on the Debug Channel, but I think it's important to clarify this within the Wiki.
--{{User|Deimos Damone}}

:I have reworded the applicable caveat to clarify the functionality. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:49, 15 October 2008 (PDT)

It may be worth including some explicit explanation of the difference between bytes and unicode characters, especially since the inworld error messages somewhat ambiguously talk about characters, when in fact referring to bytes. -- [[User:Tali Rosca|Tali Rosca]] 10:45, 15 October 2008 (PDT)

:Many functions use byte limits and not character limits. I think it would be better to make the word "byte" a link to a (new?) subsection of the [[string]] article where that can be better addressed. It would be inappropriate to duplicate this information on multiple articles, it would end up clogging the articles. That said, I'll try to find the best method for presenting this information; as you point out the current caveat is inadequate and more information is needed. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:49, 15 October 2008 (PDT)

::I agree that the actual explanation shouldn't be here, but a link should be fairly prominent, since this is the most likely place people will run into the difference. [[User:Tali Rosca|Tali Rosca]] 12:03, 15 October 2008 (PDT)

the current suggested function for "safely" truncating button text length is not safe... it can break across a multibyte character -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])

: It says it "can be used to truncate the string without giving an error". Can you produce any errors due to button length or otherwise, when using it? Usually, if LSL in general, and llBase64ToString in particular in this case, finds an incorrect or incomplete UTF-8 character, it will replace that character with a question mark, and no error will be given. Is that not what you see?
: Thanks for fixing the number, by the way. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 14:13, 2 July 2016 (PDT)

== Multiple dialogs tips ==

It may worth mention in tips.

Sending multiple dialogs in a row to one avatar may be inappropriate. In old viewer it creates stack of messages in notification area, which complicates reading other things. In viewer version 2 (as of 16/Sep/2010) newer dialogs replace unanswered dialogs from the same object, so any information and chance to react is lost.

If you need to present more than 12 options, add buttons for browsing option pages (see [[SimpleDialogMenuSystem]]).

If dialogs are not requested by user, but rather are triggered by some events, you may want to either queue further events or discard them until the first dialog will be answered, or at least throttle them. In any case, if you are sending many dialogs, there should be an option to stop them. (Making user mute your object is bad because he may then forget to unmute it when he will want to interact with the object again).

If you just need to report something that does not require an answer, consider using other means of communication. Though, you may still want to send one dialog to draw user's attention.

[[User:Wicked Winslet|Wicked Winslet]] 12:25, 16 September 2010 (UTC)

== Example ==

the first example is very likely to stop working over time with a "too many listens" error in a multi-user environment. Cause: any user that clicks on the object will generate a new listen handle, but only the last one is saved, so only the last one is closed. any user (including the current) that touches the prim before the current user has clicked on a dialog response (or within 60seconds if they do not, or click cancel on the dialog) will cause the current open listen handle to advance, and the previous one will never be closed. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 12:03, 13 January 2013 (PST)
:: I suspect the prim will have died long before that LOL. But you have a point [[User:Omei Qunhua|Omei Qunhua]] 13:47, 13 January 2013 (PST)

:: In fact it would have to be clicked by 65 different users all choosing to ignore the dialog. A subsequent listen using the same filters as a previous is assigned to the same handle. (Thanks Pedro and Innula) [[User:Omei Qunhua|Omei Qunhua]] 10:30, 14 January 2013 (PST)

Also in the first example, the call to llDialog() happens before the listen is created. In my experience it's possible for this to result in a situation where the dialog is shown to the user and, if they click fast enough, the reply is lost. Might it be a good idea to do it the other way round? [[User:Antony Fairport|Antony Fairport]] 05:29, 16 January 2013 (PST)

:: Wow, you type fast! I couldn't even move my mouse onto the dialog window that fast. Anyway I changed it. Example #2 had the same remote possibility of accumulating active listeners, I believe. [[User:Omei Qunhua|Omei Qunhua]] 08:10, 16 January 2013 (PST)

::: Admittedly it's unlikely to be an issue with that actual example but it's possible that a dialog that spawns a dialog that spawns a dialog... (etc) will have someone camping on a button and a reply can get missed. So I was just thinking it might be an idea to encourage starting the listen fist. [[User:Antony Fairport|Antony Fairport]] 08:25, 16 January 2013 (PST)

== Where's order_buttons? ==
Didn't there used to be an example of that very useful helper function, order_buttons(), on this page? Unless there was a particular reason for removing it, I think it would be good to have it back. [[User:Innula Zenovka|Innula Zenovka]] 11:27, 18 February 2013 (PST)
: It's back, a name collision hid it. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 12:11, 18 February 2013 (PST)

== Concurreny issue in first code sample (edited) ==

The first code sample has the following fundamental problem (as can be easily demonstrated): at any point in time there can be '''multiple''' listeners attached because any number of users can click on the prim. But the script sample has only '''one''' global variable to keep track of it. Result: The last user to click on the prim "wins" in the sense that whoever closes the dialog first will remove his listener. All other listeners will remain active.

The obvious mediation is
# either to introduce a more sophisticated listener tracking (and most likely some form of polling in a regular timer event)
# or to keep it simple and introduce a single static listener, omitting the need for a timer event altogether.

I personally opt for the latter. If there are no objections I can make those changes. Proposal:

<lsl>
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
state_entry()
{
// Set up a listener for potential llDialog() calls
// it might seem like a waste at this stage, but overall it is way more efficient
// than trying to track listeners on a per-user basis
gListener = llListen(-99, "", NULL_KEY, "");
}

touch_start(integer total_number)
{
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
}
}
</lsl>

Btw, the same fundamental flaw is present in the tutorial https://wiki.secondlife.com/wiki/Dialog_Menus .

Edit: the second code sample contains the flaw, too

--[[User:LovingAndRejected Resident|LovingAndRejected Resident]] 05:37, 13 November 2013 (PST)

: I'm not seeing where the multiple listens will come from given that the touch event (in the first sample on this page) removes any previous listen. [[User:Antony Fairport|Antony Fairport]] 08:42, 13 November 2013 (PST)
: Agreed. llListenRemove(gListener) will close any pre-existing instance of gListener. Because a dialog box will never self-cancel and we have no way to detect whether a user has clicked "Ignore", it is necessary to include a timer that will remove the listen handle as well.[[User:Rolig Loon|Rolig Loon]] 09:06 13 November 2013 (PST)
: Your understanding of the examples is incomplete. As written, they do close any possible open listeners before registering another. Note the first line within the touch_start() event handler of the first example, which is commented to that effect, and the call to close_menu() in the second.
: Your proposed change goes against the preferred practice of only opening a listener when required and then closing it immediately afterwards. The (still present under Mono) overhead involved with each and every open listener on a sim should be considered by the scripter. [[User:LepreKhaun Resident|LepreKhaun Resident]] 09:24, 13 November 2013 (PST)
:Ahhh, I now see that there '''is''' a problem with the page though! It does imply that listeners are being registered by the '''llDialog();''' call by not explicitly stating that the function merely opens a dialog menu and it is '''llListen();''' which opens the listener. That is confusing and should be corrected imo. [[User:LepreKhaun Resident|LepreKhaun Resident]] 10:38, 13 November 2013 (PST)

I agree that my initial analysis was wrong in that the wiki code will remove the listener for a previously created listener belonging to another user in the touch event. Therefore the issue of multiple open listeners will not occur. Instead the dialog will go dumb on the other users. If people think that is acceptable for sample code I retract my motion to change it. [[User:LovingAndRejected Resident|LovingAndRejected Resident]] 11:40, 13 November 2013 (PST)

Multi-user concurrency is a big annoying issue complicated by the limit on resources (listens & memory), it's not easy to do so most systems just don't allow it. If you don't mind insecurity and instability, concurrency can be quite easy. Listen-concurrency is really too specialized and complex a topic for llDialog, it really needs it's own page. It might be fun, I'll look into writing about how to do it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:54, 13 November 2013 (PST)

:what strife said as far as concurrency being hairy. If you check out the helper function [[User:Void_Singer/Functions#uDlgBtnPagList]] that I added to the page a while back, you'll see that one way to avoid the concurrency issue is to ignore the conventional wisdom about closing listens, and fitering them in the listen, and instead use a single always on listen, and filter by user key as provided from within the listen event... it's not ideal in all ways (I don't recommend it for mass use of multiple objects in a single area) but it does make unlimited concurrency possible on a single listen. It also results in needing to do more script work per request to filter, but if you need concurrency, it is an option. knowing Strife, it'll be torn apart and something even better will be created from it = D -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 14:21, 14 November 2013 (PST)

::That's a great solution for static content. I really like it. You could use something besides spaces to store more complex state info. I was thinking something more complex, tailored listens and release them as needed. The advantage of tailored listens is that you don't have to worry about parsing 3rd party messages but it comes at a slight performance cost of having to track listen handles. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:14, 14 November 2013 (PST)

== False ignore buttons ==

The article says, "If a button is named <code>["Ignore"]</code>, it will behave like the small <code>["Ignore"]</code> button of the menu". I just tested that, and it didn't happen for me. Is it viewer-dependent? I'm on Firestorm 4.6.5. --[[User:Brilliand Resident|Brilliand Resident]] 20:06, 18 August 2014 (PDT)

: This was fixed in 2012, with [[Release Notes/Second Life Release/3.3.1|SL viewer 3.3.1]] and third party viewers based on it. The issue was {{Jira|STORM-1718}}. Some viewers, especially those that keep a V1-style interface (Singularity, Cool VL), could still have the old behavior and should be tested. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 20:35, 18 August 2014 (PDT)

:: Documented. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:21, 20 August 2014 (PDT)

User talk:Strife Onizuka/Float Functions

2015-09-19T12:44:13Z

Pedro Oval: /* Try these */ Minor nitpick

== Ever considered making a fui16? ==

I was just looking around for how I could union a float into a 16 bit integer, perhaps using the [http://en.wikipedia.org/wiki/Half-precision_floating-point_format IEEE 754-2008 half-precision] format. Yes, I know there would be losses, and I also know that SL olny has 32 bit integers. The final goal for my application is to pack two floats into a single integer, via bitshifting the first into the high range and then ORing with the second, a la:
<source lang="lsl2">
// To pack:
float a = PI;
float b = 4.2;
integer result = (fui16(a) << 0x10) | fui16(b);

// To unpack:
float c = i16uf(result >> 0x10); // Might need to perform some further magic here to account for the fact that the sign bit doesn't shift.
float d = i16uf(result & 0xFFFF);
</source>
Of course, in the general case one can't make assumptions about range and resolution. That said, in my application I ''can'' make such assumptions, and I'm just going to hack together something that works based on those assumptions. I'm just here feeding the fetish that resulted in these very-useful-to-me functions (fui, iuf) in the first place. >:D

{{Unsigned|Cron Stardust}}

:Lets see, I could either work on [[Template:LSL Function]] et al as to split the notes section in half, or I could write fui16 a most clever function. Hmmm. Fun clever coding or Template drudge. Half precision doesn't have the same range, grrrr... -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:57, 24 December 2012 (PST)

:Upon second though, I really don't want to dig into floating point math at the moment. Mostly you just need to add clipping to fui, change the constants and add infinity support to iuf. With clipping implemented the error correcting code can be removed. Here is my first crack at updating the constants. I've not tested it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:35, 24 December 2012 (PST)

<source lang="lsl2">
integer fui16(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union half-precision float to short integer
if((a)){//is it non zero?
integer b = (integer)(a < 0) << 15;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
return b | (integer)(a * 16777216.0);//the math overlaps; saves cpu time.
if(a > 65504.0)//Round up to infinity
return b | 0x7C00;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
return (0x3FF & (integer)(a * (0x800 >> b))) | (((c + (b = (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))))) << 10 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return (integer)((string)a == (string)(-0.0)) << 15;
}

float i16uf(integer a)
{//union short integer to half-precision float
if((a & 0x7C00) == 0x7C00)
return (1 | ((a << 16) >> 31)) * (float)"Infinity";
return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));
}
</source>

<source lang="lsl2">
// To pack:
float a = PI;
float b = 4.2;
integer result = (fui16(a) << 16) | fui16(b);

// To unpack:
float c = i16uf(result >> 16); // No magic needed, sign bit is handled correctly.
float d = i16uf(result);
</source>
::Just tested in SL with the following results: Had to place a closing paren in the first return statement of iuf16, I placed it just before the mult as I suspect that's what was intended. I wrote a simple ownersay of the existing test code which gave the following as the output: [[User:Cron Stardust|Cron Stardust]] 16:12, 25 December 2012 (PST)
<source lang="lsl2">
a = 3.141593 = 0xC90FDBp-22
= c = 3.140625 = 0xC9p-6
b = 4.200000 = 0x433333p-20
= d = 4.199219 = 0x433p-8</source>
::Further testing, looking for error cases, resulted in a lot of good: the functions seem to operate as they should. I tested using all the constants demonstrated on the Wikipedia article and only one failed to match perfectly: 0.0000000596046 doesn't encode to 0x0001, instead it results in 0x0000. All other values seem to work great. [[User:Cron Stardust|Cron Stardust]] 22:00, 25 December 2012 (PST)
:: Also tested that with <code>a = -2.0</code> and <code>b = -2.0</code> that everything works out: no issues happen with the sign bit status that I could detect - so I took the liberty of changing the comment in your code. [[User:Cron Stardust|Cron Stardust]] 22:34, 25 December 2012 (PST)

:::I'm willing to bet it's a lack of precision in their approximation. Try: 0.000000059604644775390625 -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:36, 26 December 2012 (PST)

:::I'm not 100% sure of the "<code>llFloor((llLog(a) / 0.6931471...)</code>" line but I think in this range it's accurate and we don't need to do any correction. The only way to know for sure is to try every value in the range [0.0001220703125, 65504.0]. I know it's not going to overflow so I've removed the overflow protection code. If you want to do that testing, here is the return line you would use which assumes that "c" is accurate: <code>return (0x3FF & (integer)((a / (float)("0x.004p"+(string)c)))) | (((c + 15) << 10 ) | b);</code> It has the added bonus of making fui16 LSLEditor safe. This was also a good demonstration of how the layers of correction code were bolted on. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:50, 26 December 2012 (PST)

This is a better version of what I was talking about but it needs extensive testing. If c is not accurate this will not work.
<source lang="lsl2">
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 15;//extremes will error towards extremes. No corrections are attempted.
return (0x3FF & (integer)((a * 0.03125 * (0x40000000 >> c)))) | ((c << 10) | b);
</source>
I've gone back and removed my string-float pow code since it can all be done with integers and float math. Faster this way. Less stressful for the sim.
-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:32, 26 December 2012 (PST)
=== Testing ===
Just run the following code and it will tell you if c is accurate for the entire half-precision range (this is one of the things iuf is really good for, iterating over every float value). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 02:55, 26 December 2012 (PST)
<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a))
{//is it non zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)))))))) << 23 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return ((string)a == (string)(-0.0)) << 31;
}

float iuf(integer a)
{//union integer to float
return ((float)("0x1p"+(string)((a | !a) - 150))) * ((!!(a = (0xff & (a >> 23))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer test(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union half-precision float to short integer
if((a))
{//is it non zero?
if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
return FALSE;//the math overlaps; saves cpu time.
if(a > 65504.0)//Round up to infinity
return FALSE;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
return (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))) - 1;
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return FALSE;
}

float i16uf(integer a)
{//union short integer to half-precision float
if((a & 0x7C00) == 0x7C00)
return (1 | ((a << 16) >> 31)) * (float)"Infinity";
return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));
}

list gBadBlockCounts;

default
{
state_entry()
{
llOwnerSay("beginning test");llResetTime();

integer badCount = 0;
integer badStart;

integer start = fui(i16uf(1) / 2.0);//start just before min value, these will get clipped to zero.
integer end = fui(65536.0);//stop just after infinity
integer i;
for(i = start;i < end; i++)
if(test(iuf(i)))
{
llSetText("bad: "+(string)i, <1.0, 0.0, 0.0>, 1.0);
if (badCount++ <= 0)
{
badStart = i;
llOwnerSay("Found bad number: " + (string) i);
}
}
else
{
llSetText("good: "+(string)i, <0.0, 1.0, 0.0>, 1.0);
if (badCount > 0)
{
llOwnerSay("Total of " + (string) badCount + " numbers, ending with " + (string) (i-1));
gBadBlockCounts = [badStart, i - 1] + gBadBlockCounts;
badCount = 0;
}
}
llSetText("test complete.\ntook " + (string) llGetTime() + " secs over " + (string) (end - start) + " values\nsaw " + (string) llGetListLength(gBadBlockCounts) + " bad blocks.\nTouch for list of bad.", <0.0, 1.0, 1.0>, 1.0);
state printout;
}

}

state printout
{
touch_end(integer index)
{
while (--index >= 0)
{
if (llGetListLength(gBadBlockCounts))
{
llRegionSayTo(llDetectedKey(index), 0,
"Bad blocks strided list, using stride pattern (block_start, block_end):"
);
llRegionSayTo(llDetectedKey(index), 0,
llDumpList2String(gBadBlockCounts, ", ")
);
}
else
{
llRegionSayTo(llDetectedKey(index), 0,
"Nothing to report."
);
}
}
}
}
</source>
::Tested this morning. Went bad at values 864026624 through 900508790. Not sure if there were further values: I set it up to run and then wen to work for the day, when I came back it had been yelling for a very long time... :P Will see what I can do, however while I can understand the code, I've not yet been able to get my mind in deep enough to understand the algorithm. [[User:Cron Stardust|Cron Stardust]] 18:55, 26 December 2012 (PST) EDIT: Just noticed that there was a function named test in there that wasn't used: I'd pasted in the fui16 function from above to make the code compile and run. That may have invalidated the test, so I've going to retest usung the "test" function in place of the fui16 call in state_entry. I've edited the above state_entry to reflect my current code.
::Just passed the 864026624 mark without errors, so yes: my previous test was invalid. Continuing testing - just like GLaDOS likes. [[User:Cron Stardust|Cron Stardust]] 20:59, 26 December 2012 (PST)

:::I should have thought of this sooner, we don't need to test every value, just the ones who's values surround where the value of "c" changes. We only need to test ummm 84 values... just the powers of two and the immediate lesser values. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:44, 27 December 2012 (PST)

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a))
{//is it non zero?
integer b = (integer)(a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)));
integer bb = ((integer)a - (3 <= a));
return (0x7FFFFF & (integer)(a * (0x1000000 >> bb))) | (((c + 126 + bb) << 23 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return (integer)((string)a == (string)(-0.0)) << 31;
}

float iuf(integer a)
{//union integer to float
integer aa = 0xff & (a >> 23);
return ((float)("0x1p"+(string)((aa | !aa) - 150))) * ((!!aa << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer get_log2(float a)
{//we use the natural log because testing showed it's more accurate than log10.
return llFloor((llLog(a) / 0.69314718055994530941723212145818));//must be divide, multiplying the reciprocal adds extra corruption.
}

integer test_log2(integer power)
{
float a = (float)("0x1p"+(string)power);
float b = iuf(fui(a) - 1);//The underflow is in our favor and does what we want.
integer c = get_log2(a);
integer d = get_log2(b);
integer e = (c == power) && ((d + 1) == power);
// llOwnerSay(llList2CSV([power, c, d, Float2Hex(a), Float2Hex(b), int2hexdword(fui(a)), int2hexdword(fui(b)), e]));
return e;
}

default
{
state_entry()
{
integer start = -25;
integer end = 17;
integer i;
for(i = start; i <= end; i++)
if(!test_log2(i))
llOwnerSay((string)i);
}
}
</source>
:: Ok, so executed - though I'm leaving the other script running, and it seems good thus far; will report when it completes. The results from this new test are that I saw values reported in the following ranges: [-25, -16], -14, [-12, -2], [3, 17] -- [[User:Cron Stardust|Cron Stardust]] 19:14, 27 December 2012 (PST)

::: Well that is bad. Guess c is not accurate so we can't remove the correction code (the overflow code can still be removed). I wonder what happens if you feed it NaN. Probably need a special case just for that. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:45, 27 December 2012 (PST)

::: I remembered how the correction code works and I fused one of the moving parts. I don't think it's necessary for this range but I'm adding it back in. Since "c" could be off by one in either direction, this gives us three possible outcomes when generating new-a.
:::# It's too small, the result is that new-a is in range [0.5, 1)
:::# C is correct, new-a is in range [1, 2)
:::# It's too big, the result is that new-a is in range [2,4)
:::Solution? Map these three outcomes to three consecutive values so that they can be used to adjust c. Truncating new-a gives us [0.5, 1)->0, [1, 2)->1, [2,4)->{2,3}. Yes they are consecutive but we need to map the final set to a single value. Hence the subtract by (3 <= a).
:::It's a shame I never documented which edge cases this code fixed. It would take a lot of the guess work out. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:22, 27 December 2012 (PST)
: For what it's worth, the old test code finally completed! Took about 6-8 days continuous* calculation in my home region. (* script reported 521479.8 seconds, but I'd had to stop and fix a UI error after several hours of computation, and picked up where I'd left off.) Here's the report: [[User:Cron Stardust|Cron Stardust]] 18:14, 5 January 2013 (PST)
<pre>
Bad blocks list, using stride pattern [block_start, block_end]:
[
[1191182336, 1191182336], [1182793721, 1182793727], [1174405120, 1174405120], [1166016505, 1166016511],
[1157627901, 1157627903], [1149239293, 1149239295], [1140850685, 1140850687], [1132462077, 1132462079],
[1124073469, 1124073471], [1115684861, 1115684863], [1107296255, 1107296255], [1098907647, 1098907647],
[1090519039, 1090519039], [1048575999, 1048575999], [1040187390, 1040187391], [1031798782, 1031798783],
[1023410174, 1023410175], [1015021564, 1015021567], [1006632956, 1006632959], [ 998244348, 998244351],
[ 989855740, 989855743], [ 981467132, 981467135], [ 973078524, 973078527], [ 964689912, 964689919]
]
</pre>

== fui support for NaN and Inf ==

I must be one of the few people who have found an actual use to fui :) I'm using it for compact lossless transmission of floats over HTTP to a PHP server in base 64 (after removing the == and the trailing A's), and I decode it in the server using unpack() and some string manipulation. I would love to see fui support NaN, Inf and -Inf, but more for the sake of completion than because I have a real use (except possibly debugging). Maybe it's as straightforward as adding this on top?
<source lang="lsl2">
if ((string)a == "Infinity") return 0x7F800000;
if ((string)a == "-Infinity") return 0xFF800000;
if ((string)a == "NaN") return 0x7FC00000; // to choose one
</source>
I guess there's no way to extract the actual bits of a NaN, or is there? --[[User:Pedro Oval|Pedro Oval]] 05:09, 26 December 2012 (PST)

Oops, I've corrected "Inf" to read "Infinity" above. --[[User:Pedro Oval|Pedro Oval]] 07:58, 26 December 2012 (PST)

:Sure, I don't see why not. I'll think about ways of doing it (I'm not sure if successive tests is really the best way of doing so). The reason Infinity was never handled was that LSO doesn't allow it. These functions were originally conceived before Mono was on the horizon (at the time I had wanted to build an LSO bytecode emulator in LSL). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:01, 27 December 2012 (PST)
:It's done. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:43, 27 December 2012 (PST)

::You will be pleased (or horrified) to see that [[Float2Hex]] and [[Float2Sci]] both support NaN and Infinities now. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:22, 29 December 2012 (PST)

== Alternate code ==

I was pondering alternate ways to <code>b >> (13 + ((b & 0x3FFF) == 0x2000))</code> because it's just so ugly.
*<code>b >> (((0x3FFF & b ^ 0x1FFF) + 0x34001) >> 14)</code> - we flip the low bits, so if all of them are on, that is to say our condition has been met, adding one will cause a carry into the 14th bit.
*<code>b >> ((0x38000 - (0x3FFF & b ^ 0x2000)) >> 14)</code> - similar to above, we turn the high bit off, so if it's zero it doesn't cause a carry from above.
*<code>b / ((((0x3FFF & b ^ 0x1FFF) + 0x4001) & 0xC000) >> 1)</code>
It's a shame there isn't a way to further improve it. It's an ugly mess that only gets uglier. ~_~ -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:22, 28 December 2012 (PST)

= Bugs in iuf and fui =
== Bug in iuf ==

iuf does not support exponent parts of 2-104 or below. The reason is that in an intermediate step, it is trying to calculate 0x1p-127 or below, which yields 0. For exaple, iuf(0x0bffffff) returns 0, while iuf(0x0c00000) returns the correct result.

Rather than trying to find a fix, I created my own iuf that seems to work, even if it's unoptimized and not very fast (though it contains a small trick to reduce the total number of iterations to a maximum of 25 or so):

<source lang="lsl2">
float iuf(integer e)
{
float result = e & 0x7FFFFF;
integer sign = e & 0x80000000;
e = ((e >> 23) & 0xFF) + -150;
// deal with Inf/NaN
if (e == 105) { if (result) return (float)"NaN"; if (sign) return (float)"-Inf"; return (float)"Inf"; }
if (e ^ -150)
{
result += 0x800000;
while (e > 9) { result *= 512; e += -9; }
while (e < -9) { result *= 0.001953125; e += 9; }
while (e > 0) { result *= 2; --e; }
while (e < 0) { result *= 0.5; ++e; }
if (sign) return -result;
return result;
}
if (sign) return -(result*1e-45);
return result*1e-45;
}
</source>

A fix might be along the lines of not applying the -23 offset in advance (as usage of -150 implies) but postmultiplying by 2^-23 instead. I haven't tried though. --[[User:Pedro Oval|Pedro Oval]] 09:37, 8 February 2013 (PST)

:If the denormalized range isn't working then Float2Hex is likely broken too. hmmm -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:11, 9 February 2013 (PST)

::It's not just the denormal range, it affects the normal range too. 2-104 is small but not denormal; the denormal range starts at 2-127. --[[User:Pedro Oval|Pedro Oval]] 16:22, 9 February 2013 (PST)

:::I start the denormalized range a power of two early but if it's failing all the way up to -104... that's a big problem. I'll have to play with it. Multiplying by a power of two shouldn't trash the mantissa. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:29, 11 February 2013 (PST)

::::Maybe I misunderstood. If what you meant is that hex floating point format is unable to produce denormal numbers, then that's exactly the problem, yes. 0x1p-127 produces 0, even if the denormal range can represent numbers down to 0x1p-149. What I meant is that inputs to the function representing exponents of -104 or below failed (as these involved calculation of 0x1p-127 or below). Now some good news. The new function revised to use [[llPow]] works correctly for small exponents and seems to work correctly for the rest. Also, under Mono at least its performance is about 2.5 times that of the old (string operations are s-l-o-w). --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)

== Bug in fui ==

Alas, iuf is not the only one with problems. For exponents of -2 or less, and mantissas in the vicinity of 0x7FFFFF, results are almost always wrong. Examples:

* <code>fui(iuf(0x017fffdd)) = 0x01ffffee</code> (the first one failing with mantissa > 0x7FFF00, exponent is -124)
* <code>fui(iuf(0x017fffff)) = 0x01ffffff</code> (the last one failing with that exponent; all in the middle also fail)
* <code>fui(iuf(0x01ffffc5)) = 0x027fffe2</code> (next one failing)
* <code>fui(iuf(0x01ffffff)) = 0x027fffff</code> (last one with that exponent, all in the middle fail)
* <code>fui(iuf(0x037ffffd)) = 0x03fffffe</code> (for this exponent the failure range is shorter - just 3 numbers)
* <code>fui(iuf(0x38ffffff)) = 0x38ffffff</code> (for a few exponents there are no failures at all; this is an example)
* <code>fui(iuf(0x3e7fffff)) = 0x3effffff</code> (last one failing)

I've manually checked some of the iuf conversions and they worked correctly with the code I posted above, so the problem is in fui. For example: <code>if (iuf(0x25fffff6) == .44408894e-15) llOwnerSay("iuf ok");</code> says "iuf ok", but fui(.44408894e-15) gives 0x267ffffb, not 0x25fffff6. --[[User:Pedro Oval|Pedro Oval]] 11:48, 8 February 2013 (PST)

:Are you doing these tests in Mono, LSO or both? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:48, 9 February 2013 (PST)

::I tested the full range only in Mono, but a quick run seems to show that LSO is affected in exactly the same way. At least the range starts in the same number (0x017fffdd) and produces the same result (0x01ffffee). --[[User:Pedro Oval|Pedro Oval]] 16:31, 9 February 2013 (PST)

:It will take me some time (maybe a few weeks) to get around to this, I'm very busy currently. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:14, 9 February 2013 (PST)

::I admit to kicking off Pedro's investigation, as I tried to use iuf and fui in Mono and found that fui (iuf (x) ) gave zero for all values of x from 1 to 3 million, at which point when I gave up :) They seem to work a lot better in LSO from my briefer tests so far. [[User:Omei Qunhua|Omei Qunhua]] 15:52, 9 February 2013 (PST)

= Try these =
I've swapped out the hack pow method for the real function. I'm hoping this will fix iuf.

I've also expanded the compressed lines so that they are easier to tinker with. I've enlarged the supported range of <code>a</code> in the error calculation, the range supported has changed from [0.5, 4) to [0.25, 4).

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
c -= (c >> 31) | 1;//this sets up an error towards the zero
a /= llPow(2.0, c);//a should now be in the range [0.25, 4).
integer d = (integer)a + (0.5 >= a) - (3 <= a);//This calculates the actual error. It does so by mapping the value of a to the error.
//Specifically we take advantage of the where the normalization bit has been shifted.
//[0.25, 0.5) == -2, [0.5, 1) == -1, [1,2) == 0, [2, 4) == 1 ~ note the actual values of d are off by two.
llOwnerSay(llList2CSV([0x800000 == (0xF800000 & (integer)(a * (0x2000000 >> d))), c, d, a, (a < 0.25) || (a > 4)]));//first value tells you if you got d right or wrong.
//The check works by seeing where the normalization bit has been shifted. The normalization bit gets chopped off with 0x7FFFFF.
return (0x7FFFFF & (integer)(a * (0x2000000 >> d))) | (((c + 125 + d) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
integer b = 0xff & (a >> 23);
return llPow(2.0, (b | !b) - 150) * (((!!b) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>
::The above fails at every number from the range I tested (mantissa in the vicinity of 0x3FFFFF, exponent -2 and below). --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)
:::More specifically, it seems to fail for all numbers with bit 22 set (mask 0x00400000). --[[User:Pedro Oval|Pedro Oval]] 16:53, 13 February 2013 (PST)

This uses a modified error correction code. I'm not sure if it will be better or worse. It has the potential to run out the high side of the stated bounds on <code>a</code> but I don't think this will be the case. We shall have to see.

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
--c;//Make it error down. Hopefully this won't shift anyone into the [4, 8) range.
a /= llPow(2.0, c);//a should now be in the range [0.5, 4), we assume no error is added.
integer d = (integer)a - (3 <= a);//This calculates the actual error. As it turns out, the integer portion of a is {0,1,2,3} the errors in c are {-1,0,1,1}
llOwnerSay(llList2CSV([0x800000 == (0xF800000 & (integer)(a * (0x2000000 >> d))), c, d, a]));
return (0x7FFFFF & (integer)(a * (0x1000000 >> d))) | (((c + 126 + d) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
integer b = 0xff & (a >> 23);
return llPow(2.0, (b | !b) - 150) * (((!!b) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>
::The above passed the test in the range where version 1 failed (vicinity of 0x7fffff for mantissa and exponents up to -2). Also, fui(iuf(i))==i produces no mismatch in a random sample of 2M integers (version 1 produced 2 mismatches in a random sample of 1M). Looks promising. I'm not testing it in LSO though - too slow :) --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)

:::A distributed computation over the whole range of integers except those representing NaN and Inf (I used 64 scripts in 16 sims computing 64M numbers each) has showed that the fui and iuf functions above work flawlessly for every supported integer. Those representing NaN were not tested for the obvious reason of unavoidable data loss. We have a winner. Thank you so very very much. --[[User:Pedro Oval|Pedro Oval]] 21:34, 13 February 2013 (PST)

::::This is kind of scary, I wasn't expecting this version to work. The other version was the one I was expecting to work. Sounds like there were two bugs. I'll compress it back into an optimized form. This makes me worry about Float2Hex working, since it sounds like the string->float typecast doesn't like very small numbers. I wonder if there is a cap on the exponent? I shall have to test. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:08, 14 February 2013 (PST)

::::: I've made some experiments now. <code>(float)"something"</code> seems to fail under Mono whenever "something" results in a number with an absolute value less than <code>0x1p-126</code>, no matter if it's hex or otherwise.

::::: However, <code>(vector)"<something,something,something>"</code> and <code>(rotation)"<something,something,something,something>"</code> both work fine with numbers in that range even in Mono.

::::: Go figure... -- [[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 05:41, 19 September 2015 (PDT)

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = ~-llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= llPow(2.0, c)))))) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
return llPow(2.0, (a | !a) - 150) * (((!!(a = (0xff & (a >> 23)))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>

Lots to comment on, and MediaWiki's standard for follow-up responses is quite inconvenient for this purpose. I hope you don't mind if I post this reply without indentation.

First, I'm pretty sure that the failure of the previous function must be due to a bug somewhere, not to the algorithm, given that the failure pattern seems very clear and consistent. I haven't analyzed it so I can't tell more for now.

Second, your sentence "I wonder if there is a cap on the exponent?" suggests to me that you have missed my last reply in the [[#Bug in iuf|iuf bug discussion]].

Third, the "compressed" versions work, though I haven't tested the whole range, just a random sample of 10M integers.

Fourth, the NaN test is flawed. if((a)) is equivalent to if(!(a==0)) and is true for NaNs.

Fifth, the usual NaN returned by gcc is 0x7FC00000, so I suggest to use that for possible interoperability. It has the "quiet" bit set and nothing else.

Sixth, I see quite some room for memory optimizations in Mono for both functions, while minimally affecting performance if at all. Changes include:

* Changing division to multiplication where possible.
* Changing <= to < and >= to > where possible. a <= b is equivalent to !(a > b) both in size and in behavior even with NaNs (sad, I know).
* Changing subtraction to addition of opposite (a-b to a+-b).
* Changing -constant to its hex representation.
* Changing 2.0 to 2
* Changing << constant to * constant (>> and / take the same bytes so no gain there, plus there are sign issues).
* Changing (a & constant) == constant to !(~a & constant).
* Using localint^localint instead of 0.
* Change the logic of Infinity and NaN in iuf, to get rid of the list, using that (float)"Inf" yields infinity and that parsing stops at the first invalid character without invalidating the previous results.
* Changing (string)-0.0 to "-0.000000" (this one is the only one I don't have reliable experimental results to back, but I believe it will save memory; it almost surely will perform better by not needing to build that string at run time).

Here are Mono-memory-optimized versions taking into account all of these:

<source lang="lsl2">
integer fui(float a)//Mono Safe, ????LSO Safe???? (untested), Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if(a){//is it nonzero?
integer b = (a < 0) * 0x80000000;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
if(a > 1e-45)//It should at this point, except if it's NaN
{
integer c = ~-llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a + -(3 <= (a *= llPow(2, -c)))))) * 0x800000 ) | b);
}//the previous requires a lot of unwinding to understand it.
return 0x7FC00000;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}
return ((string)a == "-0.000000") * 0x80000000;//for grins, detect the sign on zero. it's not pretty but it works.
}//Mono does not support indeterminates so I'm not going to worry about it.

float iuf(integer a)
{//union integer to float
if(!(~a & 0x7F800000))
return (float)llGetSubString("-nan-inf", 4 * !(a & 0x7FFFFF) + (a > (a^a)), 7);
return llPow(2, (a | !a) + 0xffffff6a) * (((!!(a = (0xff & (a >> 23)))) * 0x800000) | ((a & 0x7fffff))) * (1 | (a >> 31));
}
</source>
Further possible optimizations include replacing other divisions with multiplications where possible (llLog(a) / 0.693... might be a candidate, but it's at the core of the algorithm so I didn't dare) and replacing <= with < in the (3 <= ...) if possible. If it's equivalent to (2 < ...) then the latter is preferable. Also, although I've not touched them, source code wise, the floats used have an unnecessary precision; using respectively 2.3509887e-38, 1e-45, 3.4028235e+38, and 0.6931472, the results are the same. You can check that doing: float f1 = 2.3509887016445750159374730744445e-38; float f2 = 2.3509887e-38; if (f1 == f2) llOwnerSay("yes"); outputs yes, and similarly for the rest. Doubles are not supported after all.

For the sake of verifiability, here's my simpler test program (not the distributed one, although it's along the same lines):
<source lang="lsl2">
string tohex(integer i)
{
string hex = "0123456789ABCDEF";
string result;
integer iter = 9;
while (--iter)
{
result = llGetSubString(hex, i & 0xF, i & 0xF) + result;
i = i >> 4;
}
return result;
}

default
{
state_entry()
{
if (fui(iuf(0x7F800000)) ^ 0x7F800000) llOwnerSay("Fail at +inf");
if (fui(iuf(0xFF800000)) ^ 0xFF800000) llOwnerSay("Fail at -inf");
if (fui(iuf(0x7FC00000)) ^ 0x7FC00000) llOwnerSay("Fail at NaN1");
if (fui(iuf(0xFFC00000)) ^ 0x7FC00000) llOwnerSay("Fail at NaN2");
if (fui(iuf(0x7FC0FFFF)) ^ 0x7FC00000) llOwnerSay("Fail at NaN3");
if (fui(iuf(0xFFC00001)) ^ 0x7FC00000) llOwnerSay("Fail at NaN4");
if (fui(iuf(0x00000000)) ^ 0x00000000) llOwnerSay("Fail at 0.0");
if (fui(iuf(0x80000000)) ^ 0x80000000) llOwnerSay("Fail at -0.0");
if (fui(iuf(0x00000001)) ^ 0x00000001) llOwnerSay("Fail at 1e-45");
if (fui(iuf(0x80000001)) ^ 0x80000001) llOwnerSay("Fail at -1e-45");
if (fui(iuf(0xFF7FFFFF)) ^ 0xFF7FFFFF) llOwnerSay("Fail at ~ -1e38");
integer a;
integer iter;
while (++iter)
{
integer rand = (integer)llFrand(65536) + 65536 * (integer)llFrand(65536);
if (!(iter & 0xFFFF)) llSetText((string)iter, <1,1,1>, 1);

if (fui(iuf(rand)) != rand) // we let it run for NaNs too to detect crashes
{
if (~rand & 0x7F800000)
{
llSetText("Fail at rand = 0x" + tohex(rand) + ", fui(iuf(rand)) = 0x" + tohex(fui(iuf(rand))), <1,1,1>,1);
return;
}
}
}
llSetText("Done", <1,1,1>, 1);
}
}
</source>
I simply let it run while desired.

--[[User:Pedro Oval|Pedro Oval]] 11:02, 15 February 2013 (PST)

:I hadn't seen your previous comment, thank you for pointing it out. I'll try to patch Float2Hex so it doesn't use exponents less than -127 (it use to work on Mono ~_~).

:You are correct, the extra precision is unnecessary for single precision. I use these values because Float2Hex uses them, and I've written versions of Float2Hex that support higher precisions. I wrote both originally in ESL (LSL fed through a C Pre-processor) with extensive use of macros.

:I tend to optimize for LSO bytecode and stack size (I know it's insane but old habits die hard). Which is why I wasn't using llPow. I'm not surprised there is a bytecode savings between 2 and 2.0 for Mono but is it really faster? I would have though the compiler would have put in the implicit typecast there... unless LL got smart... hmmm. Anyway we are well beyond optimizing for LSO.

:You could try flipping the divide in the log2 calculation, I'm not sure if the error recovery is good enough. My recollection from my initial testing was that using a multiply instead of the divide widened the range of the errors.

:I never wanted to committing to inlining "-0.000000" in fear they might change the typecast on me. We won that fight a few years ago so it should be ok.

:Quick question, what does the following do? Trying to figure out how screwed I am. I am hoping to avoid having Float2Hex revert to base 10 for |x| < 0x1p-127 (I don't even know of a good way to do that x_x).
<source lang="lsl2">default {
state_entry() {
llOwnerSay((string)(0.0 != (float)"0x0.4p-127"));
}
}</source>

:Unless testing proves otherwise, we don't want to swap in a multiplication for a shift, at the CPU level shift should be faster. Swapping a subtract out for an add-negation similarly won't give you much as negation would be an extra instruction (unless the negation is being done on a constant than it's no extra).

:1e-45 makes me uneasy. I know it works but it just looks wrong to me. I am cool with excessive precision.

:I've made a few changes. I couldn't help myself. I used the dreaded negative indexing on llGetSubString, ''with wraparound''. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:16, 16 February 2013 (PST)
<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if(a){//is it nonzero?
integer b = (a < 0) * 0x80000000;//the sign
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
if(a > 1.4012984643248170709237295832899e-45){//It should at this point, except if it's NaN
integer c = ~-llFloor(llLog(a) * 1.4426950408889634073599246810019);//extremes will error towards extremes. following yuch corrects it
return b | (0x7FFFFF & (integer)(a * (0x1000000 >> c))) | ((126 + (c = ((integer)a - (3 <= (a *= llPow(2, -c))))) + c) * 0x800000);
}//the previous requires a lot of unwinding to understand it.
return 0x7FC00000;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}//Mono does not support indeterminates so I'm not going to worry about them.
return ((string)a == "-0.000000") * 0x80000000;//for grins, detect the sign on zero. it's not pretty but it works.
}

float iuf(integer a)
{//union integer to float
if(!(0x7F800000 & ~a))
return (float)llGetSubString("-infnan", 3 * ~!(a & 0x7FFFFF), ~a >> 31);
return llPow(2, (a | !a) + 0xffffff6a) * (((!!(a = (0xff & (a >> 23)))) * 0x800000) | (a & 0x7fffff)) * (1 | (a >> 31));
}
</source>

::The version with multiply turned out to work fine in a sample of ~600M random numbers, so yay! On the bad news side, the test program you asked me to run returns 0. As I said, 1p-127 returns 0 already, so no surprise there, but I tested this:
<source lang="lsl2">
default
{
state_entry()
{
llOwnerSay((string)(0.0 != (float)"0x0.ffffffp-126"));
llOwnerSay((string)(0.0 != (float)"0x1.0p-126"));
}
}
</source>
::and got 0 and 1. So I'm afraid hex notation refuses to produce any denormal at all. <strike>A strategy you can maybe use for denormals is to treat them as a special case multiplying them by a power of two, so they come into a tractable range. But I haven't checked the source so I may be off here.</strike> (Oops, got your point now - there may be a way using part of the strategy I mention, I'll think about something)

::As for optimizations, I like your "risky" rewriting of llGetSubString, and of course it works. I know mults are slower than shifts (if that's what the code is compiled to in the end, which is questionable), but the difference, just maybe ten cycles or so, is really unnoticeable when there's a whole burden of task switching and other stuff going on. For that reason I tend to always optimize for memory. In the above case, it will matter little if the function takes 30000 or 30010 cycles to execute, just as an example to make my point (I'm sure the actual numbers will be different). Same with minus sign: the extra CPU burden will be insignificant (1 cycle probably). I've tried to test these differences but I never got conclusive results because noise level exceeds signal level by far, which just proves how insignificant the difference is. I tend to run out of space in scripts so I mostly optimize for memory. While I get to 60K+ code size often, I have yet to run into an application where shoving cycles that way gains anything noticeable. Also, I started to test this for Omei because she intended to use it in a memory-tight application. The space savings can make a difference.

::The int-to-float implicit conversion seems to add an explicit cast, as an int constant is 6 bytes, a float constant is 10, and an integer implicitly or explicitly cast to float takes 7. By the way, -~-x is a saving vs. 1-x and vs. 1+-x (1 byte per unary sign vs. 6 bytes the integer constant, 8 the subtraction and 4 the addition). I have Mono size measurements here: [[User:Pedro Oval/Mono code memory usage]].

::As for the 1e-45, OK, though I like it because it also reflects the loss of precision that happens in denormals. But it's my opinion that using the whole expansion in the comparison to detect a NaN is overkill, as any number between 1e-45 and 2.35e-38 will do. For example, 1e-40 is equally valid and doesn't clobber the source so much. --[[User:Pedro Oval|Pedro Oval]] 19:36, 17 February 2013 (PST)

::Alas, it's worse than I thought. 1.17e-38 (a denormal) works fine, but (float)"1.17e-38" returns 0. Not sure when did glibc stop supporting denormals. --[[User:Pedro Oval|Pedro Oval]] 19:59, 17 February 2013 (PST)

:::I've put -~- back. I can't thank you enough for all your testing. I totally agree, optimizing for size is the main concern. I didn't remember this about logarithms that logab * logba = 1. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:38, 17 February 2013 (PST)

:::Crap. Both Float2Sci and Float2Hex are screwed. Without having access to the source for the Mono compiler we can't be sure it's glibc or Mono, though we can confirm it's glibc that's bugged by checking how it works with LSO. I may just have to manifest at an upcoming [[Simulator_User_Group|Simulator]]/[[Server_Beta_User_Group|Server_Beta]] User Group meeting and complain. should open up a ticket on jira first. hmmm. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])

::::Duh, good point. It's a Mono-only quirk. (float)"0x1p-127", (float)"0x1p-149", and (float)"1e-45" are all nonzero in LSO, and the latter two are equal to 1e-45 as expected. About the latest change, I fail to see the gain in moving the sign of c to the <code>-~-llFloor</code> line, as that forces a subtraction later which eats 4 extra bytes. Could it not remain as <code>integer c = ~-llFloor...</code>, then <code>...llPow(2, -c))))) + c)</code>? --[[User:Pedro Oval|Pedro Oval]] 20:23, 18 February 2013 (PST)

:::::Of course it can but why should it make a difference as we have just moved the negation further down. Am I missing something? Please tell me that subtraction isn't more expensive than addition. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:47, 18 February 2013 (PST)

::::::Sorry to bring bad news but yes: addition of two local integers takes 4 bytes, as does multiplication. But subtraction takes 8, as do division, mod and shift. "!" takes 3 bytes, while "~" and "-" take 1 each. Take a look at the table I linked to. You'll want to cry. As for the several variants you enumerate below, regrettably, float to integer cast takes 5 bytes, which is more than leaving it as <= instead of < (3 extra bytes). I think function calls need at least as many bytes as their name, so I wouldn't go that route. Not 100% sure there though. Converting x-y to x+-y saves 3 bytes. --[[User:Pedro Oval|Pedro Oval]] 14:31, 19 February 2013 (PST)

:Oh yeah, ((integer)x - (3 <= x)) is equivalent to...
:* (integer)x - (2 < (integer)(x))
:* (integer)x - (((integer)(x)) == 3)
:* (integer)x + (((integer)(x)) / -3)
:* (integer)x - !(3 & ~(integer)(x))
:* (integer)x - (2 < llFloor(x))
:* (integer)x - ((llFloor(x)) == 3)
:* (integer)x + ((llFloor(x)) / -3)
:* (integer)x - !(3 & ~llFloor(x))
: the value of x will always be in the range [0.5, 4). Truncating or rounding it down to an integer result in it being in the range [0, 3], we want to further truncate this range to [0, 2]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:33, 18 February 2013 (PST)

:* (integer)x + (integer)(x * -0.3333333432674407958984375)
:* (integer)x - (2.9999997615814208984375 < x))

:Another reason for the excessive precision, I test a lot of code in LSLEditor, which uses doubles. If I want things to work I have to keep my constants in double precision land. I calculate most of them with the windows calculator and then just copy and paste. That way when I paste them back into the windows calculator I can work the math backwards and figure out where the constants came from. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:43, 18 February 2013 (PST)

== too many (, or not enough ) ==

<code>
return (0x3FF & (integer)(a * (0x800 >> b))) | (((c + (b = ((integer)a - (3 <= (a *= (0.0000152587890625 * (0x40000000 >> c)))))) << 10 ) | b);
</code>

count("(") != count(")") [[User:Cron Stardust|Cron Stardust]] 07:04, 27 June 2013 (PDT)

:I think that's a left over from a last minute refactoring. Fixed. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:36, 27 June 2013 (PDT)

:: Thanks! :D [[User:Cron Stardust|Cron Stardust]] 20:55, 27 June 2013 (PDT)

== Indeterminates ==

There's one more value that can be encoded and read back: indeterminate. Indeterminate values have a representation of FFC00000, see http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html#kevin_chart. They can be read through llList2CSV and they show as -nan. <source lang="lsl2">
default
{
state_entry()
{
float a=(float)"nan";
llOwnerSay(llList2CSV(["(float)\"nan\"", a]));
a=-a;
llOwnerSay(llList2CSV(["-a", a]));
a=(float)"inf"*0;
llOwnerSay(llList2CSV(["inf*0",a]));
a=llAcos(2);
llOwnerSay(llList2CSV(["acos(2)",a]));
}
}
/*outputs:
[08:05:05] Object: (float)"nan", nan
[08:05:05] Object: -a, -nan
[08:05:05] Object: inf*0, -nan
[08:05:05] Object: acos(2), nan
*/</source> (float)"-nan" does not work :( --[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 08:06, 6 September 2015 (PDT)

:I think I knew (float)"-nan" was borked, can't really do anything about it. I guess I'll multiple +/-inf by zero or one for the -nan generation. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 17:05, 6 September 2015 (PDT)

::It should be better now. Haven't compiled it. Probably should. No time now. Half-precision won't work right, it needs some TLC. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 17:45, 6 September 2015 (PDT)

:::Thanks a lot! fui is working perfectly, but iuf can't produce nan, only -nan. If it helps, I've found that while (float)"-nan" doesn't work, -(float)"nan" and -1*(float)"nan" do.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 18:34, 6 September 2015 (PDT)
:::Correction. (-1)*(float)"nan" doesn't produce -nan. The parentheses were important.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 08:21, 9 September 2015 (PDT)

::::That makes some perverse sense. I'll log in sometime this weekend and figure out a way to do this (hopefully without using a branch). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 15:26, 12 September 2015 (PDT)

== FUI2HexFloat ==
This fuction can t be compiled .
Error at the line if(e ^ 127)
e is a variable declared later

[[User:Miranda Umino|Miranda Umino]] ([[User talk:Miranda Umino|talk]]) 11:28, 14 September 2015 (PDT)

:it should compile now but it needs testing. --'''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:39, 14 September 2015 (PDT)

User talk:Strife Onizuka/Float Functions

2015-09-19T12:41:49Z

Pedro Oval: /* Try these */ Comment on test results of (float)"denormal" and (vector)"<denormal...>"

== Ever considered making a fui16? ==

I was just looking around for how I could union a float into a 16 bit integer, perhaps using the [http://en.wikipedia.org/wiki/Half-precision_floating-point_format IEEE 754-2008 half-precision] format. Yes, I know there would be losses, and I also know that SL olny has 32 bit integers. The final goal for my application is to pack two floats into a single integer, via bitshifting the first into the high range and then ORing with the second, a la:
<source lang="lsl2">
// To pack:
float a = PI;
float b = 4.2;
integer result = (fui16(a) << 0x10) | fui16(b);

// To unpack:
float c = i16uf(result >> 0x10); // Might need to perform some further magic here to account for the fact that the sign bit doesn't shift.
float d = i16uf(result & 0xFFFF);
</source>
Of course, in the general case one can't make assumptions about range and resolution. That said, in my application I ''can'' make such assumptions, and I'm just going to hack together something that works based on those assumptions. I'm just here feeding the fetish that resulted in these very-useful-to-me functions (fui, iuf) in the first place. >:D

{{Unsigned|Cron Stardust}}

:Lets see, I could either work on [[Template:LSL Function]] et al as to split the notes section in half, or I could write fui16 a most clever function. Hmmm. Fun clever coding or Template drudge. Half precision doesn't have the same range, grrrr... -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:57, 24 December 2012 (PST)

:Upon second though, I really don't want to dig into floating point math at the moment. Mostly you just need to add clipping to fui, change the constants and add infinity support to iuf. With clipping implemented the error correcting code can be removed. Here is my first crack at updating the constants. I've not tested it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:35, 24 December 2012 (PST)

<source lang="lsl2">
integer fui16(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union half-precision float to short integer
if((a)){//is it non zero?
integer b = (integer)(a < 0) << 15;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
return b | (integer)(a * 16777216.0);//the math overlaps; saves cpu time.
if(a > 65504.0)//Round up to infinity
return b | 0x7C00;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
return (0x3FF & (integer)(a * (0x800 >> b))) | (((c + (b = (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))))) << 10 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return (integer)((string)a == (string)(-0.0)) << 15;
}

float i16uf(integer a)
{//union short integer to half-precision float
if((a & 0x7C00) == 0x7C00)
return (1 | ((a << 16) >> 31)) * (float)"Infinity";
return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));
}
</source>

<source lang="lsl2">
// To pack:
float a = PI;
float b = 4.2;
integer result = (fui16(a) << 16) | fui16(b);

// To unpack:
float c = i16uf(result >> 16); // No magic needed, sign bit is handled correctly.
float d = i16uf(result);
</source>
::Just tested in SL with the following results: Had to place a closing paren in the first return statement of iuf16, I placed it just before the mult as I suspect that's what was intended. I wrote a simple ownersay of the existing test code which gave the following as the output: [[User:Cron Stardust|Cron Stardust]] 16:12, 25 December 2012 (PST)
<source lang="lsl2">
a = 3.141593 = 0xC90FDBp-22
= c = 3.140625 = 0xC9p-6
b = 4.200000 = 0x433333p-20
= d = 4.199219 = 0x433p-8</source>
::Further testing, looking for error cases, resulted in a lot of good: the functions seem to operate as they should. I tested using all the constants demonstrated on the Wikipedia article and only one failed to match perfectly: 0.0000000596046 doesn't encode to 0x0001, instead it results in 0x0000. All other values seem to work great. [[User:Cron Stardust|Cron Stardust]] 22:00, 25 December 2012 (PST)
:: Also tested that with <code>a = -2.0</code> and <code>b = -2.0</code> that everything works out: no issues happen with the sign bit status that I could detect - so I took the liberty of changing the comment in your code. [[User:Cron Stardust|Cron Stardust]] 22:34, 25 December 2012 (PST)

:::I'm willing to bet it's a lack of precision in their approximation. Try: 0.000000059604644775390625 -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:36, 26 December 2012 (PST)

:::I'm not 100% sure of the "<code>llFloor((llLog(a) / 0.6931471...)</code>" line but I think in this range it's accurate and we don't need to do any correction. The only way to know for sure is to try every value in the range [0.0001220703125, 65504.0]. I know it's not going to overflow so I've removed the overflow protection code. If you want to do that testing, here is the return line you would use which assumes that "c" is accurate: <code>return (0x3FF & (integer)((a / (float)("0x.004p"+(string)c)))) | (((c + 15) << 10 ) | b);</code> It has the added bonus of making fui16 LSLEditor safe. This was also a good demonstration of how the layers of correction code were bolted on. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:50, 26 December 2012 (PST)

This is a better version of what I was talking about but it needs extensive testing. If c is not accurate this will not work.
<source lang="lsl2">
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 15;//extremes will error towards extremes. No corrections are attempted.
return (0x3FF & (integer)((a * 0.03125 * (0x40000000 >> c)))) | ((c << 10) | b);
</source>
I've gone back and removed my string-float pow code since it can all be done with integers and float math. Faster this way. Less stressful for the sim.
-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:32, 26 December 2012 (PST)
=== Testing ===
Just run the following code and it will tell you if c is accurate for the entire half-precision range (this is one of the things iuf is really good for, iterating over every float value). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 02:55, 26 December 2012 (PST)
<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a))
{//is it non zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)))))))) << 23 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return ((string)a == (string)(-0.0)) << 31;
}

float iuf(integer a)
{//union integer to float
return ((float)("0x1p"+(string)((a | !a) - 150))) * ((!!(a = (0xff & (a >> 23))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer test(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union half-precision float to short integer
if((a))
{//is it non zero?
if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
return FALSE;//the math overlaps; saves cpu time.
if(a > 65504.0)//Round up to infinity
return FALSE;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
return (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))) - 1;
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return FALSE;
}

float i16uf(integer a)
{//union short integer to half-precision float
if((a & 0x7C00) == 0x7C00)
return (1 | ((a << 16) >> 31)) * (float)"Infinity";
return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));
}

list gBadBlockCounts;

default
{
state_entry()
{
llOwnerSay("beginning test");llResetTime();

integer badCount = 0;
integer badStart;

integer start = fui(i16uf(1) / 2.0);//start just before min value, these will get clipped to zero.
integer end = fui(65536.0);//stop just after infinity
integer i;
for(i = start;i < end; i++)
if(test(iuf(i)))
{
llSetText("bad: "+(string)i, <1.0, 0.0, 0.0>, 1.0);
if (badCount++ <= 0)
{
badStart = i;
llOwnerSay("Found bad number: " + (string) i);
}
}
else
{
llSetText("good: "+(string)i, <0.0, 1.0, 0.0>, 1.0);
if (badCount > 0)
{
llOwnerSay("Total of " + (string) badCount + " numbers, ending with " + (string) (i-1));
gBadBlockCounts = [badStart, i - 1] + gBadBlockCounts;
badCount = 0;
}
}
llSetText("test complete.\ntook " + (string) llGetTime() + " secs over " + (string) (end - start) + " values\nsaw " + (string) llGetListLength(gBadBlockCounts) + " bad blocks.\nTouch for list of bad.", <0.0, 1.0, 1.0>, 1.0);
state printout;
}

}

state printout
{
touch_end(integer index)
{
while (--index >= 0)
{
if (llGetListLength(gBadBlockCounts))
{
llRegionSayTo(llDetectedKey(index), 0,
"Bad blocks strided list, using stride pattern (block_start, block_end):"
);
llRegionSayTo(llDetectedKey(index), 0,
llDumpList2String(gBadBlockCounts, ", ")
);
}
else
{
llRegionSayTo(llDetectedKey(index), 0,
"Nothing to report."
);
}
}
}
}
</source>
::Tested this morning. Went bad at values 864026624 through 900508790. Not sure if there were further values: I set it up to run and then wen to work for the day, when I came back it had been yelling for a very long time... :P Will see what I can do, however while I can understand the code, I've not yet been able to get my mind in deep enough to understand the algorithm. [[User:Cron Stardust|Cron Stardust]] 18:55, 26 December 2012 (PST) EDIT: Just noticed that there was a function named test in there that wasn't used: I'd pasted in the fui16 function from above to make the code compile and run. That may have invalidated the test, so I've going to retest usung the "test" function in place of the fui16 call in state_entry. I've edited the above state_entry to reflect my current code.
::Just passed the 864026624 mark without errors, so yes: my previous test was invalid. Continuing testing - just like GLaDOS likes. [[User:Cron Stardust|Cron Stardust]] 20:59, 26 December 2012 (PST)

:::I should have thought of this sooner, we don't need to test every value, just the ones who's values surround where the value of "c" changes. We only need to test ummm 84 values... just the powers of two and the immediate lesser values. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:44, 27 December 2012 (PST)

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a))
{//is it non zero?
integer b = (integer)(a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)));
integer bb = ((integer)a - (3 <= a));
return (0x7FFFFF & (integer)(a * (0x1000000 >> bb))) | (((c + 126 + bb) << 23 ) | b);
}//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
return (integer)((string)a == (string)(-0.0)) << 31;
}

float iuf(integer a)
{//union integer to float
integer aa = 0xff & (a >> 23);
return ((float)("0x1p"+(string)((aa | !aa) - 150))) * ((!!aa << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer get_log2(float a)
{//we use the natural log because testing showed it's more accurate than log10.
return llFloor((llLog(a) / 0.69314718055994530941723212145818));//must be divide, multiplying the reciprocal adds extra corruption.
}

integer test_log2(integer power)
{
float a = (float)("0x1p"+(string)power);
float b = iuf(fui(a) - 1);//The underflow is in our favor and does what we want.
integer c = get_log2(a);
integer d = get_log2(b);
integer e = (c == power) && ((d + 1) == power);
// llOwnerSay(llList2CSV([power, c, d, Float2Hex(a), Float2Hex(b), int2hexdword(fui(a)), int2hexdword(fui(b)), e]));
return e;
}

default
{
state_entry()
{
integer start = -25;
integer end = 17;
integer i;
for(i = start; i <= end; i++)
if(!test_log2(i))
llOwnerSay((string)i);
}
}
</source>
:: Ok, so executed - though I'm leaving the other script running, and it seems good thus far; will report when it completes. The results from this new test are that I saw values reported in the following ranges: [-25, -16], -14, [-12, -2], [3, 17] -- [[User:Cron Stardust|Cron Stardust]] 19:14, 27 December 2012 (PST)

::: Well that is bad. Guess c is not accurate so we can't remove the correction code (the overflow code can still be removed). I wonder what happens if you feed it NaN. Probably need a special case just for that. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:45, 27 December 2012 (PST)

::: I remembered how the correction code works and I fused one of the moving parts. I don't think it's necessary for this range but I'm adding it back in. Since "c" could be off by one in either direction, this gives us three possible outcomes when generating new-a.
:::# It's too small, the result is that new-a is in range [0.5, 1)
:::# C is correct, new-a is in range [1, 2)
:::# It's too big, the result is that new-a is in range [2,4)
:::Solution? Map these three outcomes to three consecutive values so that they can be used to adjust c. Truncating new-a gives us [0.5, 1)->0, [1, 2)->1, [2,4)->{2,3}. Yes they are consecutive but we need to map the final set to a single value. Hence the subtract by (3 <= a).
:::It's a shame I never documented which edge cases this code fixed. It would take a lot of the guess work out. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:22, 27 December 2012 (PST)
: For what it's worth, the old test code finally completed! Took about 6-8 days continuous* calculation in my home region. (* script reported 521479.8 seconds, but I'd had to stop and fix a UI error after several hours of computation, and picked up where I'd left off.) Here's the report: [[User:Cron Stardust|Cron Stardust]] 18:14, 5 January 2013 (PST)
<pre>
Bad blocks list, using stride pattern [block_start, block_end]:
[
[1191182336, 1191182336], [1182793721, 1182793727], [1174405120, 1174405120], [1166016505, 1166016511],
[1157627901, 1157627903], [1149239293, 1149239295], [1140850685, 1140850687], [1132462077, 1132462079],
[1124073469, 1124073471], [1115684861, 1115684863], [1107296255, 1107296255], [1098907647, 1098907647],
[1090519039, 1090519039], [1048575999, 1048575999], [1040187390, 1040187391], [1031798782, 1031798783],
[1023410174, 1023410175], [1015021564, 1015021567], [1006632956, 1006632959], [ 998244348, 998244351],
[ 989855740, 989855743], [ 981467132, 981467135], [ 973078524, 973078527], [ 964689912, 964689919]
]
</pre>

== fui support for NaN and Inf ==

I must be one of the few people who have found an actual use to fui :) I'm using it for compact lossless transmission of floats over HTTP to a PHP server in base 64 (after removing the == and the trailing A's), and I decode it in the server using unpack() and some string manipulation. I would love to see fui support NaN, Inf and -Inf, but more for the sake of completion than because I have a real use (except possibly debugging). Maybe it's as straightforward as adding this on top?
<source lang="lsl2">
if ((string)a == "Infinity") return 0x7F800000;
if ((string)a == "-Infinity") return 0xFF800000;
if ((string)a == "NaN") return 0x7FC00000; // to choose one
</source>
I guess there's no way to extract the actual bits of a NaN, or is there? --[[User:Pedro Oval|Pedro Oval]] 05:09, 26 December 2012 (PST)

Oops, I've corrected "Inf" to read "Infinity" above. --[[User:Pedro Oval|Pedro Oval]] 07:58, 26 December 2012 (PST)

:Sure, I don't see why not. I'll think about ways of doing it (I'm not sure if successive tests is really the best way of doing so). The reason Infinity was never handled was that LSO doesn't allow it. These functions were originally conceived before Mono was on the horizon (at the time I had wanted to build an LSO bytecode emulator in LSL). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:01, 27 December 2012 (PST)
:It's done. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:43, 27 December 2012 (PST)

::You will be pleased (or horrified) to see that [[Float2Hex]] and [[Float2Sci]] both support NaN and Infinities now. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:22, 29 December 2012 (PST)

== Alternate code ==

I was pondering alternate ways to <code>b >> (13 + ((b & 0x3FFF) == 0x2000))</code> because it's just so ugly.
*<code>b >> (((0x3FFF & b ^ 0x1FFF) + 0x34001) >> 14)</code> - we flip the low bits, so if all of them are on, that is to say our condition has been met, adding one will cause a carry into the 14th bit.
*<code>b >> ((0x38000 - (0x3FFF & b ^ 0x2000)) >> 14)</code> - similar to above, we turn the high bit off, so if it's zero it doesn't cause a carry from above.
*<code>b / ((((0x3FFF & b ^ 0x1FFF) + 0x4001) & 0xC000) >> 1)</code>
It's a shame there isn't a way to further improve it. It's an ugly mess that only gets uglier. ~_~ -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:22, 28 December 2012 (PST)

= Bugs in iuf and fui =
== Bug in iuf ==

iuf does not support exponent parts of 2-104 or below. The reason is that in an intermediate step, it is trying to calculate 0x1p-127 or below, which yields 0. For exaple, iuf(0x0bffffff) returns 0, while iuf(0x0c00000) returns the correct result.

Rather than trying to find a fix, I created my own iuf that seems to work, even if it's unoptimized and not very fast (though it contains a small trick to reduce the total number of iterations to a maximum of 25 or so):

<source lang="lsl2">
float iuf(integer e)
{
float result = e & 0x7FFFFF;
integer sign = e & 0x80000000;
e = ((e >> 23) & 0xFF) + -150;
// deal with Inf/NaN
if (e == 105) { if (result) return (float)"NaN"; if (sign) return (float)"-Inf"; return (float)"Inf"; }
if (e ^ -150)
{
result += 0x800000;
while (e > 9) { result *= 512; e += -9; }
while (e < -9) { result *= 0.001953125; e += 9; }
while (e > 0) { result *= 2; --e; }
while (e < 0) { result *= 0.5; ++e; }
if (sign) return -result;
return result;
}
if (sign) return -(result*1e-45);
return result*1e-45;
}
</source>

A fix might be along the lines of not applying the -23 offset in advance (as usage of -150 implies) but postmultiplying by 2^-23 instead. I haven't tried though. --[[User:Pedro Oval|Pedro Oval]] 09:37, 8 February 2013 (PST)

:If the denormalized range isn't working then Float2Hex is likely broken too. hmmm -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:11, 9 February 2013 (PST)

::It's not just the denormal range, it affects the normal range too. 2-104 is small but not denormal; the denormal range starts at 2-127. --[[User:Pedro Oval|Pedro Oval]] 16:22, 9 February 2013 (PST)

:::I start the denormalized range a power of two early but if it's failing all the way up to -104... that's a big problem. I'll have to play with it. Multiplying by a power of two shouldn't trash the mantissa. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:29, 11 February 2013 (PST)

::::Maybe I misunderstood. If what you meant is that hex floating point format is unable to produce denormal numbers, then that's exactly the problem, yes. 0x1p-127 produces 0, even if the denormal range can represent numbers down to 0x1p-149. What I meant is that inputs to the function representing exponents of -104 or below failed (as these involved calculation of 0x1p-127 or below). Now some good news. The new function revised to use [[llPow]] works correctly for small exponents and seems to work correctly for the rest. Also, under Mono at least its performance is about 2.5 times that of the old (string operations are s-l-o-w). --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)

== Bug in fui ==

Alas, iuf is not the only one with problems. For exponents of -2 or less, and mantissas in the vicinity of 0x7FFFFF, results are almost always wrong. Examples:

* <code>fui(iuf(0x017fffdd)) = 0x01ffffee</code> (the first one failing with mantissa > 0x7FFF00, exponent is -124)
* <code>fui(iuf(0x017fffff)) = 0x01ffffff</code> (the last one failing with that exponent; all in the middle also fail)
* <code>fui(iuf(0x01ffffc5)) = 0x027fffe2</code> (next one failing)
* <code>fui(iuf(0x01ffffff)) = 0x027fffff</code> (last one with that exponent, all in the middle fail)
* <code>fui(iuf(0x037ffffd)) = 0x03fffffe</code> (for this exponent the failure range is shorter - just 3 numbers)
* <code>fui(iuf(0x38ffffff)) = 0x38ffffff</code> (for a few exponents there are no failures at all; this is an example)
* <code>fui(iuf(0x3e7fffff)) = 0x3effffff</code> (last one failing)

I've manually checked some of the iuf conversions and they worked correctly with the code I posted above, so the problem is in fui. For example: <code>if (iuf(0x25fffff6) == .44408894e-15) llOwnerSay("iuf ok");</code> says "iuf ok", but fui(.44408894e-15) gives 0x267ffffb, not 0x25fffff6. --[[User:Pedro Oval|Pedro Oval]] 11:48, 8 February 2013 (PST)

:Are you doing these tests in Mono, LSO or both? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:48, 9 February 2013 (PST)

::I tested the full range only in Mono, but a quick run seems to show that LSO is affected in exactly the same way. At least the range starts in the same number (0x017fffdd) and produces the same result (0x01ffffee). --[[User:Pedro Oval|Pedro Oval]] 16:31, 9 February 2013 (PST)

:It will take me some time (maybe a few weeks) to get around to this, I'm very busy currently. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:14, 9 February 2013 (PST)

::I admit to kicking off Pedro's investigation, as I tried to use iuf and fui in Mono and found that fui (iuf (x) ) gave zero for all values of x from 1 to 3 million, at which point when I gave up :) They seem to work a lot better in LSO from my briefer tests so far. [[User:Omei Qunhua|Omei Qunhua]] 15:52, 9 February 2013 (PST)

= Try these =
I've swapped out the hack pow method for the real function. I'm hoping this will fix iuf.

I've also expanded the compressed lines so that they are easier to tinker with. I've enlarged the supported range of <code>a</code> in the error calculation, the range supported has changed from [0.5, 4) to [0.25, 4).

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
c -= (c >> 31) | 1;//this sets up an error towards the zero
a /= llPow(2.0, c);//a should now be in the range [0.25, 4).
integer d = (integer)a + (0.5 >= a) - (3 <= a);//This calculates the actual error. It does so by mapping the value of a to the error.
//Specifically we take advantage of the where the normalization bit has been shifted.
//[0.25, 0.5) == -2, [0.5, 1) == -1, [1,2) == 0, [2, 4) == 1 ~ note the actual values of d are off by two.
llOwnerSay(llList2CSV([0x800000 == (0xF800000 & (integer)(a * (0x2000000 >> d))), c, d, a, (a < 0.25) || (a > 4)]));//first value tells you if you got d right or wrong.
//The check works by seeing where the normalization bit has been shifted. The normalization bit gets chopped off with 0x7FFFFF.
return (0x7FFFFF & (integer)(a * (0x2000000 >> d))) | (((c + 125 + d) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
integer b = 0xff & (a >> 23);
return llPow(2.0, (b | !b) - 150) * (((!!b) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>
::The above fails at every number from the range I tested (mantissa in the vicinity of 0x3FFFFF, exponent -2 and below). --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)
:::More specifically, it seems to fail for all numbers with bit 22 set (mask 0x00400000). --[[User:Pedro Oval|Pedro Oval]] 16:53, 13 February 2013 (PST)

This uses a modified error correction code. I'm not sure if it will be better or worse. It has the potential to run out the high side of the stated bounds on <code>a</code> but I don't think this will be the case. We shall have to see.

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
--c;//Make it error down. Hopefully this won't shift anyone into the [4, 8) range.
a /= llPow(2.0, c);//a should now be in the range [0.5, 4), we assume no error is added.
integer d = (integer)a - (3 <= a);//This calculates the actual error. As it turns out, the integer portion of a is {0,1,2,3} the errors in c are {-1,0,1,1}
llOwnerSay(llList2CSV([0x800000 == (0xF800000 & (integer)(a * (0x2000000 >> d))), c, d, a]));
return (0x7FFFFF & (integer)(a * (0x1000000 >> d))) | (((c + 126 + d) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
integer b = 0xff & (a >> 23);
return llPow(2.0, (b | !b) - 150) * (((!!b) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>
::The above passed the test in the range where version 1 failed (vicinity of 0x7fffff for mantissa and exponents up to -2). Also, fui(iuf(i))==i produces no mismatch in a random sample of 2M integers (version 1 produced 2 mismatches in a random sample of 1M). Looks promising. I'm not testing it in LSO though - too slow :) --[[User:Pedro Oval|Pedro Oval]] 06:24, 12 February 2013 (PST)

:::A distributed computation over the whole range of integers except those representing NaN and Inf (I used 64 scripts in 16 sims computing 64M numbers each) has showed that the fui and iuf functions above work flawlessly for every supported integer. Those representing NaN were not tested for the obvious reason of unavoidable data loss. We have a winner. Thank you so very very much. --[[User:Pedro Oval|Pedro Oval]] 21:34, 13 February 2013 (PST)

::::This is kind of scary, I wasn't expecting this version to work. The other version was the one I was expecting to work. Sounds like there were two bugs. I'll compress it back into an optimized form. This makes me worry about Float2Hex working, since it sounds like the string->float typecast doesn't like very small numbers. I wonder if there is a cap on the exponent? I shall have to test. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:08, 14 February 2013 (PST)

::::: I've made some experiments now. <code>(float)"something"</code> seems to fail under Mono whenever "something" results in a number less than <code>0x1p-126</code>, no matter if it's hex or otherwise.

::::: However, <code>(vector)"<something,something,something>"</code> and <code>(rotation)"<something,something,something,something>"</code> both work fine with numbers in that range even in Mono.

::::: Go figure... -- [[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 05:41, 19 September 2015 (PDT)

<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if((a)){//is it greater than or less than zero?
integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
integer c = ~-llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= llPow(2.0, c)))))) << 23 ) | b);
}//the previous requires a lot of unwinding to understand it.
if(a == 0)//Just because it's not greater than or less than zero doesn't mean it's non-zero.
return ((string)a == (string)(-0.0)) << 31;//for grins, detect the sign on zero. it's not pretty but it works.
//Mono does not support indeterminates so I'm not going to worry about it.
return 0x7FFFFFFF;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}

float iuf(integer a)
{//union integer to float
if((a & 0x7F800000) == 0x7F800000)
return (1 | (a >> 31)) * (float)llList2String(["NaN","Infinity"], !(a & 0x7FFFFF));
return llPow(2.0, (a | !a) - 150) * (((!!(a = (0xff & (a >> 23)))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));
}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.
</source>

Lots to comment on, and MediaWiki's standard for follow-up responses is quite inconvenient for this purpose. I hope you don't mind if I post this reply without indentation.

First, I'm pretty sure that the failure of the previous function must be due to a bug somewhere, not to the algorithm, given that the failure pattern seems very clear and consistent. I haven't analyzed it so I can't tell more for now.

Second, your sentence "I wonder if there is a cap on the exponent?" suggests to me that you have missed my last reply in the [[#Bug in iuf|iuf bug discussion]].

Third, the "compressed" versions work, though I haven't tested the whole range, just a random sample of 10M integers.

Fourth, the NaN test is flawed. if((a)) is equivalent to if(!(a==0)) and is true for NaNs.

Fifth, the usual NaN returned by gcc is 0x7FC00000, so I suggest to use that for possible interoperability. It has the "quiet" bit set and nothing else.

Sixth, I see quite some room for memory optimizations in Mono for both functions, while minimally affecting performance if at all. Changes include:

* Changing division to multiplication where possible.
* Changing <= to < and >= to > where possible. a <= b is equivalent to !(a > b) both in size and in behavior even with NaNs (sad, I know).
* Changing subtraction to addition of opposite (a-b to a+-b).
* Changing -constant to its hex representation.
* Changing 2.0 to 2
* Changing << constant to * constant (>> and / take the same bytes so no gain there, plus there are sign issues).
* Changing (a & constant) == constant to !(~a & constant).
* Using localint^localint instead of 0.
* Change the logic of Infinity and NaN in iuf, to get rid of the list, using that (float)"Inf" yields infinity and that parsing stops at the first invalid character without invalidating the previous results.
* Changing (string)-0.0 to "-0.000000" (this one is the only one I don't have reliable experimental results to back, but I believe it will save memory; it almost surely will perform better by not needing to build that string at run time).

Here are Mono-memory-optimized versions taking into account all of these:

<source lang="lsl2">
integer fui(float a)//Mono Safe, ????LSO Safe???? (untested), Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if(a){//is it nonzero?
integer b = (a < 0) * 0x80000000;//the sign, but later this variable is reused to store the shift
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
if(a > 1e-45)//It should at this point, except if it's NaN
{
integer c = ~-llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a + -(3 <= (a *= llPow(2, -c)))))) * 0x800000 ) | b);
}//the previous requires a lot of unwinding to understand it.
return 0x7FC00000;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}
return ((string)a == "-0.000000") * 0x80000000;//for grins, detect the sign on zero. it's not pretty but it works.
}//Mono does not support indeterminates so I'm not going to worry about it.

float iuf(integer a)
{//union integer to float
if(!(~a & 0x7F800000))
return (float)llGetSubString("-nan-inf", 4 * !(a & 0x7FFFFF) + (a > (a^a)), 7);
return llPow(2, (a | !a) + 0xffffff6a) * (((!!(a = (0xff & (a >> 23)))) * 0x800000) | ((a & 0x7fffff))) * (1 | (a >> 31));
}
</source>
Further possible optimizations include replacing other divisions with multiplications where possible (llLog(a) / 0.693... might be a candidate, but it's at the core of the algorithm so I didn't dare) and replacing <= with < in the (3 <= ...) if possible. If it's equivalent to (2 < ...) then the latter is preferable. Also, although I've not touched them, source code wise, the floats used have an unnecessary precision; using respectively 2.3509887e-38, 1e-45, 3.4028235e+38, and 0.6931472, the results are the same. You can check that doing: float f1 = 2.3509887016445750159374730744445e-38; float f2 = 2.3509887e-38; if (f1 == f2) llOwnerSay("yes"); outputs yes, and similarly for the rest. Doubles are not supported after all.

For the sake of verifiability, here's my simpler test program (not the distributed one, although it's along the same lines):
<source lang="lsl2">
string tohex(integer i)
{
string hex = "0123456789ABCDEF";
string result;
integer iter = 9;
while (--iter)
{
result = llGetSubString(hex, i & 0xF, i & 0xF) + result;
i = i >> 4;
}
return result;
}

default
{
state_entry()
{
if (fui(iuf(0x7F800000)) ^ 0x7F800000) llOwnerSay("Fail at +inf");
if (fui(iuf(0xFF800000)) ^ 0xFF800000) llOwnerSay("Fail at -inf");
if (fui(iuf(0x7FC00000)) ^ 0x7FC00000) llOwnerSay("Fail at NaN1");
if (fui(iuf(0xFFC00000)) ^ 0x7FC00000) llOwnerSay("Fail at NaN2");
if (fui(iuf(0x7FC0FFFF)) ^ 0x7FC00000) llOwnerSay("Fail at NaN3");
if (fui(iuf(0xFFC00001)) ^ 0x7FC00000) llOwnerSay("Fail at NaN4");
if (fui(iuf(0x00000000)) ^ 0x00000000) llOwnerSay("Fail at 0.0");
if (fui(iuf(0x80000000)) ^ 0x80000000) llOwnerSay("Fail at -0.0");
if (fui(iuf(0x00000001)) ^ 0x00000001) llOwnerSay("Fail at 1e-45");
if (fui(iuf(0x80000001)) ^ 0x80000001) llOwnerSay("Fail at -1e-45");
if (fui(iuf(0xFF7FFFFF)) ^ 0xFF7FFFFF) llOwnerSay("Fail at ~ -1e38");
integer a;
integer iter;
while (++iter)
{
integer rand = (integer)llFrand(65536) + 65536 * (integer)llFrand(65536);
if (!(iter & 0xFFFF)) llSetText((string)iter, <1,1,1>, 1);

if (fui(iuf(rand)) != rand) // we let it run for NaNs too to detect crashes
{
if (~rand & 0x7F800000)
{
llSetText("Fail at rand = 0x" + tohex(rand) + ", fui(iuf(rand)) = 0x" + tohex(fui(iuf(rand))), <1,1,1>,1);
return;
}
}
}
llSetText("Done", <1,1,1>, 1);
}
}
</source>
I simply let it run while desired.

--[[User:Pedro Oval|Pedro Oval]] 11:02, 15 February 2013 (PST)

:I hadn't seen your previous comment, thank you for pointing it out. I'll try to patch Float2Hex so it doesn't use exponents less than -127 (it use to work on Mono ~_~).

:You are correct, the extra precision is unnecessary for single precision. I use these values because Float2Hex uses them, and I've written versions of Float2Hex that support higher precisions. I wrote both originally in ESL (LSL fed through a C Pre-processor) with extensive use of macros.

:I tend to optimize for LSO bytecode and stack size (I know it's insane but old habits die hard). Which is why I wasn't using llPow. I'm not surprised there is a bytecode savings between 2 and 2.0 for Mono but is it really faster? I would have though the compiler would have put in the implicit typecast there... unless LL got smart... hmmm. Anyway we are well beyond optimizing for LSO.

:You could try flipping the divide in the log2 calculation, I'm not sure if the error recovery is good enough. My recollection from my initial testing was that using a multiply instead of the divide widened the range of the errors.

:I never wanted to committing to inlining "-0.000000" in fear they might change the typecast on me. We won that fight a few years ago so it should be ok.

:Quick question, what does the following do? Trying to figure out how screwed I am. I am hoping to avoid having Float2Hex revert to base 10 for |x| < 0x1p-127 (I don't even know of a good way to do that x_x).
<source lang="lsl2">default {
state_entry() {
llOwnerSay((string)(0.0 != (float)"0x0.4p-127"));
}
}</source>

:Unless testing proves otherwise, we don't want to swap in a multiplication for a shift, at the CPU level shift should be faster. Swapping a subtract out for an add-negation similarly won't give you much as negation would be an extra instruction (unless the negation is being done on a constant than it's no extra).

:1e-45 makes me uneasy. I know it works but it just looks wrong to me. I am cool with excessive precision.

:I've made a few changes. I couldn't help myself. I used the dreaded negative indexing on llGetSubString, ''with wraparound''. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:16, 16 February 2013 (PST)
<source lang="lsl2">
integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe
{//union float to integer
if(a){//is it nonzero?
integer b = (a < 0) * 0x80000000;//the sign
if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
if(a > 3.4028234663852885981170418348452e+38)//Round up to infinity
return b | 0x7F800000;//Positive or negative infinity
if(a > 1.4012984643248170709237295832899e-45){//It should at this point, except if it's NaN
integer c = ~-llFloor(llLog(a) * 1.4426950408889634073599246810019);//extremes will error towards extremes. following yuch corrects it
return b | (0x7FFFFF & (integer)(a * (0x1000000 >> c))) | ((126 + (c = ((integer)a - (3 <= (a *= llPow(2, -c))))) + c) * 0x800000);
}//the previous requires a lot of unwinding to understand it.
return 0x7FC00000;//NaN time! We have no way to tell NaN's apart so lets just choose one.
}//Mono does not support indeterminates so I'm not going to worry about them.
return ((string)a == "-0.000000") * 0x80000000;//for grins, detect the sign on zero. it's not pretty but it works.
}

float iuf(integer a)
{//union integer to float
if(!(0x7F800000 & ~a))
return (float)llGetSubString("-infnan", 3 * ~!(a & 0x7FFFFF), ~a >> 31);
return llPow(2, (a | !a) + 0xffffff6a) * (((!!(a = (0xff & (a >> 23)))) * 0x800000) | (a & 0x7fffff)) * (1 | (a >> 31));
}
</source>

::The version with multiply turned out to work fine in a sample of ~600M random numbers, so yay! On the bad news side, the test program you asked me to run returns 0. As I said, 1p-127 returns 0 already, so no surprise there, but I tested this:
<source lang="lsl2">
default
{
state_entry()
{
llOwnerSay((string)(0.0 != (float)"0x0.ffffffp-126"));
llOwnerSay((string)(0.0 != (float)"0x1.0p-126"));
}
}
</source>
::and got 0 and 1. So I'm afraid hex notation refuses to produce any denormal at all. <strike>A strategy you can maybe use for denormals is to treat them as a special case multiplying them by a power of two, so they come into a tractable range. But I haven't checked the source so I may be off here.</strike> (Oops, got your point now - there may be a way using part of the strategy I mention, I'll think about something)

::As for optimizations, I like your "risky" rewriting of llGetSubString, and of course it works. I know mults are slower than shifts (if that's what the code is compiled to in the end, which is questionable), but the difference, just maybe ten cycles or so, is really unnoticeable when there's a whole burden of task switching and other stuff going on. For that reason I tend to always optimize for memory. In the above case, it will matter little if the function takes 30000 or 30010 cycles to execute, just as an example to make my point (I'm sure the actual numbers will be different). Same with minus sign: the extra CPU burden will be insignificant (1 cycle probably). I've tried to test these differences but I never got conclusive results because noise level exceeds signal level by far, which just proves how insignificant the difference is. I tend to run out of space in scripts so I mostly optimize for memory. While I get to 60K+ code size often, I have yet to run into an application where shoving cycles that way gains anything noticeable. Also, I started to test this for Omei because she intended to use it in a memory-tight application. The space savings can make a difference.

::The int-to-float implicit conversion seems to add an explicit cast, as an int constant is 6 bytes, a float constant is 10, and an integer implicitly or explicitly cast to float takes 7. By the way, -~-x is a saving vs. 1-x and vs. 1+-x (1 byte per unary sign vs. 6 bytes the integer constant, 8 the subtraction and 4 the addition). I have Mono size measurements here: [[User:Pedro Oval/Mono code memory usage]].

::As for the 1e-45, OK, though I like it because it also reflects the loss of precision that happens in denormals. But it's my opinion that using the whole expansion in the comparison to detect a NaN is overkill, as any number between 1e-45 and 2.35e-38 will do. For example, 1e-40 is equally valid and doesn't clobber the source so much. --[[User:Pedro Oval|Pedro Oval]] 19:36, 17 February 2013 (PST)

::Alas, it's worse than I thought. 1.17e-38 (a denormal) works fine, but (float)"1.17e-38" returns 0. Not sure when did glibc stop supporting denormals. --[[User:Pedro Oval|Pedro Oval]] 19:59, 17 February 2013 (PST)

:::I've put -~- back. I can't thank you enough for all your testing. I totally agree, optimizing for size is the main concern. I didn't remember this about logarithms that logab * logba = 1. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:38, 17 February 2013 (PST)

:::Crap. Both Float2Sci and Float2Hex are screwed. Without having access to the source for the Mono compiler we can't be sure it's glibc or Mono, though we can confirm it's glibc that's bugged by checking how it works with LSO. I may just have to manifest at an upcoming [[Simulator_User_Group|Simulator]]/[[Server_Beta_User_Group|Server_Beta]] User Group meeting and complain. should open up a ticket on jira first. hmmm. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])

::::Duh, good point. It's a Mono-only quirk. (float)"0x1p-127", (float)"0x1p-149", and (float)"1e-45" are all nonzero in LSO, and the latter two are equal to 1e-45 as expected. About the latest change, I fail to see the gain in moving the sign of c to the <code>-~-llFloor</code> line, as that forces a subtraction later which eats 4 extra bytes. Could it not remain as <code>integer c = ~-llFloor...</code>, then <code>...llPow(2, -c))))) + c)</code>? --[[User:Pedro Oval|Pedro Oval]] 20:23, 18 February 2013 (PST)

:::::Of course it can but why should it make a difference as we have just moved the negation further down. Am I missing something? Please tell me that subtraction isn't more expensive than addition. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:47, 18 February 2013 (PST)

::::::Sorry to bring bad news but yes: addition of two local integers takes 4 bytes, as does multiplication. But subtraction takes 8, as do division, mod and shift. "!" takes 3 bytes, while "~" and "-" take 1 each. Take a look at the table I linked to. You'll want to cry. As for the several variants you enumerate below, regrettably, float to integer cast takes 5 bytes, which is more than leaving it as <= instead of < (3 extra bytes). I think function calls need at least as many bytes as their name, so I wouldn't go that route. Not 100% sure there though. Converting x-y to x+-y saves 3 bytes. --[[User:Pedro Oval|Pedro Oval]] 14:31, 19 February 2013 (PST)

:Oh yeah, ((integer)x - (3 <= x)) is equivalent to...
:* (integer)x - (2 < (integer)(x))
:* (integer)x - (((integer)(x)) == 3)
:* (integer)x + (((integer)(x)) / -3)
:* (integer)x - !(3 & ~(integer)(x))
:* (integer)x - (2 < llFloor(x))
:* (integer)x - ((llFloor(x)) == 3)
:* (integer)x + ((llFloor(x)) / -3)
:* (integer)x - !(3 & ~llFloor(x))
: the value of x will always be in the range [0.5, 4). Truncating or rounding it down to an integer result in it being in the range [0, 3], we want to further truncate this range to [0, 2]. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:33, 18 February 2013 (PST)

:* (integer)x + (integer)(x * -0.3333333432674407958984375)
:* (integer)x - (2.9999997615814208984375 < x))

:Another reason for the excessive precision, I test a lot of code in LSLEditor, which uses doubles. If I want things to work I have to keep my constants in double precision land. I calculate most of them with the windows calculator and then just copy and paste. That way when I paste them back into the windows calculator I can work the math backwards and figure out where the constants came from. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:43, 18 February 2013 (PST)

== too many (, or not enough ) ==

<code>
return (0x3FF & (integer)(a * (0x800 >> b))) | (((c + (b = ((integer)a - (3 <= (a *= (0.0000152587890625 * (0x40000000 >> c)))))) << 10 ) | b);
</code>

count("(") != count(")") [[User:Cron Stardust|Cron Stardust]] 07:04, 27 June 2013 (PDT)

:I think that's a left over from a last minute refactoring. Fixed. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:36, 27 June 2013 (PDT)

:: Thanks! :D [[User:Cron Stardust|Cron Stardust]] 20:55, 27 June 2013 (PDT)

== Indeterminates ==

There's one more value that can be encoded and read back: indeterminate. Indeterminate values have a representation of FFC00000, see http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html#kevin_chart. They can be read through llList2CSV and they show as -nan. <source lang="lsl2">
default
{
state_entry()
{
float a=(float)"nan";
llOwnerSay(llList2CSV(["(float)\"nan\"", a]));
a=-a;
llOwnerSay(llList2CSV(["-a", a]));
a=(float)"inf"*0;
llOwnerSay(llList2CSV(["inf*0",a]));
a=llAcos(2);
llOwnerSay(llList2CSV(["acos(2)",a]));
}
}
/*outputs:
[08:05:05] Object: (float)"nan", nan
[08:05:05] Object: -a, -nan
[08:05:05] Object: inf*0, -nan
[08:05:05] Object: acos(2), nan
*/</source> (float)"-nan" does not work :( --[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 08:06, 6 September 2015 (PDT)

:I think I knew (float)"-nan" was borked, can't really do anything about it. I guess I'll multiple +/-inf by zero or one for the -nan generation. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 17:05, 6 September 2015 (PDT)

::It should be better now. Haven't compiled it. Probably should. No time now. Half-precision won't work right, it needs some TLC. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 17:45, 6 September 2015 (PDT)

:::Thanks a lot! fui is working perfectly, but iuf can't produce nan, only -nan. If it helps, I've found that while (float)"-nan" doesn't work, -(float)"nan" and -1*(float)"nan" do.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 18:34, 6 September 2015 (PDT)
:::Correction. (-1)*(float)"nan" doesn't produce -nan. The parentheses were important.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 08:21, 9 September 2015 (PDT)

::::That makes some perverse sense. I'll log in sometime this weekend and figure out a way to do this (hopefully without using a branch). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 15:26, 12 September 2015 (PDT)

== FUI2HexFloat ==
This fuction can t be compiled .
Error at the line if(e ^ 127)
e is a variable declared later

[[User:Miranda Umino|Miranda Umino]] ([[User talk:Miranda Umino|talk]]) 11:28, 14 September 2015 (PDT)

:it should compile now but it needs testing. --'''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:39, 14 September 2015 (PDT)

GIMP Layers to SL Animated Texture

2015-08-05T21:24:29Z

Pedro Oval: Update to version 2.0.2

This is a GIMP script (written in Script-Fu, the Scheme-based scripting language that GIMP uses) that takes the layers of an image representing an animation, and converts them into a texture suitable for use with '''[[llSetTextureAnim]]'''.

== Installation ==

Copy and paste the script below into a simple text editor of your choice (Notepad is probably the best choice for Windows systems). Save it into your scripts folder with the extension .scm - the suggested name is "layers-to-sl-animation.scm". The scripts folder can be found by going to ''Preferences > Folders > Scripts''. After it's in the ''Scripts'' folder, do a refresh by selecting ''Filters > Script-Fu > Refresh Scripts''.

== Usage ==

First, create or load an animation with one layer per frame (the first frame is the bottom layer). An existing GIF animation will work for this purpose, or you can create your own, or import one if you have enough memory. Version 1.0 of this script required to use the Unoptimize filter first in some cases; as of version 2.0, that functionality is already built in.

Next, ensure that it has the correct size and number of frames desired. It's preferable to have a plan at this point of what the final resolution will be, and how many horizontal and vertical frames the final image will have. If you are not going to use all the frames in your final image (for example, you have 5 frames and decide to do a 3x2 image), you still need to fill the holes. Create empty layers or duplicate existing ones until completing the final frame count. If you need to rescale the image at this point and the image is indexed, it's better if you convert it to RGB mode first.

Now invoke the script. It is invoked using ''Script-fu > SecondLife > Frames to texture...''

A window will appear, asking the number of horizontal and vertical frames of the final image. As noted above, that number must match the number of frames in your layers, or the script will show an error instead. It also asks whether you want to generate an animation script in a message window, and the frame rate to use for that script. Click OK and you will get a new image window consisting of the original frames arranged according to the specified values, suitable for use in SL. Now you can save the file and upload it to SL. If you had the script generation option checked, you can select the code from the window that appears, copy it, and paste it as a LSL script replacing the contents.

== The script ==

<source lang="scheme">
; Layers to SL Texture Animation, version 2.0.2
;
; Written by Pedro Oval, 2010-12-04.
; Donated to the public domain.
; Thanks to Digital Dharma for the suggestions.

(define (script-fu-layers-to-sl-anim curimg curdrawable xframes yframes showscript face fps)
(let ()

; Local function: check if a string contains a substring
(define (contains-ci str substr)
(define i 0)
(define lensub (string-length substr))
(define imax (- (string-length str) lensub))
(if (negative? imax)
#f
(begin
(define found #f)
(while (and (not found) (<= i imax))
; We make a case-insensitive comparison.
(if (string-ci=? (substring str i (+ i lensub)) substr)
(set! found #t)
(set! i (+ i 1))))
found)))

; Read the layer IDs and the total number of layers from the original image.
(define layerset (gimp-image-get-layers curimg))
(define numframes (car layerset))
(set! layerset (cadr layerset))

; The frame size X and Y is the size of the original image.
(define framesizex (car (gimp-image-width curimg)))
(define framesizey (car (gimp-image-height curimg)))

; Get the image type; indexed images need special treatment.
(define imgtype (car (gimp-image-base-type curimg)))

; Check if the given number of horizontal x vertical frames matches
; the number of layers in the original image. If yes, proceed; if not,
; show an error message.
(if (= numframes (* xframes yframes))
(begin
; New image
(define img (car (gimp-image-new (* framesizex xframes) (* framesizey yframes) imgtype)))
; We create a new image, so we disable undo for it; to "undo"
; the script, just close the new image.
(gimp-image-undo-disable img)

(if (= imgtype INDEXED)
(begin
; Indexed images need the palette to be copied to the new image.
(define palette (gimp-image-get-colormap curimg))
(gimp-image-set-colormap img (car palette) (cadr palette))))

; Initialize previous layer info to 0, as there's no previous layer yet.
; On the next iteration it will hold a list with:
; layer ID, offset X, offset Y.
(define prevlayerinfo 0)

; Loop betwen 0 and numframes - 1.
(define frame 0)
(while (< frame numframes)
; For each layer/frame:
(begin

; Show progress as the current frame relative to the number of frames.
(gimp-progress-update (/ frame numframes))

; Read the individual layer ID, starting from the bottom.
(define oldlayer (vector-ref layerset (- numframes frame 1)))

; Create new layer as a copy of this one and add it to the image.
(define newlayer (car (gimp-layer-new-from-drawable oldlayer img)))
(gimp-image-add-layer img newlayer -1)

; Add alpha if the layer doesn't have it.
(if (= (car (gimp-drawable-has-alpha newlayer)) FALSE)
(gimp-layer-add-alpha newlayer))

; Calculate the offsets relative to the destination rectangle,
; and the crop size.
(define offsets (gimp-drawable-offsets oldlayer))
(define newsizex (car (gimp-drawable-width oldlayer)))
(define newsizey (car (gimp-drawable-height oldlayer)))
(define offsetx (car offsets))
(define offsety (cadr offsets))
(if (< offsetx 0)
(begin
(set! newsizex (+ newsizex offsetx))
(set! offsetx 0)))
(if (< offsety 0)
(begin
(set! newsizey (+ newsizey offsety))
(set! offsety 0)))
(if (> (+ offsetx newsizex) framesizex)
(set! newsizex (- framesizex offsetx)))
(if (> (+ offsety newsizey) framesizey)
(set! newsizey (- framesizey offsety)))

; Calculate frame rectangle's top left position.
(define framey (truncate (/ frame xframes)))
(define framex (- frame (* framey xframes)))
(set! framex (* framex framesizex))
(set! framey (* framey framesizey))

; Crop the layer if necessary so that it fits its
; rectangle, and move it to its final position.
(gimp-layer-resize newlayer
newsizex
newsizey
(- (car offsets) offsetx)
(- (cadr offsets) offsety))
(gimp-layer-set-offsets newlayer (+ framex offsetx) (+ framey offsety))

; Force it visible.
(gimp-drawable-set-visible newlayer TRUE)

; Check for (combine) mode. Note: It just works
; in layers other than 0. Otherwise no action is
; done. It makes no sense for the bottom layer to
; use combine mode anyway.
(if (and (> frame 0) (contains-ci (car (gimp-drawable-get-name oldlayer)) "(combine)"))
(begin
; Duplicate the previous layer to serve as a base
; for the differencing frame being added.
(define layercopy (car (gimp-layer-new-from-drawable (car prevlayerinfo) img)))

; Add the new layer below the last layer.
(gimp-image-add-layer img layercopy 1)

; Set the layer position to match that of the new layer.
(gimp-layer-set-offsets layercopy (+ framex (cadr prevlayerinfo))
(+ framey (caddr prevlayerinfo)))

; Ensure the previous layer's copy is visible.
(gimp-drawable-set-visible layercopy TRUE)

; Merge the differencing frame into the previous layer's copy.
(set! newlayer (car (gimp-image-merge-down img newlayer EXPAND-AS-NECESSARY)))

; Correct the offsets. We use 'min' to match what
; EXPAND-AS-NECESSARY has supposedly done. Ideally
; we should read the new offsets and subtract
; framex/framey from them, but this is faster and simpler,
(set! offsetx (min offsetx (cadr prevlayerinfo)))
(set! offsety (min offsety (caddr prevlayerinfo)))))

; Previous layer = this.
(set! prevlayerinfo (list newlayer offsetx offsety))

; All done. Next loop iteration.
(set! frame (+ frame 1))))

; Progress 100%
(gimp-progress-update 1.0)

; Merge visible layers (all are visible now).
(define mergedlayer (car (gimp-image-merge-visible-layers img CLIP-TO-IMAGE)))

; Make the new layer the size of the image.
(gimp-layer-resize-to-image-size mergedlayer)

; Convert the image to RGB if it is not already.
(if (not (= imgtype RGB))
(gimp-image-convert-rgb img))

; Detect alpha by converting it to a selection.
(gimp-selection-layer-alpha mergedlayer)

; If there is no useful alpha, the selection should cover the whole image.
; Invert it, and if it becomes empty, then it means that alpha was not
; in use: the whole image was covered with 100% opacity.
(gimp-selection-invert img)
(define hasalpha (car (gimp-selection-bounds img)))
(gimp-selection-none img)

; If it didn't have any alpha, remove the alpha mask from the layer.
(if (= hasalpha FALSE)
(gimp-layer-flatten mergedlayer))

; All done - enable undo again and add a display window for the new image.
(gimp-image-undo-enable img)
(gimp-display-new img)

; Prepare a version of fps ending in .0 if it doesn't.
(define fpsstr (number->string fps))
(if (not (contains-ci fpsstr "."))
(set! fpsstr (string-append fpsstr ".0")))

; Show the script if requested
(if (= showscript TRUE)
(gimp-message (string-append "// Copy-paste the following fragment as a script:\n\n"
"default\n{\n state_entry()\n {\n"
" llSetTextureAnim(ANIM_ON | LOOP, "
face
", "
(number->string xframes)
", "
(number->string yframes)
", 0.0, "
(number->string (* xframes yframes))
".0, "
fpsstr ");\n }\n}\n"))))

; If the frame counts didn't match...
(gimp-message "Error: Number of layers doesn't match horizontal x vertical frames"))))

; Register the function.
(script-fu-register "script-fu-layers-to-sl-anim"
_"<Image>/Script-Fu/SecondLife/Frames to texture..."
_"Convert a set of layers (frames) to a texture suitable for llSetTextureAnim."
"Pedro Oval"
_"Public Domain"
"2010-12-04"
"RGB*, GRAY*, INDEXED*"
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0
SF-ADJUSTMENT _"# of horizontal frames" '(2 1 1024 1 10 0 1)
SF-ADJUSTMENT _"# of vertical frames" '(2 1 1024 1 10 0 1)
SF-TOGGLE _"Generate LSL script?" TRUE
SF-STRING _"Face number (ALL__SIDES for all) (for script):" "ALL_SIDES"
SF-VALUE _"Frames per second (for script):" "10.0")
</source>

== Change Log ==

* Version 2.0.2 (2015-08-05):
** Make locals be really local.
** The generated script did not compile because it lacked the sides parameter. Fixed.
* Version 2.0.1 (2012-06-05):
** Disable undo instead of creating an undo group. Makes more sense to the user and saves memory.
* Version 2.0 (2010-12-22):
** Frames are no longer required to be the same size as the image.
** Recognize "combine" layers. Should work with all animated GIFs now.
** Option to generate the LSL script, active by default.
** Deal with alpha, so that it's removed if not needed and vice versa.
** Added progress indicator.
** Extensively commented.
* Version 1.0 (2010-12-04): First public release.

See also [[User:Pedro Oval/GIMP Layers to SL Animated Texture]] for the (possibly unstable) current development version and future plans.

== Credits/License ==

Written by Pedro Oval. Donated to the public domain.

PRIM NORMAL

2015-07-23T13:14:28Z

Pedro Oval: Fix typo in sign

<onlyinclude>{{#if:

{{#vardefine:normal_return|an empty list.}}

{{#vardefine:normal_const|{{LSL Const|PRIM_NORMAL|integer|37|c=Used to {{GetSet|{{{1|}}}|get|set|/}} the normal map settings of a prim's face}}}}

{{LSL_Function/angle|rotation_in_radians}}

{{#vardefine:p_repeats_desc|x and y range from -100.0 to 100.0, in 0.0001 increments. Negative values flip the texture (z is ignored)}}
{{#vardefine:p_offsets_desc|x and y range from 0.0 to 1.0, in 0.0001 increments. (z is ignored)}}

{{LSL_Function/inventory|texture|uuid=true|type=texture|no_caveat={{#ifeq:{{{1|}}}|get|true|<noinclude>*</noinclude>}}|full={{{remote|}}}|remote={{#ifeq:{{{1|set}}}|get|*}}|target=PRIM_NORMAL#Target}}

{{#ifeq:{{{1|}}}|none||

{{#vardefine:facetable|{{#var:facetable}}
{{!}}-
{{!}} [ {{#var:normal_const}} ]
{{!}} {{#var:normal_return}} }}

{{#vardefine:caveats_get|
* {{LSLP|repeats}} is not only used to get the number of repeats but the sign of the individual components indicate if "Flip" is set.
* With {{LSLP|texture}} as with [[llGetTexture]], {{LSL Constant/NULL KEY}} is returned when the {{LSLGC|Owner|owner}} does not have {{LSLGC|Permissions/Asset|full permissions}} to the object and the [[PRIM_NORMAL|texture]] is not in the prim's inventory.
*If {{LSLP|face}} indicates a face that exists but does not contain a material, the [[PRIM_NORMAL]] return is '''[ [[NULL_KEY]], <1,1,0>, [[ZERO_VECTOR]], 0.0 ]''' }}

{{#vardefine:caveats_set|
* {{LSLP|repeats}} is not only used to set the number of repeats but the sign of the individual components is also used to set the "Flip" attribute.
* To clear the normal map parameters from the face (and possibly remove the material), set {{LSLP|texture}} to [[NULL_KEY]] (the other parameters must be supplied in this case but will be ignored).
* Note that whenever any face in a linkset contains a material (i.e. has a non-default [[PRIM_NORMAL]], [[PRIM_SPECULAR]], or [[PRIM_ALPHA_MODE]]), the linkset will use the [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 new accounting system]. }}

{{#ifeq:{{{1|}}}|get|

{{#vardefine:caveats|{{#var:caveats}}
{{#var:caveats_get}}
}}

|

{{Issues/SVC-914}}
{{#vardefine:caveats|{{#var:caveats}}
{{#var:caveats_set}}
}}

}}

<noinclude>
{{:PRIM TEXGEN|{{{1|}}}}}
</noinclude>

}}

{{#vardefine:shared_caveat|* In the [[PRIM_TEXGEN_DEFAULT|default]] [[PRIM_TEXGEN|texture mapping]] {{LSLP|tg_type|mode}} the [[PRIM_NORMAL|texture]] {{LSLP|repeats}} units are in texture repeats per face. In the [[PRIM_TEXGEN_PLANAR|planar]] texture mapping mode the texture {{LSLP|repeats}} units are in texture repeats per half meter. This is in contrast to the in-world editing tool, in which the planar texture scaling units are repeats per meter.}}

{{#vardefine:caveats|{{#var:caveats}}
{{#var:shared_caveat}}}}

}}</onlyinclude>{{#if:

{{#vardefine:caveats_set|{{#var:caveats}}{{#vardefine:caveats|}}}}
{{#vardefine:issues_set|{{#var:issues}}{{#vardefine:issues|}}}}

{{LSL_Function/face|face|{{#var:normal_const}}|!footer=*|return={{#var:normal_return}}}}

{{#vardefine:caveats_get|{{#var:caveats}}{{#vardefine:caveats|}}
{{#var:caveats_get}}
{{#var:shared_caveat}}}}
{{#vardefine:issues_get|{{#var:issues}}{{#vardefine:issues|}}}}

}}{{LSL Constant
|inject-2={{LSL PrimitiveParam Categorize|Face}}
|name=PRIM_NORMAL
|type=integer
|value=37
|desc=Used to get or set the normal map texture settings of a prim's {{LSLP|face}}.
|examples=
|pa={{LSL Constant/List|i_front=[ {{#var:normal_const}}, |i_end= ]|
|inject-1={{#vardefine:p_texture_desc|}}
{{#vardefine:p_texture_hover|}}
{{#vardefine:direction|_set}}
{{LSL_Function/inventory|texture|uuid=true|type=texture}}
|text=Used with [[llSetPrimitiveParams]] & [[llSetLinkPrimitiveParams]].

{{LSL Generic/Caveats|issues={{#var:issues_set}}|title=*|h=4}}

====Examples====
<source lang="lsl2">llSetPrimitiveParams([ PRIM_NORMAL, ALL_SIDES, "1ece3148-6cea-f9eb-2152-9902944dbc3d", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]);
llSetPrimitiveParams([ PRIM_NORMAL, ALL_SIDES, llGetInventoryName(INVENTORY_TEXTURE, 0), <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]);</source>

|toc=llSetPrimitiveParams
|i1_type=integer|i1_name=face
|i2_type=string|i2_name=texture
|i3_type=vector|i3_name=repeats
|i4_type=vector|i4_name=offsets
|i5_type=float|i5_name=rotation_in_radians|i5_disp=rot
}}
|pb={{LSL Constant/List|i_front=[[llGetPrimitiveParams]]([ {{#var:normal_const}}, |i_end= ]);|
|inject-1={{#vardefine:p_texture_desc|}}
{{#vardefine:p_texture_hover|}}
{{#vardefine:direction|_get}}
{{LSL_Function/inventory|texture|uuid=true|type=texture|no_caveat=true|full={{{remote|}}}|remote=*|target=#Target}}
{{LSL Function/link|link|nogroup=*|nocaveats=*}}
|r_front=Returns the list [ |r_end= ]
|text=
{{LSL Generic/Caveats|caveats={{#var:caveats_get}}{{#vardefine:caveats_get}}|issues={{#var:issues_get}}|title=*|h=4}}
====Target====
In the case of llGetPrimitiveParams is either the prim the script resides in, or the prim specified by the immediately prior [[PRIM_LINK_TARGET]] call. However in the case of llGetLinkPrimitiveParams, it is either the value of the {{LSLP|link}} parameter, or the prim specified by the immediately prior [[PRIM_LINK_TARGET]] call.
|toc=llGetPrimitiveParams
|i1_type=integer|i1_name=face
|r1_type=string|r1_name=texture
|r2_type=vector|r2_name=repeats
|r3_type=vector|r3_name=offsets
|r4_type=float|r4_name=rotation_in_radians|r4_disp=rot
}}
|functions=
{{LSL DefineRow||[[llSetPrimitiveParams]]|}}
{{LSL DefineRow||[[llSetLinkPrimitiveParams]]|}}
{{LSL DefineRow||[[llGetPrimitiveParams]]|}}
|events
|location
|notes
|cat1=Texture
|cat2
|cat3
|cat4
}}

Limits

2015-07-22T19:34:58Z

Pedro Oval: /* All Viewers */ Add note on minimum

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers''' - 60 including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers before Second Life Release 3.7.29.301305, the potential total was still 60, but limited to 5 items of each type.
** In any case, only one each of shape, skin, eyes and hair base may be worn.
* '''Max Clothing Texture''' - 512x512 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures.
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 10 teleports per 15 seconds, since SL server 1.27.1

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first. Size is after conversion to SL [[Internal Animation Format|internal animaton format]], not BVH source which can be much larger.
| n/a

|-
||animation priority
| {{no|0}}
| {{no|4, with custom tools 6}}
| n/a
| [[Animation_Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.

The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive'' channels, to 1023 bytes. These limits do not affect communication between scripts.
| [[llInstantMessage]]
|-
||Number of offline messages
| n/a
| {{no|Capped at 25 messages, unless the account has a Premium Subscription, in which case the cap raises to 50 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above 25 (or 50 in the case of Premium members), go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|-
| Maximum steps data
| n/a
| {{no|1000 bytes}} of packed data; saving with more data returns the message "Gesture save failed. This gesture has too many steps. Try removing some steps, then save again." Shorter text, for example, will allow more steps.
| n/a
| n/a
|-
||Length of included assets
| n/a
| see sections for [[#Animation|animation]], [[#Sound|sound]]
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42 for Basic accounts, 60 for Premium accounts.
** After downgrading from a Premium account to a Basic account, you may not join any new groups until you are a member of fewer than 42 groups.
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/X/128/128/24 X].
* '''Maximum ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters. If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** Full region: 100 (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]}}
| n/a
| n/a
|-
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|10.00000 seconds (441,000 samples)}}
| 441,001 samples (10.00002 seconds) won't work. You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - 4:3 (60×45 pixels)
* '''Profile > Pick expanded''' - 4:3 (320×240 pixels)

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

* '''Minimum texture size''' - 4×4 pixels
** This means that there are nine possible image dimensions: 4, 8, 16, 32, 64, 128, 256, 512, and 1024 pixels, either horizontal or vertical.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

Template:LSL Animation States

2015-07-15T15:23:04Z

Pedro Oval: Add defaults

{{{!}} class="sortable" {{Prettytable|style=margin-top:0;}}
{{!}}+{{{title|}}}
{{!}}-{{Hl2}}
!Value
!Type
!Description
!Default
{{!}}-
{{#if:{{{all|<noinclude>*</noinclude>}}}|
{{!}} "ALL"
{{!}} Macro
{{!}} Used to [[llResetAnimationOverride|reset]] all overrides.
{{!}}
}}
{{!}}-
{{!}}"Crouching"
{{!}}State
{{!}}
{{!}}crouch
{{!}}-
{{!}}"CrouchWalking"
{{!}}State
{{!}}
{{!}}crouchwalk
{{!}}-
{{!}}"Falling Down"
{{!}}State
{{!}}
{{!}}falldown
{{!}}-
{{!}}"Flying"
{{!}}State
{{!}}
{{!}}fly
{{!}}-
{{!}}"FlyingSlow"
{{!}}State
{{!}}
{{!}}flyslow
{{!}}-
{{!}}"Hovering"
{{!}}State
{{!}}
{{!}}hover
{{!}}-
{{!}}"Hovering Down"
{{!}}State
{{!}}
{{!}}hover_down
{{!}}-
{{!}}"Hovering Up"
{{!}}State
{{!}}
{{!}}hover_up
{{!}}-
{{!}}"Jumping"
{{!}}State
{{!}}While still in the air during a jump.
{{!}}jump
{{!}}-
{{!}}"Landing"
{{!}}Transition
{{!}}When landing from a jump.
{{!}}land
{{!}}-
{{!}}"PreJumping"
{{!}}Transition
{{!}}At the beginning of a jump.
{{!}}prejump
{{!}}-
{{!}}"Running"
{{!}}State
{{!}}
{{!}}run
{{!}}-
{{!}}"Sitting"
{{!}}State
{{!}}Sitting on an object (and linked to it).
{{!}}sit
{{!}}-
{{!}}"Sitting on Ground"
{{!}}State
{{!}}Sitting, but not linked to an object.{{Footnote|1="Sit down" on the avatar context menu allows ground sits anywhere: atop the terrain, objects or even in the air.}}
{{!}}sit_ground_constrained
{{!}}-
{{!}}"Standing"
{{!}}State
{{!}}
{{!}}stand
{{!}}-
{{!}}"Standing Up"
{{!}}Transition
{{!}}After falling a great distance. Sometimes referred to as Hard Landing.
{{!}}standup
{{!}}-
{{!}}"Striding"
{{!}}State
{{!}}When the avatar is stuck on the edge of an object or on top of another avatar.
{{!}}stride
{{!}}-
{{!}}"Soft Landing"
{{!}}Transition
{{!}}After falling a small distance.
{{!}}soft_land
{{!}}-
{{!}}"Taking Off"
{{!}}State
{{!}}
{{!}}hover_up
{{!}}-
{{!}}"Turning Left"
{{!}}State
{{!}}
{{!}}turnleft
{{!}}-
{{!}}"Turning Right"
{{!}}State
{{!}}
{{!}}turnright
{{!}}-
{{!}}"Walking"
{{!}}State
{{!}}
{{!}}walk
{{!}}}

Talk:LlGetAnimationOverride

2015-07-15T15:17:18Z

Pedro Oval: Reply

== Default Values ==
The default values for each of these overrides, that is without any override active, is as follows:
<code> 
[14:41] Object: Listing Overridden Animations 
[14:41] Object: crouch 
[14:41] Object: crouchwalk 
[14:41] Object: falldown 
[14:41] Object: fly 
[14:41] Object: flyslow 
[14:41] Object: hover 
[14:41] Object: hover_down 
[14:41] Object: hover_up 
[14:41] Object: jump 
[14:41] Object: land 
[14:41] Object: prejump 
[14:41] Object: run 
[14:41] Object: sit 
[14:41] Object: sit_ground_constrained 
[14:41] Object: stand 
[14:41] Object: standup 
[14:41] Object: stride 
[14:41] Object: soft_land 
[14:41] Object: hover_up 
[14:41] Object: turnleft 
[14:41] Object: turnright 
[14:41] Object: walk 
</code> 
--[[User:Kanashio Resident|Kanashio Resident]] ([[User talk:Kanashio Resident|talk]]) 14:43, 14 July 2015 (PDT)

: Note that the order llOwnerSay outputs lines can not be relied on. Also, empty ones are not output. I've modified your script to prefix each line with the corresponding state. Output with no AO follows:
<pre>
[08:07:40] Object: Listing Overridden Animations
[08:07:40] Object: Crouching: crouch
[08:07:40] Object: CrouchWalking: crouchwalk
[08:07:40] Object: Falling Down: falldown
[08:07:40] Object: Flying: fly
[08:07:40] Object: FlyingSlow: flyslow
[08:07:40] Object: Hovering: hover
[08:07:40] Object: Hovering Down: hover_down
[08:07:40] Object: Hovering Up: hover_up
[08:07:40] Object: Jumping: jump
[08:07:40] Object: Landing: land
[08:07:40] Object: PreJumping: prejump
[08:07:40] Object: Running: run
[08:07:40] Object: Sitting: sit
[08:07:40] Object: Sitting on Ground: sit_ground_constrained
[08:07:40] Object: Standing: stand
[08:07:40] Object: Standing Up: standup
[08:07:40] Object: Striding: stride
[08:07:40] Object: Soft Landing: soft_land
[08:07:40] Object: Taking Off: hover_up
[08:07:40] Object: Turning Left: turnleft
[08:07:40] Object: Turning Right: turnright
[08:07:40] Object: Walking: walk
</pre>

LlGetAnimationOverride

2015-07-15T15:15:20Z

Pedro Oval: Add state names to the output

{{LSL_Function
|inject-1=
|inject-2=
{{LSL_Function/permission|PERMISSION_OVERRIDE_ANIMATIONS|PERMISSION_TRIGGER_ANIMATION}}
|func_id=?|func_sleep=0.0|func_energy=?
|func=llGetAnimationOverride|sort=GetAnimationOverride
|p1_type=string|p1_name=anim_state|p1_desc=animation state
|func_footnote
|return_type=string
|return_text=that is the name of the animation that is being used for the specified animation state ({{LSLPT|anim_state}}).
|spec
|caveats
|constants={{LSL Animation States}}
|examples=
<source lang="lsl2">
// llGetAnimationOverride Example
// A Script to check the animation Stats on
// all available overridable animations.
// By Kanashio Koroshi and Pedro Oval

default
{
state_entry()
{
llRequestPermissions(llGetOwner(),
PERMISSION_OVERRIDE_ANIMATIONS);
}

run_time_permissions(integer permissions)
{
if (permissions & PERMISSION_OVERRIDE_ANIMATIONS)
{
llOwnerSay("Listing Overridden Animations");
llOwnerSay("Crouching: " + llGetAnimationOverride("Crouching"));
llOwnerSay("CrouchWalking: " + llGetAnimationOverride("CrouchWalking"));
llOwnerSay("Falling Down: " + llGetAnimationOverride("Falling Down"));
llOwnerSay("Flying: " + llGetAnimationOverride("Flying"));
llOwnerSay("FlyingSlow: " + llGetAnimationOverride("FlyingSlow"));
llOwnerSay("Hovering: " + llGetAnimationOverride("Hovering"));
llOwnerSay("Hovering Down: " + llGetAnimationOverride("Hovering Down"));
llOwnerSay("Hovering Up: " + llGetAnimationOverride("Hovering Up"));
llOwnerSay("Jumping: " + llGetAnimationOverride("Jumping"));
llOwnerSay("Landing: " + llGetAnimationOverride("Landing"));
llOwnerSay("PreJumping: " + llGetAnimationOverride("PreJumping"));
llOwnerSay("Running: " + llGetAnimationOverride("Running"));
llOwnerSay("Sitting: " + llGetAnimationOverride("Sitting"));
llOwnerSay("Sitting on Ground: " + llGetAnimationOverride("Sitting on Ground"));
llOwnerSay("Standing: " + llGetAnimationOverride("Standing"));
llOwnerSay("Standing Up: " + llGetAnimationOverride("Standing Up"));
llOwnerSay("Striding: " + llGetAnimationOverride("Striding"));
llOwnerSay("Soft Landing: " + llGetAnimationOverride("Soft Landing"));
llOwnerSay("Taking Off: " + llGetAnimationOverride("Taking Off"));
llOwnerSay("Turning Left: " + llGetAnimationOverride("Turning Left"));
llOwnerSay("Turning Right: " + llGetAnimationOverride("Turning Right"));
llOwnerSay("Walking: " + llGetAnimationOverride("Walking"));
}
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llSetAnimationOverride]]|}}
{{LSL DefineRow||[[llResetAnimationOverride]]|}}
|also_tests
|also_events
|also_articles={{LSL DefineRow||[[Internal_Animations]]|lists internal Animations always available}}
|notes
|cat1=Animation
|cat2=Animation/Override
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/13#13.04.12.273874 | 12/04/2013 ]]
}}

LlGetAnimationOverride

2015-07-15T14:49:03Z

Pedro Oval: Check if the permissions were granted, per best practices

{{LSL_Function
|inject-1=
|inject-2=
{{LSL_Function/permission|PERMISSION_OVERRIDE_ANIMATIONS|PERMISSION_TRIGGER_ANIMATION}}
|func_id=?|func_sleep=0.0|func_energy=?
|func=llGetAnimationOverride|sort=GetAnimationOverride
|p1_type=string|p1_name=anim_state|p1_desc=animation state
|func_footnote
|return_type=string
|return_text=that is the name of the animation that is being used for the specified animation state ({{LSLPT|anim_state}}).
|spec
|caveats
|constants={{LSL Animation States}}
|examples=
<source lang="lsl2">
// llGetAnimationOverride Example
// A Script to check the animation Stats on
// all available overridable animations.
// By Kanashio Koroshi

default
{
state_entry()
{
llRequestPermissions(llGetOwner(),
PERMISSION_OVERRIDE_ANIMATIONS);
}

run_time_permissions(integer permissions)
{
if (permissions & PERMISSION_OVERRIDE_ANIMATIONS)
{
llOwnerSay("Listing Overridden Animations");
llOwnerSay(llGetAnimationOverride("Crouching"));
llOwnerSay(llGetAnimationOverride("CrouchWalking"));
llOwnerSay(llGetAnimationOverride("Falling Down"));
llOwnerSay(llGetAnimationOverride("Flying"));
llOwnerSay(llGetAnimationOverride("FlyingSlow"));
llOwnerSay(llGetAnimationOverride("Hovering"));
llOwnerSay(llGetAnimationOverride("Hovering Down"));
llOwnerSay(llGetAnimationOverride("Hovering Up"));
llOwnerSay(llGetAnimationOverride("Jumping"));
llOwnerSay(llGetAnimationOverride("Landing"));
llOwnerSay(llGetAnimationOverride("PreJumping"));
llOwnerSay(llGetAnimationOverride("Running"));
llOwnerSay(llGetAnimationOverride("Sitting"));
llOwnerSay(llGetAnimationOverride("Sitting on Ground"));
llOwnerSay(llGetAnimationOverride("Standing"));
llOwnerSay(llGetAnimationOverride("Standing Up"));
llOwnerSay(llGetAnimationOverride("Striding"));
llOwnerSay(llGetAnimationOverride("Soft Landing"));
llOwnerSay(llGetAnimationOverride("Taking Off"));
llOwnerSay(llGetAnimationOverride("Turning Left"));
llOwnerSay(llGetAnimationOverride("Turning Right"));
llOwnerSay(llGetAnimationOverride("Walking"));
}
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llSetAnimationOverride]]|}}
{{LSL DefineRow||[[llResetAnimationOverride]]|}}
|also_tests
|also_events
|also_articles={{LSL DefineRow||[[Internal_Animations]]|lists internal Animations always available}}
|notes
|cat1=Animation
|cat2=Animation/Override
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/13#13.04.12.273874 | 12/04/2013 ]]
}}

Common compilation problems

2015-07-01T18:06:49Z

Pedro Oval: /* C4018: '<' : signed/unsigned mismatch */ <php> to <source> and change language

{{CompileNav}}

= General Problems =

* Make sure you download not only the source, but the artwork zipfile, and the appropriate zipfile/tarball of libraries for your platform

= Windows =

== Viewer 1.19.1.4 / VS2003 ==
=== C1083: Cannot open include file: 'dxdiag.h' ===
The DirectX SDK doesn't automatically insert its include directory into the VS2003 paths. For the June 2008 DirectX SDK release, go to Tools -> Options -> Projects (on left) -> VC++ Directories. On right show directories for Include files, and add:
* C:\Program Files\Microsoft DirectX SDK (June 2008)\Include

=== C1083: Cannot open include file: 'unistd.h' ===
On Apr 27, 2008 in thread ''[sldev] error while compiling on vc8/9 (unistd.h)'', SLDev contributor wuhanzymail <wuhanzymail@163.com> recommended the following:

1) right-click project lscript_compile, choose properties, c/c++, Preprocessor, add ''YY_NO_UNISTD_H'' to Preprcessor Definitions.

2) in lex_yy.cpp, line 5915 change:
<source lang="cpp"> #ifndef __cplusplus
extern int isatty (int );
#endif</source>
to:
<source lang="cpp"> #ifndef YY_NEVER_INTERACTIVE
extern int isatty (int );
#endif</source>
3) still in lex_yy.cpp, line 5943 change:
<source lang="cpp"> b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;</source>
to:
<source lang="cpp"> #if YY_NEVER_INTERACTIVE
b->yy_is_interactive = 0;
#else
b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
#endif</source>

=== C4018: '<' : signed/unsigned mismatch ===
On Apr 30, 2008 in thread ''[sldev] cygwin flex lscript_compile workaround'', SLDev contributor Steve Linden recommended the following:

I'm not sure whether this has already been addressed here, but we
discovered a problem with the latest version of Cygwin flex and
lscript_compile and I thought I would share the workaround. We've
committed the workaround to our release-candidate branche so it should
be in an upcoming source drop as well.

1. Add ''YY_NO_UNISTD_H'' to the list of Preprocessor Definitions in the
lscript_compile project file.

2. Apply the following patch it indra.l:

<source lang="diff">Index: indra.l
===================================================================
--- indra.l (revision 86342)
+++ indra.l (revision 86343)
@@ -12,6 +12,7 @@
#include "linden_common.h"
// Deal with the fact that lex/yacc generates unreachable code
#ifdef LL_WINDOWS
+#pragma warning (disable : 4018) // warning C4018: signed/unsigned mismatch
#pragma warning (disable : 4702) // warning C4702: unreachable code
#endif // LL_WINDOWS
#include "llmath.h"
@@ -44,7 +45,10 @@

#define YYLMAX 16384
#define YY_NEVER_INTERACTIVE 1 /* stops flex from calling isatty() */
-
+#ifdef LL_WINDOWS
+#define isatty(x) 0 /* hack for bug in cygwin flex 2.5.35 */
+#endif
+
#ifdef ECHO
#undef ECHO
#endif
</source>

=== [...] error result returned from 'link.exe' ===
By checking the Output window (View menu -> Other Windows), this shows up as an error saying: ''link: extra operand `/NOLOGO' ''

As reported by Brad Linden, this is caused by having the compiler executable directories in the wrong order, with the Cygwin directory path listed above the Visual Studio paths. This causes the Cygwin linker to be used instead of Visual Studio's linker.

Go to Tools -> Options -> Projects -> VC++ Directories, show directories for Executables, and move "C:\cygwin\bin" to the bottom of the list.

== Unresolved external symbol _CLSID_DxDiagProvider/_IID_IDxDiagProvider ==
* ''newview error LNK2001: unresolved external symbol _CLSID_DxDiagProvider''
* ''newview error LNK2001: unresolved external symbol _IID_IDxDiagProvider''

These errors reportedly occur with MSVC 2003 and certain versions of the DirectX SDK. To workaround, edit lldxhardware.cpp and replace the following (line 35):

#include <dxdiag.h>
with...
#define INITGUID
#include <dxdiag.h>
#undef INITGUID

== Cannot open input file 'dxguid.lib' ==
* ''fatal error LNK1181: cannot open input file 'dxguid.lib' in ...''

If you are using a fairly recent DirectX SDK ("December 2006" or newer), your VC++ Libraries Directory may be wrong because the SDK's lib folder now has 2 sub-folders for x64 and x86. Try changing the path from ''C:\Program Files\Microsoft DirectX SDK (December 2006)\Lib'' to ''C:\Program Files\Microsoft DirectX SDK (December 2006)\'' '''Lib\x86'''
 
 
== Cannot open input file 'dxerr8.lib' ==
* ''fatal error LNK1104: cannot open file 'dxerr8.lib'''

If you are using the most recent DirectX SDK ("November 2007"), the file dxerr8.lib does no longer exist. To fix this, you'll need to change the newview project to include 'dxerr9.lib' instead. To do this, right-lick newview > Configuration Properties > Linker > Input, click Additional Dependencies on the right to show a button labeled "..." on it at the very right on the line, then click the ... button. Scroll down the list to find 'dxerr8.lib'. Rewrite it to 'dxerr9.lib'. Remember to do this for both the ReleaseForDownload and the ReleaseNoOpt Configurations.
 
 

== A tool returned an error code from "Building ytab.cpp" ==
* ''lscript_compile_fb error PRJ0019: A tool returned an error code from "Building ytab.cpp" ''

One possible reason for this is that Visual Studio does not know where cygwin/bin is, especially if this is accompanied by an error relating to bison.exe being an invalid command. Even if the directory for cygwin is in the environment variable PATH, Visual Studio maintains its own separate copy which does not seem to be automatically synchronized after the initial installation.

For Visual Studio .NET 2003, go to Tools > Options > Projects > VC++ Directories. In the "show directories for" dropdown, choose "Executable files". Make sure that your cygwin (default C:\cygwin\bin) and ActivePython (default C:\Python25) directories are listed.

== Cannot open include file: 'ytab.h': No such file or directory ==
* ''indra.l (20) : fatal error C1083: Cannot open include file: 'ytab.h': No such file or directory.''
Workaround: Manually copy "linden\indra\lscript\lscript_compile\ytab.hpp" to "linden\indra\lscript\lscript_compile\ytab.h" and build again.

Note: The underlying issue is that in indra.y there is a postbuild step which should do this automatically, but which is missing in some configurations (e.g. in Debug builds).
 
 
== Cannot open include file: 'png.h': No such file or directory ==
* ''imagepng.cpp : fatal error C1083: Cannot open include file: 'libpng12/png.h': No such file or directory.''
There are a couple of files missing since the 1.17. distribution. You can either get the missing files from the internet (from the libpng and zlib projects) or download a set with just the missing files from [http://www.blueflash.cc/users/nicholaz/~libs here] (see the readme.txt inside the png archive there).
 
 
== Cannot open include file: 'glh/glh_linear.h' or 'glh/glh_convenience.h' ==
These files are currently missing from Linden Windlight distributions. See [https://jira.secondlife.com/browse/VWR-3415 JIRA VWR-3415] or grab a copy from [http://www.blueflash.cc/users/nicholaz/~libs here] and put the files into a folder named linden/libraries/include/glh.
 
 

== Errors relating to "template_verifier.py" ==
With version 1.18 a template verifier script written in Python is used to ensure the message template is correct. In some distributions the file was missing. You will also get an error if you have skipped the Python install. In both cases it is safe to hack the prebuild.bat file in the newview folder as described on the JIRA [http://jira.secondlife.com/browse/VWR-1267 VWR-1267]
 
 

== Missing resources ==
* ''.\res\newViewRes.rc(64) : error RC2135 : file not found: ll_icon.ico''
Some releases have missing files, which were reported to be last seen in the '''1.14.0.1''' release.
* Go to the [[source downloads]] page and grab the [[http://secondlife.com/developers/opensource/downloads/2007/04/slviewer-src-1.14.0.1.zip '''1.14.0.1''' viewer]] sources.
* Explore the archive to "linden/indra/newview/res" folder and extract content to your "linden/indra/newview/res" folder into current revision.
Missing folder in recent release, "'''1.17.0.12'''" which causes the SecondLife to hang while loading into the world.
* Go to the previous source and copy the missing folder, "Character" and place it into the "newview" folder
 
== Error code from "Copying message template" ==
* ''newview error PRJ0019: A tool returned an error code from "Copying message template"''
This is caused by the script trying to do a copy command, but the source path isn't in quotes. Open up newview.vcproj in notepad, and near the bottom there are 4 line that say:
CommandLine="copy $(InputPath) .\app_settings\message_template.msg
replace them with
CommandLine="copy &quot;$(InputPath)&quot; .\app_settings\message_template.msg
The source and destination paths on line 158 may also require wrapping in quotes. In which case:
CommandLine="copy $(TargetDir)\$(TargetFileName) $(ProjectDir)
should become:
CommandLine="copy &quot;$(TargetDir)\$(TargetFileName)&quot; &quot;$(ProjectDir)&quot;
 
== Can not find library ll*.lib ==
If you get a compile error for missing libraries with names of the projects (lscript_compile.lib, llaudio.lib, llcharacter.lib, etc.) go to newview > Properties > Linker > Input and remove these from the list of input libraries (they will be linked through the dependencies and should not be in the list).
 
 

== Cannot open include file: 'windows.h' ==
If you run into this problem:
..\..\..\boost/regex/v4/fileiter.hpp(44) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
Fix it with this: (thanks Fairlight!)
set INCLUDE=C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include;%INCLUDE%
set LIB=C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib;%LIB%
You might need to edit the above path to refer to your particular platform SDK. If you don't have the Microsoft Windows Platform SDK installed, then you can download it for free from Microsoft. It is version specific and can be tricky to find on their website.

If you're having problems with windows.h in Visual Studio Express 2005, check out this forum post:
[http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1995837&SiteID=1 MSDN Forum Post]

 

== Unresolved external symbol "int __cdecl lscript_compile" (VS2005) ==
* ''llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z)''
* ''llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z)''

This is not entirely clear, but there seems to be a problem with VS2005 if projects are unloaded while being in the dependency tree. I have seen this error while I had win_crash_logger and win_updater unloaded from the project tree and the problem went away when I loaded them back and excluded them from the newview dependency first.

Also make sure that in newview, properties, linker, input, input libraries, no libraries named ll*.lib and lscript_compile.lib are listed there (remove them if you find them).

Also be sure that your error does not come from previously in the log: like the cgywin component bison not being found. For MSVS2005 Express, you may need to go to tools>options>Projects and Solutions>VC++ Directories>Executable files and add the directory for cgywin.

 
 

== Unresolved external symbol __invalid_parameter_noinfo (VS2005) ==
* ''llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced''

You are most likely trying a debug build under VS2005. For debug builds, see the compile instruction section on [[finding_leaks]]
 
 

== Cannot open include file: 'ares.h' ==
download src from http://daniel.haxx.se/projects/c-ares/

compile c-ares-1.4.0/vc/areslib

copy c-ares-1.4.0/vc/areslib/Release/areslib.lib to linden/libraries/i686-win32/lib_release and to lib_debug

copy c-ares-1.4.0/*.h to linden/libraries/i686-win32/include/ares

===FMOD===
FMOD headers and libs need to be copied into the viewer build directory BUT on Windows the manifests are not currently moving the libs to the correct location post build so the application will fail to run, to resolve copy fmod.dll to indra/build-vc71/newview/debug and indra/build-vc71/newview/relwithdebinfo and indra/build-vc71/newview/release

===Boost and VS 2008===
If you use Visual Studio C++ 2008 (VC90), you may find that the Boost library will lock up solid and the viewer will not tun consuming 50-100% of CPU doing nothing. The only solutions are to use Visual Studio 2005 OR to get a newer version/rebuild boost with Visual Studio 2008.

This problem is being worked on. Look here for updates: [https://jira.secondlife.com/browse/VWR-9541 VWR-9541]

===Express editions of Visual C++===
Express editions do not have some of the extra features that VSTool.exe requires, VSTool is a little application that sets a few default project options, like which project is the startup and which build configuration to use.

===LLKDU===
This is not present in the automated libs download but is required at least on windows by the copy_win_scrips script. The file is not actually needed for the viewer to run (if present it will be used for jpeg2000 decoding in preference to Openjpeg. The solution is to remove the lines from newview/copy_win_scripts that reference llkdu and this should then allow this custom build step to run without issue

=== [...]/CMakeDetermineCompilerABI_C.bin cannot be read. ===
Occurs on Windows 7, make sure your running the cmd shell (or whatever your using to run the "python develop.py") with Administrator privileges.

== fatal error C1060: compiler is out of heap space ==
If you are not using Incredibuild and have precompiled headers disabled, you may encounter this error.
Try enabling building with precompiled headers:
<pre>autobuild configure -c [configuration] -- -DUSE_PRECOMPILED_HEADERS:BOOL=ON</pre>

== Other (older) notes ==
* Mozilla is not compatible with visual studio 2005, so we have not migrated the codebase, so we do not know if it works.

* Added my errors at [[User:Adam_Zaius/MSVS2005 Errors]] [[User:Adam Zaius|Adam Zaius]] 09:40, 8 January 2007 (PST)

* To minimize the number of warnings for now: in C/C++-Preprocessor add ';_CRT_SECURE_NO_DEPRECATE' to the Preprocessor Definitions, that will supress deprecation warnings --[[User:Artm Udal|Artm Udal]] 12:42, 8 January 2007 (PST)

 

= Mac OS X =

Getting:

*/linden/indra/newview/../llwindow/llglheaders.h:377:31: error: GL/glh_extensions.h: No such file or directory
** This means you didn't [[Compiling the viewer (Mac OS X)#Viewer Source, Libraries, and Artwork|merge the libraries]] right.

 

= Linux =

=== libGL ===

Sometimes the provide libGL.a can cause issues. To avoid linker errors, you may need to remove indra/libraries/i686-linux/release/libGL.a and indra/libraries/i686-linux/debug/libGL.a

=== Packaging errors ===

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/viewer_manifest.py

=== Various Compilation problems ===

====Various missing libraries====
<pre>g++-3.4 -o linux_crash_logger/linux-crash-logger-i686-bin-globalsyms --no-keep-memory --reduce-memory-overheads /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/llcrashlogger/llcrashlogger.o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/linux_crash_logger/linux_crash_logger.o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/linux_crash_logger/llcrashloggerlinux.o -Llib_release_client/i686-linux -L/home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client -lllui -lllxml -lllmessage -lllvfs -lllmath -lllcommon -lcurl -lssl -lcrypto -laprutil-1 -lapr-1 -lcares -lexpat -ldb-4.2 -lgtk-x11-2.0
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcurl.a when searching for -lcurl
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libssl.so when searching for -lssl
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcrypto.so when searching for -lcrypto
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libaprutil-1.so when searching for -laprutil-1
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libapr-1.so when searching for -lapr-1
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcares.a when searching for -lcares
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libexpat.so when searching for -lexpat
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libdb-4.2.so when searching for -ldb-4.2
/usr/bin/ld: cannot find -ldb-4.2
collect2: ld returned 1 exit status</pre>

[paul@myhost secondlife]$ pacman -Q db
db 4.6.21-2

[paul@myhost secondlife]$ uname -a
Linux myhost 2.6.23-ARCH #1 SMP PREEMPT Tue Jan 15 07:17:51 CET 2008 x86_64 Intel(R) Celeron(R) CPU 2.66GHz GenuineIntel GNU/Linux

And using:<pre>
source=('secondlife.desktop' 'secondlife.install' 'secondlife.launcher' \
"http://secondlife.com/developers/opensource/downloads/2008/01/slviewer-src-RC-${pkgver}.tar.gz" \
'http://secondlife.com/developers/opensource/downloads/2007/12/slviewer-artwork-RC-1.18.6.2.zip' \
'http://secondlife.com/developers/opensource/downloads/2007/12/slviewer-linux-libs-RC-1.18.6.2.tar.gz' \
'http://www.fmod.org/index.php/release/version/fmodapi375linux.tar.gz' \
'http://secondlife.com/developers/opensource/downloads/2007/12/llmozlib-src-20071221.tar.gz')</pre>

Hum ok, I was trying to use:
scons DISTCC=no BTARGET=client BUILD=release MOZLIB=yes

I'll retry with:
scons BUILD=release ARCH=x86_64 BTARGET=client DISTCC=no MOZLIB=yes FMOD=yes GSTREAMER=yes STANDALONE=yes
(Sconstruct says that with STANDALONE=yes -db-4.2 will not be used)

But at the beginning I get:
<pre>
scons: Reading SConscript files ...
Building client 1.18.6.2 on x86_64-linux (release)
No CCACHE_DIR set.

scons: warning: Two different environments were specified for target /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llcrashlogger/llcrashlogger.o>,
but they appear to have the same action: $CXX -o $TARGET -c $CXXFLAGS $_CCCOMCOM $SOURCES
File "/home/paul/builds/secondlife/src/linden/indra/SConstruct", line 568, in create_executable
scons: done reading SConscript files.
scons: Building targets ...</pre>

well, the new scons line give different problem:
<pre>g++ -o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.o -c -g -pipe -Wall -Wno-reorder -Wno-trigraphs -Wno-sign-compare -Werror -fexceptions -pthread -D_REENTRANT -fno-math-errno -fsigned-char -fno-strict-aliasing -falign-loops=16 -ffast-math -O2 -D_FORTIFY_SOURCE=2 -DLL_STANDALONE -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0 -DLL_X11=1 -DLL_GTK=1 -DLL_LIBXUL_ENABLED=1 -DLL_GSTREAMER_ENABLED=1 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illcrashlogger -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -Ilscript/lscript_compile -I/home/paul/builds/secondlife/src/linden/libraries/include -I/home/paul/builds/secondlife/src/linden/libraries/include/havok -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include -I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/SDL -I/usr/include/apr-1 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gstreamer-0.10 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/libxml2 /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp
cc1plus: warnings being treated as errors
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp: In function 'const char* OrderToString(LLQuaternion::Order)':
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:701: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:704: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:707: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:710: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:713: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:716: warning: deprecated conversion from string constant to 'char*'
scons: *** [/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.o] Error 1
scons: building terminated because of errors.</pre>

Well, STANDALONE=yes make it use g++ rather than g++-3.4, so I decided to remove it, keeping
ARCH=X86_64 and others, but I get:
<pre>ranlib lib_release_client/x86_64-linux/libllprimitive.a
g++-3.4 -o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.o -c -g -pipe -Wall -Wno-reorder -Wno-trigraphs -Wno-sign-compare -Werror -fexceptions -pthread -D_REENTRANT -fno-math-errno -fsigned-char -fno-strict-aliasing -falign-loops=16 -ffast-math -O2 -D_FORTIFY_SOURCE=2 -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0 -DLL_X11=1 -DLL_GTK=1 -DLL_LIBXUL_ENABLED=1 -DLL_GSTREAMER_ENABLED=1 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illcrashlogger -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -Ilscript/lscript_compile -I/home/paul/builds/secondlife/src/linden/libraries/include -I/home/paul/builds/secondlife/src/linden/libraries/include/havok -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/ELFIO -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/atk-1.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gtk-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/llfreetype2 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/pango-1.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gstreamer-0.10 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/libxml2 /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:41:44: llfreetype2/freetype/ft2build.h: No such file or directory
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:56: error: `FT_Render_Mode' does not name a type
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:60: error: `FT_Library' does not name a type
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp: In constructor `LLFontManager::LLFontManager()':
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:78: error: `gFTLibrary' was not declared in this scope
... [many more errors]</pre>

oh well, SConstruct says I need: cairo glib-2.0 atk gmobile-2.0 gdk-2.0 gdk-pixbuf-2.0 pango pangoft2 pangox pangoxft gtk+-2.0 sdl vorbis vorbisenc vorbisfile

Maybe this is pangoft2 that is missing.

* This part is probably not relevant anymore --[[USER:Thickbrick Sleaford|Thickbrick]]

===="Unable to initialize communications"====
* If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

====Blino's SL build/linking patches for '''gcc4'''====
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/secondlife/current/

====objcopy: 'newview/linux_tools/exposed-symbols.txt': No such file====
* Tofu says... 'This is an omission from our manifest which I'll fix. Meanwhile it's a safe fix to create an empty file with that name.'

====Something like: /usr/bin/ld: cannot find -lz====
* Nadia says: Install the zlib development headers. (Ubuntu package zlib1g-dev, Red Hat zlib-devel.)

====Something like: indra.y.cpp:17: error: previous declaration of `int yyparse()'====
* Tofu says... 'This appears to be a problem with some versions of flex/bison. A resident reports success when comment out the #ifdef __cplusplus lines in lscript/lscript_compile/indra.y'
* Nadia says: install the zlib development headers first and try recompiling. Commenting out those lines results in a error indra.l:666: undefined
* Abi says: I forgot to install bison. Once I did that, problem solved.

====Linking failures ("script not found") due to spaces in the LINKFLAGS variable?====
* I saw a [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665538 report], and modified the SConstruct file to drop the trailing arguments (and spaces) in LINKFLAGS.

====''cp: target `SecondLife_i686_1_13_1_7/app_settings/*’ is not a directory''====
Building [https://lists.secondlife.com/pipermail/sldev/2007-January/000091.html 20070112a] using ''BUILD=releasefordownload'' I get many ''[: 89: ==: unexpected operator'' errors; ''cp: target `SecondLife_i686_1_13_1_7/app_settings/*’ is not a directory'' error, and same thing for character, fonts, help, skins, res-sdl; ''[: 111: ==: unexpected operator, [: 120: SecondLife_i686_1_13_1_7.tar.bz2: unexpected operator''. I can succesfully run the client from the source tree.
* i think this has been fixed --[[User:Signore Iredell|Signore Iredell]] 06:09, 9 June 2007 (PDT)

====`['.../lscript/lscript_compile/indra.l.cpp']': Don't know how to build a file with suffix `.l'====
scons: *** While building `['.../linden/indra/i686-linux-client-release/lscript/lscript_compile/indra.l.cpp']': Don't know how to build a file with suffix `.l'.
* You probably don't have all the dependencies installed (I had the same problem). Check that you have flex and bison. --[[User:Random73 Janus|Random73 Janus]] 07:43, 16 May 2007 (PDT)

====`glActiveTextureARB' was not declared in this scope====
Something like: linden/indra/i686-linux-client-release/llrender/llimagegl.cpp:122: error: `glActiveTextureARB' was not declared in this scope
* Tofu says... 'You'll need to install OpenGL headers if you don't already have them: gl.h, glext.h, glu.h (The ones from 'mesa' should work)
* two residents report good luck on Gentoo after doing 'eselect opengl set xorg-x11' (but note!! You must know what you're doing; this may change your default system OpenGL drivers, and you will probably want to change them back again after the compile, e.g. 'eselect opengl set nvidia')'
* Note that the above xorg-x11/nvidia issue is addressed in [http://jira.secondlife.com/browse/VWR-9557 VWR-9557] which includes patches!

====Building Shared Library ELFIO====
Building Shared Library ELFIO [[Compiling_the_viewer_%28Linux%29]] on AMD64 ubuntu 6.10
g++-3.4 -shared *.o -o libelfio.so
/usr/bin/ld: ELFIDynamic.o: relocation R_X86_64_32 against `a local symbol' can
not be used when making a shared object; recompile with -fPIC
ELFIDynamic.o: could not read symbols: Bad value'''
* I got around this with "export CXXFLAGS=-fPIC" before configuring ELFIO.

====incompatible libopenjpeg.a when searching for -lopenjpeg====
Building Client on Ubuntu 7.04 AMD64
/usr/bin/ld: skipping incompatible /home/dereck/Desktop/SLdev/linden/libraries/i686-linux/lib_release_client/libopenjpeg.a when searching for -lopenjpeg
/usr/bin/ld: cannot find -lopenjpeg
collect2: ld returned 1 exit status
* I went to the OpenJPEG website, downloaded the source, compiled for my system, installed it. The VWR compile was happy after that. Although it's not done yet and I'm still fixing another error, that I assume is unrelated.

====C-Ares compatability issue.====
Compiling with c-ares version 1.5.1 got a compile error in llares.cpp:

linden/indra/x86_64-linux-client-release/llcommon/llares.cpp: In member function `void LLAres::getHostByName(const char*, LLAres::HostResponder*, int)':

linden/indra/x86_64-linux-client-release/llcommon/llares.cpp:147: error: invalid conversion from `void (*)(void*, int, hostent*)' to `void (*)(void*, int, int, hostent*)'

Fixed with patch from https://jira.secondlife.com/browse/VWR-3480

====memset used with constant zero length parameter====
Building with -t Release causes memset error in /usr/include/bits/string3.h:82
The error is "/usr/include/bits/string3.h:82: error: call to `__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters"

Patch: [http://jira.secondlife.com/browse/VWR-10001 VWR-10001]

====Boost errors in Snowglobe (GCC >= 4.3)====
Build stops with errors: "../libraries/include/boost/token_functions.hpp:338: error: suggest explicit braces to avoid ambiguous 'else'"

See [http://jira.secondlife.com/browse/SNOW-204 SNOW-204]

====Gentoo: undefined reference to `FT_Realloc'* from libpangoft2-1.0.so====
If you get an undefined reference to `FT_Realloc'* from libpangoft2-1.0.so, you might have to delete some bundled libraries. [http://imprudenceviewer.org/wiki/How_to_compile#Removing_Bad_Libraries_on_Gentoo_Linux See here]

[[Category:Compiling viewer]]

Common compilation problems

2015-07-01T18:04:42Z

Pedro Oval: /* C1083: Cannot open include file: 'unistd.h' */ <php> to <source> and change language

{{CompileNav}}

= General Problems =

* Make sure you download not only the source, but the artwork zipfile, and the appropriate zipfile/tarball of libraries for your platform

= Windows =

== Viewer 1.19.1.4 / VS2003 ==
=== C1083: Cannot open include file: 'dxdiag.h' ===
The DirectX SDK doesn't automatically insert its include directory into the VS2003 paths. For the June 2008 DirectX SDK release, go to Tools -> Options -> Projects (on left) -> VC++ Directories. On right show directories for Include files, and add:
* C:\Program Files\Microsoft DirectX SDK (June 2008)\Include

=== C1083: Cannot open include file: 'unistd.h' ===
On Apr 27, 2008 in thread ''[sldev] error while compiling on vc8/9 (unistd.h)'', SLDev contributor wuhanzymail <wuhanzymail@163.com> recommended the following:

1) right-click project lscript_compile, choose properties, c/c++, Preprocessor, add ''YY_NO_UNISTD_H'' to Preprcessor Definitions.

2) in lex_yy.cpp, line 5915 change:
<source lang="cpp"> #ifndef __cplusplus
extern int isatty (int );
#endif</source>
to:
<source lang="cpp"> #ifndef YY_NEVER_INTERACTIVE
extern int isatty (int );
#endif</source>
3) still in lex_yy.cpp, line 5943 change:
<source lang="cpp"> b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;</source>
to:
<source lang="cpp"> #if YY_NEVER_INTERACTIVE
b->yy_is_interactive = 0;
#else
b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
#endif</source>

=== C4018: '<' : signed/unsigned mismatch ===
On Apr 30, 2008 in thread ''[sldev] cygwin flex lscript_compile workaround'', SLDev contributor Steve Linden recommended the following:

I'm not sure whether this has already been addressed here, but we
discovered a problem with the latest version of Cygwin flex and
lscript_compile and I thought I would share the workaround. We've
committed the workaround to our release-candidate branche so it should
be in an upcoming source drop as well.

1. Add ''YY_NO_UNISTD_H'' to the list of Preprocessor Definitions in the
lscript_compile project file.

2. Apply the following patch it indra.l:

<php>Index: indra.l
===================================================================
--- indra.l (revision 86342)
+++ indra.l (revision 86343)
@@ -12,6 +12,7 @@
#include "linden_common.h"
// Deal with the fact that lex/yacc generates unreachable code
#ifdef LL_WINDOWS
+#pragma warning (disable : 4018) // warning C4018: signed/unsigned mismatch
#pragma warning (disable : 4702) // warning C4702: unreachable code
#endif // LL_WINDOWS
#include "llmath.h"
@@ -44,7 +45,10 @@

#define YYLMAX 16384
#define YY_NEVER_INTERACTIVE 1 /* stops flex from calling isatty() */
-
+#ifdef LL_WINDOWS
+#define isatty(x) 0 /* hack for bug in cygwin flex 2.5.35 */
+#endif
+
#ifdef ECHO
#undef ECHO
#endif
</php>
=== [...] error result returned from 'link.exe' ===
By checking the Output window (View menu -> Other Windows), this shows up as an error saying: ''link: extra operand `/NOLOGO' ''

As reported by Brad Linden, this is caused by having the compiler executable directories in the wrong order, with the Cygwin directory path listed above the Visual Studio paths. This causes the Cygwin linker to be used instead of Visual Studio's linker.

Go to Tools -> Options -> Projects -> VC++ Directories, show directories for Executables, and move "C:\cygwin\bin" to the bottom of the list.

== Unresolved external symbol _CLSID_DxDiagProvider/_IID_IDxDiagProvider ==
* ''newview error LNK2001: unresolved external symbol _CLSID_DxDiagProvider''
* ''newview error LNK2001: unresolved external symbol _IID_IDxDiagProvider''

These errors reportedly occur with MSVC 2003 and certain versions of the DirectX SDK. To workaround, edit lldxhardware.cpp and replace the following (line 35):

#include <dxdiag.h>
with...
#define INITGUID
#include <dxdiag.h>
#undef INITGUID

== Cannot open input file 'dxguid.lib' ==
* ''fatal error LNK1181: cannot open input file 'dxguid.lib' in ...''

If you are using a fairly recent DirectX SDK ("December 2006" or newer), your VC++ Libraries Directory may be wrong because the SDK's lib folder now has 2 sub-folders for x64 and x86. Try changing the path from ''C:\Program Files\Microsoft DirectX SDK (December 2006)\Lib'' to ''C:\Program Files\Microsoft DirectX SDK (December 2006)\'' '''Lib\x86'''
 
 
== Cannot open input file 'dxerr8.lib' ==
* ''fatal error LNK1104: cannot open file 'dxerr8.lib'''

If you are using the most recent DirectX SDK ("November 2007"), the file dxerr8.lib does no longer exist. To fix this, you'll need to change the newview project to include 'dxerr9.lib' instead. To do this, right-lick newview > Configuration Properties > Linker > Input, click Additional Dependencies on the right to show a button labeled "..." on it at the very right on the line, then click the ... button. Scroll down the list to find 'dxerr8.lib'. Rewrite it to 'dxerr9.lib'. Remember to do this for both the ReleaseForDownload and the ReleaseNoOpt Configurations.
 
 

== A tool returned an error code from "Building ytab.cpp" ==
* ''lscript_compile_fb error PRJ0019: A tool returned an error code from "Building ytab.cpp" ''

One possible reason for this is that Visual Studio does not know where cygwin/bin is, especially if this is accompanied by an error relating to bison.exe being an invalid command. Even if the directory for cygwin is in the environment variable PATH, Visual Studio maintains its own separate copy which does not seem to be automatically synchronized after the initial installation.

For Visual Studio .NET 2003, go to Tools > Options > Projects > VC++ Directories. In the "show directories for" dropdown, choose "Executable files". Make sure that your cygwin (default C:\cygwin\bin) and ActivePython (default C:\Python25) directories are listed.

== Cannot open include file: 'ytab.h': No such file or directory ==
* ''indra.l (20) : fatal error C1083: Cannot open include file: 'ytab.h': No such file or directory.''
Workaround: Manually copy "linden\indra\lscript\lscript_compile\ytab.hpp" to "linden\indra\lscript\lscript_compile\ytab.h" and build again.

Note: The underlying issue is that in indra.y there is a postbuild step which should do this automatically, but which is missing in some configurations (e.g. in Debug builds).
 
 
== Cannot open include file: 'png.h': No such file or directory ==
* ''imagepng.cpp : fatal error C1083: Cannot open include file: 'libpng12/png.h': No such file or directory.''
There are a couple of files missing since the 1.17. distribution. You can either get the missing files from the internet (from the libpng and zlib projects) or download a set with just the missing files from [http://www.blueflash.cc/users/nicholaz/~libs here] (see the readme.txt inside the png archive there).
 
 
== Cannot open include file: 'glh/glh_linear.h' or 'glh/glh_convenience.h' ==
These files are currently missing from Linden Windlight distributions. See [https://jira.secondlife.com/browse/VWR-3415 JIRA VWR-3415] or grab a copy from [http://www.blueflash.cc/users/nicholaz/~libs here] and put the files into a folder named linden/libraries/include/glh.
 
 

== Errors relating to "template_verifier.py" ==
With version 1.18 a template verifier script written in Python is used to ensure the message template is correct. In some distributions the file was missing. You will also get an error if you have skipped the Python install. In both cases it is safe to hack the prebuild.bat file in the newview folder as described on the JIRA [http://jira.secondlife.com/browse/VWR-1267 VWR-1267]
 
 

== Missing resources ==
* ''.\res\newViewRes.rc(64) : error RC2135 : file not found: ll_icon.ico''
Some releases have missing files, which were reported to be last seen in the '''1.14.0.1''' release.
* Go to the [[source downloads]] page and grab the [[http://secondlife.com/developers/opensource/downloads/2007/04/slviewer-src-1.14.0.1.zip '''1.14.0.1''' viewer]] sources.
* Explore the archive to "linden/indra/newview/res" folder and extract content to your "linden/indra/newview/res" folder into current revision.
Missing folder in recent release, "'''1.17.0.12'''" which causes the SecondLife to hang while loading into the world.
* Go to the previous source and copy the missing folder, "Character" and place it into the "newview" folder
 
== Error code from "Copying message template" ==
* ''newview error PRJ0019: A tool returned an error code from "Copying message template"''
This is caused by the script trying to do a copy command, but the source path isn't in quotes. Open up newview.vcproj in notepad, and near the bottom there are 4 line that say:
CommandLine="copy $(InputPath) .\app_settings\message_template.msg
replace them with
CommandLine="copy &quot;$(InputPath)&quot; .\app_settings\message_template.msg
The source and destination paths on line 158 may also require wrapping in quotes. In which case:
CommandLine="copy $(TargetDir)\$(TargetFileName) $(ProjectDir)
should become:
CommandLine="copy &quot;$(TargetDir)\$(TargetFileName)&quot; &quot;$(ProjectDir)&quot;
 
== Can not find library ll*.lib ==
If you get a compile error for missing libraries with names of the projects (lscript_compile.lib, llaudio.lib, llcharacter.lib, etc.) go to newview > Properties > Linker > Input and remove these from the list of input libraries (they will be linked through the dependencies and should not be in the list).
 
 

== Cannot open include file: 'windows.h' ==
If you run into this problem:
..\..\..\boost/regex/v4/fileiter.hpp(44) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
Fix it with this: (thanks Fairlight!)
set INCLUDE=C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include;%INCLUDE%
set LIB=C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib;%LIB%
You might need to edit the above path to refer to your particular platform SDK. If you don't have the Microsoft Windows Platform SDK installed, then you can download it for free from Microsoft. It is version specific and can be tricky to find on their website.

If you're having problems with windows.h in Visual Studio Express 2005, check out this forum post:
[http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1995837&SiteID=1 MSDN Forum Post]

 

== Unresolved external symbol "int __cdecl lscript_compile" (VS2005) ==
* ''llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z)''
* ''llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z)''

This is not entirely clear, but there seems to be a problem with VS2005 if projects are unloaded while being in the dependency tree. I have seen this error while I had win_crash_logger and win_updater unloaded from the project tree and the problem went away when I loaded them back and excluded them from the newview dependency first.

Also make sure that in newview, properties, linker, input, input libraries, no libraries named ll*.lib and lscript_compile.lib are listed there (remove them if you find them).

Also be sure that your error does not come from previously in the log: like the cgywin component bison not being found. For MSVS2005 Express, you may need to go to tools>options>Projects and Solutions>VC++ Directories>Executable files and add the directory for cgywin.

 
 

== Unresolved external symbol __invalid_parameter_noinfo (VS2005) ==
* ''llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced''

You are most likely trying a debug build under VS2005. For debug builds, see the compile instruction section on [[finding_leaks]]
 
 

== Cannot open include file: 'ares.h' ==
download src from http://daniel.haxx.se/projects/c-ares/

compile c-ares-1.4.0/vc/areslib

copy c-ares-1.4.0/vc/areslib/Release/areslib.lib to linden/libraries/i686-win32/lib_release and to lib_debug

copy c-ares-1.4.0/*.h to linden/libraries/i686-win32/include/ares

===FMOD===
FMOD headers and libs need to be copied into the viewer build directory BUT on Windows the manifests are not currently moving the libs to the correct location post build so the application will fail to run, to resolve copy fmod.dll to indra/build-vc71/newview/debug and indra/build-vc71/newview/relwithdebinfo and indra/build-vc71/newview/release

===Boost and VS 2008===
If you use Visual Studio C++ 2008 (VC90), you may find that the Boost library will lock up solid and the viewer will not tun consuming 50-100% of CPU doing nothing. The only solutions are to use Visual Studio 2005 OR to get a newer version/rebuild boost with Visual Studio 2008.

This problem is being worked on. Look here for updates: [https://jira.secondlife.com/browse/VWR-9541 VWR-9541]

===Express editions of Visual C++===
Express editions do not have some of the extra features that VSTool.exe requires, VSTool is a little application that sets a few default project options, like which project is the startup and which build configuration to use.

===LLKDU===
This is not present in the automated libs download but is required at least on windows by the copy_win_scrips script. The file is not actually needed for the viewer to run (if present it will be used for jpeg2000 decoding in preference to Openjpeg. The solution is to remove the lines from newview/copy_win_scripts that reference llkdu and this should then allow this custom build step to run without issue

=== [...]/CMakeDetermineCompilerABI_C.bin cannot be read. ===
Occurs on Windows 7, make sure your running the cmd shell (or whatever your using to run the "python develop.py") with Administrator privileges.

== fatal error C1060: compiler is out of heap space ==
If you are not using Incredibuild and have precompiled headers disabled, you may encounter this error.
Try enabling building with precompiled headers:
<pre>autobuild configure -c [configuration] -- -DUSE_PRECOMPILED_HEADERS:BOOL=ON</pre>

== Other (older) notes ==
* Mozilla is not compatible with visual studio 2005, so we have not migrated the codebase, so we do not know if it works.

* Added my errors at [[User:Adam_Zaius/MSVS2005 Errors]] [[User:Adam Zaius|Adam Zaius]] 09:40, 8 January 2007 (PST)

* To minimize the number of warnings for now: in C/C++-Preprocessor add ';_CRT_SECURE_NO_DEPRECATE' to the Preprocessor Definitions, that will supress deprecation warnings --[[User:Artm Udal|Artm Udal]] 12:42, 8 January 2007 (PST)

 

= Mac OS X =

Getting:

*/linden/indra/newview/../llwindow/llglheaders.h:377:31: error: GL/glh_extensions.h: No such file or directory
** This means you didn't [[Compiling the viewer (Mac OS X)#Viewer Source, Libraries, and Artwork|merge the libraries]] right.

 

= Linux =

=== libGL ===

Sometimes the provide libGL.a can cause issues. To avoid linker errors, you may need to remove indra/libraries/i686-linux/release/libGL.a and indra/libraries/i686-linux/debug/libGL.a

=== Packaging errors ===

The final packaging step may fail with errors about the manifest if you are not using the slviewer-linux-libs bundle; in this case, if you still wish to end up with an end-user viewer package incorporating your own libraries, you can edit the manifest file found at indra/newview/viewer_manifest.py

=== Various Compilation problems ===

====Various missing libraries====
<pre>g++-3.4 -o linux_crash_logger/linux-crash-logger-i686-bin-globalsyms --no-keep-memory --reduce-memory-overheads /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/llcrashlogger/llcrashlogger.o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/linux_crash_logger/linux_crash_logger.o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/i686-linux-client-release/linux_crash_logger/llcrashloggerlinux.o -Llib_release_client/i686-linux -L/home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client -lllui -lllxml -lllmessage -lllvfs -lllmath -lllcommon -lcurl -lssl -lcrypto -laprutil-1 -lapr-1 -lcares -lexpat -ldb-4.2 -lgtk-x11-2.0
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcurl.a when searching for -lcurl
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libssl.so when searching for -lssl
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcrypto.so when searching for -lcrypto
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libaprutil-1.so when searching for -laprutil-1
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libapr-1.so when searching for -lapr-1
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libcares.a when searching for -lcares
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libexpat.so when searching for -lexpat
/usr/bin/ld: skipping incompatible /home/paul/builds/secondlife/src/linden/libraries/i686-linux/lib_release_client/libdb-4.2.so when searching for -ldb-4.2
/usr/bin/ld: cannot find -ldb-4.2
collect2: ld returned 1 exit status</pre>

[paul@myhost secondlife]$ pacman -Q db
db 4.6.21-2

[paul@myhost secondlife]$ uname -a
Linux myhost 2.6.23-ARCH #1 SMP PREEMPT Tue Jan 15 07:17:51 CET 2008 x86_64 Intel(R) Celeron(R) CPU 2.66GHz GenuineIntel GNU/Linux

And using:<pre>
source=('secondlife.desktop' 'secondlife.install' 'secondlife.launcher' \
"http://secondlife.com/developers/opensource/downloads/2008/01/slviewer-src-RC-${pkgver}.tar.gz" \
'http://secondlife.com/developers/opensource/downloads/2007/12/slviewer-artwork-RC-1.18.6.2.zip' \
'http://secondlife.com/developers/opensource/downloads/2007/12/slviewer-linux-libs-RC-1.18.6.2.tar.gz' \
'http://www.fmod.org/index.php/release/version/fmodapi375linux.tar.gz' \
'http://secondlife.com/developers/opensource/downloads/2007/12/llmozlib-src-20071221.tar.gz')</pre>

Hum ok, I was trying to use:
scons DISTCC=no BTARGET=client BUILD=release MOZLIB=yes

I'll retry with:
scons BUILD=release ARCH=x86_64 BTARGET=client DISTCC=no MOZLIB=yes FMOD=yes GSTREAMER=yes STANDALONE=yes
(Sconstruct says that with STANDALONE=yes -db-4.2 will not be used)

But at the beginning I get:
<pre>
scons: Reading SConscript files ...
Building client 1.18.6.2 on x86_64-linux (release)
No CCACHE_DIR set.

scons: warning: Two different environments were specified for target /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llcrashlogger/llcrashlogger.o>,
but they appear to have the same action: $CXX -o $TARGET -c $CXXFLAGS $_CCCOMCOM $SOURCES
File "/home/paul/builds/secondlife/src/linden/indra/SConstruct", line 568, in create_executable
scons: done reading SConscript files.
scons: Building targets ...</pre>

well, the new scons line give different problem:
<pre>g++ -o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.o -c -g -pipe -Wall -Wno-reorder -Wno-trigraphs -Wno-sign-compare -Werror -fexceptions -pthread -D_REENTRANT -fno-math-errno -fsigned-char -fno-strict-aliasing -falign-loops=16 -ffast-math -O2 -D_FORTIFY_SOURCE=2 -DLL_STANDALONE -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0 -DLL_X11=1 -DLL_GTK=1 -DLL_LIBXUL_ENABLED=1 -DLL_GSTREAMER_ENABLED=1 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illcrashlogger -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -Ilscript/lscript_compile -I/home/paul/builds/secondlife/src/linden/libraries/include -I/home/paul/builds/secondlife/src/linden/libraries/include/havok -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include -I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/SDL -I/usr/include/apr-1 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gstreamer-0.10 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/libxml2 /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp
cc1plus: warnings being treated as errors
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp: In function 'const char* OrderToString(LLQuaternion::Order)':
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:701: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:704: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:707: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:710: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:713: warning: deprecated conversion from string constant to 'char*'
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.cpp:716: warning: deprecated conversion from string constant to 'char*'
scons: *** [/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llmath/llquaternion.o] Error 1
scons: building terminated because of errors.</pre>

Well, STANDALONE=yes make it use g++ rather than g++-3.4, so I decided to remove it, keeping
ARCH=X86_64 and others, but I get:
<pre>ranlib lib_release_client/x86_64-linux/libllprimitive.a
g++-3.4 -o /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.o -c -g -pipe -Wall -Wno-reorder -Wno-trigraphs -Wno-sign-compare -Werror -fexceptions -pthread -D_REENTRANT -fno-math-errno -fsigned-char -fno-strict-aliasing -falign-loops=16 -ffast-math -O2 -D_FORTIFY_SOURCE=2 -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0 -DLL_X11=1 -DLL_GTK=1 -DLL_LIBXUL_ENABLED=1 -DLL_GSTREAMER_ENABLED=1 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illcrashlogger -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -Ilscript/lscript_compile -I/home/paul/builds/secondlife/src/linden/libraries/include -I/home/paul/builds/secondlife/src/linden/libraries/include/havok -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/ELFIO -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/atk-1.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gtk-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/llfreetype2 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/pango-1.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/gstreamer-0.10 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0 -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/glib-2.0/include -I/home/paul/builds/secondlife/src/linden/libraries/x86_64-linux/include/libxml2 /tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:41:44: llfreetype2/freetype/ft2build.h: No such file or directory
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:56: error: `FT_Render_Mode' does not name a type
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:60: error: `FT_Library' does not name a type
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp: In constructor `LLFontManager::LLFontManager()':
/tmp/paul/home/paul/builds/secondlife/src/linden/indra/x86_64-linux-client-release/llrender/llfont.cpp:78: error: `gFTLibrary' was not declared in this scope
... [many more errors]</pre>

oh well, SConstruct says I need: cairo glib-2.0 atk gmobile-2.0 gdk-2.0 gdk-pixbuf-2.0 pango pangoft2 pangox pangoxft gtk+-2.0 sdl vorbis vorbisenc vorbisfile

Maybe this is pangoft2 that is missing.

* This part is probably not relevant anymore --[[USER:Thickbrick Sleaford|Thickbrick]]

===="Unable to initialize communications"====
* If the viewer just displays the error message " Unable to initialize communications" and exits, it can't find message_template.msg. You did remember to copy it over, right?

====Blino's SL build/linking patches for '''gcc4'''====
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/secondlife/current/

====objcopy: 'newview/linux_tools/exposed-symbols.txt': No such file====
* Tofu says... 'This is an omission from our manifest which I'll fix. Meanwhile it's a safe fix to create an empty file with that name.'

====Something like: /usr/bin/ld: cannot find -lz====
* Nadia says: Install the zlib development headers. (Ubuntu package zlib1g-dev, Red Hat zlib-devel.)

====Something like: indra.y.cpp:17: error: previous declaration of `int yyparse()'====
* Tofu says... 'This appears to be a problem with some versions of flex/bison. A resident reports success when comment out the #ifdef __cplusplus lines in lscript/lscript_compile/indra.y'
* Nadia says: install the zlib development headers first and try recompiling. Commenting out those lines results in a error indra.l:666: undefined
* Abi says: I forgot to install bison. Once I did that, problem solved.

====Linking failures ("script not found") due to spaces in the LINKFLAGS variable?====
* I saw a [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665538 report], and modified the SConstruct file to drop the trailing arguments (and spaces) in LINKFLAGS.

====''cp: target `SecondLife_i686_1_13_1_7/app_settings/*’ is not a directory''====
Building [https://lists.secondlife.com/pipermail/sldev/2007-January/000091.html 20070112a] using ''BUILD=releasefordownload'' I get many ''[: 89: ==: unexpected operator'' errors; ''cp: target `SecondLife_i686_1_13_1_7/app_settings/*’ is not a directory'' error, and same thing for character, fonts, help, skins, res-sdl; ''[: 111: ==: unexpected operator, [: 120: SecondLife_i686_1_13_1_7.tar.bz2: unexpected operator''. I can succesfully run the client from the source tree.
* i think this has been fixed --[[User:Signore Iredell|Signore Iredell]] 06:09, 9 June 2007 (PDT)

====`['.../lscript/lscript_compile/indra.l.cpp']': Don't know how to build a file with suffix `.l'====
scons: *** While building `['.../linden/indra/i686-linux-client-release/lscript/lscript_compile/indra.l.cpp']': Don't know how to build a file with suffix `.l'.
* You probably don't have all the dependencies installed (I had the same problem). Check that you have flex and bison. --[[User:Random73 Janus|Random73 Janus]] 07:43, 16 May 2007 (PDT)

====`glActiveTextureARB' was not declared in this scope====
Something like: linden/indra/i686-linux-client-release/llrender/llimagegl.cpp:122: error: `glActiveTextureARB' was not declared in this scope
* Tofu says... 'You'll need to install OpenGL headers if you don't already have them: gl.h, glext.h, glu.h (The ones from 'mesa' should work)
* two residents report good luck on Gentoo after doing 'eselect opengl set xorg-x11' (but note!! You must know what you're doing; this may change your default system OpenGL drivers, and you will probably want to change them back again after the compile, e.g. 'eselect opengl set nvidia')'
* Note that the above xorg-x11/nvidia issue is addressed in [http://jira.secondlife.com/browse/VWR-9557 VWR-9557] which includes patches!

====Building Shared Library ELFIO====
Building Shared Library ELFIO [[Compiling_the_viewer_%28Linux%29]] on AMD64 ubuntu 6.10
g++-3.4 -shared *.o -o libelfio.so
/usr/bin/ld: ELFIDynamic.o: relocation R_X86_64_32 against `a local symbol' can
not be used when making a shared object; recompile with -fPIC
ELFIDynamic.o: could not read symbols: Bad value'''
* I got around this with "export CXXFLAGS=-fPIC" before configuring ELFIO.

====incompatible libopenjpeg.a when searching for -lopenjpeg====
Building Client on Ubuntu 7.04 AMD64
/usr/bin/ld: skipping incompatible /home/dereck/Desktop/SLdev/linden/libraries/i686-linux/lib_release_client/libopenjpeg.a when searching for -lopenjpeg
/usr/bin/ld: cannot find -lopenjpeg
collect2: ld returned 1 exit status
* I went to the OpenJPEG website, downloaded the source, compiled for my system, installed it. The VWR compile was happy after that. Although it's not done yet and I'm still fixing another error, that I assume is unrelated.

====C-Ares compatability issue.====
Compiling with c-ares version 1.5.1 got a compile error in llares.cpp:

linden/indra/x86_64-linux-client-release/llcommon/llares.cpp: In member function `void LLAres::getHostByName(const char*, LLAres::HostResponder*, int)':

linden/indra/x86_64-linux-client-release/llcommon/llares.cpp:147: error: invalid conversion from `void (*)(void*, int, hostent*)' to `void (*)(void*, int, int, hostent*)'

Fixed with patch from https://jira.secondlife.com/browse/VWR-3480

====memset used with constant zero length parameter====
Building with -t Release causes memset error in /usr/include/bits/string3.h:82
The error is "/usr/include/bits/string3.h:82: error: call to `__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters"

Patch: [http://jira.secondlife.com/browse/VWR-10001 VWR-10001]

====Boost errors in Snowglobe (GCC >= 4.3)====
Build stops with errors: "../libraries/include/boost/token_functions.hpp:338: error: suggest explicit braces to avoid ambiguous 'else'"

See [http://jira.secondlife.com/browse/SNOW-204 SNOW-204]

====Gentoo: undefined reference to `FT_Realloc'* from libpangoft2-1.0.so====
If you get an undefined reference to `FT_Realloc'* from libpangoft2-1.0.so, you might have to delete some bundled libraries. [http://imprudenceviewer.org/wiki/How_to_compile#Removing_Bad_Libraries_on_Gentoo_Linux See here]

[[Category:Compiling viewer]]

LlGetRot

2015-07-01T17:41:45Z

Pedro Oval: <lsl> to <source>

{{LSL_Function
|func=llGetRot
|sort=GetRot
|func_id=62|func_sleep=0.0|func_energy=10.0
|func_desc
|func_footnote
|return_type=rotation
|return_text=that is the prim's rotation relative to the [[Viewer coordinate frames#Region|region]]'s axes.
|constants
|spec
|caveats=
* [[llGetRot]] incorrectly reports the avatars rotation when called from the root of an attached object, use [[llGetLocalRot]] for root prims, instead
** [[llGetRot]] will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise when called from an attached prim.
**When called in an attachment's child prim, the reported rotation will only be visually correct if the object's root is attached to [[ATTACH_AVATAR_CENTER]], at [[ZERO_ROTATION]]. Moving the attachment's root or changing the attachment point will not affect the reported rotation. Avatar animation is invisible to the simulator, so it also does not affect the reported rotation. Also see [[Rotation#Single_or_Root_Prims_vs_Linked_Prims_vs_Attachments|Single or Root Prims vs Linked Prims vs Attachments]].
|examples=
<source lang="lsl2"> //-- rotates an object to face the nearest cardinal direction (N,E,S,W)
//-- assumes build is aligned to root object facing

default{
state_entry()
{
llSay( 0, "Rotate me in edit, then touch to make me face the nearest compass point" );
}

touch_start( integer vIntTouches )
{
//-- convert our rotation to x/y/z radians
vector vRadBase = llRot2Euler( llGetRot() );
//-- round the z-axis to the nearest 90deg (PI_BY_TWO = 90deg in radians)
llSetRot( llEuler2Rot( <0.0, 0.0, llRound( vRadBase.z / PI_BY_TWO ) * PI_BY_TWO > ) );
}
}</source>
|helpers
|also_header
|also_functions=
{{LSL DefineRow||[[llGetLocalRot]]|}}
{{LSL DefineRow||[[llGetRootRotation]]|}}
{{LSL DefineRow||[[llGetPrimitiveParams]]|}}
{{LSL DefineRow||[[llSetRot]]|}}
{{LSL DefineRow||[[llSetLocalRot]]|}}
{{LSL DefineRow||[[llSetPrimitiveParams]]|}}
{{LSL DefineRow||[[llSetLinkPrimitiveParams]]|}}
{{LSL DefineRow||[[llSetLinkPrimitiveParamsFast]]|}}
|also_tests
|also_events
|also_articles
|also_footer
|notes
|mode
|deprecated
|location
|cat1=Movement
|cat2=Rotation
|cat3=Prim
|cat4
|cat5
|cat6
}}

Viewer coordinate frames

2015-07-01T17:39:12Z

Pedro Oval: Fix formatting glitch (text contained something that wasn't a tag in past but now it is)

{{Multi-lang}}
{{ViewerArchNav}}

= Coordinate frames =
There are currently four different reference frames which are being used on the viewer.
Note that there are a couple of cases in the code which do NOT follow this convention on the viewer: The rendering code uses "World" and "W" for Agent, and some of the character/joint code doesn't have a coordinate frame specified, but is specified in Agent.
Also, common libraries (LLCamera and LLPrimitive in particular) do NOT use this convention. Be particularly careful when pulling values directly out of these.

=== Global ===
Absolute global coordinate frame, expressed using F64's. This is derived from the U32 x and y coords of the handles of regions, plus the region offset. Precise enough for ~109 regions on an edge with same precision as region-local coordinates.

=== {{Anchor|region-local|Region}} ===
''Also called region-local.'' 
Origin is the origin of the [[Land#Region|region]] which "owns" the object.

=== Agent ===
Currently, the origin is the origin of the agent's current region. THIS DOES NOT necessarily have to be the case in the future. This should be used only for code involving rendering (pipeline, visibility/frustum calculations)

=== Local ===
Currently a catch-all for coordinate frames which are not one of the ones above. Generally object-relative positioning.

The local frame is used in two ways in [[LSL]]:
:<h4> Child Prims </h4>
:Child prims (not root prims) are positioned local to the root prim; their global position and angle affected by both the root prim's rotation and position.
:<h4> Attachments </h4>
:Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar and the playing animations{{Footnote|Playing animations don't affect the positions and rotations returned or used by LSL, they only affect how the viewer displays the position of the attachments.}}.

= Naming conventions =
ALL variables/class members dealing with values in one of these coordinate frames should be post-fixed appended with the coordinate frame that it's being used in. PLEASE do this - it greatly reduces errors.

For example:
<pre>
mPositionGlobal, pos_global
mPositionRegion, pos_region
mPositionAgent, pos_agent
</pre>

= Conversion functions =
In LLAgent and LLViewerRegion there are conversion functions for converting from one coordinate frame to the other. They have syntax of the form getPos<target>From<source>() - i.e. getPosAgentFromGlobal() converts from the global coordinate frame to the agent coordinate frame.

= Type conversion =
In order to support the high-precision global coordinates, there is a new class LLVector3d, standing for LLVector3, double precision. It's somewhat inconsistent, but the only other alternative was renaming ALL of the math classes to use the GL style last-letter type convention, which I wasn't up to doing.

ALL math being done in global coordinates should be done using LLVector3ds. Currently, all functions which return global coordinates do so in LLVector3ds. The ONLY current exception to this is audio, which I am converting to regular LLVector3s before handing them off to the audio engine - I guess this will be the case until we convert the audio engine to use agent coords.

The LLVector3d class DELIBERATELY does not have ANY form of automatic type-conversion between it and the LLVector3 class. Since conversion back and forth isn't cheap (and potentially loses precision), you have to explicitly do a setVec() on the other class to convert back and forth.

= Footnotes =
{{Footnotes}}

Limits

2015-05-20T12:52:35Z

Pedro Oval: /* Sound */ Exactly 10 seconds

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers''' including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers from before the layer limits project: 5 per slot
** On viewers with revised layer limits: up to 60 total, no per-slot limit. ''As of May 2015, this is only available in candidate viewers.''
** In any case, only one each of shape, skin, eyes and hair base may be worn.
* '''Max Clothing Texture''' - 512x512 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures.
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 10 teleports per 15 seconds, since SL server 1.27.1

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first. Size is after conversion to SL [[Internal Animation Format|internal animaton format]], not BVH source which can be much larger.
| n/a

|-
||animation priority
| {{no|0}}
| {{no|4, with custom tools 6}}
| n/a
| [[Animation_Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.

The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive'' channels, to 1023 bytes. These limits do not affect scripts.
| [[llInstantMessage]]
|-
||Number of offline messages
| n/a
| {{no|Capped at 25 messages, unless the account has a Premium Subscription, in which case the cap raises to 50 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above 25 (or 50 in the case of Premium members), go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|-
| Maximum steps data
| n/a
| {{no|1000 bytes}} of packed data; saving with more data returns the message "Gesture save failed. This gesture has too many steps. Try removing some steps, then save again." Shorter text, for example, will allow more steps.
| n/a
| n/a
|-
||Length of included assets
| n/a
| see sections for [[#Animation|animation]], [[#Sound|sound]]
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/X/128/128/24 X].
* '''Maximum ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters. If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** Full region: 100 (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]}}
| n/a
| n/a
|-
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|10.00000 seconds (441,000 samples)}}
| 441,001 samples (10.00002 seconds) won't work. You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - 4:3 (60×45 pixels)
* '''Profile > Pick expanded''' - 4:3 (320×240 pixels)

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

LlSetPrimMediaParams/Tricks

2015-05-13T11:41:01Z

Pedro Oval: Last missing tag

== Shared Media and HTTP-In ==
{{Warning|While these tricks are still useful, they are largely unneeded now with [[llSetContentType]] and [[CONTENT_TYPE_HTML]]}}

Pre-Viewer 2.0 interfacing with an LSL script is a jumble of llDialog, chats, touches and possibly external web sites. With Shared Media that all changes.

One step at a time .......
=== llSetPrimMediaParams ===
* Use llSetPrimMediaParams to set the url and various parameters on the face of a prim via LSL.
<source lang="lsl2">
default
{
state_entry()
{
llSetPrimMediaParams(0, // Side to display the media on.
[PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately
PRIM_MEDIA_CURRENT_URL,"http://google.com", // The url currently showing
PRIM_MEDIA_HOME_URL,"http://google.com", // The url if they hit 'home'
PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be
PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2.
}
}
</source>

=== data: urls ===
There is a special url type: "data:" that lets you send the html ''in the url''. Paste the below into your browser's address bar.
<pre>
data:text/html,<h1>This is a test</h1><h2>This is a test</h2><h3>This is a test</h3>
</pre>

=== llSetPrimMediaParams for data: urls ===
* Thus you can build arbitrary html in your LSL script and display it on the face of the prim
<source lang="lsl2">
show(string html)
{
html = "data:text/html," + llEscapeURL(html);
llSetPrimMediaParams(0, // Side to display the media on.
[PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately
PRIM_MEDIA_CURRENT_URL,html, // The url currently showing
PRIM_MEDIA_HOME_URL,html, // The url if they hit 'home'
PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be
PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2.
}
default
{
state_entry()
{
show("<h1>This is a test</h1><h2>This is a test</h2><h3>This is a test</h3>");
}
}
</source>

=== HTTP-In ===
* Scripts can become web servers via HTTP-In
<source lang="lsl2">
default
{
state_entry()
{
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL is: " + body);
}
else if (method == "GET")
{
llSay(0,"Received page request.");
llHTTPResponse(id,200,"OK");
}
}
}
</source>

=== llSetPrimMediaParams for data: urls that link back to HTTP-In ===
* Which means you can make web pages that trigger other page views via http-in links
<source lang="lsl2">
show(string html)
{
html = "data:text/html," + llEscapeURL(html);
llSetPrimMediaParams(0, // Side to display the media on.
[PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately
PRIM_MEDIA_CURRENT_URL,html, // The url currently showing
PRIM_MEDIA_HOME_URL,html, // The url if they hit 'home'
PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be
PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2.
}

string replace_all(string src, string target, string replace)
{
return llDumpList2String(llParseString2List(src,[target],[]),replace);
}

string get_query(key id, string name)
{
string query = llGetHTTPHeader(id,"x-query-string");
query = replace_all(query,"+"," ");
query = llUnescapeURL(query);
list q = llParseString2List(query,["=","&",";"],[]);
integer i = llListFindList(q,[name]);
if (i != -1)
{
return llList2String(q,i+1);
}

return "";
}

default
{
state_entry()
{
show("<h1>This is a test</h1><h2>This is a test</h2><h3>This is a test</h3>");
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
show("<h1><a href='" + body + "/?get=owner'>Owner ID</a> <a href='" + body + "/?get=object'>Object ID</a></h1>");
}
else if (method == "GET")
{
string get = get_query(id,"get");
if (get == "owner")
{
llHTTPResponse(id,200,"Owner is: " + (string)llGetOwner());
}
else if (get == "object")
{
llHTTPResponse(id,200,"Object is: " + (string)llGetKey());
}
else
{
llHTTPResponse(id,400,"huh?");
}
}
}
}
</source>

=== Forms ===
* You can put forms in data: urls
<pre>
data:text/html,<form action="http://google.com/search" method="GET">Search:<input type="text" name="q"><input type="submit" value="Submit"></form>
</pre>

=== The Magic ===
* You can set the script HTTP-In url as the form action to get the results of the form sent back to the script
<source lang="lsl2">
string html_base =
"<h1><form action='%url%' method='GET'>
Floating Text:<input type='text' name='text'> 
<input type='submit' value='Set'>
</form></h1>";

string url;

integer r;
show(string html)
{
html = "data:text/html," + llEscapeURL(html) + "";

llSetPrimMediaParams(0, // Side to display the media on.
[PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately
PRIM_MEDIA_CURRENT_URL,html, // The url currently showing
PRIM_MEDIA_HOME_URL,html, // The url if they hit 'home'
PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be
PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2.
}

string replace_all(string src, string target, string replace)
{
return llDumpList2String(llParseString2List(src,[target],[]),replace);
}

string get_query(key id, string name)
{
string query = llGetHTTPHeader(id,"x-query-string");
query = replace_all(query,"+"," ");
query = llUnescapeURL(query);
list q = llParseString2List(query,["=","&",";"],[]);
integer i = llListFindList(q,[name]);
if (i != -1)
{
return llList2String(q,i+1);
}

return "";
}

default
{
state_entry()
{
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
url = body + "/";

show(replace_all(html_base,"%url%",url));
}
else if (method == "GET")
{
llSetText(get_query(id,"text"),<1,1,0>,1);
show(replace_all(html_base,"%url%",url));
llHTTPResponse(id,200,"Loading....");
}
}
}
</source>

=== The Limits ===
* 1024 bytes per url
* llEscapeURLs means non-alphanumeric characters are 3 bytes (ouch)
** I'm actually not clear on if this is really needed. I seem to sometimes get blank pages if I don't but some pages render fine with out it. Maybe there is a subset of symbols that must be escaped and escaping only those would ease some of the space constraints?
* Must force another page view after form submission since HTTP-In can't generate HTML
* No real way of knowing which avatar is interacting with the HTML

=== The Tricks ===
* <base href="<http-in-url>/">
** HTTP-In urls are long, especially if escaped. In a page that includes more than a single link back to the script, or more than a single form, this can save a lot of space.
* Tiny urls
** You can use url shortening services to create short links to long data urls. In theory this should let you get past the 1k limit quite nicely, however there is overhead in setting up the tiny url.
=== The future? ===
I think there is a lot more potential here than what I have outlined .... if you have ideas or work out great new hacks let me know! Also let me know if it is ok to share those hacks with others. :)
* svg?
* javascript?
* ajax?

=== DHTML / Javascript (Tali Rosca) ===
Tali Rosca sent me the code to render the output of HTTP-In directly. I've wrapped her magic into the build_url and build_response functions in the example below. This example renders a page that is around 3.5k bytes - well past the 1k limit of urls. 
'''Pros''':
* Navigation is much smoother and feels more natural
* Only limited by script memory
'''Cons''':
* Links are extremely large: 296 bytes for a link to just the base http-in url.

<source lang="lsl2">
string url; // Our base http-in url
integer r; // Used for uniqueness in PrimMedia urls
integer page; // The page number.

show(string html)
{
html += "";

llSetPrimMediaParams(0, // Side to display the media on.
[PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately
PRIM_MEDIA_CURRENT_URL,html, // The url if they hit 'home'
PRIM_MEDIA_HOME_URL,html, // The url currently showing
PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be
PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2.
}

// This creates a data: url that will render the output of the http-in url
// given.
string build_url(string url)
{
return "data:text/html,"
+ llEscapeURL("<html><head><script src='" + url
+ "' type='text/javascript'></script></head><body onload='init()'></body></html>");
}

// This wraps the html you want to display so that it will be shown from links
// made with build_url
string build_response(string body)
{
return "function init() {document.getElementsByTagName('body')[0].innerHTML='" + body + "';}";
}

default
{
state_entry()
{
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
url = body + "/";

show(build_url(url + "page" + (string)(page)));
}
else if (method == "GET")
{
string path = llGetHTTPHeader(id,"x-path-info");
string content = "<h1>path: " + path + "</h1>";
page = (integer)llGetSubString(path,5,5);
if (page > 0) content += "<a href=\"" + build_url(url + "page" + (string)(page - 1)) + "\">Previous</a> ";
if (page < 9) content += "<a href=\"" + build_url(url + "page" + (string)(page + 1)) + "\">Next</a> ";
integer k;
for(;k<10;++k)
{
if (k == page)
content += " Page " + (string)k;
else
content += " <a href=\"" + build_url(url + "page" + (string)(k)) + "\">Page " + (string)k + "</a>";
}
content += " This page is " + (string)(llStringLength(build_response(content)) + 37) + " bytes long.";
llHTTPResponse(id,200,build_response(content));
}
}
}
</source>
* I'm not quite sure if it is possible to hook up a form using this method. Ideas?

=== Another javascript boot strapping method (Vegas Silverweb) ===
This one makes it pretty easy to build out some arbitrary length web pages, using http-in's output directly. Loading between pages is kinda slow.
<source lang="lsl2">
string URL;

string get(string page)
{
if (page == "index")
{
return "<h1>Index</h1>This is the index page. <a href='page1.html'>Link to page 1</a>";
}
else if (page == "page1")
{
return "<h1>Page 1</h1>This is page 1!. <a href ='index.html'>Link to the index page.</a>";
}
else return "Unknown page.";
}

string serve(string page)
{
return "document.write(atob('"+llStringToBase64(get(page))+"'));";
}

integer R;
load(string page)
{
string content="data:text/html;base64,"
+llStringToBase64("<html><head><base href='"+URL+"/'></head><body>"+
"<script src='"+page+".js' type='text/javascript'>"+
"</script></html>");

llSetPrimMediaParams(0,[
PRIM_MEDIA_CURRENT_URL,content,
PRIM_MEDIA_HOME_URL,content,
PRIM_MEDIA_AUTO_ZOOM,FALSE,
PRIM_MEDIA_FIRST_CLICK_INTERACT,TRUE,
PRIM_MEDIA_PERMS_INTERACT,PRIM_MEDIA_PERM_ANYONE,
PRIM_MEDIA_PERMS_CONTROL,PRIM_MEDIA_PERM_NONE,
PRIM_MEDIA_AUTO_PLAY,TRUE
]);
}

default
{
state_entry()
{
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
URL = body;
load("index");
}
else if (method == URL_REQUEST_DENIED)
{
llOwnerSay("Unable to get url!");
}
else if (method == "GET")
{
string path_raw = llGetHTTPHeader(id,"x-path-info");
if (path_raw == "")
{
// No path, assume index.html
path_raw = "/index.html";
}

list path = llParseString2List(llGetSubString(path_raw,1,-1),["."],[]);
string page = llList2String(path,0);
string type = llList2String(path,1);

if (type == "js")
{
llHTTPResponse(id,200,serve(page));
}
else if (type == "html")
{
llHTTPResponse(id,100,"");
load(page);
}
}
}
}
</source>
[[Category:Shared Media]]

Limits

2015-05-09T19:28:44Z

Pedro Oval: /* Communication */ Formatting screwup

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers''' including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers from before the layer limits project: 5 per slot
** On viewers with revised layer limits: up to 60 total, no per-slot limit. ''As of May 2015, this is only available in candidate viewers.''
** In any case, only one each of shape, skin, eyes and hair base may be worn.
* '''Max Clothing Texture''' - 512x512 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures.
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 10 teleports per 15 seconds, since SL server 1.27.1

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first. Size is after conversion to SL [[Internal Animation Format|internal animaton format]], not BVH source which can be much larger.
| n/a

|-
||animation priority
| {{no|0}}
| {{no|4, with custom tools 6}}
| n/a
| [[Animation_Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.

The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive'' channels, to 1023 bytes. These limits do not affect scripts.
| [[llInstantMessage]]
|-
||Number of offline messages
| n/a
| {{no|Capped at 25 messages, unless the account has a Premium Subscription, in which case the cap raises to 50 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above 25 (or 50 in the case of Premium members), go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/X/128/128/24 X].
* '''Maximum ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters. If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** Full region: 100 (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]}}
| n/a
| n/a
|-
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|any length ''less than'' 10.0 seconds}}
| You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - 4:3 (60×45 pixels)
* '''Profile > Pick expanded''' - 4:3 (320×240 pixels)

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

Limits

2015-05-09T19:28:02Z

Pedro Oval: /* Communication */ Add also a note on positive channels.

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers''' including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers from before the layer limits project: 5 per slot
** On viewers with revised layer limits: up to 60 total, no per-slot limit. ''As of May 2015, this is only available in candidate viewers.''
** In any case, only one each of shape, skin, eyes and hair base may be worn.
* '''Max Clothing Texture''' - 512x512 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures.
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 10 teleports per 15 seconds, since SL server 1.27.1

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first. Size is after conversion to SL [[Internal Animation Format|internal animaton format]], not BVH source which can be much larger.
| n/a

|-
||animation priority
| {{no|0}}
| {{no|4, with custom tools 6}}
| n/a
| [[Animation_Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.

The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive channels, to 1023 bytes. These limits do not affect scripts.
| [[llInstantMessage]]
|-
||Number of offline messages
| n/a
| {{no|Capped at 25 messages, unless the account has a Premium Subscription, in which case the cap raises to 50 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above 25 (or 50 in the case of Premium members), go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/X/128/128/24 X].
* '''Maximum ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters. If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** Full region: 100 (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]}}
| n/a
| n/a
|-
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|any length ''less than'' 10.0 seconds}}
| You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - 4:3 (60×45 pixels)
* '''Profile > Pick expanded''' - 4:3 (320×240 pixels)

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

Limits

2015-05-09T19:22:47Z

Pedro Oval: /* Communication */ Note on negative channels from viewer to server

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers''' including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers from before the layer limits project: 5 per slot
** On viewers with revised layer limits: up to 60 total, no per-slot limit. ''As of May 2015, this is only available in candidate viewers.''
** In any case, only one each of shape, skin, eyes and hair base may be worn.
* '''Max Clothing Texture''' - 512x512 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures.
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 10 teleports per 15 seconds, since SL server 1.27.1

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first. Size is after conversion to SL [[Internal Animation Format|internal animaton format]], not BVH source which can be much larger.
| n/a

|-
||animation priority
| {{no|0}}
| {{no|4, with custom tools 6}}
| n/a
| [[Animation_Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.

The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes. This limit does not affect scripts.
| [[llInstantMessage]]
|-
||Number of offline messages
| n/a
| {{no|Capped at 25 messages, unless the account has a Premium Subscription, in which case the cap raises to 50 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above 25 (or 50 in the case of Premium members), go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/X/128/128/24 X].
* '''Maximum ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters. If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** Full region: 100 (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]}}
| n/a
| n/a
|-
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|any length ''less than'' 10.0 seconds}}
| You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - 4:3 (60×45 pixels)
* '''Profile > Pick expanded''' - 4:3 (320×240 pixels)

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

Typecast

2015-03-29T03:29:36Z

Pedro Oval: Change to using proper tags.

{{LSL Header|ml=*}}
{{LSLC|Syntax}}
{{RightToc}}

To convert the type of a value a typecast is required. There are two types of typecasting, explicit and implicit. Explicit typecasts must be provided by the programmer, but implicit typecasts are put in place by the compiler. LSL implicitly typecasts strings to keys and integers to floats where the latter type is required but the former is provided.
{| {{Prettytable|style=float:right; clear:right; margin:0em; line-height:1em; font-size:75%;}}
|-
!colspan="9"| Supported Typecasts
|-
|colspan="2" rowspan="2"|
! colspan="7" {{Hl2}}|To
|- align="center" {{Hl2}}
![[integer]]
![[float]]
![[string]]
![[key]]
![[list]]
![[vector]]
![[rotation]]
|- align="center"
! rowspan="7" {{Hl2}}|From
!{{Hl2}}| [[integer]]
| x
| x
| x
|
| x
|
|
|- align="center"
!{{Hl2}}| [[float]]
| x
| x
| x
|
| x
|
|
|- align="center"
!{{Hl2}}| [[string]]
| x
| x
| x
| x
| x
| x
| x
|- align="center"
!{{Hl2}}| [[key]]
|
|
| x
| x
| x
|
|
|- align="center"
!{{Hl2}}| [[list]]
|
|
| x
|
| x
|
|
|- align="center"
!{{Hl2}}| [[vector]]
|
|
| x
|
| x
| x
|
|- align="center"
!{{Hl2}}| [[rotation]]
|
|
| x
|
| x
|
| x
|}

{{#vardefine:p_type_desc|variable type
}}{{#vardefine:p_value_desc|expression or constant
}}
<div id="box">
== Syntax: ({{LSL Param|type}}){{LSL Param|value}} ==
<div style="padding: 0.5em;">
Converts {{LSLP|value}} to {{LSLP|type}}.
{|
{{LSL DefineRow|expression|type|{{#var:p_type_desc}}}}
{{LSL DefineRow|expression|value|{{#var:p_value_desc}}}}
|}
If {{LSL Param|value}} is a complex expression, it may be beneficial to wrap it in parentheses. ({{LSL Param|type}})({{LSL Param|value}})
</div></div>

<div id="box">
== Examples ==
<div style="padding: 0.5em;">
<source lang="lsl2">
string a = "1.5";
float b = (float)a;
integer c = (integer)a;

integer i;
i = (integer) 1.23; // 1
i = (integer) -1.23; // -1
i = (integer) "0123"; // 123
i = (integer) "0x12A"; // 298
i = (integer) " -5 "; // -5; leading white space is ignored
i = (integer) "105 degrees here, it is a nice day"; // 105; non-numeric text which follows numeric text is ignored
i = (integer) "String with no numbers"; // 0

float f;
f = (float) "6.2e1"; // 62.0
f = (float) " -16.2°C is seriously cold!"; // -16.2; (float)string also ignores leading whitespace and trailing non-numeric characters
// "6.2e1", "6.2e+1", "6.2E1", "6.2E+1" are all equivalent.
f = (float) "Nancy"; // any string beginning with "nan" (case insensitive) --
// Mono only: NaN (not a number); LSO: causes a math error
f = (float) "infallible LSL!"; // any string beginning with "inf" (case insensitive) --
// Mono only: Infinity; LSO: causes a math error

string s;
s = (string) -PI; // "-3.141593" with precision set to 6 decimal places by zero padding or rounding
s = (string) [1, 2.3, "a"]; // "12.300000a" again 6 decimal places, but ...
s = (string) <1.0, 2.3, 4.56>; // "<1.00000, 2.30000, 4.56000>" .. now with precision set to 5 decimal places
s = (string) <2, 4, 0.0, PI >; // "<2.00000, 4.00000, 0.00000, 3.14159>"

list l;
l = (list) ""; // [""]
l = (list) <1.0, 2.3, 4.56>; // ["<1.00000, 2.30000, 4.56000>"]

vector v;
v = (vector) "<1.0, 2.3, 4.56>"; // <1.0, 2.3, 4.56>
v = (vector) "<1.0, 2.3>"; // ZERO_VECTOR (Due to insufficient value)

rotation r;
r = (rotation) "<1.0, 2.3, 4.56, 1.0>"; // <1.0, 2.3, 4.56, 1.0>
r = (rotation) "<1.0, 2.3, 4.56>"; // ZERO_ROTATION (Due to insufficient value)
</source>

===Applied===
<source lang="lsl2">default
{
state_entry()
{
integer iUnixTime = llGetUnixTime();
string sUnixTime = (string)unixTime;
string sRegionTime = (string)llGetTimeOfDay();
llSetObjectDesc(sUnixTime);
llSetText(sRegionTime, <1.0, 0.0 ,0.0>, 1.0);
}
}</source>
</div></div>

<div id="box">
== Caveats ==
<div style="padding: 0.5em;">
*The compiler allows explicit typecasting where it is not needed and does not optimize it out. Unnecessary typecasts will bloat code and slow it down.
</div></div>

<div id="box">
== Notes ==
<div style="padding: 0.5em;">
*Typecasting from a float to an integer merely removes the portion of the number following the decimal point. To round to the nearest whole integer, use [[llRound]].
*For getting at the elements of a list use the {{LSLGC|List/Read Element|llList2*}} functions.
</div></div>

Talk:LlSensor

2015-03-19T18:04:43Z

Pedro Oval: /* Diameter or Radius? */ No sphere

{{talk}}
If PI/4 is a 45 degree cone: if the cone's axis is 1, does the base have a diameter of 2, or a diameter of ~0.82? --[[User:Asha Vultee|Asha Vultee]] 12:53, 19 November 2007 (PST)

:Strictly speaking, it's not a cone. If you want an idea of what the shape will look like run the following script. -- [[User:Strife Onizuka|Strife Onizuka]] 13:20, 19 November 2007 (PST)
<pre>
float arc;

default
{
state_entry()
{
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_SPHERE, 0, <0.,1.,0.>, 0.0, <0.,0.,0.>, <0.,arc/PI,0.>]);
}
}
</pre>

== Agent? ==

Hey everyone, don't you think the "AGENT" flag should have a description along the lines of "This is used to find avatars only". rather than a blank description? I tried to add it myself, but I'm afraid I'm too newbie to understand the formatting... I couldn't find that particular table.{{unsigned|Hikaru Dreadlow|17:31, 23 June 2008}}

:Will do, the table is in a template ([[Template:LSL_Constants_Sensor]]) so that it can be included on llSensorRepeat too. -- [[User:Strife Onizuka|Strife Onizuka]] 15:02, 23 June 2008 (PDT)

== All Object Sensor? ==

Hey, can anyone tell me how to make an llSensor() that will scan for ANY object? For example, both physical and nonphysical, scripted and nonscripted, any combination. I tried combining all the flags (besides AGENT) with bitwise |, but it didn't seem to pick up all objects in range.{{unsigned|Crystals Galicia|16:45, 22 September 2008}}

BloodyRain Rang: seems like LL screwed the sensors up cause 0 as type should find all things, even avatars but it doesnt work. And without that it seems impossible to detect any objects without going through all combinations of ACTIVE PASSIVE and SCRIPTED (7 combinations btw). Hope this get fixed someday. (2008-12-08){{unsigned|BloodyRain Rang|18:02, 8 December 2008}}

:My apologies for not catching this sooner (or seeing these comments). The documentation was in error about zero being an acceptable value for '''type'''. The error stemmed from the documentation being based initially on the tooltips from the client script editor. Most such errors were caught during the initial import but not all. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:21, 8 December 2008 (UTC)

== The return of NULL_KEY caveats are a little lacking ==

The sensor will not trigger if an invalid key (NULL_KEY) is "found" but if the structure of the script allows it the empty NULL_KEY can be returned. As with the simple following.<lsl>default
{
state_entry()
{
llSensorRepeat("", "", 3, 20.0, PI, 1.0);
}
sensor(integer detected)
{
llSay(0, (string)llDetectedName(0));
llSay(0, (string)llDetectedName(1));
llSay(0, (string)llDetectedName(2));
llSay(0, (string)llDetectedName(3));
llSay(0, (string)llDetectedName(4));
llSay(0, (string)llDetectedName(5));
}
}</lsl>I'm not saying this is good scripting but since it returns 5 null keys and 1 avatar (if it only finds one etc.) not being fully aware of the facts while compiling lists for eg. could get messy. Fact: If the event is not structured well to exclude NULL_KEYs they can be returned. -- '''[[User:EddyFragment Robonaught|Eddy]]''' ([[User talk:EddyFragment_Robonaught|talk]]|[[Special:Contributions/EddyFragment_Robonaught|contribs]]) 21:21, 8 August 2009 (UTC)

== Agent's sit target no longer shows up? ==
This statement:
"If the agent is sitting on an object, the root prim of the sat upon object becomes a second sensor target for the agent (but not if the avatar is outside the sensor arc, see SVC-5145[c])."
no longer seems to be true - if you search for an agent, you only get the agent, and not the object it's sitting on. (No clue when this changed, I only tried it for the first time tonight).
[[User:Redwood Rhiadra|Redwood Rhiadra]] 01:22, 2 October 2010 (UTC)
: Hi, this feature is definitely confusing, that is what {{Jira|SVC-5145}} is, a request to make the behavior sensible and consistent. I will repeat the tests this weekend and see if it is broken in the same old way or if there are new ways too. --[[User:Cerise Sorbet|Cerise Sorbet]] 03:30, 2 October 2010 (UTC)

__________________________________

== examples on this page are inadequate. ==

And no, I don't dare try to add any more, because Strife the Control Queen doesn't need examples for himself, so he just deletes them all.

[[User:Chaz Longstaff|Chaz Longstaff]] 18:20, 19 September 2011 (PDT)
:The ad homimem attack is unnecessary. Taking a look at llListen which is another function that is paired with an event, I added an example script to showcase llSensor with the sensor event. Will that do? --[[User:Nexii Malthus|Nexii Malthus]] 19:45, 19 September 2011 (PDT)

I don't recall deleting any content recently, let alone an example. I remember once in the last year(or two?) deleting an entirely duplicate example (had been double pasted into the article?) but nothing more recent. So I'm at a bit of a loss for words.

I honestly wish people would post more examples, there is even a category for articles in need of examples: [[:Category:LSL_Needs_Example]] and general improvement [[:Category:LSL FixMe]]. I generally leave writing examples to others, not because I don't find them useful, I often can't think of a simple useful example, my examples tend to bury the usage in a script that is better placed in the Script Library (which no one ever sees or uses). I don't spend much time here and less time in SL, so I'm pretty cautious with my edits and unlikely to edit an example or script.

So I'm Currently working my way through the new functions and features from [[Release_Notes/Second_Life_RC_LeTigre/11#11.09.09.240509]] but I don't have a lot of time to devote to it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:21, 20 September 2011 (PDT)

== Error with sensor page ==

has anybody noticed that the sensor page shows up odd when not loged into the wiki?[[User:Tmzasz Luminos|Tmzasz Luminos]] 20:15, 14 February 2012 (PST)

:What browser are you using? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 12:21, 15 February 2012 (PST)

:Never mind, it's definitely a wiki engine issue. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 12:31, 15 February 2012 (PST)

:{{Jira|WEB-4489}} -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:34, 17 February 2012 (PST)

== AGENT vs AGENT_BY_LEGACY_NAME - No ambiguity if there's no name to filter by ==

The docs say: "If name, id, and/or type are empty or 0, they are ignored." In that case, the name is empty, it's ignored and not to be interpreted in any meaningful way. There is no possible ambiguity on how the name should be interpreted because there is no name to filter by. And please explain the removal of the text about how adding a name affects the result. It was a good example of how to use AGENT_BY_LEGACY_NAME to resolve the ambiguity. Maybe a fictitious name should be used instead of an existing one to prevent self-promotion. I'd agree with that, but that name wasn't even touched. I don't understand the reversal. -- [[User:Sei Lisa|Sei Lisa]] 10:00, 22 October 2013 (PDT)

: I think the example text rollback was an oversight. I shall put it back. I agree, we should choose someone else, for kicks we could make it the last person who edits the page. Thoughts?
: I'm going to split hairs a bit, the ambiguity does not go away, it just becomes meaningless. However when you edit the code to add a name, that is when the ambiguity matters and where AGENT bite you in the butt. I'd really would like to kill [[AGENT]] off to rid us of this problem. With AGENT we save in letters typed but we get burned by creating a lovely little "Gotcha": For the new users they would see the three flags and expect [[AGENT]] to be the generic form that allows you to search by either and most likely to be the one that searches by display name. No [[AGENT]], no misunderstanding in the mind of the reader. Hopefully when they encounter [[AGENT]] it will be on the documentation. Regardless, I find using the longer name with the null case distasteful but something I think is worth inflicting on new users. Like using [[run_time_permissions]].
: Your gallery solution is the most practical of them all. I not happy with how gallery breaks things but recreating gallery with templates is something I'm going to avoid. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:39, 22 October 2013 (PDT)

:: On names: using either a famous Linden name or a fictitious name feels better than a variable one. Governor Linden is one I'm considering, and John Doe is another. I'd lean towards the latter.
:: On the gallery: What I miss with the gallery is a reference in the text that says where to find it ("look at the bottom of this page...")
:: On the edit: Given that I have yet to see one use case for AGENT_BY_USERNAME, I would aim for readability, and AGENT is preferable not because it's shorter, but because it doesn't confuse with something that is very rarely if at all there (the username or the legacy name). Once you put a name, if that ever happens, which I doubt, especially for a new user, you can change it to the correct type of name. And of course, you can not "kill" AGENT, because AGENT_BY_USERNAME does simply not work at all with llDetectedType, and AGENT_BY_LEGACY_NAME is very clearly a misname for that case. The flags are shared with llDetectedType and there's even no indication in that page that AGENT_BY_USERNAME won't work at all with it. That is a separate issue, but the logic that leads to preferring AGENT there also applies to prefer AGENT when no name is specified in llSensor. -- [[User:Sei Lisa|Sei Lisa]] 01:16, 23 October 2013 (PDT)

:: <rant> I consider the introduction of AGENT_BY_LEGACY_NAME a mistake. The whole display name system has been a hack on top of the existing, now "legacy" name system, including the LSL additions. The same logic that led to the introduction of AGENT_BY_LEGACY_NAME should for example have led to deprecating llKey2Name and introducing llGetLegacyName as a synonym, yet that didn't happen. People are expected to know that llKey2Name returns a legacy name and not a display name or username. It shouldn't be any different with AGENT; just adding AGENT_BY_USERNAME to provide access to the new functionality should have been enough. The mere presence of AGENT_BY_LEGACY_NAME has proven to introduce more confusion than the one caused by forgetting to change it to AGENT_BY_USERNAME when using a username in the name (again, if that ever happens). The problem is that it references a name where it isn't applicable, leaving the reader of the code wondering: "Name? What name?" It's akin to giving instructions to someone having a step that is not applicable at all. Imagine telling someone "Go straight through this street; turn right when you see a sign that says 'X', and turn left when you see a sign that says 'Y'" but there is only an 'Y' sign and all that is needed to reach the destination is to turn left when reaching it. The instructions are logically impeccable, and anyone following them literally will reach the destination, but the receiver will wonder where is that 'X' sign. That's what I feel every time I see a llSensor call using "" as name and AGENT_BY_LEGACY_NAME as constant. If one is to be killed, it's AGENT_BY_LEGACY_NAME, not AGENT. </rant>
:: There, I said it. To elaborate on shortness, being shorter is not at all a reason to prefer it. I really wish that it at least had a namespace prefix like SENSOR_ or OBJECT_TYPE_ or the like, to reduce the chance of name collisions and clarify the scope of its applicability. It doesn't, sadly. -- [[User:Sei Lisa|Sei Lisa]] 02:00, 23 October 2013 (PDT)
:::Good point about directions.
:::llDetectedType: I'll poke the template so it does not show the AGENT_* constants there, only AGENT. I really wish they had prefixed them, also the texture animation constants, who would guess [[PING_PONG]] was a texture animation constant without looking it up? LSL was built before it was designed. Personally it all have been better if LSL was object oriented, you wouldn't have had so many silly lookup functions.
:::Governor Linden was actually who I was thinking of, that or Philip Linden. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:59, 23 October 2013 (PDT)

::::I have to agree with Sei on this one. It is clearly silly to say you are searching by a name when that is exactly what you are not doing. Like it or not, AGENT exists, and we should demonstrate it. I will continue to use AGENT where appropriate for as long as it compiles. I also belong to the school that feels that the whole display name idea was a stupid mistake. [[User:Omei Qunhua|Omei Qunhua]] 12:52, 23 October 2013 (PDT)

:::: @ Strife:
:::: On names: While I still would lean towards John Doe, I have no strong opinion; Governor Linden is fine with me. Philip Linden could potentially have political issues in future, I hope not.
:::: On prefixes: Sad thing is they made the same mistake recently when they introduced HORIZONTAL and VERTICAL for pathfinding. Talk about namespace pollution. Oh, well.
:::: On the change: would you consider re-applying my changes then?
:::: @ Omei: Thanks for the support :) I wouldn't go as far as calling it a stupid mistake, but it's a hack no matter how good or bad idea it is. -- [[User:Sei Lisa|Sei Lisa]] 13:20, 23 October 2013 (PDT)

:::: Thanks for the change, very appreciated! -- [[User:Sei Lisa|Sei Lisa]] 10:05, 24 October 2013 (PDT)

::::: You are welcome. I would be ok with causing a little political uproar. Streisand effect, would be good for the wiki. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:01, 25 October 2013 (PDT)

== Diameter or Radius? ==

Why does this functions wiki page not explicitly state weather the float RANGE, is a Diameter, or a Radius?

Just calling it a Range, seems kinda ambiguous. Sure many of us can just assume, or experiment to be sure. But it seems like info that belongs on the upper most definition of the function.

Maybe I'm just missing it due to sleep deprivation. [[User:ThumpieBunnyEve Hax|ThumpieBunnyEve Hax]] ([[User talk:ThumpieBunnyEve Hax|talk]]) 15:23, 18 March 2015 (PDT)

:"Range" means distance from the prim's or the wearer's center. That forms a sphere around said center, with the range's radius, within which everything is "in range" and everything outside is "out of range". Therefore it is the radius. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 04:44, 19 March 2015 (PDT)

::I submit my edit to the page for clarity. I was confident my mention of radius, and "distance from center" was sufficient, valid, and helpful. If it doesn't get changed back, then yay for a positive contribution! [[User:ThumpieBunnyEve Hax|ThumpieBunnyEve Hax]] ([[User talk:ThumpieBunnyEve Hax|talk]]) 07:33, 19 March 2015 (PDT)

::: I personally find it more confusing when put that way. It doesn't state the center of what, or the radius or what geometric figure or why it matters, while "range" is clearly implicitly referring to a distance, which logically must be from the script that has the sensor to the detected object. I don't know where did your confusion between radius and diameter come from, as not many people will realize immediately that the range volume forms a sphere. My vote is for that change to be reverted. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 08:57, 19 March 2015 (PDT)

:::: I fail to see where saying "Range" by itself is any more descriptive or accurate. It leaves more to the imagination then saying Radius, which by definition indicates from center point, inclusively to an end. Range, in fact can be easily misconstrued as a diameter, a square field, or a point at a variable distance forming a ring. Semantics are important and layman's terms such as "Range" when referring to a Radius, do not provide enough info for an accurate visualization of the procedure. I prefer to call a dog "a dog", rather then "the thing". One I know not to store in the attic for a few years, the other, not so much. If you don't understand what the word Radius means, you can easily look it up in a dictionary, but looking up "Range" in a dictionary wont provide you any insight as to weather this process uses a diameter or a radius. In fact many people who I've taught scripting to have asked me if "Range" was halved, when the Arc, was PI / 4. Implying they presumed "Range" to be a diameter. I wonder where they got that notion?? Perhaps it was from the lack of clarity in this functions description. I suppose Ray-Length could be another plausible word. but it's 2 words. and "Length", by itself would also not distinguish between diameter and radius as both are a measure of length. [[User:ThumpieBunnyEve Hax|ThumpieBunnyEve Hax]] ([[User talk:ThumpieBunnyEve Hax|talk]]) 09:56, 19 March 2015 (PDT)

::::: {{quote|radius:

1. a straight line from the center to the circumference of a circle or sphere.
2. the thicker and shorter of the two bones in the human forearm.}}
There's no sphere here. There's a vector that goes from the sensor to the potentially sensed object, whose length can be in-range or out-of-range. And there's another vector, the X axis of the prim, whose angle with the first vector determines whether the arc is in-range or out-of-range. No idea where your pupils got the concept of radius from, but I'd bet that it's either from their own imagination or because you introduced it as a sphere in the first place. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 11:04, 19 March 2015 (PDT)

Talk:LlSensor

2015-03-19T15:57:43Z

Pedro Oval: /* Diameter or Radius? */ "Radius" is more confusing

Talk:LlSensor

2015-03-19T11:44:42Z

Pedro Oval: /* Diameter or Radius? */ Radius

Talk:Key Compression

2015-02-06T00:04:11Z

Pedro Oval: Nitpick and sign

Recommending the following for base64 example for compatibility:

<source lang="lsl2">string keyToBase64(string s) {
s = llDumpList2String(llParseString2List(s, ["-"], []), "");
return
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,0,5))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,6,11))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,12,17))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,18,23))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,24,29))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,30,31))<<24),0,1);
}

string integer2hex(integer in) {
string s = "0123456789abcdef";
string ret = "";
integer i;
in = in >> 8;
for (i = 0; i < 6; i++) {
ret = llGetSubString(s, in & 0xF, in & 0xF) + ret;
in = in >> 4;
}
return ret;
}

string pad_dash(string s) {
return
llGetSubString(s, 0, 7) + "-" +
llGetSubString(s, 8,11) + "-" +
llGetSubString(s,12,15) + "-" +
llGetSubString(s,16,19) + "-" +
llGetSubString(s,20,31);
}

key base64ToKey(string s) {
return (key) pad_dash(
integer2hex(llBase64ToInteger(llGetSubString(s,0,3))) +
integer2hex(llBase64ToInteger(llGetSubString(s,4,7))) +
integer2hex(llBase64ToInteger(llGetSubString(s,8,11))) +
integer2hex(llBase64ToInteger(llGetSubString(s,12,15))) +
integer2hex(llBase64ToInteger(llGetSubString(s,16,19))) +
integer2hex(llBase64ToInteger(llGetSubString(s,20,21)+"AA")));
}</source>

== Base 32768 optimized for size in Mono ==

<source lang="lsl2">
// Copyright (C) 2009 Adam Wozniak and Doran Zemlja
// Copyright (C) 2015 Pedro Oval
// Released into the public domain.
// Free for anyone to use for any purpose they like.
//
// INTERNALLY, strings are represented as UTF-16, and internal memory
// is what we actually care about
//
// going for maximum compression, we should be able to get a 128 bit key
// down to 8 x 16 bit characters
//
// we'll do this by encoding integers as UTF-8 URL escaped characters,
// and calling llUnescapeURL to convert them to strings.
//
// unfortunately, UTF-16 has some unallowed codepoints. In particular,
// llEscapeURL/llUnescapeURL fails on the following code points:
//
// 0000, D800-DFFF, FDD0-FDEF, FFFE, FFFF
//
// Let's just make our lives easy and go with 15 bits per character.
// We'll encode 0000-7FFF as 0100-8100 to avoid null characters and leave
// all ASCII characters available as serialisation seperators.
// Also, let's go easy and just save up the 8 MSB as a final character at
// the end.
//
// this gives us a quick and easy 9 character key

// MOD: To make life even easier, use the range 0x800-0x87FF as they all
// start with the same UTF-8 range and there are no bits to test.
// (range is %E0-%EF)

string bhex(integer in)
{
return llGetSubString("0123456789abcdef", (in>>4) & 0xF, (in>>4) & 0xF)
+ llGetSubString("0123456789abcdef", in & 0xF, in & 0xF);
}

integer utf2i(string c)
{
integer ret = (integer)("0x" + (string)llParseString2List(llEscapeURL(c), (list)"%", []));
return ((ret & 0x0F0000) >> 4) + ((ret & 0x3F00) >> 2) + (ret & 0x3F) + (integer)-0x800;
}

string i2url(integer i)
{
i += 0x800;

return "%" + bhex(0xE0 | (i >> 12))
+ "%" + bhex(0x80 | ((i >> 6) & 0x3F))
+ "%" + bhex(0x80 | (i & 0x3F))
;
}

string compress_key(string k)
{
k = (string)llParseString2List(k, (list)"-", []);
string ret;
integer i = (integer)-9;
integer msbs;
integer word;

while (++i)
{
word = (integer) ("0x" + llGetSubString(k, 4*i, ~(4*~i)));
msbs = (msbs | (word & 0x8000)) >> 1;
ret += i2url(word & 0x7FFF);
}
return llUnescapeURL(i2url(msbs) + ret);
}

string uncompress_key(string s)
{
integer i = (integer)-9;
integer value;
integer msbs = utf2i(llGetSubString(s, value, value));
string ret;
while (++i)
{
value = utf2i(llGetSubString(s, i, i)) + ((msbs << (-i)) & 0x8000);
ret += bhex(value>>8) + bhex(value);
}
i = 24;
while ((i += (integer)-4) & (integer)-8)
ret = llInsertString(ret, i, "-");
return ret;
}

// Example usage: generate a key, compress, uncompress, and check if it matches.
default
{
state_entry()
{
string k = llGenerateKey();
string s = uncompress_key(compress_key(k));
llOwnerSay((string)(k==s)+"\n"+k + "\n" + s);
}
}
</source>
--[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 16:04, 5 February 2015 (PST)

Talk:Key Compression

2015-02-06T00:03:03Z

Pedro Oval: /* Base 32768 optimized for size in Mono */ new section

Recommending the following for base64 example for compatibility:

<source lang="lsl2">string keyToBase64(string s) {
s = llDumpList2String(llParseString2List(s, ["-"], []), "");
return
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,0,5))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,6,11))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,12,17))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,18,23))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,24,29))<<8),0,3) +
llGetSubString(llIntegerToBase64((integer)("0x"+llGetSubString(s,30,31))<<24),0,1);
}

string integer2hex(integer in) {
string s = "0123456789abcdef";
string ret = "";
integer i;
in = in >> 8;
for (i = 0; i < 6; i++) {
ret = llGetSubString(s, in & 0xF, in & 0xF) + ret;
in = in >> 4;
}
return ret;
}

string pad_dash(string s) {
return
llGetSubString(s, 0, 7) + "-" +
llGetSubString(s, 8,11) + "-" +
llGetSubString(s,12,15) + "-" +
llGetSubString(s,16,19) + "-" +
llGetSubString(s,20,31);
}

key base64ToKey(string s) {
return (key) pad_dash(
integer2hex(llBase64ToInteger(llGetSubString(s,0,3))) +
integer2hex(llBase64ToInteger(llGetSubString(s,4,7))) +
integer2hex(llBase64ToInteger(llGetSubString(s,8,11))) +
integer2hex(llBase64ToInteger(llGetSubString(s,12,15))) +
integer2hex(llBase64ToInteger(llGetSubString(s,16,19))) +
integer2hex(llBase64ToInteger(llGetSubString(s,20,21)+"AA")));
}</source>

== Base 32768 optimized for size in Mono ==

<source lang="lsl2">
// Copyright (C) 2009 Adam Wozniak and Doran Zemlja
// Copyright (C) 2015 Pedro Oval
// Released into the public domain.
// Free for anyone to use for any purpose they like.
//
// INTERNALLY, strings are represented as UTF-16, and internal memory
// is what we actually care about
//
// going for maximum compression, we should be able to get a 128 bit key
// down to 8 x 16 bit characters
//
// we'll do this by encoding integers as UTF-8 URL escaped characters,
// and calling llUnescapeURL to convert them to strings.
//
// unfortunately, UTF-16 has some unallowed codepoints. In particular,
// llEscapeURL/llUnescapeURL fails on the following code points:
//
// 0000, D800-DFFF, FDD0-FDEF, FFFE, FFFF
//
// Let's just make our lives easy and go with 15 bits per character.
// We'll encode 0000-7FFF as 0100-8100 to avoid null characters and leave
// all ASCII characters available as serialisation seperators.
// Also, let's go easy and just save up the 8 MSB as a final character at
// the end.
//
// this gives us a quick and easy 9 character key

// MOD: To make life even easier, use the range 0x800-0x8800 as they all
// start with the same UTF-8 range and there are no bits to test.
// (range is %E0-%EF)

string bhex(integer in)
{
return llGetSubString("0123456789abcdef", (in>>4) & 0xF, (in>>4) & 0xF)
+ llGetSubString("0123456789abcdef", in & 0xF, in & 0xF);
}

integer utf2i(string c)
{
integer ret = (integer)("0x" + (string)llParseString2List(llEscapeURL(c), (list)"%", []));
return ((ret & 0x0F0000) >> 4) + ((ret & 0x3F00) >> 2) + (ret & 0x3F) + (integer)-0x800;
}

string i2url(integer i)
{
i += 0x800;

return "%" + bhex(0xE0 | (i >> 12))
+ "%" + bhex(0x80 | ((i >> 6) & 0x3F))
+ "%" + bhex(0x80 | (i & 0x3F))
;
}

string compress_key(string k)
{
k = (string)llParseString2List(k, (list)"-", []);
string ret;
integer i = (integer)-9;
integer msbs;
integer word;

while (++i)
{
word = (integer) ("0x" + llGetSubString(k, 4*i, ~(4*~i)));
msbs = (msbs | (word & 0x8000)) >> 1;
ret += i2url(word & 0x7FFF);
}
return llUnescapeURL(i2url(msbs) + ret);
}

string uncompress_key(string s)
{
integer i = (integer)-9;
integer value;
integer msbs = utf2i(llGetSubString(s, value, value));
string ret;
while (++i)
{
value = utf2i(llGetSubString(s, i, i)) + ((msbs << (-i)) & 0x8000);
ret += bhex(value>>8) + bhex(value);
}
i = 24;
while ((i += (integer)-4) & (integer)-8)
ret = llInsertString(ret, i, "-");
return ret;
}

// Example usage: generate a key, compress, uncompress, and check if it matches.
default
{
state_entry()
{
string k = llGenerateKey();
string s = uncompress_key(compress_key(k));
llOwnerSay((string)(k==s)+"\n"+k + "\n" + s);
}
}
</source>

Talk:LlListSort

2015-02-05T12:52:13Z

Pedro Oval: <cpp> to <source>

== Bubble Sort? ==

This script:
<source lang="lsl2">
default
{
state_entry()
{
llOwnerSay(llList2CSV(llListSort([3,2,3,5,3,1,1,4], 2, TRUE)));
}
}
</source>

outputs

1, 4, 3, 5, 3, 1, 3, 2

both in LSO and in Mono. This means that the sort is not [http://en.wikipedia.org/wiki/Sorting_algorithm#Stability stable]. Since stability is a characteristic of Bubble Sort, it looks like the claim of using Bubble Sort is not correct. --[[User:Pedro Oval|Pedro Oval]] 20:01, 5 April 2014 (PDT)

:Good point. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:26, 5 April 2014 (PDT)

maybe... needs an extended example to see if LSL backwards ordering isn't the culprit -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 22:19, 5 April 2014 (PDT)
:If it's in reverse order, it's not stable either. The reverse would be 3,1,3,5,3,2 but the actual result is 3,5,3,1,3,2 --[[User:Pedro Oval|Pedro Oval]] 12:39, 6 April 2014 (PDT)

doh, you're right... comb sort perhaps? looking at the ordering exchange seems more likely than insertion -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 17:20, 6 April 2014 (PDT)

:Best option could be to pose this question on the scripting mail list, Kelly appears to prefer that channel for tech information dumps. The bubble sort presumption probably came from a function included with the viewer part of the source, but its comments describe list syntax and functions that never made it to LSL2. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 17:30, 6 April 2014 (PDT)

::I think it was a semantic problem, the existing list functions don't leave any room for embedded lists. When they couldn't get pass-by-reference to work properly (assumption), they likely killed embedded lists because it didn't fit well in 16KiB.
::'''Q:''' Why does the viewer source contain code that is obviously server LSL VM source code?
::'''A:''' A bit of history, before the age of Mono, scripts were compiled by the client, and the viewer source included a copy of much of the server VM code. You have to remember that the viewer wasn't always open source, it's likely that the client and server code once existed in a single repository, that would be recompiled at the same time. When LL opensourced the viewer, they split the repository, but because of interdependence between the server and client code, some files were duplicated between the two repositories. LSL related files overtime diverged, largely driven by Mono's server side compilation. So while it may seem strange now that the viewer contains server source, it wasn't at the time the article was written.
::-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:08, 6 April 2014 (PDT)

It's probably not very polite to bring up this link, but it may shed some light on the reasons behind usage of Bubble Sort and the presumption that it was used in the server code: [https://github.com/openmetaversefoundation/simian/blob/544379ec7fc85fabfbeb01c89bc168e46bc83452/Simian.Scripting.LindenApi/Lists.cs#LC464]. It mentions what it calls "type specific feathered sorting", which I assume it to mean the individual sorting of elements of each type. The code claims that "unoptimized bubble sort" is the only way to achieve it. I haven't given it much thought yet, but I wonder if comb sort, as mentioned by Void, would also preserve that ordering. --[[User:Pedro Oval|Pedro Oval]] 03:09, 8 April 2014 (PDT)
: I think that 3 passes index, sort, write could do this as well. Miranda's comment in {{Jira|SVC-2988}} suggests that there is some other kind of overhead in there. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 05:31, 8 April 2014 (PDT)

:I've tried Quicksort and Comb Sort. My input list was [3,2,1,3,3,4,3,3,1,4,1,9,3,6] with stride 2. llListSort returns [1,3,1,4,1,9,3,3,3,2,3,4,3,6]. I could not reproduce this result with Comb sort, not even pre-inverting the array nor by pre-inverting, sorting descending and post-inverting it. I've tried two variations and all possible ''shrink'' values for this length. I've also tried with Quicksort with a decent amount of possible choices of pivot (first, central, last, median, and sorting the first, central and last elements, using several variations of < and <= for median and sorting), to no avail. --[[User:Pedro Oval|Pedro Oval]] 07:01, 8 April 2014 (PDT)

::I wish I had more time to play with this. Going by what is typically found in LL code, my first guess would be "whatever the GNU library is using in std::sort". It could very well be a wrapper around that. Adding to fun, there are 2 major C++ libraries in GNU land, each uses a different approach. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 07:30, 8 April 2014 (PDT)

:::Boost? P.S. I've looked at opensim code. I have no problem with us documenting opensim functions etc. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 08:58, 8 April 2014 (PDT)

::::Same difference, as Boost uses std::sort: [http://svn.boost.org/svn/boost/trunk/boost/range/algorithm/sort.hpp]. Digging a bit I have found this: [http://en.wikipedia.org/wiki/Introsort#Implementations Introsort#Implementations (Wikipedia)] which made it sound like any attempt at reproducing the results without GNU libstdc++ was going to be too painful to be worth it. Then I've tried with the C++11 program below; it was sorted in a stable way, as the result is: "1,3, 1,4, 1,9, 3,2, 3,4, 3,3, 3,6, ". I'm willing to make more experiments but I'm out of ideas at the moment. Any suggestions? (P.S.: who chose the colors for the C++ highlighter? Yuck!) --[[User:Pedro Oval|Pedro Oval]] 09:30, 9 April 2014 (PDT)

<source lang="cpp">
#include <iostream>
#include <algorithm>
#include <vector>

struct Rec
{
int key;
int data;
};

bool sortByKey(const Rec &lhs, const Rec &rhs) { return lhs.key < rhs.key; }

int main()
{
std::vector<Rec> v = {{3,2},{1,3},{3,4},{3,3},{1,4},{1,9},{3,6}};
std::sort(v.begin(), v.end(), sortByKey);
for (Rec &n : v)
std::cout << n.key << "," << n.data << ", ";
std::cout << std::endl;
return 0;
}
</source>

:tried substituting partial_sort (I think that bypasses the insertion sort libstdc++ likes to use on small sets), almost the same as LSL but not close enough. 1,4, 1,3, 1,9, 3,3, 3,2, 3,4, 3,6, --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 15:34, 9 April 2014 (PDT)

I don t know why you are using boost c++ library .
Probably the key of the answer is inside the implementation of sort in the mono library .

I dont know which version mono is , and which algorithm it uses for sort .
Nevertheless , the documentation from microsoft on dotnet c# gives :

from [ http://msdn.microsoft.com/en-us/library/b0zbh7b6(v=vs.110).aspx ]

This method uses the Array.Sort method, which applies the introspective sort as follows:
* If the partition size is fewer than 16 elements, it uses an insertion sort algorithm.
* If the number of partitions exceeds 2 * LogN, where N is the range of the input array, it uses a Heapsort algorithm.
* Otherwise, it uses a Quicksort algorithm.
This implementation performs an unstable sort; that is, if two elements are equal, their order might not be preserved.
In contrast, a stable sort preserves the order of elements that are equal.
On average, this method is an O(n log n) operation, where n is Count; in the worst case it is an O(n ^ 2) operation.

We should verify if the actual version of mono used by linden uses the same strategy as microsoft.
But , at first view , it seems coherent with the actual observations

Other note : a bubble sort is O(n) if the list is already sorted . Some other algorithms too.
And some other algorithms , not.
But in LSL/mono , sortig an already sorted list don t make it faster

[[User:Miranda Umino|Miranda Umino]] 20:55, 17 April 2014 (PDT)

:The sort works the same under LSO, so I believe we can rule out a native .net library call as the source of this behavior. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 00:29, 18 April 2014 (PDT)

I'm still researching, but I'll advance some information. I've reproduced the results with this script, which implements a very simple sort algorithm that is not listed in Wikipedia:

<source lang="lsl2">
list Sort(list input, integer stride)
{
integer i;
integer j;

for (i = 0; i < llGetListLength(input) - stride; i += stride)
{
for (j = i + stride; j < llGetListLength(input); j += stride)
{
if (llList2Integer(input, i) > llList2Integer(input, j))
{
// Swap records i & j
input = llListReplaceList(
llListReplaceList(input, llList2List(input, j, j+stride-1), i, i+stride-1),
llList2List(input, i, i+stride-1), j, j+stride-1);
}
}
}
return input;
}

default
{
state_entry()
{
list MyList = [3,2,1,3,3,4,3,3,1,4,1,9,3,6];
string L1 = llList2CSV(llListSort(MyList, 2, TRUE));
string L2 = llList2CSV(Sort(MyList, 2));
llOwnerSay("O: " + L1);
llOwnerSay("N: " + L2);
if (L1 != L2) llOwnerSay("Different"); else llOwnerSay("Equal");
}
}
// Output:
// [09:50:20] Sort: O: 1, 3, 1, 4, 1, 9, 3, 3, 3, 2, 3, 4, 3, 6
// [09:50:20] Sort: N: 1, 3, 1, 4, 1, 9, 3, 3, 3, 2, 3, 4, 3, 6
// [09:50:20] Sort: Equal
</source>

I realized it was a candidate while trying to understand how bubble sort would preserve the ordering as claimed by the OpenSim code. I couldn't, so I looked into the code in more detail, and I realized that the sorting algorithm used was ''not'' bubble sort, but the one implemented in the above script. It's a naïve algorithm similar to selection sort, but less optimal: it goes through each element, and does a sweep over the rest of the elements to see if there's one less than it. If so, it swaps them (selection sort just takes note of the index position of the least element, and swaps them at the end of the inner loop instead of as it goes). At the end of each sweep, the element in question will have the least of the remaining elements in the list. It's still O(n²), and worse in performance than selection sort (since it does more swaps), but it does indeed guarantee preservation of the order of the types as claimed, assuming that comparison of two elements of different types does not cause a swap. It's also not stable, by its nature, and as proved by the results above. --[[User:Pedro Oval|Pedro Oval]] 10:09, 19 April 2014 (PDT)

'''Update:''' Selection Sort fails to reproduce the results, which is expected. However, the above algorithm matched the results every time I've tried. I tested with this list generation code in place of the constant:
<source lang="lsl2">
list MyList;
while (llGetListLength(MyList) < 500)
{
MyList = MyList + (integer)llFrand(12) + llGetListLength(MyList);
}
</source>
It seems we have a winner. --[[User:Pedro Oval|Pedro Oval]] 10:51, 19 April 2014 (PDT)

'''Update 2:''' It gets better. Type feathering is NOT respected in case of a descending sort. OpenSim gives different results to SL in that case. It looks like type feathering is not a feature, but a side effect of the algorithm used. I've reproduced the results by always swapping when the types are different. The results I got are consistent with this: the comparison function returns TRUE if A and B are of the same type and A is greater than B, and FALSE otherwise, and the swap is done if (the comparison function returns TRUE) '''xor''' (ascending!=1), causing it to ''always'' swap elements of different types for descending sort, thus destroying the feathering. OpenSim respects the feathering for descending order. --[[User:Pedro Oval|Pedro Oval]] 14:38, 19 April 2014 (PDT)

----

One sure thing : llListSort is not O(N*N) . LLstsort is O(N * Log2(N) )

Here some results of your algorithm ( 2nd column = number of pairs ; 3rd column time in frames per iteration)

BubbleSort
NumberTest N size Average Time in Frames
Test #1 with 2 0.020000
Test #2 with 3 0.050000
Test #3 with 4 0.090000
Test #4 with 6 0.200000
Test #5 with 8 0.200000
Test #6 with 12 0.650000
Test #7 with 16 0.970000
Test #8 with 24 1.850000
Test #9 with 32 2.300000
Test #10 with 48 5.590000
Test #11 with 64 7.540000
Test #12 with 96 18.270000
Test #13 with 128 28.950000
Test #14 with 160 53.440000
Test #15 with 192 71.920000
Test #16 with 224 90.050000
Test #17 with 256 112.140000

Time ( 2*128 ) = (2*2) * Time(128) => ALgorithm is O(N*N)

And with LListSort
LListSort
Test #1 with 2 0.040000
Test #2 with 3 0.070000
Test #3 with 4 0.040000
Test #4 with 6 0.050000
Test #5 with 8 0.070000
Test #6 with 12 0.150000
Test #7 with 16 0.080000
Test #8 with 24 0.210000
Test #9 with 32 0.320000
Test #10 with 48 0.340000
Test #11 with 64 0.430000
Test #12 with 96 0.280000
Test #13 with 128 0.670000
Test #14 with 160 0.650000
Test #15 with 192 0.760000
Test #16 with 224 0.660000
Test #17 with 256 0.840000

Time ( 2*128 ) = 2*log(2) * Time(128) => ALgorithm is O(N*LogN)

<source lang="lsl2">
list Sort(list input, integer stride)
{
integer i;
integer j;

for (i = 0; i < llGetListLength(input) - stride; i += stride)
{
for (j = i + stride; j < llGetListLength(input); j += stride)
{
if (llList2Integer(input, i) > llList2Integer(input, j))
{
// Swap records i & j
input = llListReplaceList(
llListReplaceList(input, llList2List(input, j, j+stride-1), i, i+stride-1),
llList2List(input, i, i+stride-1), j, j+stride-1);
}
}
}
return input;
}
default {
state_entry() {
list tests = [
// Ascending lists
2, TRUE,
3, TRUE,
4, TRUE,
6, TRUE,
8, TRUE,
12, TRUE,
16, TRUE,
24, TRUE,
32, TRUE,
48, TRUE,
64, TRUE,
96, TRUE,
128, TRUE,
160, TRUE,
192, TRUE,
224, TRUE,
256, TRUE
/* 320, TRUE,
384, TRUE,
448, TRUE,
512, TRUE
*/

];
integer repetitions = 100;
integer test = 0; integer testsLength = tests != [];

integer listSize; integer ascending; integer i; list t;
float f; string s; list l = [];
float nFrameStart;
float nFrameEnd;
float overhead;
llOwnerSay("Starting tests…");
for (; test < testsLength; test += 2) {
listSize = llList2Integer(tests, test);
ascending = llList2Integer(tests, test + 1);

if (ascending) {
i = 0;
for (; i < listSize; ++i)
l += [(integer)llFrand(3),llFrand(10000)] ;
} else {
i = listSize;
while ((--i) >= 0)
l += (integer)llFrand(10000);
}

i = 0;
nFrameStart = (float)llGetEnv("frame_number");
for (; i < repetitions; ++i)
t = [];
nFrameEnd = (float)llGetEnv("frame_number");
overhead = nFrameEnd - nFrameStart;
i = 0;
nFrameStart = (float)llGetEnv("frame_number");
for (; i < repetitions; ++i)
// t = llListSort(l, 2, ascending);
t = Sort(l,2);
nFrameEnd = (float)llGetEnv("frame_number");
f = nFrameEnd - nFrameStart - overhead;
t = l = [];

f /= (float)repetitions;
s = "\tTest #" + (string)((test / 2) + 1) + " with\t" + (string)listSize + "\t" + (string)( f );

llOwnerSay(s);
}
llOwnerSay("Tests complete.");
}
}
</source>

--[[User:Miranda Umino|Miranda Umino]] 21:41, 19 April 2014 (PDT)

:It's definitively quadratic, i.e. O(n²). http://inky.ws/g/2zz --[[User:Pedro Oval|Pedro Oval]] 19:39, 5 May 2014 (PDT)
:'''Update:''' Added benchmarking script to the linked gallery. --[[User:Pedro Oval|Pedro Oval]] 06:15, 6 May 2014 (PDT)
:'''Update 2:''' I tried the same benchmarking script listed in Inky under LSO and the strangest thing happened. I changed the list addition line to use the <code>(MyList = []) + MyList</code> trick, which allowed for an extra batch of 50. Here are the results I got:
:{| {{Prettytable}}
|- {{Hl2}}
!N !! Time
|-
|50 || 3.333132
|-
|100 || 6.786429
|-
|150 || 13.334011
|-
|200 || 13.333488
|-
|250 || 13.333256
|-
|300 || 13.333005
|-
|350 || 13.332855
|-
|400 || 13.334793
|-
|450 || 13.334989
|-
|500 || 13.332029
|}
:Looks like under LSO the function is being throttled. --[[User:Pedro Oval|Pedro Oval]] 13:36, 6 May 2014 (PDT)

:'''Update 3:''' It seems it's throttled under Mono as well, just not so much. I've added to the [http://inky.ws/g/2zz gallery] a graphic with a benchmark over the first 200-300 values, going through them one at a time. The delay seems roughly linear on N up to about N=80. Then it gets constant (to almost 3 seconds, actually about 2.95 or 2.97, according to the data, meaning almost 10 ms per call) until the actual time the function takes overtakes the throttle. When does that happen, depends on what is being compared (I used integers and vectors because they have a noticeably different comparison time) and on the performance of the sim (green line was taken on a faster sim).
:The benchmarking script is the same, just setting Step=1 and MaxN=300. The vectors were constant, set to <1,2,3>. For the descending test, I just changed all TRUE to FALSE. The first run is up to N=200 only because I thought it was enough, but when I finished and graphed it, it wasn't clear enough from the results I got, so I raised it to 300.
:I conjecture that the spikes are GC kicking in and may depend on available memory. The sim I went to to take the sample with the green line was much emptier. --[[User:Pedro Oval|Pedro Oval]] 05:07, 19 May 2014 (PDT)

== Merge Sort in LSL ==

I've written a Merge Sort that's nearly comparable to the llListSort provided by LSL. It supports strided lists (as in the example below), but cannot reverse the order as llListSort does. I ran this test a few times on it, and surprisingly, it's faster than llListSort. The code:

<source lang="lsl2">list elements = [8.627350, "a3c6cf64-8daf-b6ca-9851-8a49a597fafc", 18.943806, "3e0a230a-16ef-f539-b070-0ef0a16b1835", 6.843595, "aa3183b2-a5ad-abb3-98c2-c07517c049b5", 5.199630, "513ec659-a280-5ea4-ab3c-5f3a5544820e", 14.510715, "7f1f52bc-c63f-aef0-73c9-cd97f1bddccc", 12.230530, "3c719f4f-072d-b35f-9fe6-ed157e06c487", 3.188807, "a84db094-9630-79fc-eb02-74bcbd030190", 1.648486, "e0a8af06-2c43-57df-9571-22c035424acc", 8.481318, "891c3eba-3723-29c4-f1ea-032b6dad2b1b", 17.444149, "e4b04775-8d68-0d4a-773f-19f02c112066"];

list merge(list left, list right, integer stride)
{
list result;

while(llGetListLength(left) > 0 || llGetListLength(right) > 0)
{
if(llGetListLength(left) > 0 && llGetListLength(right) > 0)
{
// Ensure we're comparing the same things...
if(llGetListEntryType(left, 0) == llGetListEntryType(right, 0))
{
// Get values in a re-cast-able form
integer type = llGetListEntryType(left, 0);
string InitialLeftValue = llList2String(left, 0);
string InitialRightValue = llList2String(right, 0);

// Handle all type cases

if(type == TYPE_INTEGER)
{
integer leftValue = (integer)InitialLeftValue;
integer rightValue = (integer)InitialRightValue;

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_FLOAT)
{
float leftValue = (float)InitialLeftValue;
float rightValue = (float)InitialRightValue;

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_VECTOR)
{
float leftValue = llVecMag((vector)InitialLeftValue);
float rightValue = llVecMag((vector)InitialRightValue);

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_ROTATION)
{
float leftValue = llRot2Angle((rotation)InitialLeftValue);
float rightValue = llRot2Angle((rotation)InitialRightValue);

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
}
}
else if(llGetListLength(left) > 0)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else if(llGetListLength(right) > 0)
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
return result;
}

list llListSortFast(list in, integer stride)
{
if(llGetListLength(in) <= stride)
{
return in;
}
integer middle = (llGetListLength(in) / stride) / 2;

list left = llList2List(in, 0, (middle) * stride - 1);
list right = llList2List(in, middle * stride, -1);

left = llListSortFast(left, stride);
right = llListSortFast(right, stride);

return merge(left, right, stride);
}

default
{
state_entry()
{
llSay(0, "Input: \n Merge Sort:" + llList2CSV(elements));
float time = llGetAndResetTime();
llSay(0, "Sorted Result: \n" + llList2CSV(llListSortFast(elements, 2)));
llSay(0, "Time Taken: " + (string)time);
time = llGetAndResetTime();
llSay(0, "Bubble Sort Result: \n" + llList2CSV(llListSort(elements, 2, TRUE)));
llSay(0, "Time Taken: " + (string)time);

}
}
</source>

Can others proofread and/or test this with other values and confirm that I am not producing false results?

If does turn out to be more efficient, please feel free to use it in your own projects.

::I'm afraid your timing system is faulty. You're not reading the times at the right points in your code. I'm afraid on an admitedly very quick test llListSort() wins by a long chalk. Never-the-less, bravo on getting your merge sort to work.

<source lang="lsl2">
touch_start(integer num)
{

llSay(0, "Input: \n Merge Sort:" + llList2CSV(elements));
llResetTime();
list lx = ListSortFast(elements, 2);
float time = llGetTime();
llSay(0, "Time Taken MergeSort: " + (string)time);
llSay(0, "Sorted Result: \n" + llList2CSV(lx));

llSleep(1);
llResetTime();
lx = llListSort(elements, 2, TRUE);
time = llGetTime();
llSay(0, "Time Taken llListSort: " + (string)time);
llSay(0, "Bubble Sort Result: \n" + llList2CSV(lx));
}
</source>

p.s. On a test of 5000 sorts of your data, the merge sort is 5.5 times slower than llListSort(). Sorry!
[[User:Omei Qunhua|Omei Qunhua]] 15:09, 22 May 2014 (PDT)

Talk:Key Compression

2015-02-05T11:10:26Z

Pedro Oval: oops, how did that get there?

Talk:Key Compression

2015-02-05T11:09:47Z

Pedro Oval: <lsl> to <source>

Talk:LlListSort

2015-02-05T11:05:13Z

Pedro Oval: <lsl> to <source>

== Bubble Sort? ==

This script:
<source lang="lsl2">
default
{
state_entry()
{
llOwnerSay(llList2CSV(llListSort([3,2,3,5,3,1,1,4], 2, TRUE)));
}
}
</source>

outputs

1, 4, 3, 5, 3, 1, 3, 2

both in LSO and in Mono. This means that the sort is not [http://en.wikipedia.org/wiki/Sorting_algorithm#Stability stable]. Since stability is a characteristic of Bubble Sort, it looks like the claim of using Bubble Sort is not correct. --[[User:Pedro Oval|Pedro Oval]] 20:01, 5 April 2014 (PDT)

:Good point. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:26, 5 April 2014 (PDT)

maybe... needs an extended example to see if LSL backwards ordering isn't the culprit -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 22:19, 5 April 2014 (PDT)
:If it's in reverse order, it's not stable either. The reverse would be 3,1,3,5,3,2 but the actual result is 3,5,3,1,3,2 --[[User:Pedro Oval|Pedro Oval]] 12:39, 6 April 2014 (PDT)

doh, you're right... comb sort perhaps? looking at the ordering exchange seems more likely than insertion -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 17:20, 6 April 2014 (PDT)

:Best option could be to pose this question on the scripting mail list, Kelly appears to prefer that channel for tech information dumps. The bubble sort presumption probably came from a function included with the viewer part of the source, but its comments describe list syntax and functions that never made it to LSL2. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 17:30, 6 April 2014 (PDT)

::I think it was a semantic problem, the existing list functions don't leave any room for embedded lists. When they couldn't get pass-by-reference to work properly (assumption), they likely killed embedded lists because it didn't fit well in 16KiB.
::'''Q:''' Why does the viewer source contain code that is obviously server LSL VM source code?
::'''A:''' A bit of history, before the age of Mono, scripts were compiled by the client, and the viewer source included a copy of much of the server VM code. You have to remember that the viewer wasn't always open source, it's likely that the client and server code once existed in a single repository, that would be recompiled at the same time. When LL opensourced the viewer, they split the repository, but because of interdependence between the server and client code, some files were duplicated between the two repositories. LSL related files overtime diverged, largely driven by Mono's server side compilation. So while it may seem strange now that the viewer contains server source, it wasn't at the time the article was written.
::-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:08, 6 April 2014 (PDT)

It's probably not very polite to bring up this link, but it may shed some light on the reasons behind usage of Bubble Sort and the presumption that it was used in the server code: [https://github.com/openmetaversefoundation/simian/blob/544379ec7fc85fabfbeb01c89bc168e46bc83452/Simian.Scripting.LindenApi/Lists.cs#LC464]. It mentions what it calls "type specific feathered sorting", which I assume it to mean the individual sorting of elements of each type. The code claims that "unoptimized bubble sort" is the only way to achieve it. I haven't given it much thought yet, but I wonder if comb sort, as mentioned by Void, would also preserve that ordering. --[[User:Pedro Oval|Pedro Oval]] 03:09, 8 April 2014 (PDT)
: I think that 3 passes index, sort, write could do this as well. Miranda's comment in {{Jira|SVC-2988}} suggests that there is some other kind of overhead in there. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 05:31, 8 April 2014 (PDT)

:I've tried Quicksort and Comb Sort. My input list was [3,2,1,3,3,4,3,3,1,4,1,9,3,6] with stride 2. llListSort returns [1,3,1,4,1,9,3,3,3,2,3,4,3,6]. I could not reproduce this result with Comb sort, not even pre-inverting the array nor by pre-inverting, sorting descending and post-inverting it. I've tried two variations and all possible ''shrink'' values for this length. I've also tried with Quicksort with a decent amount of possible choices of pivot (first, central, last, median, and sorting the first, central and last elements, using several variations of < and <= for median and sorting), to no avail. --[[User:Pedro Oval|Pedro Oval]] 07:01, 8 April 2014 (PDT)

::I wish I had more time to play with this. Going by what is typically found in LL code, my first guess would be "whatever the GNU library is using in std::sort". It could very well be a wrapper around that. Adding to fun, there are 2 major C++ libraries in GNU land, each uses a different approach. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 07:30, 8 April 2014 (PDT)

:::Boost? P.S. I've looked at opensim code. I have no problem with us documenting opensim functions etc. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 08:58, 8 April 2014 (PDT)

::::Same difference, as Boost uses std::sort: [http://svn.boost.org/svn/boost/trunk/boost/range/algorithm/sort.hpp]. Digging a bit I have found this: [http://en.wikipedia.org/wiki/Introsort#Implementations Introsort#Implementations (Wikipedia)] which made it sound like any attempt at reproducing the results without GNU libstdc++ was going to be too painful to be worth it. Then I've tried with the C++11 program below; it was sorted in a stable way, as the result is: "1,3, 1,4, 1,9, 3,2, 3,4, 3,3, 3,6, ". I'm willing to make more experiments but I'm out of ideas at the moment. Any suggestions? (P.S.: who chose the colors for the C++ highlighter? Yuck!) --[[User:Pedro Oval|Pedro Oval]] 09:30, 9 April 2014 (PDT)

<cpp>
#include <iostream>
#include <algorithm>
#include <vector>

struct Rec
{
int key;
int data;
};

bool sortByKey(const Rec &lhs, const Rec &rhs) { return lhs.key < rhs.key; }

int main()
{
std::vector<Rec> v = {{3,2},{1,3},{3,4},{3,3},{1,4},{1,9},{3,6}};
std::sort(v.begin(), v.end(), sortByKey);
for (Rec &n : v)
std::cout << n.key << "," << n.data << ", ";
std::cout << std::endl;
return 0;
}
</cpp>

:tried substituting partial_sort (I think that bypasses the insertion sort libstdc++ likes to use on small sets), almost the same as LSL but not close enough. 1,4, 1,3, 1,9, 3,3, 3,2, 3,4, 3,6, --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 15:34, 9 April 2014 (PDT)

I don t know why you are using boost c++ library .
Probably the key of the answer is inside the implementation of sort in the mono library .

I dont know which version mono is , and which algorithm it uses for sort .
Nevertheless , the documentation from microsoft on dotnet c# gives :

from [ http://msdn.microsoft.com/en-us/library/b0zbh7b6(v=vs.110).aspx ]

This method uses the Array.Sort method, which applies the introspective sort as follows:
* If the partition size is fewer than 16 elements, it uses an insertion sort algorithm.
* If the number of partitions exceeds 2 * LogN, where N is the range of the input array, it uses a Heapsort algorithm.
* Otherwise, it uses a Quicksort algorithm.
This implementation performs an unstable sort; that is, if two elements are equal, their order might not be preserved.
In contrast, a stable sort preserves the order of elements that are equal.
On average, this method is an O(n log n) operation, where n is Count; in the worst case it is an O(n ^ 2) operation.

We should verify if the actual version of mono used by linden uses the same strategy as microsoft.
But , at first view , it seems coherent with the actual observations

Other note : a bubble sort is O(n) if the list is already sorted . Some other algorithms too.
And some other algorithms , not.
But in LSL/mono , sortig an already sorted list don t make it faster

[[User:Miranda Umino|Miranda Umino]] 20:55, 17 April 2014 (PDT)

:The sort works the same under LSO, so I believe we can rule out a native .net library call as the source of this behavior. --[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 00:29, 18 April 2014 (PDT)

I'm still researching, but I'll advance some information. I've reproduced the results with this script, which implements a very simple sort algorithm that is not listed in Wikipedia:

<source lang="lsl2">
list Sort(list input, integer stride)
{
integer i;
integer j;

for (i = 0; i < llGetListLength(input) - stride; i += stride)
{
for (j = i + stride; j < llGetListLength(input); j += stride)
{
if (llList2Integer(input, i) > llList2Integer(input, j))
{
// Swap records i & j
input = llListReplaceList(
llListReplaceList(input, llList2List(input, j, j+stride-1), i, i+stride-1),
llList2List(input, i, i+stride-1), j, j+stride-1);
}
}
}
return input;
}

default
{
state_entry()
{
list MyList = [3,2,1,3,3,4,3,3,1,4,1,9,3,6];
string L1 = llList2CSV(llListSort(MyList, 2, TRUE));
string L2 = llList2CSV(Sort(MyList, 2));
llOwnerSay("O: " + L1);
llOwnerSay("N: " + L2);
if (L1 != L2) llOwnerSay("Different"); else llOwnerSay("Equal");
}
}
// Output:
// [09:50:20] Sort: O: 1, 3, 1, 4, 1, 9, 3, 3, 3, 2, 3, 4, 3, 6
// [09:50:20] Sort: N: 1, 3, 1, 4, 1, 9, 3, 3, 3, 2, 3, 4, 3, 6
// [09:50:20] Sort: Equal
</source>

I realized it was a candidate while trying to understand how bubble sort would preserve the ordering as claimed by the OpenSim code. I couldn't, so I looked into the code in more detail, and I realized that the sorting algorithm used was ''not'' bubble sort, but the one implemented in the above script. It's a naïve algorithm similar to selection sort, but less optimal: it goes through each element, and does a sweep over the rest of the elements to see if there's one less than it. If so, it swaps them (selection sort just takes note of the index position of the least element, and swaps them at the end of the inner loop instead of as it goes). At the end of each sweep, the element in question will have the least of the remaining elements in the list. It's still O(n²), and worse in performance than selection sort (since it does more swaps), but it does indeed guarantee preservation of the order of the types as claimed, assuming that comparison of two elements of different types does not cause a swap. It's also not stable, by its nature, and as proved by the results above. --[[User:Pedro Oval|Pedro Oval]] 10:09, 19 April 2014 (PDT)

'''Update:''' Selection Sort fails to reproduce the results, which is expected. However, the above algorithm matched the results every time I've tried. I tested with this list generation code in place of the constant:
<source lang="lsl2">
list MyList;
while (llGetListLength(MyList) < 500)
{
MyList = MyList + (integer)llFrand(12) + llGetListLength(MyList);
}
</source>
It seems we have a winner. --[[User:Pedro Oval|Pedro Oval]] 10:51, 19 April 2014 (PDT)

'''Update 2:''' It gets better. Type feathering is NOT respected in case of a descending sort. OpenSim gives different results to SL in that case. It looks like type feathering is not a feature, but a side effect of the algorithm used. I've reproduced the results by always swapping when the types are different. The results I got are consistent with this: the comparison function returns TRUE if A and B are of the same type and A is greater than B, and FALSE otherwise, and the swap is done if (the comparison function returns TRUE) '''xor''' (ascending!=1), causing it to ''always'' swap elements of different types for descending sort, thus destroying the feathering. OpenSim respects the feathering for descending order. --[[User:Pedro Oval|Pedro Oval]] 14:38, 19 April 2014 (PDT)

----

One sure thing : llListSort is not O(N*N) . LLstsort is O(N * Log2(N) )

Here some results of your algorithm ( 2nd column = number of pairs ; 3rd column time in frames per iteration)

BubbleSort
NumberTest N size Average Time in Frames
Test #1 with 2 0.020000
Test #2 with 3 0.050000
Test #3 with 4 0.090000
Test #4 with 6 0.200000
Test #5 with 8 0.200000
Test #6 with 12 0.650000
Test #7 with 16 0.970000
Test #8 with 24 1.850000
Test #9 with 32 2.300000
Test #10 with 48 5.590000
Test #11 with 64 7.540000
Test #12 with 96 18.270000
Test #13 with 128 28.950000
Test #14 with 160 53.440000
Test #15 with 192 71.920000
Test #16 with 224 90.050000
Test #17 with 256 112.140000

Time ( 2*128 ) = (2*2) * Time(128) => ALgorithm is O(N*N)

And with LListSort
LListSort
Test #1 with 2 0.040000
Test #2 with 3 0.070000
Test #3 with 4 0.040000
Test #4 with 6 0.050000
Test #5 with 8 0.070000
Test #6 with 12 0.150000
Test #7 with 16 0.080000
Test #8 with 24 0.210000
Test #9 with 32 0.320000
Test #10 with 48 0.340000
Test #11 with 64 0.430000
Test #12 with 96 0.280000
Test #13 with 128 0.670000
Test #14 with 160 0.650000
Test #15 with 192 0.760000
Test #16 with 224 0.660000
Test #17 with 256 0.840000

Time ( 2*128 ) = 2*log(2) * Time(128) => ALgorithm is O(N*LogN)

<source lang="lsl2">
list Sort(list input, integer stride)
{
integer i;
integer j;

for (i = 0; i < llGetListLength(input) - stride; i += stride)
{
for (j = i + stride; j < llGetListLength(input); j += stride)
{
if (llList2Integer(input, i) > llList2Integer(input, j))
{
// Swap records i & j
input = llListReplaceList(
llListReplaceList(input, llList2List(input, j, j+stride-1), i, i+stride-1),
llList2List(input, i, i+stride-1), j, j+stride-1);
}
}
}
return input;
}
default {
state_entry() {
list tests = [
// Ascending lists
2, TRUE,
3, TRUE,
4, TRUE,
6, TRUE,
8, TRUE,
12, TRUE,
16, TRUE,
24, TRUE,
32, TRUE,
48, TRUE,
64, TRUE,
96, TRUE,
128, TRUE,
160, TRUE,
192, TRUE,
224, TRUE,
256, TRUE
/* 320, TRUE,
384, TRUE,
448, TRUE,
512, TRUE
*/

];
integer repetitions = 100;
integer test = 0; integer testsLength = tests != [];

integer listSize; integer ascending; integer i; list t;
float f; string s; list l = [];
float nFrameStart;
float nFrameEnd;
float overhead;
llOwnerSay("Starting tests…");
for (; test < testsLength; test += 2) {
listSize = llList2Integer(tests, test);
ascending = llList2Integer(tests, test + 1);

if (ascending) {
i = 0;
for (; i < listSize; ++i)
l += [(integer)llFrand(3),llFrand(10000)] ;
} else {
i = listSize;
while ((--i) >= 0)
l += (integer)llFrand(10000);
}

i = 0;
nFrameStart = (float)llGetEnv("frame_number");
for (; i < repetitions; ++i)
t = [];
nFrameEnd = (float)llGetEnv("frame_number");
overhead = nFrameEnd - nFrameStart;
i = 0;
nFrameStart = (float)llGetEnv("frame_number");
for (; i < repetitions; ++i)
// t = llListSort(l, 2, ascending);
t = Sort(l,2);
nFrameEnd = (float)llGetEnv("frame_number");
f = nFrameEnd - nFrameStart - overhead;
t = l = [];

f /= (float)repetitions;
s = "\tTest #" + (string)((test / 2) + 1) + " with\t" + (string)listSize + "\t" + (string)( f );

llOwnerSay(s);
}
llOwnerSay("Tests complete.");
}
}
</source>

--[[User:Miranda Umino|Miranda Umino]] 21:41, 19 April 2014 (PDT)

:It's definitively quadratic, i.e. O(n²). http://inky.ws/g/2zz --[[User:Pedro Oval|Pedro Oval]] 19:39, 5 May 2014 (PDT)
:'''Update:''' Added benchmarking script to the linked gallery. --[[User:Pedro Oval|Pedro Oval]] 06:15, 6 May 2014 (PDT)
:'''Update 2:''' I tried the same benchmarking script listed in Inky under LSO and the strangest thing happened. I changed the list addition line to use the <code>(MyList = []) + MyList</code> trick, which allowed for an extra batch of 50. Here are the results I got:
:{| {{Prettytable}}
|- {{Hl2}}
!N !! Time
|-
|50 || 3.333132
|-
|100 || 6.786429
|-
|150 || 13.334011
|-
|200 || 13.333488
|-
|250 || 13.333256
|-
|300 || 13.333005
|-
|350 || 13.332855
|-
|400 || 13.334793
|-
|450 || 13.334989
|-
|500 || 13.332029
|}
:Looks like under LSO the function is being throttled. --[[User:Pedro Oval|Pedro Oval]] 13:36, 6 May 2014 (PDT)

:'''Update 3:''' It seems it's throttled under Mono as well, just not so much. I've added to the [http://inky.ws/g/2zz gallery] a graphic with a benchmark over the first 200-300 values, going through them one at a time. The delay seems roughly linear on N up to about N=80. Then it gets constant (to almost 3 seconds, actually about 2.95 or 2.97, according to the data, meaning almost 10 ms per call) until the actual time the function takes overtakes the throttle. When does that happen, depends on what is being compared (I used integers and vectors because they have a noticeably different comparison time) and on the performance of the sim (green line was taken on a faster sim).
:The benchmarking script is the same, just setting Step=1 and MaxN=300. The vectors were constant, set to <1,2,3>. For the descending test, I just changed all TRUE to FALSE. The first run is up to N=200 only because I thought it was enough, but when I finished and graphed it, it wasn't clear enough from the results I got, so I raised it to 300.
:I conjecture that the spikes are GC kicking in and may depend on available memory. The sim I went to to take the sample with the green line was much emptier. --[[User:Pedro Oval|Pedro Oval]] 05:07, 19 May 2014 (PDT)

== Merge Sort in LSL ==

I've written a Merge Sort that's nearly comparable to the llListSort provided by LSL. It supports strided lists (as in the example below), but cannot reverse the order as llListSort does. I ran this test a few times on it, and surprisingly, it's faster than llListSort. The code:

<source lang="lsl2">list elements = [8.627350, "a3c6cf64-8daf-b6ca-9851-8a49a597fafc", 18.943806, "3e0a230a-16ef-f539-b070-0ef0a16b1835", 6.843595, "aa3183b2-a5ad-abb3-98c2-c07517c049b5", 5.199630, "513ec659-a280-5ea4-ab3c-5f3a5544820e", 14.510715, "7f1f52bc-c63f-aef0-73c9-cd97f1bddccc", 12.230530, "3c719f4f-072d-b35f-9fe6-ed157e06c487", 3.188807, "a84db094-9630-79fc-eb02-74bcbd030190", 1.648486, "e0a8af06-2c43-57df-9571-22c035424acc", 8.481318, "891c3eba-3723-29c4-f1ea-032b6dad2b1b", 17.444149, "e4b04775-8d68-0d4a-773f-19f02c112066"];

list merge(list left, list right, integer stride)
{
list result;

while(llGetListLength(left) > 0 || llGetListLength(right) > 0)
{
if(llGetListLength(left) > 0 && llGetListLength(right) > 0)
{
// Ensure we're comparing the same things...
if(llGetListEntryType(left, 0) == llGetListEntryType(right, 0))
{
// Get values in a re-cast-able form
integer type = llGetListEntryType(left, 0);
string InitialLeftValue = llList2String(left, 0);
string InitialRightValue = llList2String(right, 0);

// Handle all type cases

if(type == TYPE_INTEGER)
{
integer leftValue = (integer)InitialLeftValue;
integer rightValue = (integer)InitialRightValue;

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_FLOAT)
{
float leftValue = (float)InitialLeftValue;
float rightValue = (float)InitialRightValue;

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_VECTOR)
{
float leftValue = llVecMag((vector)InitialLeftValue);
float rightValue = llVecMag((vector)InitialRightValue);

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
else if(type == TYPE_ROTATION)
{
float leftValue = llRot2Angle((rotation)InitialLeftValue);
float rightValue = llRot2Angle((rotation)InitialRightValue);

if(leftValue <= rightValue)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
}
}
else if(llGetListLength(left) > 0)
{
result += llList2List(left, 0, 1);
left = llDeleteSubList(left, 0, stride - 1);
}
else if(llGetListLength(right) > 0)
{
result += llList2List(right, 0, 1);
right = llDeleteSubList(right, 0, stride - 1);
}
}
return result;
}

list llListSortFast(list in, integer stride)
{
if(llGetListLength(in) <= stride)
{
return in;
}
integer middle = (llGetListLength(in) / stride) / 2;

list left = llList2List(in, 0, (middle) * stride - 1);
list right = llList2List(in, middle * stride, -1);

left = llListSortFast(left, stride);
right = llListSortFast(right, stride);

return merge(left, right, stride);
}

default
{
state_entry()
{
llSay(0, "Input: \n Merge Sort:" + llList2CSV(elements));
float time = llGetAndResetTime();
llSay(0, "Sorted Result: \n" + llList2CSV(llListSortFast(elements, 2)));
llSay(0, "Time Taken: " + (string)time);
time = llGetAndResetTime();
llSay(0, "Bubble Sort Result: \n" + llList2CSV(llListSort(elements, 2, TRUE)));
llSay(0, "Time Taken: " + (string)time);

}
}
</source>

Can others proofread and/or test this with other values and confirm that I am not producing false results?

If does turn out to be more efficient, please feel free to use it in your own projects.

::I'm afraid your timing system is faulty. You're not reading the times at the right points in your code. I'm afraid on an admitedly very quick test llListSort() wins by a long chalk. Never-the-less, bravo on getting your merge sort to work.

<source lang="lsl2">
touch_start(integer num)
{

llSay(0, "Input: \n Merge Sort:" + llList2CSV(elements));
llResetTime();
list lx = ListSortFast(elements, 2);
float time = llGetTime();
llSay(0, "Time Taken MergeSort: " + (string)time);
llSay(0, "Sorted Result: \n" + llList2CSV(lx));

llSleep(1);
llResetTime();
lx = llListSort(elements, 2, TRUE);
time = llGetTime();
llSay(0, "Time Taken llListSort: " + (string)time);
llSay(0, "Bubble Sort Result: \n" + llList2CSV(lx));
}
</source>

p.s. On a test of 5000 sorts of your data, the merge sort is 5.5 times slower than llListSort(). Sorry!
[[User:Omei Qunhua|Omei Qunhua]] 15:09, 22 May 2014 (PDT)

Talk:LSL Portal

2015-01-31T16:58:15Z

Pedro Oval: /* Tiny font in script samples */ Reason

{{LSL Header}}{{Talk}}
= Please do not copy content from LSLwiki =

From [http://forums.secondlife.com/showpost.php?p=1392697&postcount=44 Rob Linden's post to the forum]:
:Hi folks, sorry for dropping into this conversation late. I haven't read through everything here, but I'd like to present an alternative.

:There have been several requests that Linden Lab take on the hosting of the LSL wiki. There are several problems with us doing this work. The primary problem is the question of ownership of the material. Since, to the best of our knowledge, there was never an explicit, consistent notice of ownership of this material throughout its creation, nor a clear assignment/license associated with contributing more material, it would seem the only safe way to license this content would be to contact every single contributor throughout the life of the wiki and get an explicit license or copyright assignment from them. Note that I said "safe", not "practical".

:We're not in a position to go down that road. However, we do have wiki.secondlife.com, which has had, since day one, a very clear notice about the license under which contributions are made and distributed. We would be very happy to see the community collaborate on newly created content on wiki.secondlife.com. As long as you author the content (not cut and paste from sources you are not the sole author of), we welcome your contribution. -- [[User:Rob Linden|Rob Linden]] 14:30, 24 January 2007 (PST)

----

OK, so let's talk about formatting rules for entries.

(Moved to [[LSL Portal Guidelines]], so that this talk doesn't get too cluttered.) -- [[User:Talarus Luan|Talarus Luan]] 16:32, 24 January 2007 (PST)

[[User:Talarus Luan|Talarus Luan]] 14:28, 24 January 2007 (PST)

----

=Other Discussion=

== LSL Guide lost ==

http://svn.secondlife.com/trac/linden/changeset/1392
linked from the page history
says new residents downloading the client won't be getting a copy of the LSL_Guide.html any more ...

Q1. Where on the web do new residents go to get the LSL_Guide now? -- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 16:17, 3 January 2009 (UTC)

Q2. How should this [[LSL Portal]] page tell new residents to be sure to read the LSL_Guide first to correctly understand what else we say here? -- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 16:17, 3 January 2009 (UTC)

== Untitled Chat ==

Should we make this the front page to the LSL reference, or put that one more level down? I kinda lean toward the former. [[User:Gigs Taggart|Gigs Taggart]] 14:09, 24 January 2007 (PST)

----

Yeah i think so... (Unsigned by Dimentox Travanti}
:Remember to sign your post with four tildes. [[User:Gigs Taggart|Gigs Taggart]] 14:26, 24 January 2007 (PST)

I used a modified version of the [http://meta.wikimedia.org/wiki/User:Ajqnic:GeSHiHighlight GeSHiHighlight] plugin for MediaWiki. With an LSL syntax file. The license for the plugin and for [http://qbnz.com/highlighter/ GeSHi] is GPL, it also requires another plugin [http://meta.wikimedia.org/wiki/User:Ajqnic:purgePage purgePage].
--[[User:Thraxis Epsilon|Thraxis Epsilon]] 15:00, 24 January 2007 (PST)

== Regarding copying content from the existing Wiki ==

This isn't clear from Rob's post, but it should be made clear: we CAN copy our OWN content from the existing wiki. IE, I plan to copy/paste my XML-RPC notes from the existing one. Does that present an issue? If so, why?
[[User:Talarus Luan|Talarus Luan]] 16:03, 24 January 2007 (PST)
:If you are the sole author, it wouldn't. Just be careful and check the page history. [[User:Gigs Taggart|Gigs Taggart]] 16:10, 24 January 2007 (PST)

== Syntax Highlighting ==

Updated info on the syntax highlighting is available here [[http://rpgstats.com/wiki/index.php?title=GeSHiHiLight.php GeSHiHiLight]]
--[[User:Thraxis Epsilon|Thraxis Epsilon]] 16:10, 24 January 2007 (PST)

:Lets hope they include it soon ^^ [[User:Strife Onizuka|Strife Onizuka]] 21:21, 24 January 2007 (PST)
:Is there anyone we can ask? [[User:Dimentox Travanti|Dimentox Travanti]] 10:50, 25 January 2007 (PST)
:any news or update on this? [[User:Blueman Steele|Blueman Steele]] 6:12, 10 February 2007 (PST)

::We tried to use start using this on Thursday, but ran into some problems. Thraxis, it'll help if you can contact me privately to discuss some of the issues. -- [[User:Rob Linden|Rob Linden]] 00:37, 11 February 2007 (PST)

:What's the status of syntax highlighting? --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 15:11, 24 April 2007 (PDT)

::No one has made any efforts recently to get the highlighter included in the wiki. If you are going to post highlighted code, it would be good to have it output in such a way that keywords link to their appropriate pages. -- [[User:Strife Onizuka|Strife Onizuka]] 16:53, 24 April 2007 (PDT)

:Talked with Rob Liden - The concern with the script is about security and the possiblity of injecting PHP code into the script hilighting. Since its a possible security issue he would like somebody at Linden to look into and fix it. I'm going to look into the script and tell Rob what I found also. --[[User:Mokelembembe Mokeev|Mokelembembe Mokeev]] 15:29, 4 May 2007 (PDT)

== Let's refer to this simply as the "LSL portal" ==

Since there's already something out there called the "LSLwiki", let's refer to this as the LSL Portal to distinguish it. If there's no objection, I'll move the pages with "LSL Wiki" in the title to some other appropriate name -- [[User:Rob Linden|Rob Linden]] 17:09, 24 January 2007 (PST)
:No objections here. :) I just updated [[LSL Wiki To-do]] with some assignment tables. I went ahead and moved it to [[LSL Portal To-do]] [[User:Talarus Luan|Talarus Luan]] 18:12, 24 January 2007 (PST)
:: Simple, consistent messaging: I've gotten into the habit of using "LSL Portal" regularly myself.
:: --[[User:Torley Linden|Torley Linden]] 10:40, 31 January 2007 (PST)

== A way back... ==

Every page should have a header that goes back to the portal index not the wiki index.
if we could even geta link in the left hand would be great.

[[User:Dimentox Travanti|Dimentox Travanti]] 10:47, 25 January 2007 (PST)

: I second the idea of a link in the main Navigation list. It makes it a lot easier to access the LSL Portal.
: [[User:Cron Stardust|Cron Stardust]] 11:25, 5 March 2007 (PST)

== Transitions ==
Encouraging to see this happening — and to see [http://www.lslwiki.org/ a second mirror] for the [http://www.lslwiki.com LSL wiki] too; hopefully I haven't come too late, because these developments look like they've transpired over the last few days.

Just wanted to let you know I've added a link to our LSL Portal from our blog's Notices; it'll be up for some time. I'm also going to add a simple article to the [http://secondlife.com/knowledgebase/ Knowledge Base] directing to this LSL Portal, since it's important to get more contributors aware, interested, and involved.

I'd like to personally be more active in this wiki... great things are afoot. I've been spread across too many [http://secondlife.com/knowledgebase/article.php?id=357 communication channels] lately, so I've been rotating between focuses (foci?); hopefully next week I'll have more hands-on energy here.

Thanx to each and all of you building up this resource so far!

--[[User:Torley Linden|Torley Linden]] 10:21, 26 January 2007 (PST)

== LSL Header/Footer ==
Below is the header/footer template: <nowiki>{{LSL Header}}</nowiki>
{{LSL Header}}
Also, since <nowiki><lsl></lsl></nowiki> tags don't seem to work yet, I used <nowiki><pre></pre></nowiki>... hope that's alright, I know nothing about wikis except what I've taught myself tonight. --[[User:DoteDote Edison|DoteDote Edison]] 20:45, 27 January 2007 (EST)
:Actually, go ahead and use the <nowiki><lsl></lsl></nowiki> tags. Even though it may look like crap right this minute, as soon as the module is installed, it will instantly be perfect. :) [[User:Talarus Luan|Talarus Luan]] 14:59, 29 January 2007 (PST)

== LSL wiki-namespace ==

All the LSL pages are prefixed with "LSL ", like "LSL Portal", "LSL LLRand", etc. It would seem more justly to use the wiki-namespace "LSL:". Change the names from "LSL LLRand" to "LSL:LLRand". My 2 lindens. [[User:Dzonatas Sol|Dzonatas Sol]] 00:28, 2 February 2007 (PST)
:Just thought about this little more. We could use subpages instead of namespaces, then the talk pages will fully work. "LSL/LLRand" for example [[User:Dzonatas Sol|Dzonatas Sol]] 00:41, 2 February 2007 (PST)
::I'm not going to make a big fuss about it, but I'd prefer if, per the [[Editing Guidelines]], that the page just be called "LLRand". -- [[User:Rob Linden|Rob Linden]] 01:06, 2 February 2007 (PST)
:As this wiki has grown a great deal in other aspects the need for a namespace for LSL: has become even greater. This would allow the search functions to isolate LSL results from the more general content unrelated to LSL. This would also start a shift from many listings being sorted entirely under '''L'''. — [[User:Kizmut Smit|kizmut]][[User Talk:Kizmut Smit|T]]/[[Special:Contributions/Kizmut Smit|C]] 12:02, 14 June 2012 (PDT)

== LSL conformance test ==

Hi folks, we're planning to consolidate a lot of our scattered LSL conformance tests on this wiki. I created two rather crude templates: [[Template:LSL conformance test]] and [[Template:LSL conformance script]], which were created for adding our conformance suite. See [[LSL llGetUnixTime test]] for an example. I'd like to get a sense from people if this is a sensible way to do this. The idea is to get these templates stabilized, and that will provide us a mechanism for those of us at LL to consolidate our tests. Of course, if the community wants to chip in, that's great too...having items in our standard LSL conformance suite makes it less likely that we'll break an LSL feature that's important to you. -- [[User:Rob Linden|Rob Linden]] 22:53, 7 February 2007 (PST)

== LSL Categories List ==
What about a vertical list of categories down the right side of the LSL Portal front page? The right-side list on the original wiki was my primary source of navigation, but maybe I'm odd. I could add it myself, but I'm not sure how to make it automatically update the list as new categories are added. --[[User:DoteDote Edison|DoteDote Edison]] 20:20, 9 February 2007 (EST)
:Oops... right after I posted this, I noticed that it's item #4 on the "To-Do" list. I went ahead and modified the front page to add a cetagories list. If you don't like it, feel free to revert. --[[User:DoteDote Edison|DoteDote Edison]] 20:55, 9 February 2007 (EST)
:The names all start with "LSL" and the names are not optimal for listing... The names could be changed though. I'll dig though the MediaWiki commands later and see if I can find any that would work well in this case. I don't have high hopes in this case. [[User:Strife Onizuka|Strife Onizuka]] 18:59, 9 February 2007 (PST)
Is the 200 articles per category page a mediawiki limit, or can we change it to 400 per page in a configuration somewhere? [[User:DoteDote Edison|DoteDote Edison]] 21:50, 22 February 2007 (EST)

:If there's an issue with seeing all the pages, I can add the alphabetical navigation template later.
:[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:16, 23 February 2007 (PST)

== Internationalizing ==

How do we want to go about internationalizing the LSL wiki. It should probably be tied into the global wiki effort. [[User:Strife Onizuka|Strife Onizuka]] 07:20, 11 February 2007 (PST)

:With modular templates (e.g. the way I do them) vs monolithic templates (e.g. the way you do them), the templates won't need to be changed, only the content going into them. Regarding [[User talk:SignpostMarv Martin/Sandbox/Project:Internationalisation#multi-lingual articles|Project:Internationalisation#multi-lingual articles]], I have some freaky ideas to make maintenance of the LSL-specific multi-lingual articles a little easier to maintain. p.s. I'm not sure whether Internationalisation of the LSL articles should be discussed here or [[User talk:SignpostMarv Martin/Sandbox/Project:Internationalisation#multi-lingual articles|there]]. [[User:SignpostMarv Martin|SignpostMarv Martin]] 08:05, 11 February 2007 (PST) [[Talk:LSL_Function_Style|Moved from Talk:LSL_Function_Style]]

::But your idea on templates don't provide structure, it requires the user to provide the structure and if we want to change the layout of the pages we need to go through and change ever single page. I'm pretty sure I can put together template-templates that should make translating the templates easy as setting a few variables. We wouldn't be using the template-template directly for rendering but use [http://meta.wikimedia.org/wiki/Help:Substitution substitution]. Changing a dozen monolithic templates is better then changing a dozen * 328 pages. Also means that you get the same translation ever single time. I've been thinking i could modify the LSLC, LSLG, LSLGC templates to support automated linking in language specific subpages. So if the page you are on is in Spanish, the links will lead to pages in Spanish if they exist. No special modifications to the links needed.[[User:Strife Onizuka|Strife Onizuka]] 06:43, 13 February 2007 (PST)
:::''But your idea on templates don't provide structure, it requires the user to provide the structure''
:::* That's kinda the point. Look at what information will need to be reused over and over again, and put it into a small template. Then those templates can be used directly, or as part of a wrapper template.
:::''I'm pretty sure I can put together template-templates that should make translating the templates easy as setting a few variables.''
:::* The templates don't need translating, just the content.
:::''I've been thinking i could modify the LSLC, LSLG, LSLGC templates to support automated linking in language specific subpages. So if the page you are on is in Spanish, the links will lead to pages in Spanish if they exist.''
:::* That would be bad.
:::* Better idea to follow.
:::[[User:SignpostMarv Martin|SignpostMarv Martin]] 13:13, 13 February 2007 (PST)
:::[[Template:Multi-lang]] I've given up fixing the bugs in that, but you get the idea behind it's intent. Include [[Help:Getting_started_in_Second_Life/langs]] in your test page and <nowiki>{{#vardefine:article-lang}}</nowiki> to either '''spa'' or '''eng'''.
:::Please fork the code into your own userspace if you're going to work on it (unless you know of an instant fix) to prevent edit collisions.
:::I've also started work on [[Template:ISO_639-3/native]] to save a bit of time with entering languages that one browser might not be configured for (e.g. the higher-end UTF-8 characters)
:::[[User:SignpostMarv Martin|SignpostMarv Martin]] 22:08, 19 February 2007 (PST)

:[[User:CatherinePfeffer|Catherine Pfeffer]] Starting translation of the LSL Portal to French with the group "Constructeurs et scripteurs"

: Please refer to a related discussion on [[Project:Languages]]. -- [[User:Alissa Sabre|Alissa Sabre]] 07:58, 4 November 2007 (PST)

== phasing out of [[Template:LSLG]] ==

Since the need to prefix almost everything with LSL_ is now being removed, all articles that are calling [[Template:LSLG]] should be edited to use a Wiki link, as the template is now rather redundant.

The list of articles calling [[Template:LSLG|LSLG]] can be viewed via [https://wiki.secondlife.com/w/index.php?title=Special:Whatlinkshere&target=Template%3ALSLG Special:Whatlinkshere].
 [[User:SignpostMarv Martin|SignpostMarv Martin]] 22:08, 19 February 2007 (PST)

:I think the pages in the {{LSLGC|FixMe}} category should be of a higher priority. Phasing out usage is reasonable, going through every page that uses it on the other hand just to remove it would be a waste of resources. I'm a bit nervous about stopping using it at present, the metaphoric paint hasn't even dried on the move yet. Considering it doesn't effect the rendering, phasing it's usage out is appropriate. [[User:Strife Onizuka|Strife Onizuka]] 23:20, 20 February 2007 (PST)
::Waste of resources ?
::Isn't it a waste of resources to use a template that in most cases is entirely redundant ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 02:23, 21 February 2007 (PST)
:::We haven't even finihed moving the function pages to the new names and template yet. You could help with that instead of worrying about templates, you know. [[User:Gigs Taggart|Gigs Taggart]] 07:35, 21 February 2007 (PST)

== The original LSL Wiki is back! ==
Catherine Omega's [http://www.lslwiki.net original LSL Wiki] is back. She mentioned:

: ''"This is DEFINITELY back. And it's definitely permanent. It's all editable. And it's the 'official', Catherine-Omega-approved one."''

[http://www.catherineomega.com/2007/37/the-lsl-wiki-finds-a-new-home Further context can be found @ her blog.] --[[User:Torley Linden|Torley Linden]] 13:41, 28 February 2007 (PST)

== Table ==

I've been playing with the table (again). I've tried to get it so it looks decent in both IE and Firefox. I've been trying to get it to put all the extra space into the last section, which I managed in Firefox but haven't figured out the correct permutation of parameters for IE. I'm content at this moment to leave it be (I use Firefox). [[User:Strife Onizuka|Strife Onizuka]] 08:49, 17 March 2007 (PDT)

== Warning notice? ==

Might it be an idea to include a short warning on the top of this page that the LSL Portal is as yet incomplete?

I just spent a while trying to find a list function I knew existed, but couldn't remember the exact name of, which hasn't made it here yet before realising that not all functions are listed yet.
--[[User:Nick Shatner|Nick Shatner]], 02:56, 2 May 2007 (PDT)

:The vast majority of functions have been catagorized so if you had started from the {{LSLGC|List|list category page}} you probably would have found it. There are a small handful of functions that haven't been catagorized beyond the {{LSLGC|Functions}} category. I'm not sure if a warning is warranted but I do recognize there are gaps in the LSL information. -- [[User:Strife Onizuka|Strife Onizuka]] 13:31, 2 May 2007 (PDT)

llSetText page
which is here
http://wiki.secondlife.com/wiki/LlSetText
is missing from page listing all the functions. Can't quite figure out how that page gets its info, so not going to touch it.
-- (anonymous and undated) (because not signed with dash dash tilde tilde tilde tilde)

:http://wiki.secondlife.com/w/index.php?title=Category:LSL_Functions&from=PlaySound
:includes [[llSetText]] nowadays
:maybe because "LSL Functions" appears in the Categories list at the end nowadays.
:-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 05:57, 2 December 2007 (PST)

== Conspiracy? ==

I whould like to know if 
a) this is a public wiki, where everybody can contribute so the LSL gets better known, or if it is a private viki with conspirativ charakter 
b) why it is kept so spartanik with information 
c) why no lindens who wrote LSL document their work 
d) why some private persons are called administrators, what rights do they have, and if they have ever signed a paper that makes them not abuse theyr position 
e) why linden lab employees never fisicaly work and only give "precios advises" 
dont dare to delete this. 
{{User|Anylyn Hax}} 04:09, 8 August 2007 (PDT)

:I shall try to answer:
:a) It is a public wiki but not everyone can contribute, you must have an SL account to contribute.
:b) No one has added more information.
:c) They did, it's in the LSL manual that ships with the client (it's common knowledge that it sucks).
:d) I don't know of any non-linden administrators on the wiki.
:e) The design of LSL is stable and there are very few LSL bugs that haven't been vetted; it would surprise me if there were any full time LSL devs. Just because we don't see them working doesn't mean they aren't working; the SL code base is huge.
:-- [[User:Strife Onizuka|Strife Onizuka]] 12:56, 8 August 2007 (PDT)

== Vehicle Tutorial ==

Could we get the original vehicle tutorial added to this wiki. I realize it's not in the correct format, but it's a place to start. There was a wikified version too in the old wiki someone did, but they'd have to contribute it themselves I'd think. I can't find the original tutorial outside the old wiki.

:The tutorial was part of the LSL manual that ships with the client. LL has given permission to post it on the wiki. -- [[User:Strife Onizuka|Strife Onizuka]] 16:37, 8 September 2007 (PDT)

::I found an old copy I had and wikified it. This is pretty much the original version, so it's probably a bit whacked, please fix any problems you're aware of [[User:Ralph Doctorow|Ralph Doctorow]]

== color ==

It would be very helpful if I could use different colored text when writing my articles. Could buttons be added for black text, red text, green text, and one other color of text? Or could someone list the codes that can be used to change text color?

Just as an example of what I intend to use color for:

''black''rotation ''red''variable''black''=<''red''%,%,%,''green''#.#''black''>;

-- Anonymous, Undated

: The LSL /LSL tags give colour to LSL code, ''e.g.'':

<lsl>vector up = < 0, 0, 1 >;</lsl> -- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 16:20, 3 January 2009 (UTC)

== LSL tags and automatic linking: some errors noticed ==

I'm not aware of a specific template to edit/update, but I've noticed some of auto-linked functions and constants from <nowiki><lsl></lsl></nowiki> tags point to incorrect or 'bad' (not found) pages. case in point, llSay points to Lsl_LLSay (which will redirect), and PUBLIC_CHANNEL points to a non-existant search page (there is an actual page available, but it doesn't go there). I'm sure there are other examples of this, but I'm not aware of a way to update it....

also curious to know if there is any hope of having localized pages (like french) redirect to their language equivalents through these tags at some point (I know it's not really feasible at the moment)
-- [[User:Void Singer|Void Singer]] 13:42, 19 February 2008 (PST)

== Hacks? ==

Could we please create a hacks page to be linked on the main LSL portal. Similiar to the old LSL wiki of compiling a growing list of well known tricks and tips for scripting.

For example a well known trick, which I use frequently is the use of (List!=[]) instead of llGetListLength. --[[User:Nexii Malthus|Nexii Malthus]] 07:38, 19 May 2008 (PDT)

:I've slapped a page together: [[LSL Hacks]]. I'd like comments on the style and layout. Please in the future don't stand on ceremony, if a niche needs filling, then please fill it with content. I have found that if you wait for people to weigh in before you start then nothing will get done. Better to do your best and make adjustments when there is a stink. -- [[User:Strife Onizuka|Strife Onizuka]] 09:37, 19 May 2008 (PDT)

== LSLwiki.net ==
(moved from [{{fullurl:Template talk:LSL Function|oldid=110833}} Template talk:LSL Function])

I had a discussion with [[User:Gally Young|Gally]] today and we came to the following conclusion: Since we're not able to copy content from [http://www.lslwiki.net lslwiki.net] and vice versa - because of licensing problems - we might benefit from linking related articles of both wikis. So users can easily switch from one Wiki to the other and find the information most helpful for them. There shouldn't be a rivalry between these two documentation projects. They should benefit from each other. Therefor, we're adding a link to the related LSLwiki.net article to this template. I hope it's ok. 
Something else on the same topic: It seems to be(come) quite popular in Wiki culture to double-license the own contributions, in order to make them easier to share. Wikis of interest for us:
* The Second Life Wiki (of course): [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-Share Alike 3.0]
* The [http://www.lslwiki.net LSLwiki.net]: an [http://lslwiki.net/lslwiki/wakka.php?wakka=LSLwikicopyright implicit copyright model]
* The [http://secondlife.wikia.com/wiki/Main_Page SecondLife Wikia]: [http://www.gnu.org/copyleft/fdl.html GNU Free Documentation License]
Please consider to double-license your contributions to this (or other) Wikis in order to make them easier to share, by writing a statemanet about double licensing on your userpage. You can also use one of [[User:SignpostMarv Martin|Marv]]'s templates: [[Template:Re-license contributions]] as well as [[Template:License]]. 
This is just a ''suggestion'' of course. Just do it, in case you want to do it. 
Greetz, [[Image:Zai_signature.png|45px]] '''[[User:Zai Lynch|Lynch]]''' ([[User talk:Zai Lynch|talk]]|[[Special:Contributions/Zai Lynch|contribs]]) 20:14, 9 September 2008 (PDT)

== LSL Portal should have links to pages that are helpful and often used ==

* The guidelines shown is for editing the LSL portal and not about LSL script it self. Instead it should link to say [[LSL Style Guide]] or just be removed.
* The same thing with the to do link. I would just remove it.
* I most often use [[:Category:LSL Functions]]. When I first was looking for information on how to script in LSL this is what I wanted. I think it should be the first link. Looking at [[Special:Statistics]] it is the 5th most viewed page with 708,956 views.
* Next I think [[LSL Tutorial]] should be added as it is a great place for people who have never scripted before and even for those who work in other languages. This is also the 8th most viewed page on the wiki.
* The last link I would add [[:Category:LSL_Library]] which is a list of scripts that show off how LSL works or does a common task.
:* For the the two categories you may want to use [[Template:LSLGC]].
[[User:Master Starship|Master Starship]] 17:34, 23 April 2010 (UTC)

* I take it you haven't see the [[Template:LSL Header|Header]] at the top of every article in the [[LSL Portal]]. It has all those links you call for. (Those articles didn't get popular because people used "Search").
* The [[LSL Portal Guidelines]] contains not just the rules but the mission statement for the LSL Portal. It is fundamental to the this portals continued existence. Without it we would lack direction, and defined social guidelines. Without defined guidelines we would eventual descend into chaos (I've seen it happen; the writing of the guidelines has mostly been in reaction to specific incidents). It needs to be in a prominent position so that editors will find it and read it (or can't make excuses as to why they haven't read it).
* Like the [[LSL Portal Guidelines]], the [[LSL Portal To-do]] link is in a section dedicated to the [[LSL Portal]] as a whole, not to LSL scripting. The rest of the page is dedicated to scripting. It's a small section.
-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 19:14, 23 April 2010 (UTC)

== Proposal About "LSL Categories" Section ==

I find current view is too messing and difficult to find what I need. The users end up looking in huge list of {{LSLGC|Functions}}, clicking much. I am thinking about organizing the list to easily look up the LSL articles.

Here is the proposal of categorizing.
<pre>
Avatar
- Animation
- Attachment
- Behavior
- Camera
- Properties
Land
- Parcel
- Region
Object
- Detection
- Existence
- Face
- Inventory
- Link
- Media
- Physic
- Properties
- Text
Script
- Control
　- Convert
- List
- Math
- Network
- String
- Time
</pre>

I tried to sort all existing 339 functions (except God, not active one).
Here is the list ---> [[User:Mako_Nozaki/Category_Function]]

My thought is, current categories will remain as is and will be used as "tags". Missing categories will be added and be linked from each functions. Adding these categories to LSL Header using Javascript (pulldown menu) might be cool. --[[User:Mako Nozaki|Mako]] 12:56, 1 May 2010 (UTC)

== User-Defined Functions ==

I'm personally adverse to linking to the template description rather than the category (which already back links to the template) in the "language reference" section, as per the [[https://wiki.secondlife.com/w/index.php?title=LSL_Portal&diff=0&oldid=1158048|most recent edit]]. but since it's obvious someone else is not I thought I'd solicit thoughts before reverting it. I'm thinking it could be more clear on the category page though. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 22:49, 10 May 2012 (PDT)

:I agree with you. In addition to that, I think the two articles should be merged. We gain nothing of value by having them separate. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:37, 11 May 2012 (PDT)

::Pointed the link back at the category, folded the article into the category page, and marked the original article page for deletion. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 10:45, 1 June 2012 (PDT)

== Categories ==

It's probably time to update the category list and tree again. It's been a while and I'm sure I've added more since the last time we update them. Also I should remember to update the LSL News box. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:42, 11 May 2012 (PDT)
:There are extensions that can update the category list automagically like [https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia) Extension:DynamicPageList]. I am not sure one is installed here. Would we have to wait for a Linden to set something up like this? — [[User:Kizmut Smit|kizmut]][[User Talk:Kizmut Smit|T]]/[[Special:Contributions/Kizmut Smit|C]] 12:18, 14 June 2012 (PDT)
::It really has to be done manually, some categories are intentionally excluded and it's not a pure tree (I think there may even be loops). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:00, 14 June 2012 (PDT)
:::If the category list on LSL portal top page is shorter, I think it will be more navigable. I have once considered the new list few years ago (you can see it above). Both tag (as wiki category) and hierarchical access may be needed to easily find what they want to know. -- [[User:Mako Nozaki|Mako]] 03:47, 15 June 2012 (PDT)

We've had several new categories in the last year. Wouldn't be a bad time to update. I wonder if there is some good way of indexing them. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:16, 7 July 2013 (PDT)

== Recent Formatting Edits ==
prettying up the alphabetical Functions links as they were (formatted now for consistency as bulletted links) brought up a deficiency in the original manner in how the links Should work. towit A-L should find an Anchor ID in the target page's listed functions to scroll the browser to, same as L-V (i suppose at the L functions), T-Z (at the T). i can't edit the subsequent target page Category:LSL Functions so the actual listing shows more than what it actually performs. each alpha category jumps the browser to the top of the page. if anyone can access the Category:LSL Functions page could they put some Anchor ID tags at the demarked alphabetical links?
-- [[User:EnCore_Mayne|EnCore Mayne]] 21:55, 7 September 2012 (PDT)

:I added an anchor at the end of the content but it looks better to use the one supplied with ''Pages in category "LSL Functions"''. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 07:50, 8 September 2012 (PDT)

== Articles in need of version number ==

I've gotten sick of seeing the [[:Category:Articles in need of version number/LSL|Articles in need of version number/LSL]] category link, so I've modified Multi-lang to support disabling of versioning (which will require a wiki-god to approve the edit), and I've hidden the category for the mean time. Versioning is a underused feature and we don't use it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:10, 7 July 2013 (PDT)

== Tiny font in script samples ==
Since 22 January 2015, I've noticed the text of code snippets has shrank, reducing readability. Upon further inspection of recent changes, I learned that all instances were the result of the '''<nowiki><lsl></lsl></nowiki>''' tags being replaced with '''<nowiki><source lang="lsl2"></source></nowiki>'''. The Caveats list sections of several pages have also become vertically misaligned. Whatever benefits the change from '''<nowiki><lsl></nowiki>''' to '''<nowiki><source></nowiki>''' brings, I doubt they are worth having to squint at. Isn't readable text a must on a nearly pure text site? I can only imagine how it will appear for users with 1080p+ resolution monitors. Unless lsl2 brings critical features or is mandatory, I propose the change be reverted for easier reading. -- [[User:Sharpe Clowes|Sharpe Clowes]] ([[User talk:Sharpe Clowes|talk]]) 19:29, 30 January 2015 (PST)
: Yep, the tag change was required by a move from an old extension to a current one. I'm not seeing big font changes or caveat misalignment here, what browser are you on? --[[User:Cerise Sorbet|Cerise Sorbet]] ([[User talk:Cerise Sorbet|talk]]) 21:54, 30 January 2015 (PST)
:: OK, going to guess that you're using Firefox? The current CSS yields to the user's browser preference for the monospace font, and Firefox defaults to a tiny 13 points for that. --[[User:Cerise Sorbet|Cerise Sorbet]] ([[User talk:Cerise Sorbet|talk]]) 00:14, 31 January 2015 (PST)
::: <div>It's happening to me too in Iceweasel (Firefox). The culprit seems to be this line from the geshi stylesheet:<pre>.lsl2.source-lsl2 .de1, .lsl2.source-lsl2 .de2 {font: normal normal 1em/1.2em monospace; margin:0; padding:0; background:none; vertical-align:top;font-family: monospace, monospace;}</pre>specifically the <code>1em</code> part. Removing it gets the font back to the <nowiki><pre></nowiki> font default height which is 12px and makes it work decently. --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 08:58, 31 January 2015 (PST)</div>

Talk:Internal Animations

2015-01-25T16:06:07Z

Pedro Oval: /* Animation embarrassed */ Explain why

I have not figured out how to get the priority levels for the animations. If someone knows how, please update this list. Descriptions would help as well. [[User:Fennec Wind|Fennec Wind]]

:The priorities for the built in animations are complicated, each bone has it's own priority. [[User:Strife Onizuka|Strife Onizuka]] 20:42, 4 March 2007 (PST)

::Well, that's good to know. Another answer is this: press Ctrl-Alt-Shift-D to enable the debug menu and go to Client -> Characters -> Animation Info. This will display the animation name and priority above an avatar's head (or an agent's bounding box, or whatever.) It also shows that some animations (sometimes) automatically play other animations. Like playing express_afraid, listed as priority 2, also triggers express_afraid_emote, priority 1. But back to your statement -- is there an easier way to figure out which bones are affected besides having five whole-body animations of P0-4 and playing each animation over them to see which bones get moved? --[[User:Stickman Ingmann|Stickman Ingmann]] 16:19, 10 December 2007 (PST)

:::I've got an animation decompiler somewhere, I may also have the default priorities on file somewhere too. I'm a bit busy at the moment but I'll look into digging it out later. -- [[User:Strife Onizuka|Strife Onizuka]] 01:05, 11 December 2007 (PST)

Ok, that makes sense, I guess I should just remove the column then. Thanks for putting this in the comments section, I'm not used to this wiki software yet. [[User:Fennec Wind|Fennec Wind]] 02:25, 5 March 2007 (PST)

== Animation embarrassed ==

It looks like express_embarrassed / express_embarrased_emote does not work for me.
There is however a gesture which plays ani:Embarrassed - [[User:Bernd Elswit|Bernd Elswit]] 18:51, 30 April 2007 (PDT)

: The spellings are the other way around: express_embarrased (single 's') and express_embarrassed_emote (double 's'). --[[User:Pedro Oval|Pedro Oval]] ([[User talk:Pedro Oval|talk]]) 08:06, 25 January 2015 (PST)

== Voice Chat ==
As far as I've been informed by random passerbys, there are three animations for voice chat. One is UUID 37694185-3107-d418-3a20-0181424e542d, which seems to be the "mid volume" voice. This and the other two (and how they work) should be added to this page if someone has time. --[[User:Stickman Ingmann|Stickman]] 21:53, 1 January 2009 (UTC)

They're also not available in the .bvh download pack, which makes them pretty illusive. (I needed them to re-upload as a higher priority.) :( [[User:Adeon Writer|Adeon Writer]] 18:08, 12 October 2010 (UTC)

Alright, after a bit of digging I found a list of 19 animation UUID's related to Speech Gestures. that's 3 more than the amount of speech gestures (16) which means 3 of them are actually the animations. Which 3? I don't know! The others are communicating volume levels.

list voice = [
"8cd77049-0670-e0ad-85cd-d12fdd7a33f3",
"3557510a-5eb4-d0ce-0b91-67c72aa75312",
"2b78c24a-2451-6135-fc49-ad274552bb68",
"0f645c60-3151-2805-b6f7-28e710ed22ac",
"9a7f3201-7bbd-4f75-b762-24270536e4e3",
"68db359f-4c9c-0932-5f1e-e95e3a0b19bc",
"7ef0d5c0-3346-06e4-5cfc-f081db108baa",
"37694185-3107-d418-3a20-0181424e542d",
"cb1139b6-e7c3-fdc7-a9c1-e21673d7a50e",
"28a3f544-268d-da71-7da6-82c8dd522cb9",
"cc340155-3e9d-60fe-d8e3-9e9abc7062d1",
"bbf194d1-a118-1312-998b-8145cec6eaff",
"a71890f1-0dab-8744-fd47-7defaf411dbf",
"593e9a3d-58d8-c594-d6dd-f4b98965202e",
"55fe6788-8a16-d998-2f63-3c1eab2b6009",
"c1802201-5f4e-366f-7f78-2d08ec6ea54a",
"69d5a8ed-9ec6-6dac-842f-d92d82e69428",
"c541c47f-e0c0-058b-ad1a-d6ae3a4584d9",
"951070f8-00fc-d3bd-813d-bd2922464246"];

Good luck! [[User:Adeon Writer|Adeon Writer]] 18:34, 12 October 2010 (UTC)

== BVH files location ==
Yay! the file is back. Thanks Cerise
[[User:Darien Caldwell|Darien Caldwell]] 01:36, 13 January 2011 (UTC)

:: The original location was http://s3.amazonaws.com/static-secondlife-com/downloads/avatar/bvh_files.zip and it is still active, this page is updated to use it. --[[User:Cerise Resident|Cerise Resident]] 02:41, 13 January 2011 (UTC)

Internal Animations

2015-01-25T16:04:38Z

Pedro Oval: /* User-playable animations */ Fix spelling to match the actual ones (express_embarrased BUT ALSO express_embarrassed_emote) - note the double 's')

{{LSL Header|ml=*}}
This is a complete listing of the [[Animation|animations]] built into Second Life. The name and UUID information was extracted from the Second Life client source code([ Your directory where is the sources of SecondLife]\indra\llcharacter\llanimationstates.cpp, llanimationstates.h and from the Second Life client installation folder <strike>viewerart.ini</strike> [ Your directory where is installed SecondLife]\app_settings\viewerart.xml) with some missing file names filled in from in-world testing. It should be complete as of January 2013. Looped animations are those that need to be explicitly stopped.
__TOC__
==About Animation Priority==
Priorities reported are those from the viewer version 1.19.1.4 (but they haven't changed in several years), and are the animation's global priority. Animations also have priorities for each bone in the animation, which will override the animation's global priority for that bone. When uploading an animations there is no interface to set individual bone priorities; they default to the animations global priority (which is configurable).

==User-playable animations==
These animations can be triggered by the simulator, viewer, or scripts. Corresponding [[BVH]] files may be downloaded from [http://static-secondlife-com.s3.amazonaws.com/downloads/avatar/bvh_files.zip here] (ZIP format, 926k), you may also want [http://static-secondlife-com.s3.amazonaws.com/downloads/avatar/avatar_mesh.zip .obj files for the SL avatar mesh].
{| class="sortable" {{prettytable}}
|-{{Hl2}}
!Animation Name
![[UUID]]
!Filename
!Priority
!Looped
!Description
|- 
|express_afraid
|6b61c8e8-4747-0d75-12d7-e49ff207a4ca
|avatar_express_afraid.bvh
|2
|No
|Also triggers express_afraid_emote
|- 
|aim_r_bazooka
|b5b4a67d-0aee-30d2-72cd-77b333e932ef
|avatar_aim_r_bazooka.bvh
|2
|Yes
|Also triggers targeting
|- 
|aim_l_bow
|46bb4359-de38-4ed8-6a22-f1f52fe8f506
|avatar_aim_l_bow.bvh
|2
|Yes
|Also triggers targeting
|- 
|aim_r_handgun
|3147d815-6338-b932-f011-16b56d9ac18b
|avatar_aim_r_handgun.bvh
|2
|Yes
|Also triggers targeting
|- 
|aim_r_rifle
|ea633413-8006-180a-c3ba-96dd1d756720
|avatar_aim_r_rifle.bvh
|2
|Yes
|Also triggers targeting
|- 
|express_anger
|5747a48e-073e-c331-f6f3-7c2149613d3e
|avatar_express_anger.bvh
|2
|No
|Also triggers express_anger_emote
|- 
|away
|fd037134-85d4-f241-72c6-4f42164fedee
|avatar_away.bvh
|2
|Yes
|Places avatar in Away mode.
|- 
|backflip
|c4ca6188-9127-4f31-0158-23c4e2f93304
|avatar_backflip.bvh
|2
|No
|Also triggers express_laugh_emote
|- 
|express_laugh
|18b3a4b5-b463-bd48-e4b6-71eaac76c515
|avatar_express_laugh.bvh
|2
|No
|Also triggers express_laugh_emote
|- 
|blowkiss
|db84829b-462c-ee83-1e27-9bbee66bd624
|avatar_blowkiss.bvh
|2
|No
|Also triggers express_kiss
|- 
|express_bored
|b906c4ba-703b-1940-32a3-0c7f7d791510
|avatar_express_bored.bvh
|2
|No
|Also triggers express_bored_emote
|- 
|bow
|82e99230-c906-1403-4d9c-3889dd98daba
|avatar_bow.bvh
|2
|No
|
|- 
|brush
|349a3801-54f9-bf2c-3bd0-1ac89772af01
|avatar_brush.bvh
|2
|No
|
|- 
|busy
|efcf670c-2d18-8128-973a-034ebc806b67
|
|2
|Yes
|No actual animation. Causes [[llGetAgentInfo]] to return [[AGENT_BUSY]] and adds "(Busy)" to avatar's title. Triggered by the viewer's busy mode, but does not fully set that mode by itself.
|- 
|clap
|9b0c1c4e-8ac7-7969-1494-28c874c4f668
|avatar_clap.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|courtbow
|9ba1c942-08be-e43a-fb29-16ad440efc50
|avatar_courtbow.bvh
|2
|No
|
|- 
|crouch
|201f3fdf-cb1f-dbec-201f-7333e328ae7c
|avatar_crouch.bvh
|0
|Yes
|
|- 
|crouchwalk
|47f5f6fb-22e5-ae44-f871-73aaaf4a6022
|avatar_crouchwalk.bvh
|0
|Yes
|
|- 
|express_cry
|92624d3e-1068-f1aa-a5ec-8244585193ed
|avatar_express_cry.bvh
|2
|No
|Also triggers express_cry_emote
|- 
|turn_180
|038fcec9-5ebd-8a8e-0e2e-6e71a0a1ac53
|avatar_turn_180.bvh
|5
|Yes
|Adds "(Editing Appearance)" to avatar's title
|- 
|turnback_180
|6883a61a-b27b-5914-a61e-dda118a9ee2c
|avatar_turnback_180.bvh
|3
|No
|
|- 
|dance1
|b68a3d7c-de9e-fc87-eec8-543d787e5b0d
|avatar_dance1.bvh
|2
|No
|
|- 
|dance2
|928cae18-e31d-76fd-9cc9-2f55160ff818
|avatar_dance2.bvh
|2
|No
|
|- 
|dance3
|30047778-10ea-1af7-6881-4db7a3a5a114
|avatar_dance3.bvh
|2
|No
|
|- 
|dance4
|951469f4-c7b2-c818-9dee-ad7eea8c30b7
|avatar_dance4.bvh
|2
|No
|
|- 
|dance5
|4bd69a1d-1114-a0b4-625f-84e0a5237155
|avatar_dance5.bvh
|2
|No
|
|- 
|dance6
|cd28b69b-9c95-bb78-3f94-8d605ff1bb12
|avatar_dance6.bvh
|2
|No
|
|- 
|dance7
|a54d8ee2-28bb-80a9-7f0c-7afbbe24a5d6
|avatar_dance7.bvh
|2
|No
|
|- 
|dance8
|b0dc417c-1f11-af36-2e80-7e7489fa7cdc
|avatar_dance8.bvh
|2
|No
|
|- 
|dead
|57abaae6-1d17-7b1b-5f98-6d11a6411276
|avatar_dead.bvh
|4
|Yes
|Also triggers express_surprise_emote
|- 
|drink
|0f86e355-dd31-a61c-fdb0-3a96b9aad05f
|avatar_drink.bvh
|2
|No
|Also triggers express_laugh_emote
|- 
|express_embarrased
|514af488-9051-044a-b3fc-d4dbf76377c6
|avatar_express_embarrased.bvh
|2
|No
|Also triggers express_embarrassed_emote
|- 
|express_afraid_emote
|aa2df84d-cf8f-7218-527b-424a52de766e
|avatar_express_afraid_emote.bvh
|1
|No
|Facial expression
|- 
|express_anger_emote
|1a03b575-9634-b62a-5767-3a679e81f4de
|avatar_express_anger_emote.bvh
|1
|No
|Facial expression
|- 
|express_bored_emote
|214aa6c1-ba6a-4578-f27c-ce7688f61d0d
|avatar_express_bored_emote.bvh
|1
|No
|Facial expression
|- 
|express_cry_emote
|d535471b-85bf-3b4d-a542-93bea4f59d33
|avatar_express_cry_emote.bvh
|1
|No
|Facial expression
|- 
|express_disdain
|d4416ff1-09d3-300f-4183-1b68a19b9fc1
|avatar_express_disdain_emote.bvh
|1
|No
|Facial expression
|- 
|express_embarrassed_emote
|0b8c8211-d78c-33e8-fa28-c51a9594e424
|avatar_express_embarrassed_emote.bvh
|1
|No
|Facial expression
|- 
|express_frown
|fee3df48-fa3d-1015-1e26-a205810e3001
|avatar_express_frown.bvh
|1
|No
|Facial expression
|- 
|express_kiss
|1e8d90cc-a84e-e135-884c-7c82c8b03a14
|avatar_express_kiss.bvh
|1
|No
|Facial expression
|- 
|express_laugh_emote
|62570842-0950-96f8-341c-809e65110823
|avatar_express_laugh_emote.bvh
|1
|No
|Facial expression
|- 
|express_open_mouth
|d63bc1f9-fc81-9625-a0c6-007176d82eb7
|avatar_express_open_mouth.bvh
|1
|No
|Facial expression
|- 
|express_repulsed_emote
|f76cda94-41d4-a229-2872-e0296e58afe1
|avatar_express_repulsed_emote.bvh
|1
|No
|Facial expression
|- 
|express_sad_emote
|eb6ebfb2-a4b3-a19c-d388-4dd5c03823f7
|avatar_express_sad_emote.bvh
|1
|No
|Facial expression
|- 
|express_shrug_emote
|a351b1bc-cc94-aac2-7bea-a7e6ebad15ef
|avatar_express_shrug_emote.bvh
|1
|No
|Facial expression
|- 
|express_smile
|b7c7c833-e3d3-c4e3-9fc0-131237446312
|avatar_express_smile.bvh
|1
|No
|Facial expression
|- 
|express_surprise_emote
|728646d9-cc79-08b2-32d6-937f0a835c24
|avatar_express_surprise.bvh
|1
|No
|Facial expression
|- 
|express_tongue_out
|835965c6-7f2f-bda2-5deb-2478737f91bf
|avatar_express_tongue_out.bvh
|1
|No
|Facial expression
|- 
|express_toothsmile
|b92ec1a5-e7ce-a76b-2b05-bcdb9311417e
|avatar_express_toothsmile.bvh
|1
|No
|Facial expression
|- 
|express_wink_emote
|da020525-4d94-59d6-23d7-81fdebf33148
|avatar_express_wink_emote.bvh
|1
|No
|Facial expression
|- 
|express_worry_emote
|9c05e5c7-6f07-6ca4-ed5a-b230390c3950
|avatar_express_worry_emote.bvh
|1
|No
|Facial expression
|- 
|falldown
|666307d9-a860-572d-6fd4-c3ab8865c094
|avatar_falldown.bvh
|3
|Yes
|
|- 
|female_walk
|f5fc7433-043d-e819-8298-f519a119b688
|avatar_female_walk.bvh
|3 & 0
|Yes
|(priority 3 for pelvis and legs, 0 for everything else)
|- 
|angry_fingerwag
|c1bc7f36-3ba0-d844-f93c-93be945d644f
|avatar_angry_fingerwag.bvh
|2
|No
|Also triggers express_frown
|- 
|fist_pump
|7db00ccd-f380-f3ee-439d-61968ec69c8a
|avatar_fist_pump.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|fly
|aec4610c-757f-bc4e-c092-c6e9caf18daf
|avatar_fly.bvh
|0
|Yes
|
|- 
|flyslow
|2b5a38b2-5e00-3a97-a495-4c826bc443e6
|avatar_flyslow.bvh
|0
|Yes
|
|- 
|hello
|9b29cd61-c45b-5689-ded2-91756b8d76a9
|avatar_hello.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|hold_r_bazooka
|ef62d355-c815-4816-2474-b1acc21094a6
|avatar_hold_r_bazooka.bvh
|2
|Yes
|Automatically replaced by aim_r_bazooka in [[mouselook]]
|- 
|hold_l_bow
|8b102617-bcba-037b-86c1-b76219f90c88
|avatar_hold_l_bow.bvh
|2
|Yes
|Automatically replaced by aim_l_bow in [[mouselook]]
|- 
|hold_r_handgun
|efdc1727-8b8a-c800-4077-975fc27ee2f2
|avatar_hold_r_handgun.bvh
|2
|Yes
|Automatically replaced by aim_r_handgun in [[mouselook]]
|- 
|hold_r_rifle
|3d94bad0-c55b-7dcc-8763-033c59405d33
|avatar_hold_r_rifle.bvh
|2
|Yes
|Automatically replaced by aim_r_rifle in [[mouselook]]
|- 
|hold_throw_r
|7570c7b5-1f22-56dd-56ef-a9168241bbb6
|avatar_hold_throw_r.bvh
|?
|?
|(Missing as of 2008-06-12)
|- 
|hover
|4ae8016b-31b9-03bb-c401-b1ea941db41d
|avatar_hover.bvh
|0
|Yes
|
|- 
|hover_down
|20f063ea-8306-2562-0b07-5c853b37b31e
|avatar_hover_down.bvh
|0
|Yes
|
|- 
|hover_up
|62c5de58-cb33-5743-3d07-9e4cd4352864
|avatar_hover_up.bvh
|0
|Yes
|
|- 
|impatient
|5ea3991f-c293-392e-6860-91dfa01278a3
|avatar_impatient.bvh
|2
|No
|Also triggers express_frown
|- 
|jump
|2305bd75-1ca9-b03b-1faa-b176b8a8c49e
|avatar_jump.bvh
|0
|Yes
|
|- 
|jumpforjoy
|709ea28e-1573-c023-8bf8-520c8bc637fa
|avatar_jumpforjoy.bvh
|2
|No
|Also triggers express_laugh_emote
|- 
|kissmybutt
|19999406-3a3a-d58c-a2ac-d72e555dcf51
|avatar_kissmybutt.bvh
|2
|No
|Also triggers express_kiss
|- 
|land
|7a17b059-12b2-41b1-570a-186368b6aa6f
|avatar_land.bvh
|0
|Yes
|Stopped automatically by viewer
|- 
|laugh_short
|ca5b3f14-3194-7a2b-c894-aa699b718d1f
|avatar_laugh_short.bvh
|2
|No
|Also triggers express_laugh_emote
|- 
|soft_land
|f4f00d6e-b9fe-9292-f4cb-0ae06ea58d57
|avatar_soft_land.bvh
|2
|Yes
|Stopped automatically by viewer
|- 
|motorcycle_sit
|08464f78-3a8e-2944-cba5-0c94aff3af29
|avatar_motorcycle_sit.bvh
|4
|Yes
|
|- 
|musclebeach
|315c3a41-a5f3-0ba4-27da-f893f769e69b
|avatar_musclebeach.bvh
|2
|No
|Also triggers express_anger_emote
|- 
|no_head
|5a977ed9-7f72-44e9-4c4c-6e913df8ae74
|avatar_no_head.bvh
|2
|No
|
|- 
|no_unhappy
|d83fa0e5-97ed-7eb2-e798-7bd006215cb4
|avatar_no_unhappy.bvh
|2
|No
|Also triggers express_frown
|- 
|nyanya
|f061723d-0a18-754f-66ee-29a44795a32f
|avatar_nyanya.bvh
|2
|No
|Also triggers express_tongue_out
|- 
|punch_onetwo
|eefc79be-daae-a239-8c04-890f5d23654a
|avatar_punch_onetwo.bvh
|2
|No
|Also triggers express_frown
|- 
|peace
|b312b10e-65ab-a0a4-8b3c-1326ea8e3ed9
|avatar_peace.bvh
|2
|No
|Also triggers express_smile
|- 
|point_me
|17c024cc-eef2-f6a0-3527-9869876d7752
|avatar_point_me.bvh
|2
|No
|
|- 
|point_you
|ec952cca-61ef-aa3b-2789-4d1344f016de
|avatar_point_you.bvh
|2
|No
|
|- 
|prejump
|7a4e87fe-de39-6fcb-6223-024b00893244
|avatar_prejump.bvh
|0
|Yes
|Stopped automatically by viewer {{JIRA|SVC-3860}}
|- 
|punch_l
|f3300ad9-3462-1d07-2044-0fef80062da0
|avatar_punch_l.bvh
|2
|No
|Also triggers express_frown
|- 
|punch_r
|c8e42d32-7310-6906-c903-cab5d4a34656
|avatar_punch_r.bvh
|2
|No
|Also triggers express_frown
|- 
|express_repulsed
|36f81a92-f076-5893-dc4b-7c3795e487cf
|avatar_express_repulsed.bvh
|2
|No
|Also triggers express_repulsed_emote
|- 
|kick_roundhouse_r
|49aea43b-5ac3-8a44-b595-96100af0beda
|avatar_kick_roundhouse_r.bvh
|2
|No
|also triggers express_anger_emote
|- 
|rps_countdown
|35db4f7e-28c2-6679-cea9-3ee108f7fc7f
|avatar_rps_countdown.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|rps_paper
|0836b67f-7f7b-f37b-c00a-460dc1521f5a
|avatar_rps_paper.bvh
|2
|No
|Also triggers express_surprise_emote
|- 
|rps_rock
|42dd95d5-0bc6-6392-f650-777304946c0f
|avatar_rps_rock.bvh
|2
|No
|Also triggers express_surprise_emote
|- 
|rps_scissors
|16803a9f-5140-e042-4d7b-d28ba247c325
|avatar_rps_scissors.bvh
|2
|No
|Also triggers express_surprise_emote
|- 
|run
|05ddbff8-aaa9-92a1-2b74-8fe77a29b445
|avatar_run.bvh
|0
|Yes
|
|- 
|express_sad
|0eb702e2-cc5a-9a88-56a5-661a55c0676a
|avatar_express_sad.bvh
|2
|No
|Also triggers express_sad_emote
|- 
|salute
|cd7668a6-7011-d7e2-ead8-fc69eff1a104
|avatar_salute.bvh
|2
|No
|Also triggers express_frown
|- 
|shoot_l_bow
|e04d450d-fdb5-0432-fd68-818aaf5935f8
|avatar_shoot_l_bow.bvh
|2
|No
|
|- 
|shout
|6bd01860-4ebd-127a-bb3d-d1427e8e0c42
|avatar_shout.bvh
|2
|No
|Also triggers express_laugh_emote. Sent with "shout" volume chat from viewer
|- 
|express_shrug
|70ea714f-3a97-d742-1b01-590a8fcd1db5
|avatar_express_shrug.bvh
|2
|No
|Also triggers express_shrug_emote
|- 
|sit
|1a5fe8ac-a804-8a5d-7cbd-56bd83184568
|avatar_sit.bvh
|4
|Yes
|Automatically replaced by sit_female if female shape is worn
|- 
|sit_female
|b1709c8d-ecd3-54a1-4f28-d55ac0840782
|avatar_sit_female.bvh
|4
|Yes
|
|- 
|sit_ground
|1c7600d6-661f-b87b-efe2-d7421eb93c86
|avatar_sit_ground.bvh
|3
|Yes
|
|- 
|sit_ground_constrained
|1a2bd58e-87ff-0df8-0b4c-53e047b0bb6e
|avatar_sit_ground_constrained.bvh
|3
|Yes
|
|- 
|sit_generic
|245f3c54-f1c0-bf2e-811f-46d8eeb386e7
|avatar_sit_generic.bvh
|4
|Yes
|
|- 
|sit_to_stand
|a8dee56f-2eae-9e7a-05a2-6fb92b97e21e
|avatar_sit_to_stand.bvh
|2
|No
|
|- 
|sleep
|f2bed5f9-9d44-39af-b0cd-257b2a17fe40
|avatar_sleep.bvh
|4
|Yes
|
|- 
|smoke_idle
|d2f2ee58-8ad1-06c9-d8d3-3827ba31567a
|avatar_smoke_idle.bvh
|2
|No
|
|- 
|smoke_inhale
|6802d553-49da-0778-9f85-1599a2266526
|avatar_smoke_inhale.bvh
|2
|No
|Also triggers express_kiss
|- 
|smoke_throw_down
|0a9fb970-8b44-9114-d3a9-bf69cfe804d6
|avatar_smoke_throw_down.bvh
|2
|No
|
|- 
|snapshot
|eae8905b-271a-99e2-4c0e-31106afd100c
|avatar_snapshot.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|stand
|2408fe9e-df1d-1d7d-f4ff-1384fa7b350f
|avatar_stand.bvh
|0
|Yes
|
|- 
|standup
|3da1d753-028a-5446-24f3-9c9b856d9422
|avatar_standup.bvh
|3
|Yes
|Stopped automatically by viewer. Viewer also randomly triggers brush on stop.
|- 
|stand_1
|15468e00-3400-bb66-cecc-646d7c14458e
|avatar_stand_1.bvh
|0
|Yes
|Stopped automatically by viewer
|- 
|stand_2
|370f3a20-6ca6-9971-848c-9a01bc42ae3c
|avatar_stand_2.bvh
|0
|Yes
|Stopped automatically by viewer
|- 
|stand_3
|42b46214-4b44-79ae-deb8-0df61424ff4b
|avatar_stand_3.bvh
|0
|Yes
|Stopped automatically by viewer
|- 
|stand_4
|f22fed8b-a5ed-2c93-64d5-bdd8b93c889f
|avatar_stand_4.bvh
|0
|Yes
|Stopped automatically by viewer
|- 
|stretch
|80700431-74ec-a008-14f8-77575e73693f
|avatar_stretch.bvh
|2
|No
|
|- 
|stride
|1cb562b0-ba21-2202-efb3-30f82cdf9595
|avatar_stride.bvh
|1
|Yes
|
|- 
|surf
|41426836-7437-7e89-025d-0aa4d10f1d69
|avatar_surf.bvh
|4
|Yes
|
|- 
|express_surprise
|313b9881-4302-73c0-c7d0-0e7a36b6c224
|avatar_express_surprise.bvh
|2
|No
|Also triggers express_surprise_emote
|- 
|sword_strike_r
|85428680-6bf9-3e64-b489-6f81087c24bd
|avatar_sword_strike_r.bvh
|2
|No
|Also triggers express_frown
|- 
|talk
|5c682a95-6da4-a463-0bf6-0f5b7be129d1
|avatar_talk.bvh
|1
|No
|Nod sent with "say" volume chat from viewer
|- 
|angry_tantrum
|11000694-3f41-adc2-606b-eee1d66f3724
|avatar_angry_tantrum.bvh
|2
|No
|Also triggers express_anger_remote
|- 
|throw_r
|aa134404-7dac-7aca-2cba-435f9db875ca
|avatar_throw_r.bvh
|2
|No
|
|- 
|tryon_shirt
|83ff59fe-2346-f236-9009-4e3608af64c1
|avatar_tryon_shirt.bvh
|1
|No
|
|- 
|turnleft
|56e0ba0d-4a9f-7f27-6117-32f2ebbf6135
|avatar_turnleft.bvh
|1
|Yes
|
|- 
|turnright
|2d6daa51-3192-6794-8e2e-a15f8338ec30
|avatar_turnright.bvh
|1
|Yes
|
|- 
|type
|c541c47f-e0c0-058b-ad1a-d6ae3a4584d9
|avatar_type.bvh
|2
|Yes
|
|- 
|walk
|6ed24bd8-91aa-4b12-ccc7-c97c857ab4e0
|avatar_walk.bvh
|3 & 0
|Yes{{Footnote|"walk" is treated specially in the viewer. The animation played standalone is not looped, the viewer does the looping so it can adjust for walking speed. Since viewer 2.1, the walk loop rate is fixed so it behaves like a normal looped animation. If you want to use the default walk in a scripted device with a sitting avatar, female_walk will give better results.}}
|Automatically replaced by female_walk if female shape is worn (priority 3 for pelvis and legs, 0 for everything else)
|- 
|whisper
|7693f268-06c7-ea71-fa21-2b30d6533f8f
|avatar_whisper.bvh
|0
|No
|Also triggers express_wink_emote. Sent with "whisper" volume chat from viewer
|- 
|whistle
|b1ed7982-c68e-a982-7561-52a88a5298c0
|avatar_whistle.bvh
|2
|No
|Also triggers express_kiss
|- 
|express_wink
|869ecdad-a44b-671e-3266-56aef2e3ac2e
|avatar_express_wink.bvh
|2
|No
|Also triggers express_wink_emote
|- 
|wink_hollywood
|c0c4030f-c02b-49de-24ba-2331f43fe41c
|avatar_wink_hollywood.bvh
|2
|No
|Also triggers express_wink_emote
|- 
|express_worry
|9f496bd2-589a-709f-16cc-69bf7df1d36c
|avatar_express_worry.bvh
|2
|No
|Also triggers express_worry_emote
|- 
|yes_head
|15dd911d-be82-2856-26db-27659b142875
|avatar_yes_head.bvh
|2
|No
|
|- 
|yes_happy
|b8c8b2a3-9008-1771-3bfc-90924955ab2d
|avatar_yes_happy.bvh
|2
|No
|Also triggers express_toothsmile
|- 
|yoga_float
|42ecd00b-9947-a97c-400a-bbc9174c7aeb
|avatar_yoga_float.bvh
|2
|No
|Also triggers express_bored_remote
|}
===Facial expressions===
[[Image:SL face expressions.jpg|200px|thumb|left|Samples of the facial expressions from the table above, click to enlarge.]]
<div style="clear:both;"></div>

==Viewer-generated motions==
Some types of movement are generated at run time by the viewer, in response to the environment. Like regular animations most have names and UUIDs, but they are not available to be stopped, started or even seen by scripts. These motions do have priorities and can be overridden. Names and UUIDs are defined in newview/llvoavatar.h.
{| class="sortable" {{prettytable}}
|-{{Hl2}}
!Animation Name
![[UUID]]
!Source
!Priority
!class="unsortable"|Description
|- 
|body_noise
|9aa8b0a6-0c6f-9518-c7c3-4f41f2c001ad
|LLBodyNoiseMotion in newview/llvoavatar.cpp
|2
|Minor body turns. Joints moved: torso.
|- 
|breathe_rot
|4c5a103e-b830-2f1c-16bc-224aa0ad5bc8
|LLBreatheMotionRot in newview/llvoavatar.cpp
|1
|Breathing simulation. Joints moved: chest
|- 
|editing
|2a8eba1d-a7f8-5596-d44a-b4977bf8c8bb
|LLEditingMotion in llcharacter/lleditingmotion.cpp
|2
|Left arm follows selected and edited objects. Joints moved: left shoulder, left elbow, left wrist, torso.
|- 
|eye
|5c780ea8-1cd1-c463-a128-48c023f6fbea
|LLEyeMotion in llcharacter/llheadrotmotion.cpp
|1
|Eye rotation and blinking. Joints moved: head, left eye, right eye
|- 
|fly_adjust
|db95561f-f1b0-9f9a-7224-b12f71af126e
|LLFlyAdjustMotion in llcharacter/llkeyframewalkmotion.cpp
|3
|Add body roll during flight. Joints moved: pelvis
|- 
|hand_motion
|ce986325-0ba7-6e6e-cc24-b17c4b795578
|LLHandMotion in llcharacter/llhandmotion.cpp
|1
|Sets standard hand poses defined in other animations
|- 
|head_rot
|e6e8d1dd-e643-fff7-b238-c6b4b056a68d
|LLHeadRotMotion in llcharacter/llheadrotmotion.cpp
|1
|Moves head and torso to follow the avatar's look at position (cursor, camera). Joints moved: torso, neck, head
|- 
|pelvis_fix
|0c5dd2a2-514d-8893-d44d-05beffad208b
|LLPelvisFixMotion in newview/llvoavatar.cpp
|0
|Makes corrections to keep avatar standing upright. Joints moved: pelvis
|- 
|target
|0e4896cb-fba4-926c-f355-8720189d5b55
|LLTargetingMotion in llcharacter/lltargetingmotion.cpp
|2
|Move body with look at position, used during aim_* animations above. Joints moved: pelvis, torso, right wrist
|- 
|walk_adjust
|829bc85b-02fc-ec41-be2e-74cc6dd7215d
|LLWalkAdjustMotion in llcharacter/llkeyframewalkmotion.cpp
|2
|Makes walking corrections for terrain, turns. Joints moved: pelvis, left ankle, right ankle
|- 
| Lipsync_Ooh Lipsync_Aah
|(none assigned)
|character/avatar_lad.xml
|
|Mouth movement for voice [[LipSync|lip sync]] feature
|}

==Footnotes==
{{Footnotes}}
[[Category:LSL_Animation]]

GIMP Layers to SL Animated Texture

2015-01-24T04:56:05Z

Pedro Oval: <scheme> to <source>

This is a GIMP script (written in Script-Fu, the Scheme-based scripting language that GIMP uses) that takes the layers of an image representing an animation, and converts them into a texture suitable for use with '''[[llSetTextureAnim]]'''.

== Installation ==

Copy and paste the script below into a simple text editor of your choice (Notepad is probably the best choice for Windows systems). Save it into your scripts folder with the extension .scm - the suggested name is "layers-to-sl-animation.scm". The scripts folder can be found by going to ''Preferences > Folders > Scripts''. After it's in the ''Scripts'' folder, do a refresh by selecting ''Filters > Script-Fu > Refresh Scripts''.

== Usage ==

First, create or load an animation with one layer per frame (the first frame is the bottom layer). An existing GIF animation will work for this purpose, or you can create your own, or import one if you have enough memory. Version 1.0 of this script required to use the Unoptimize filter first in some cases; as of version 2.0, that functionality is already built in.

Next, ensure that it has the correct size and number of frames desired. It's preferable to have a plan at this point of what the final resolution will be, and how many horizontal and vertical frames the final image will have. If you are not going to use all the frames in your final image (for example, you have 5 frames and decide to do a 3x2 image), you still need to fill the holes. Create empty layers or duplicate existing ones until completing the final frame count. If you need to rescale the image at this point and the image is indexed, it's better if you convert it to RGB mode first.

Now invoke the script. It is invoked using ''Script-fu > SecondLife > Frames to texture...''

A window will appear, asking the number of horizontal and vertical frames of the final image. As noted above, that number must match the number of frames in your layers, or the script will show an error instead. It also asks whether you want to generate an animation script in a message window, and the frame rate to use for that script. Click OK and you will get a new image window consisting of the original frames arranged according to the specified values, suitable for use in SL. Now you can save the file and upload it to SL. If you had the script generation option checked, you can select the code from the window that appears, copy it, and paste it as a LSL script replacing the contents.

== The script ==

<source lang="scheme">
; Layers to SL Texture Animation, version 2.0.1
;
; Written by Pedro Oval, 2010-12-04.
; Donated to the public domain.
; Thanks to Digital Dharma for the suggestions.

(define (script-fu-layers-to-sl-anim curimg curdrawable xframes yframes showscript fps)

; Local function: check if a string contains a substring
(define (contains-ci str substr)
(define i 0)
(define lensub (string-length substr))
(define imax (- (string-length str) lensub))
(if (negative? imax)
#f
(begin
(define found #f)
(while (and (not found) (<= i imax))
; We make a case-insensitive comparison.
(if (string-ci=? (substring str i (+ i lensub)) substr)
(set! found #t)
(set! i (+ i 1))))
found)))

; Read the layer IDs and the total number of layers from the original image.
(define layerset (gimp-image-get-layers curimg))
(define numframes (car layerset))
(set! layerset (cadr layerset))

; The frame size X and Y is the size of the original image.
(define framesizex (car (gimp-image-width curimg)))
(define framesizey (car (gimp-image-height curimg)))

; Get the image type; indexed images need special treatment.
(define imgtype (car (gimp-image-base-type curimg)))

; Check if the given number of horizontal x vertical frames matches
; the number of layers in the original image. If yes, proceed; if not,
; show an error message.
(if (= numframes (* xframes yframes))
(begin
; New image
(define img (car (gimp-image-new (* framesizex xframes) (* framesizey yframes) imgtype)))
; We create a new image, so we disable undo for it; to "undo"
; the script, just close the new image.
(gimp-image-undo-disable img)

(if (= imgtype INDEXED)
(begin
; Indexed images need the palette to be copied to the new image.
(define palette (gimp-image-get-colormap curimg))
(gimp-image-set-colormap img (car palette) (cadr palette))))

; Initialize previous layer info to 0, as there's no previous layer yet.
; On the next iteration it will hold a list with:
; layer ID, offset X, offset Y.
(define prevlayerinfo 0)

; Loop betwen 0 and numframes - 1.
(define frame 0)
(while (< frame numframes)
; For each layer/frame:
(begin

; Show progress as the current frame relative to the number of frames.
(gimp-progress-update (/ frame numframes))

; Read the individual layer ID, starting from the bottom.
(define oldlayer (vector-ref layerset (- numframes frame 1)))

; Create new layer as a copy of this one and add it to the image.
(define newlayer (car (gimp-layer-new-from-drawable oldlayer img)))
(gimp-image-add-layer img newlayer -1)

; Add alpha if the layer doesn't have it.
(if (= (car (gimp-drawable-has-alpha newlayer)) FALSE)
(gimp-layer-add-alpha newlayer))

; Calculate the offsets relative to the destination rectangle,
; and the crop size.
(define offsets (gimp-drawable-offsets oldlayer))
(define newsizex (car (gimp-drawable-width oldlayer)))
(define newsizey (car (gimp-drawable-height oldlayer)))
(define offsetx (car offsets))
(define offsety (cadr offsets))
(if (< offsetx 0)
(begin
(set! newsizex (+ newsizex offsetx))
(set! offsetx 0)))
(if (< offsety 0)
(begin
(set! newsizey (+ newsizey offsety))
(set! offsety 0)))
(if (> (+ offsetx newsizex) framesizex)
(set! newsizex (- framesizex offsetx)))
(if (> (+ offsety newsizey) framesizey)
(set! newsizey (- framesizey offsety)))

; Calculate frame rectangle's top left position.
(define framey (truncate (/ frame xframes)))
(define framex (- frame (* framey xframes)))
(set! framex (* framex framesizex))
(set! framey (* framey framesizey))

; Crop the layer if necessary so that it fits its
; rectangle, and move it to its final position.
(gimp-layer-resize newlayer
newsizex
newsizey
(- (car offsets) offsetx)
(- (cadr offsets) offsety))
(gimp-layer-set-offsets newlayer (+ framex offsetx) (+ framey offsety))

; Force it visible.
(gimp-drawable-set-visible newlayer TRUE)

; Check for (combine) mode. Note: It just works
; in layers other than 0. Otherwise no action is
; done. It makes no sense for the bottom layer to
; use combine mode anyway.
(if (and (> frame 0) (contains-ci (car (gimp-drawable-get-name oldlayer)) "(combine)"))
(begin
; Duplicate the previous layer to serve as a base
; for the differencing frame being added.
(define layercopy (car (gimp-layer-new-from-drawable (car prevlayerinfo) img)))

; Add the new layer below the last layer.
(gimp-image-add-layer img layercopy 1)

; Set the layer position to match that of the new layer.
(gimp-layer-set-offsets layercopy (+ framex (cadr prevlayerinfo))
(+ framey (caddr prevlayerinfo)))

; Ensure the previous layer's copy is visible.
(gimp-drawable-set-visible layercopy TRUE)

; Merge the differencing frame into the previous layer's copy.
(set! newlayer (car (gimp-image-merge-down img newlayer EXPAND-AS-NECESSARY)))

; Correct the offsets. We use 'min' to match what
; EXPAND-AS-NECESSARY has supposedly done. Ideally
; we should read the new offsets and subtract
; framex/framey from them, but this is faster and simpler,
(set! offsetx (min offsetx (cadr prevlayerinfo)))
(set! offsety (min offsety (caddr prevlayerinfo)))))

; Previous layer = this.
(set! prevlayerinfo (list newlayer offsetx offsety))

; All done. Next loop iteration.
(set! frame (+ frame 1))))

; Progress 100%
(gimp-progress-update 1.0)

; Merge visible layers (all are visible now).
(define mergedlayer (car (gimp-image-merge-visible-layers img CLIP-TO-IMAGE)))

; Make the new layer the size of the image.
(gimp-layer-resize-to-image-size mergedlayer)

; Convert the image to RGB if it is not already.
(if (not (= imgtype RGB))
(gimp-image-convert-rgb img))

; Detect alpha by converting it to a selection.
(gimp-selection-layer-alpha mergedlayer)

; If there is no useful alpha, the selection should cover the whole image.
; Invert it, and if it becomes empty, then it means that alpha was not
; in use: the whole image was covered with 100% opacity.
(gimp-selection-invert img)
(define hasalpha (car (gimp-selection-bounds img)))
(gimp-selection-none img)

; If it didn't have any alpha, remove the alpha mask from the layer.
(if (= hasalpha FALSE)
(gimp-layer-flatten mergedlayer))

; All done - enable undo again and add a display window for the new image.
(gimp-image-undo-enable img)
(gimp-display-new img)

; Prepare a version of fps ending in .0 if it doesn't.
(define fpsstr (number->string fps))
(if (not (contains-ci fpsstr "."))
(set! fpsstr (string-append fpsstr ".0")))

; Show the script if requested
(if (= showscript TRUE)
(gimp-message (string-append "// Copy-paste the following fragment as a script:\n\n"
"default\n{\n state_entry()\n {\n"
" llSetTextureAnim(ANIM_ON | LOOP, "
(number->string xframes)
", "
(number->string yframes)
", 0.0, "
(number->string (* xframes yframes))
".0, "
fpsstr ");\n }\n}\n"))))

; If the frame counts didn't match...
(gimp-message "Error: Number of layers doesn't match horizontal x vertical frames")))

; Register the function.
(script-fu-register "script-fu-layers-to-sl-anim"
_"<Image>/Script-Fu/SecondLife/Frames to texture..."
_"Convert a set of layers (frames) to a texture suitable for llSetTextureAnim."
"Pedro Oval"
_"Public Domain"
"2010-12-04"
"RGB*, GRAY*, INDEXED*"
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0
SF-ADJUSTMENT _"# of horizontal frames" '(2 1 1024 1 10 0 1)
SF-ADJUSTMENT _"# of vertical frames" '(2 1 1024 1 10 0 1)
SF-TOGGLE _"Generate LSL script?" TRUE
SF-VALUE _"Frames per second (for script):" "10.0")
</source>

== Change Log ==

* Version 2.0.1 (2012-06-05):
** Disable undo instead of creating an undo group. Makes more sense to the user and saves memory.
* Version 2.0 (2010-12-22):
** Frames are no longer required to be the same size as the image.
** Recognize "combine" layers. Should work with all animated GIFs now.
** Option to generate the LSL script, active by default.
** Deal with alpha, so that it's removed if not needed and vice versa.
** Added progress indicator.
** Extensively commented.
* Version 1.0 (2010-12-04): First public release.

See also [[User:Pedro Oval/GIMP Layers to SL Animated Texture]] for the (possibly unstable) current development version and future plans.

== Credits/License ==

Written by Pedro Oval. Donated to the public domain.

User:Pedro Oval/Table of implicit type conversions for list extracting functions

2015-01-24T04:45:27Z

Pedro Oval: <lsl> to <source>

This table tells whether an implicit type cast is supported by <code>llList2*</code> depending on the item type in the list. Last tested with this server version: Second Life Server 11.10.18.243270

Updated 2011-10-30 with note on unsupported llList2Key conversions in LSO, which weren't tested before

{| {{Prettytable}}
|- {{Hl2}}
! List item type: Function: !! string !! key !! integer !! float !! vector !! rotation
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2String
| YES || YES || YES || YES || YES || YES
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2Key
| YES || YES || no || no || no || no
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2Integer
| YES || no || YES || YES || no || no
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2Float
| YES || no || YES || YES || no || no
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2Vector
| no || no || no || no || YES || no
|- style="text-align:center"
!scope="row" {{Hl2}}|llList2Rot
| no || no || no || no || no || YES
|}

The non-supported conversions for <code>llList2Key</code> return <code>(key)""</code> in Mono, and <code>(key)NULL_KEY</code> in LSO.

The non-supported conversions for <code>llList2Integer</code> return <code>0</code>.

The non-supported conversions for <code>llList2Float</code> return <code>0.0</code>.

The non-supported conversions for <code>llList2Vector</code> return <code>ZERO_VECTOR</code>.

The non-supported conversions for <code>llList2Rot</code> return <code>ZERO_ROTATION</code>.

In short: <code>llList2String</code> can be applied to all types. A string element can be extracted by all functions except <code>llList2Vector</code> and <code>llList2Rot</code>. <code>llList2Integer</code> can extract a float, and <code>llList2Float</code> can extract an integer. No other implicit conversions are supported.

== Test code ==

Here's the program used to elaborate the above table:

<source lang="lsl2">
string CheckResults(integer ExpectedYes, integer ExpectedNo)
{
if (ExpectedYes && ExpectedNo)
{
// Inconsistent check - revise code
return "*INCONSISTENT*";
}

if (!ExpectedYes && !ExpectedNo)
{
// Neither of the checks is met
return "*UNEXPECTED*";
}
if (ExpectedYes)
return " YES";
return " no ";
}

string v2s(vector v)
{
return "<"+(string)v.x+", "+(string)v.y+", "+(string)v.z+">";
}

string r2s(rotation r)
{
return "<"+(string)r.x+", "+(string)r.y+", "+(string)r.z+", "+(string)r.s+">";
}

default
{
state_entry()
{
string line;
string s;
key k;
integer i;
float f;
vector v;
rotation r;

llOwnerSay("-------------- s k i f v r");

line = "llList2String ";
s = "¡!¿?";
k = (key)"01234567-89ab-cdef-0123-456789abcdef";
i = -314159;
f = -3.141592e33;
v = <-1.22, 0.0, 9.9e9>;
r = <0.33, 0.66, 0.33, 0.589>;
line += CheckResults(llList2String([s], 0) == s, llList2String([s], 0) == "");
line += CheckResults(llList2String([k], 0) == (string)k, llList2String([k], 0) == "");
line += CheckResults(llList2String([i], 0) == (string)i, llList2String([i], 0) == "");
line += CheckResults(llList2String([f], 0) == (string)f, llList2String([f], 0) == "");
// we can't compare to (string)v because that returns 5 decimals in components instead of the usual 6
line += CheckResults(llList2String([v], 0) == v2s(v), llList2String([v], 0) == "");
// same caveat as above
line += CheckResults(llList2String([r], 0) == r2s(r), llList2String([r], 0) == "");
llOwnerSay(line);

line = "llList2Key ";
key expectedNo = llList2Key([], 0); // different expected negative result for Mono and LSO
line += CheckResults(llList2Key([s], 0) == (key)s, llList2Key([s], 0) == expectedNo);
line += CheckResults(llList2Key([k], 0) == k, llList2Key([k], 0) == expectedNo);
line += CheckResults(llList2Key([i], 0) == (key)((string)i), llList2Key([i], 0) == expectedNo);
line += CheckResults(llList2Key([f], 0) == (key)((string)f), llList2Key([f], 0) == expectedNo);
line += CheckResults(llList2Key([v], 0) == (key)v2s(v), llList2Key([v], 0) == expectedNo);
line += CheckResults(llList2Key([r], 0) == (key)r2s(r), llList2Key([r], 0) == expectedNo);
llOwnerSay(line);

line = "llList2Integer ";
s = "234";
k = (key)"234";
i = 234;
f = 234.1;
v = <234.0, 30.0, 20.0>;
r = <1.0, 1.0, 1.0, 1.0>;
line += CheckResults(llList2Integer([s], 0) == (integer)s, llList2Integer([s], 0) == 0);
line += CheckResults(llList2Integer([k], 0) == (integer)((string)k), llList2Integer([k], 0) == 0);
line += CheckResults(llList2Integer([i], 0) == i, llList2Integer([i], 0) == 0);
line += CheckResults(llList2Integer([f], 0) == (integer)f, llList2Integer([f], 0) == 0);
line += CheckResults(llList2Integer([v], 0) == (integer)v.x, llList2Integer([v], 0) == 0);
line += CheckResults(llList2Integer([r], 0) == (integer)r.x, llList2Integer([r], 0) == 0);
llOwnerSay(line);

line = "llList2Float ";
s = "234.1";
k = (key)"234.1";
i = 234;
f = 234.1;
v = <234.1, 30.0, 20.0>;
r = <0.33, 0.66, 0.33, 0.589>;
line += CheckResults(llList2Float([s], 0) == (float)s, llList2Float([s], 0) == 0.0);
line += CheckResults(llList2Float([k], 0) == (float)((string)k), llList2Float([k], 0) == 0.0);
line += CheckResults(llList2Float([i], 0) == (float)i, llList2Float([i], 0) == 0.0);
line += CheckResults(llList2Float([f], 0) == f, llList2Float([f], 0) == 0.0);
line += CheckResults(llList2Float([v], 0) == v.x, llList2Float([v], 0) == 0.0);
line += CheckResults(llList2Float([r], 0) == r.x, llList2Float([r], 0) == 0.0);
llOwnerSay(line);

line = "llList2Vector ";
s = "<1.3, 1.4, 1.5>";
k = (key)s;
line += CheckResults(llList2Vector([s], 0) == (vector)s, llList2Vector([s], 0) == ZERO_VECTOR);
line += CheckResults(llList2Vector([k], 0) == (vector)((string)k), llList2Vector([k], 0) == ZERO_VECTOR);
line += CheckResults(llList2Vector([i], 0) == <i, 0, 0>, llList2Vector([i], 0) == ZERO_VECTOR);
line += CheckResults(llList2Vector([f], 0) == <f, 0, 0>, llList2Vector([f], 0) == ZERO_VECTOR);
line += CheckResults(llList2Vector([v], 0) == v, llList2Vector([v], 0) == ZERO_VECTOR);
line += CheckResults(llList2Vector([r], 0) == <r.x,r.y,r.z>, llList2Vector([r], 0) == ZERO_VECTOR);
llOwnerSay(line);

line = "llList2Rot ";
s = "<1.3, 1.4, 1.5, 1.6>";
k = (key)s;
line += CheckResults(llList2Rot([s], 0) == (rotation)s, llList2Rot([s], 0) == ZERO_ROTATION);
line += CheckResults(llList2Rot([k], 0) == (rotation)((string)k), llList2Rot([k], 0) == ZERO_ROTATION);
line += CheckResults(llList2Rot([i], 0) == <i, 0, 0, 0>, llList2Rot([i], 0) == ZERO_ROTATION);
line += CheckResults(llList2Rot([f], 0) == <f, 0, 0, 0>, llList2Rot([f], 0) == ZERO_ROTATION);
line += CheckResults(llList2Rot([v], 0) == <v.x, v.y, v.z, 0>, llList2Rot([v], 0) == ZERO_ROTATION);
line += CheckResults(llList2Rot([r], 0) == r, llList2Rot([r], 0) == ZERO_ROTATION);
llOwnerSay(line);
}
}
</source>

User:Pedro Oval/XorBase64StringsSameLength

2015-01-24T04:43:47Z

Pedro Oval: <lsl> to <source>

{{Note|This function has been obsoleted by the release of [[llXorBase64]] in [[Release Notes/Second Life Server/13#13.06.21.277682|server version 13.06.21.277682]].}}

This code works around a bug in [[llXorBase64StringsCorrect]] in order to perform correct XOR of two strings of the same length but without the 0.3 second delay included in [[llXorBase64Strings]]. It relies on [[llBase64ToInteger]]'s unpredictable behaviour not affecting the bits actually used, for speed. It is a workaround to [http://jira.secondlife.com/browse/SCR-35 SCR-35] to provide a substitutive while that bug isn't fixed. Note that it is not a full substitutive for <code>llXorBase64StringsCorrect</code>, because it doesn't deal with the case of the second string being shorter than the first. Its main purpose is stream encryption, where the lengths usually match or at least the second string is longer (that case will be correctly handled by this function, trimming the result to the length of the first string).

<source lang="lsl2">
string XorBase64StringsSameLength(string s1, string s2)
{
integer i;
string s3;
integer len = llStringLength(s1); // assumed to be the same in s1 and s2
integer pad = (llGetSubString(s1, -2, -2) == "=") + (llGetSubString(s1, -1, -1) == "=");
for (i = 0; i < len; i += 4)
{
s3 += llGetSubString(llIntegerToBase64(llBase64ToInteger(llGetSubString(s1, i, i+3))
^ llBase64ToInteger(llGetSubString(s2, i, i+3))),
0, 3);
}
if (pad)
{
s3 = llGetSubString(s3, 0, -pad-1) + llGetSubString("==", -pad, -1);
}
return s3;
}

/* Test suite */
default
{
state_entry()
{
llOwnerSay((string)llStringLength(XorBase64StringsSameLength("", "whatever"))); // Returns 0 as it should
llOwnerSay(XorBase64StringsSameLength("AABA", "1234")); // Returns 1224 as it should
llOwnerSay(XorBase64StringsSameLength("1234", "AABA")); // Returns 1224 as it should

llOwnerSay(XorBase64StringsSameLength("BAAA", "1234")); // Returns 0234 as it should
llOwnerSay(XorBase64StringsSameLength("1234", "BAAA")); // Returns 0234 as it should

llOwnerSay(XorBase64StringsSameLength("AABA", "AABA")); // Returns AAAA as it should

llOwnerSay(XorBase64StringsSameLength("1234///=", "1234AAA=")); // Returns AAAA//8= as it should
llOwnerSay(XorBase64StringsSameLength("1234///=", "1234AAA/")); // Returns AAAA//8= as it should
llOwnerSay(llXorBase64StringsCorrect ("1234///=", "1234AAA=")); // Returns AAAAKJI= (wrong)
llOwnerSay(llXorBase64StringsCorrect ("1234AAA=", "1234///=")); // Returns AAAA//8= as it should

llOwnerSay(XorBase64StringsSameLength("1234//==", "1234AA==")); // Returns AAAA/w== as it should
llOwnerSay(XorBase64StringsSameLength("1234//==", "1234AA//")); // Returns AAAA/w== as it should
llOwnerSay(llXorBase64StringsCorrect ("1234//==", "1234AA==")); // Returns AAAAKA== (wrong)
llOwnerSay(llXorBase64StringsCorrect ("1234AA==", "1234//==")); // Returns AAAA/w== as it should
}
}
</source>

User:Pedro Oval/Float formatting functions

2015-01-24T04:39:27Z

Pedro Oval: <lsl> to <source>

=== WARNING: WORK IN PROGRESS - NOT READY FOR USE YET ===

This is a collection of functions for formatting floats with rounding, carefully tuned to get the expected results in most cases, something that other widely available functions often fail to accomplish. None of them will work with more than 6 decimals though.

The variations are for slightly different purposes. Some can be a question of taste; others depend on functionality.

The variants with the dot removed are good for human-readable formatted output, because it's prettier to see <code>"4"</code> than to see <code>"4."</code>; if the output has to include the decimals mandatorily, <code>"4.0"</code> is usually considered prettier than <code>"4."</code>. The variants that don't remove the dot are good e.g. for machine-generated code where the formatting is not important but the type is. (<code>4</code> is an integer; <code>4.</code> is a float.) This may save an implicit type conversion at runtime where a float is expected but an integer is given, which just wastes memory and speed unnecessarily. For example, <code><1, 0, 0></code> adds 3 type conversions to the code, but <code><1., 0., 0.></code> doesn't add any extra burden.

Pick your poison:

== Just trim zeros at the end ==

These functions take just one argument and return at most 6 decimals, with the zeros trimmed and rounded to the 6th decimal. For example, <code>FormatFloat(4.31)</code> returns <code>"4.31"</code> instead of <code>"4.310000"</code>.

=== Dot removed if last character ===

E.g. <code>FormatFloat(4.0)</code> returns <code>"4"</code>.

Faster:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0";
if (llGetSubString(fs, -6, -1) == "000000" return llDeleteSubString(fs, -7, -1);
if (llGetSubString(fs, -5, -1) == "00000" return llDeleteSubString(fs, -5, -1);
if (llGetSubString(fs, -4, -1) == "0000" return llDeleteSubString(fs, -4, -1);
if (llGetSubString(fs, -3, -1) == "000" return llDeleteSubString(fs, -3, -1);
if (llGetSubString(fs, -2, -1) == "00" return llDeleteSubString(fs, -2, -1);
if (llGetSubString(fs, -1, -1) == "0" return llDeleteSubString(fs, -1, -1);
return fs;
}
</source>

Shorter:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0";
integer i;
string last;
do ; while ((last = llGetSubString(fs, i=~-i, i)) == "0");
return llGetSubString(fs, 0, i - (last == "."));
}
</source>

=== Dot not removed if last character ===

E.g. <code>FormatFloat(4.0)</code> returns <code>"4."</code>.

Faster:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0.";
if (llGetSubString(fs, -6, -1) == "000000" return llDeleteSubString(fs, -6, -1);
if (llGetSubString(fs, -5, -1) == "00000" return llDeleteSubString(fs, -5, -1);
if (llGetSubString(fs, -4, -1) == "0000" return llDeleteSubString(fs, -4, -1);
if (llGetSubString(fs, -3, -1) == "000" return llDeleteSubString(fs, -3, -1);
if (llGetSubString(fs, -2, -1) == "00" return llDeleteSubString(fs, -2, -1);
if (llGetSubString(fs, -1, -1) == "0" return llDeleteSubString(fs, -1, -1);
return fs;
}
</source>

Shorter:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0.";
integer i;
do ; while (llGetSubString(fs, (i=~-i), i) == "0");
return llGetSubString(fs, 0, i);
}
</source>

=== 1 decimal minimum ===

E.g. <code>FormatFloat(4.0)</code> returns <code>"4.0"</code>.

Faster:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0.0";
if (llGetSubString(fs, -5, -1) == "00000" return llDeleteSubString(fs, -5, -1);
if (llGetSubString(fs, -4, -1) == "0000" return llDeleteSubString(fs, -4, -1);
if (llGetSubString(fs, -3, -1) == "000" return llDeleteSubString(fs, -3, -1);
if (llGetSubString(fs, -2, -1) == "00" return llDeleteSubString(fs, -2, -1);
if (llGetSubString(fs, -1, -1) == "0" return llDeleteSubString(fs, -1, -1);
return fs;
}
</source>

Shorter:
<source lang="lsl2">
string FormatFloat(float f)
{
string fs = (string)f;
if (fs == "-0.000000") return "0.0";
integer i;
do ; while (i > -6 && llGetSubString(fs, (i=~-i), i) == "0");
return llGetSubString(fs, 0, i);
}
</source>

== Fixed number of decimals ==

These functions take two arguments: the float to format and the number of decimals. They perform rounding in the last digit. For example, <code>FormatFloat(4.361262, 4)</code> returns <code>"4.3613"</code> and <code>FormatFloat(4.36, 4)</code> returns <code>"4.3600"</code>.

=== Dot removed if zero decimals ===

E.g. <code>FormatFloat(4.3, 0)</code> returns <code>"4"</code>; <code>FormatFloat(-4.6, 0)</code> returns <code>"-5"</code>.

<source lang="lsl2">
string FormatFloat(float f, integer num_decimals)
{
float rounding = (float)(".5e-" + (string)num_decimals) - 0.0000005;
if (f < 0.) f -= rounding; else f += rounding;
string ret = llGetSubString((string)f, 0, num_decimals - !num_decimals - 7);
if ((float)ret == 0. && llGetSubString(ret, 0, 0) == "-")
ret = llDeleteSubString(ret, 0, 0);
return ret;
}
</source>

=== Dot not removed if zero decimals ===

E.g. <code>FormatFloat(4.3, 0)</code> returns <code>"4."</code>. This is the shortest version, recommended if you will never use zero decimals.

<source lang="lsl2">
string FormatFloat(float f, integer num_decimals)
{
float rounding = (float)(".5e-" + (string)num_decimals) - 0.0000005;
if (f < 0.) f -= rounding; else f += rounding;
string ret = llGetSubString((string)f, 0, num_decimals - 7);
if ((float)ret == 0. && llGetSubString(ret, 0, 0) == "-")
ret = llDeleteSubString(ret, 0, 0);
return ret;
}
</source>

=== Add .0 if zero decimals ===

E.g. <code>FormatFloat(4.3, 0)</code> returns <code>"4.0"</code>. This can be unexpected and surprising for many users, so use it only if you are sure you need something like that.

<source lang="lsl2">
string FormatFloat(float f, integer num_decimals)
{
float rounding = (float)(".5e-" + (string)num_decimals) - 0.0000005;
if (f < 0.0) f -= rounding; else f += rounding;
string ret = llGetSubString((string)f, 0, num_decimals - 7);
if ((float)ret == 0. && llGetSubString(ret, 0, 0) == "-")
ret = llDeleteSubString(ret, 0, 0);
if (! num_decimals) ret += "0";
return ret;
}
</source>

== Fixed number of decimals, trimming trailing zeros ==

This is an hybrid between both kinds of functions above. It limits the number of decimals output to the given maximum, but also trims zeros at the end, so it's possible to get less decimals than requested (but not more). For example, <code>FormatFloat(4.396, 2)</code> returns <code>"4.4"</code> because 4.396 rounded to two decimals is 4.40 and then the trailing zero is trimmed.

=== Dot removed if zero decimals ===

=== Dot not removed if zero decimals ===

=== Add .0 if zero decimals ===

== Test suite for all of the above ==

The program below exercises some corner cases I could come up with, to ensure that the resuls are as expected. Many other float formatting functions fail some of these tests.

User:Pedro Oval/Uniform random rotation

2015-01-24T04:35:15Z

Pedro Oval: <lsl> to <source>

Based on a "graphics gem" by Ken Shoemake [http://books.google.com/books?id=xmW_u3mQLmQC&pg=PA130]

<source lang="lsl2">
rotation UniformRandRot()
{
// Method from Graphic Gems 3, "Uniform Random Rotations"
// by Ken Shoemake, p.130
float r2 = llFrand(1.0);
float a1 = llFrand(TWO_PI);
float a2 = llFrand(TWO_PI);
float r1 = llSqrt(1.0 - r2);
r2 = llSqrt(r2);
return <r1*llSin(a1), r1*llCos(a1), r2*llSin(a2), r2*llCos(a2)>;
}
</source>

User:Pedro Oval/Calculate rotation for pointing in a direction

2015-01-24T04:31:00Z

Pedro Oval: <lsl> to <source>

Here are two functions that, given a [[vector]] to point at, return the [[rotation]] that corresponds to that vector.

One of the functions, <code>PointAt2Rot</code>, makes the forward (X) vector point exactly in that direction, while keeping the up (Z) vector pointing "as up as possible" and the left (Y) vector completely horizontal. It is similar to what [[llLookAt]] does, except that the vector that points to the target is X (forward) instead of Z (up), and the result is a rotation, not a continuously updating state of pointing in the given direction. A similar result can be obtained by combining these functions with [[llRotLookAt]].

The other function, <code>PointAtHoriz2Rot</code>, points to the horizontal that is closest to the given vector, while the up vector points exactly up. It is useful if the final resulting rotation must be horizontal.

<source lang="lsl2">
// Written by Pedro Oval, 2011-01-11

rotation PointAt2Rot(vector target)
{
vector left = llVecNorm(<0,0,1> % target);
target = llVecNorm(target);
return llAxes2Rot(target, left, target % left);
}

rotation PointAtHoriz2Rot(vector target)
{
// Find the Z angle and halve it for the quaternion:
target.z = llAtan2(target.y, target.x) * 0.5;
// Make a quaternion out of it on z:
return <0, 0, llSin(target.z), llCos(target.z)>;
}
</source>

The following are versions of <code>PointAt2Rot</code> and <code>PointAtHoriz2Rot</code> that allow a viewup vector (the vector that determines the tilting) expressed in the same coordinate system as the target vector:

<source lang="lsl2">
// Written by Pedro Oval, 2011-01-08

rotation PointAtViewup2Rot(vector target, vector viewup)
{
// Reuse the variables to avoid declaring locals, which is expensive
viewup = llVecNorm(viewup % target);
target = llVecNorm(target);
return llAxes2Rot(target, viewup, target % viewup);
}

rotation PointAtHorizViewup2Rot(vector target, vector viewup)
{
// Reuse the variables to avoid declaring locals, which is expensive
target = llVecNorm(viewup % target);
viewup = llVecNorm(viewup);
return llAxes2Rot(target % viewup, target, viewup);
}
</source>

When these two functions are passed a viewup of <code><0, 0, 1></code>, they return the same result as the former two (except for possible precision issues).

== Examples ==
The following are incomplete examples, as they need the above functions included, which have been stripped for brevity and ease of maintenance.

This example uses a 0.5 second sensor to detect a nearby prim called ''Target'' and makes the current prim's X axis point to it (assuming it's in a prim alone, or in the root of a linked set):
<source lang="lsl2">
default
{
state_entry()
{
llSensorRepeat("Target", "", ACTIVE | PASSIVE, 30., PI, 0.5);
}

sensor(integer num)
{
llSetRot(PointAt2Rot(llDetectedPos(0) - llGetPos()));
}
}
</source>

Changing <code>PointAt2Rot</code> to <code>PointAtHoriz2Rot</code> in the above will make the prim be always horizontal but with its X face facing the target as much as possible while keeping the horizontal.

The following example shows how to use <code>PointAtViewup2Rot</code> to orient the prim's top in world coordinates, when the script is used within a linked prim. It is assumed to be in a prim with a link number greater than 2. It detects the position of the prim with link number 2 using a timer, and makes this prim's X axis point towards it, and the Z axis as close to the world's up vector as possible:
<source lang="lsl2">
default
{
state_entry()
{
llSetTimerEvent(0.5);
}

timer()
{
rotation RootRot = llGetRootRotation();

// Get the target prim's position in world coordinates.
vector pos = llList2Vector(llGetLinkPrimitiveParams(2, [PRIM_POSITION]), 0);

// Use the world's <0, 0, 1> vector as viewup, after converting it
// to local coordinates, and the vector from our position to the target
// as the PointAt, also in local coordinates:
llSetLocalRot(PointAtViewup2Rot((pos - llGetPos()) / RootRot, <0, 0, 1> / RootRot));
}
}
</source>

User:Pedro Oval/Base64 HMAC SHA-1

2015-01-24T04:29:34Z

Pedro Oval: <lsl> to <source>

TODO: Add some text here, add padding test vectors

<source lang="lsl2">
string HexToBase64Unpadded(string a)
{
integer i = 0;
integer len = llStringLength(a += "0000") - 4;
string res = "";
while (i < len)
{
res += llGetSubString(llIntegerToBase64(4*(integer)("0x" + llGetSubString(a, i, i+5))), 1, 4);
i += 6;
}
return llGetSubString(res, 0, len*2/3);
}

string RemovePadding(string b64) // specialized - it won't work if the string consists of all "="
{
integer i;
do ; while(llGetSubString(b64, i = ~-i, i) == "=");
return llGetSubString(b64, 0, i);
}

list Base64SHA1Compress(string b64, integer H1, integer H2, integer H3, integer H4, integer H5, integer i)
{
integer A = H1;
integer B = H2;
integer C = H3;
integer D = H4;
integer E = H5;

integer round;
integer S = 0;
integer T;
list x = [];
string buf;

do
{
T = llBase64ToInteger(buf = llGetSubString(b64, T = ((i + round) << 4) / 3, T+6)) << (S = ((i + round) % 3) << 1);
if(S)
T = T | (llBase64ToInteger("A" + (llDeleteSubString(buf, 0, 1))) >> (6 - S));
// llOwnerSay("W["+(string)round+"]="+hex(T));
x += T;
T += ((A << 5) | ((A >> 27) & 0x1F)) + (D ^ (B & (C ^ D))) + E + 0x5a827999;
E = D;
D = C;
C = ((B << 30) | ((B >> 2) & 0x3FFFFFFF));
B = A;
A = T;
}while(16 > (round = -~round));
// llOwnerSay(llList2CSV(hexm(x)));
do
{
S = llList2Integer(x, -3) ^ llList2Integer(x, -8) ^ llList2Integer(x, -14) ^ llList2Integer(x, -16);
x = llList2List(x + (T = ((S << 1) | !!(S & 0x80000000))), -16, -1);
// llOwnerSay("W["+(string)round+"]="+hex(T));
T += ((A << 5) | ((A >> 27) & 0x1F)) + (D ^ (B & (C ^ D))) + E + 0x5a827999;
E = D;
D = C;
C = ((B << 30) | ((B >> 2) & 0x3FFFFFFF));
B = A;
A = T;
}while(20 > (round = -~round));
do
{
S = llList2Integer(x, -3) ^ llList2Integer(x, -8) ^ llList2Integer(x, -14) ^ llList2Integer(x, -16);
x = llList2List(x + (T = ((S << 1) | !!(S & 0x80000000))), -16, -1);
// llOwnerSay("W["+(string)round+"]="+hex(T));
T += ((A << 5) | ((A >> 27) & 0x1F)) + (B ^ C ^ D) + E + 0x6ed9eba1;
E = D;
D = C;
C = ((B << 30) | ((B >> 2) & 0x3FFFFFFF));
B = A;
A = T;
}while(40 > (round = -~round));
do
{
S = llList2Integer(x, -3) ^ llList2Integer(x, -8) ^ llList2Integer(x, -14) ^ llList2Integer(x, -16);
x = llList2List(x + (T = ((S << 1) | !!(S & 0x80000000))), -16, -1);
// llOwnerSay("W["+(string)round+"]="+hex(T));
T += ((A << 5) | ((A >> 27) & 0x1F)) + ((B & C) | (B & D) | (C & D)) + E + 0x8f1bbcdc;
E = D;
D = C;
C = ((B << 30) | ((B >> 2) & 0x3FFFFFFF));
B = A;
A = T;
}while(60 > (round = -~round));
do
{
S = llList2Integer(x, -3) ^ llList2Integer(x, -8) ^ llList2Integer(x, -14) ^ llList2Integer(x, -16);
x = llList2List(x + (T = ((S << 1) | !!(S & 0x80000000))), -16, -1);
// llOwnerSay("W["+(string)round+"]="+hex(T));
T += ((A << 5) | ((A >> 27) & 0x1F)) + (B ^ C ^ D) + E + 0xca62c1d6;
E = D;
D = C;
C = ((B << 30) | ((B >> 2) & 0x3FFFFFFF));
B = A;
A = T;
}while(80 > (round = -~round));

return [H1+A, H2+B, H3+C, H4+D, H5+E];
}

string Base64SHA1forHMAC(string b64, integer bit_length, integer extra_bit_length, integer H1, integer H2, integer H3, integer H4, integer H5)
{
//OR on the extra bit.
integer b = ((bit_length + 40) >> 5) | 15;
integer T = llBase64ToInteger(RemovePadding(llGetSubString(b64, -4, -1)) + "AAAA");
string buf = "AAA";
integer i = -5;
do buf += buf; while((i = -~i));
if(bit_length)
{
i = 0x800000;
if(!(bit_length % 24))
i = 0x80;
else if((bit_length % 24) == 16)
i = 0x8000;
}
else
T = 0x80000000;//T is corrupt because of https://jira.secondlife.com/browse/SVC-104
bit_length += extra_bit_length;
// llOwnerSay(llList2CSV([i,bit_length]));
b64 = llGetSubString( llDeleteSubString(b64, -4, -1) +
llGetSubString(llIntegerToBase64(T | i), 0, 5) +
buf, 0, (b << 4) / 3) +
llIntegerToBase64(bit_length << (6 - ((b % 3) << 1)));
list x;
i = 0;
do
{
x = Base64SHA1Compress(b64, H1, H2, H3, H4, H5, i);
H1 = llList2Integer(x, 0);
H2 = llList2Integer(x, 1);
H3 = llList2Integer(x, 2);
H4 = llList2Integer(x, 3);
H5 = llList2Integer(x, 4);
}while(b > (i += 16));
x = [H1, H2, H3, H4, H5];
i = -5;
buf = "";
do
{
T = llList2Integer(x,i);
bit_length = 32;
do
buf += llGetSubString("0123456789abcdef", b = ((T >> (bit_length -= 4)) & 0xF), b);
while (bit_length);
}while ((i = -~i));
return buf;
}

// The Real Thing
string Base64_HMAC_SHA1(string B64Key, string B64Data)
{
// integer H1 = 0x67452301;
// integer H2 = 0xefcdab89;
// integer H3 = 0x98badcfe;
// integer H4 = 0x10325476;
// integer H5 = 0xc3d2e1f0;
integer bit_length = llSubStringIndex(B64Key, "=");
if (!~bit_length)
{
bit_length = llStringLength(B64Key);
}
if (bit_length > 86)
{
// Use a hash of the key instead as a key
B64Key = HexToBase64Unpadded(Base64SHA1forHMAC(B64Key, (bit_length*6)&-8, 0, 0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0));
bit_length = 27;
}
B64Key = llGetSubString(B64Key, 0, bit_length-1);
string buf = "AAA";
integer i = -5;
do buf += buf; while((i = -~i));
B64Key = llXorBase64StringsCorrect(llGetSubString(B64Key + buf, 0, 85) + "==", "NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Ng==");

list x = Base64SHA1Compress(B64Key, 0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0, 0);
bit_length = (6 * !(B64Data=="") * (llStringLength(B64Data)-4+llStringLength(RemovePadding(llGetSubString(B64Data,-4,-1))))) & -8;
B64Data = HexToBase64Unpadded(Base64SHA1forHMAC(B64Data, bit_length, 512, llList2Integer(x, 0), llList2Integer(x, 1), llList2Integer(x, 2), llList2Integer(x, 3), llList2Integer(x, 4))) + "=";

// Xor with Base64(chr(0x36 xor 0x5C) * 64)
B64Key = llXorBase64StringsCorrect(B64Key, "ampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqag==");
x = Base64SHA1Compress(B64Key, 0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0, 0);
bit_length = 160;
return Base64SHA1forHMAC(B64Data, bit_length, 512, llList2Integer(x, 0), llList2Integer(x, 1), llList2Integer(x, 2), llList2Integer(x, 3), llList2Integer(x, 4));
}

test_vector_SHA1(string B64Key, string B64Data, string HexHash)
{
llResetTime();
string hmac = Base64_HMAC_SHA1(B64Key, B64Data);
if (hmac != HexHash)
{
llOwnerSay("HMAC-SHA1 test failed.\nComputed: " + hmac + "\nExpected : " + HexHash);
}
else
{
llOwnerSay("HMAC-SHA1 test passed in " + (string)llGetTime() + " seconds.");
}
}

default
{
state_entry()
{
// RFC 2202 test vectors:

test_vector_SHA1(HexToBase64Unpadded("0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b") + "=",
llStringToBase64("Hi There"),
"b617318655057264e28bc0b6fb378c8ef146be00");
test_vector_SHA1(llStringToBase64("Jefe"),
llStringToBase64("what do ya want for nothing?"),
"effcdf6ae5eb2fa2d27416d5f184df9c259a7c79");
test_vector_SHA1("qqqqqqqqqqqqqqqqqqqqqqqqqqo=",
"3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d0=",
"125d7342b9ac11cd91a39af48aa17b4f63f175d3");
test_vector_SHA1(HexToBase64Unpadded("0102030405060708090a0b0c0d0e0f10111213141516171819")+"==",
HexToBase64Unpadded("cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd")+"=",
"4c9007f4026250c6bc8414f9bf50c86c2d7235da");
test_vector_SHA1(HexToBase64Unpadded("0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c") + "=",
llStringToBase64("Test With Truncation"),
"4c1a03424b55e07fe7f27be1d58bb9324a9a5a04");
string buf = "aaaaa";
buf += buf;
buf += buf;
buf += buf;
buf += buf;
buf += buf;
test_vector_SHA1(HexToBase64Unpadded(buf) + "=",
llStringToBase64("Test Using Larger Than Block-Size Key - Hash Key First"),
"aa4ae5e15272d00e95705637ce8a3b55ed402112");
test_vector_SHA1(HexToBase64Unpadded(buf) + "=",
llStringToBase64("Test Using Larger Than Block-Size Key and Larger Than One Block-Size Data"),
"e8e99d0f45237d786d6bbaa7965c7808bbff1a91");

// Test vector added by the author
test_vector_SHA1("", "", "fbdb1d1b18aa6c08324b7d64b71fb76370690e1d");
// Test vectors added by the author for zero-terminated data strings at different padding positions
// (generated with an independent program written in PHP):
test_vector_SHA1("blah", "", "cf63ad15d4e1d7cdc33cb0084e362afe60d047b1"); // ""
test_vector_SHA1("blah", "AA==", "36cda2fc2a348a0b3645a9c135a12118e6f4dcca"); // "\0"
test_vector_SHA1("blah", "AAA=", "7b6527796c885a794f695541b4ec1a5af28dec3e"); // "\0\0"
test_vector_SHA1("blah", "AAAA", "d79915ec627764b7092ec66036fcaf94e4d94091"); // "\0\0\0"
test_vector_SHA1("blah", "MQA=", "9fa63e8684813ca6f601e7e082fd989c72295019"); // "1\0"
test_vector_SHA1("blah", "MQAA", "0d1ad14b1c4da14d5fca5b2e3486a7df2ef5fa12"); // "1\0\0"
test_vector_SHA1("blah", "MQAAAA==", "29ba52e7d932fdb2854cf52f75dea30aa0773025"); // "1\0\0\0"
test_vector_SHA1("blah", "MTIA", "ee65d68cdba172a95b7cc1640573bfa4f10fcf9d"); // "12\0"
test_vector_SHA1("blah", "MTIAAA==", "4908fdece951bc779690565b54960a5e93119d56"); // "12\0\0"
test_vector_SHA1("blah", "MTIAAAA=", "3213b2e563af1d5c04159bfcee0ee81124aaefb7"); // "12\0\0\0"
test_vector_SHA1("blah", "MTIzAA==", "f3967f44b64b8a32b3d0c9cfe514e580aca6869d"); // "123\0"
test_vector_SHA1("blah", "MTIzAAA=", "e509dfb925f1bd533216ba1f44d3ba1a998d078c"); // "123\0\0"
test_vector_SHA1("blah", "MTIzAAAA", "06476a68a5c2c6cfc5c595b83dcc672e910a3e3e"); // "123\0\0\0"

llOwnerSay("End of tests.");
}
}
</source>

User:Pedro Oval/Base64 HMAC MD5

2015-01-24T04:28:58Z

Pedro Oval: <lsl> to <source>

MD5 core written by [[User:Strife Onizuka|Strife Onizuka]]. HMAC calculation function, test vectors function and testcases, and modifications to Base64_MD5 made by [[User:Pedro Oval|Pedro Oval]]. Also, added functions HexToBase64Unpadded and RemovePadding, written by [[User:Pedro Oval|Pedro Oval]]. Modifications to Base64_MD5 comprise:

* Accept base64 strings instead of plain text strings.
* Accept an initial input state.
* Accept an extra bitlength to consider as already added.
* Separated into compression function and padding function, to avoid the costly Base64 bitshift that would be needed otherwise.
* Renamed globals to minimize the risk of a collision with usercode.
* Fixed bug with data ending in zeros.

Best speed seen under Mono: 0.201365 seconds for test case 15; worst: 0.495030 for test case 5.
Best speed seen under LSO : 5.698544 seconds for test case 19; worst: 13.351786 seconds for test case 7.

All test cases pass with both LSO and Mono.

<source lang="lsl2">
string HexToBase64Unpadded(string a)
{
integer i = 0;
integer len = llStringLength(a += "0000") - 4;
string res = "";
while (i < len)
{
res += llGetSubString(llIntegerToBase64(4*(integer)("0x" + llGetSubString(a, i, i+5))), 1, 4);
i += 6;
}
return llGetSubString(res, 0, len*2/3);
}

string RemovePadding(string b64) // specialized - it won't work if the string consists of all "="
{
integer i;
do ; while(llGetSubString(b64, i = ~-i, i) == "=");
return llGetSubString(b64, 0, i);
}

string hexc="0123456789abcdef";

list MD5_r1 = [7, 12, 17, 22];
list MD5_r2 = [5, 9, 14, 20];
list MD5_r3 = [4, 11, 16, 23];
list MD5_r4 = [6, 10, 15, 21];

list MD5_k1 = [
0xd76aa478, 0xe8c7b756, 0x242070db, 0xc1bdceee, 0xf57c0faf, 0x4787c62a, 0xa8304613, 0xfd469501,
0x698098d8, 0x8b44f7af, 0xffff5bb1, 0x895cd7be, 0x6b901122, 0xfd987193, 0xa679438e, 0x49b40821];
list MD5_k2 = [
0xf61e2562, 0xc040b340, 0x265e5a51, 0xe9b6c7aa, 0xd62f105d, 0x02441453, 0xd8a1e681, 0xe7d3fbc8,
0x21e1cde6, 0xc33707d6, 0xf4d50d87, 0x455a14ed, 0xa9e3e905, 0xfcefa3f8, 0x676f02d9, 0x8d2a4c8a];
list MD5_k3 = [
0xfffa3942, 0x8771f681, 0x6d9d6122, 0xfde5380c, 0xa4beea44, 0x4bdecfa9, 0xf6bb4b60, 0xbebfbc70,
0x289b7ec6, 0xeaa127fa, 0xd4ef3085, 0x04881d05, 0xd9d4d039, 0xe6db99e5, 0x1fa27cf8, 0xc4ac5665];
list MD5_k4 = [
0xf4292244, 0x432aff97, 0xab9423a7, 0xfc93a039, 0x655b59c3, 0x8f0ccc92, 0xffeff47d, 0x85845dd1,
0x6fa87e4f, 0xfe2ce6e0, 0xa3014314, 0x4e0811a1, 0xf7537e82, 0xbd3af235, 0x2ad7d2bb, 0xeb86d391];

list Base64MD5Compress(string b64, integer H1, integer H2, integer H3, integer H4, integer i)
{
integer A = H1;
integer B = H2;
integer C = H3;
integer D = H4;
integer round = 0;
list x = [];
string buf;
integer S = 0;
integer T;
do
{
T = llBase64ToInteger(buf = llGetSubString(b64, T = ((i + round) << 4) / 3, T+6)) << (S = (((i + round) % 3) << 1));
if(S)
T = T | (llBase64ToInteger("A" + (llDeleteSubString(buf, 0, 1))) >> (6 - S));
x += (T = ((T << 24) | ((T & 0xFF00) << 8) | ((T >> 8) & 0xFF00) | ((T >> 24) & 0xFF)));

S = A + llList2Integer(MD5_k1, round) + T + (D ^ (B & (C ^ D)));
T = llList2Integer(MD5_r1, round & 3);
A = D;
D = C;
C = B;
B += (S << T) | ((S >> (32 - T)) & ~(0xFFFFFFFF << T));
}
while(16 > (round = -~round));
do
{
S = A + llList2Integer(MD5_k2, round & 15) + (C ^ (D & (B ^ C))) + llList2Integer(x, (-~(5 * round)) & 15);
T = llList2Integer(MD5_r2, round & 3);
A = D;
D = C;
C = B;
B += (S << T) | ((S >> (32 - T)) & ~(0xFFFFFFFF << T));
}
while(32 > (round = -~round));
do
{
S = A + llList2Integer(MD5_k3, round & 15) + (B ^ C ^ D) + llList2Integer(x, (3 * round + 5) & 15);
T = llList2Integer(MD5_r3, round & 3);
A = D;
D = C;
C = B;
B += (S << T) | ((S >> (32 - T)) & ~(0xFFFFFFFF << T));
}
while(48 > (round = -~round));
do
{
S = A + llList2Integer(MD5_k4, round & 15) + (C ^ (B | (~D))) + llList2Integer(x, (7 * round) & 15);
T = llList2Integer(MD5_r4, round & 3);
A = D;
D = C;
C = B;
B += (S << T) | ((S >> (32 - T)) & ~(0xFFFFFFFF << T));
}
while(64 > (round = -~round));
// llOwnerSay(llList2CSV(x));

return [H1+A, H2+B, H3+C, H4+D];
}

string Base64MD5forHMAC(string b64, integer bit_length, integer extra_bit_length, integer H1, integer H2, integer H3, integer H4)
{
//OR on the extra bit.
integer b = (~-(((bit_length + 552) & -512) >> 5));
integer T = llBase64ToInteger(RemovePadding(llGetSubString(b64, -4, -1)) + "AAAA");
string buf = "AAA";
integer i = -5;
do buf += buf; while((i = -~i));
if(bit_length)
{
i = 0x800000;
if(!(bit_length % 24))
i = 0x80;
else if((bit_length % 24) == 16)
i = 0x8000;
}
else
T = 0x80000000;//T is corrupt because of https://jira.secondlife.com/browse/SVC-104
// llOwnerSay(llList2CSV([i,j]));
bit_length += extra_bit_length;
b64 = llGetSubString( llDeleteSubString(b64, -4, -1) +
llGetSubString(llIntegerToBase64(T | i), 0, 5) +
buf, 0, ((b << 4) / 3) - 7) +
llGetSubString(llIntegerToBase64((((bit_length & 0xFF) << 20) | ((bit_length & 0xFF00) << 4) | ((bit_length >> 12) & 0xFF0) | ((bit_length >> 28) & 0xF)) >> ((b % 3) << 1)), 0, 5) +
"AAAAAAAA";
i = 0;
list x;
do
{
x = Base64MD5Compress(b64, H1, H2, H3, H4, i);
H1 = llList2Integer(x, 0);
H2 = llList2Integer(x, 1);
H3 = llList2Integer(x, 2);
H4 = llList2Integer(x, 3);
}while(b > (i += 16));
i = -4;
buf = "";
do
{
T = llList2Integer(x,~i);
bit_length = 32;
do
buf = llGetSubString(hexc, b = ((T >> (bit_length - 4)) & 0xF), b) + llGetSubString(hexc, b = ((T >> (bit_length - 8)) & 0xF), b) + buf;
while ((bit_length -= 8));
}while ((i = -~i));
return buf;
}

// The Real Thing
string Base64_HMAC_MD5(string B64Key, string B64Data)
{
integer bit_length = llSubStringIndex(B64Key, "=");
if (!~bit_length)
{
bit_length = llStringLength(B64Key);
}
if (bit_length > 86)
{
B64Key = HexToBase64Unpadded(Base64MD5forHMAC(B64Key, (bit_length*6)&-8, 0, 1732584193, -271733879, -1732584194, 271733878));
bit_length = 22;
}
B64Key = llGetSubString(B64Key, 0, bit_length-1);
string buf = "AAA";
integer i = -5;
do buf += buf; while((i = -~i));
B64Key = llXorBase64StringsCorrect(llGetSubString(B64Key + buf, 0, 85) + "==", "NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Ng==");

list x = Base64MD5Compress(B64Key, 1732584193, -271733879, -1732584194, 271733878, 0);
bit_length = (6 * !(B64Data=="") * (llStringLength(B64Data)-4+llStringLength(RemovePadding(llGetSubString(B64Data,-4,-1))))) & -8;
B64Data = HexToBase64Unpadded(Base64MD5forHMAC(B64Data, bit_length, 512, llList2Integer(x, 0), llList2Integer(x, 1), llList2Integer(x, 2), llList2Integer(x, 3))) + "==";

// Xor with Base64(chr(0x36 xor 0x5C) * 64)
B64Key = llXorBase64StringsCorrect(B64Key, "ampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqampqag==");
x = Base64MD5Compress(B64Key, 1732584193, -271733879, -1732584194, 271733878, 0);
bit_length = 128;
return Base64MD5forHMAC(B64Data, bit_length, 512, llList2Integer(x, 0), llList2Integer(x, 1), llList2Integer(x, 2), llList2Integer(x, 3));
}

test_vector_MD5(string B64Key, string B64Data, string HexHash)
{
llResetTime();
string hmac = Base64_HMAC_MD5(B64Key, B64Data);
if (hmac != HexHash)
{
llOwnerSay("HMAC-MD5 test failed.\nComputed: " + hmac + "\nExpected : " + HexHash);
}
else
{
llOwnerSay("HMAC-MD5 test passed in " + (string)llGetTime() + " seconds.");
}
}

default
{
state_entry()
{
// RFC 2202 test vectors:
test_vector_MD5(HexToBase64Unpadded("0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b") + "==",
llStringToBase64("Hi There"),
"9294727a3638bb1c13f48ef8158bfc9d");
test_vector_MD5(llStringToBase64("Jefe"),
llStringToBase64("what do ya want for nothing?"),
"750c783e6ab0b503eaa86e310a5db738");
test_vector_MD5("qqqqqqqqqqqqqqqqqqqqqg==",
"3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d3d0=",
"56be34521d144c88dbb8c733f0e8b3f6");
test_vector_MD5(HexToBase64Unpadded("0102030405060708090a0b0c0d0e0f10111213141516171819")+"==",
HexToBase64Unpadded("cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd")+"=",
"697eaf0aca3a3aea3a75164746ffaa79");
test_vector_MD5(HexToBase64Unpadded("0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c") + "==",
llStringToBase64("Test With Truncation"),
"56461ef2342edc00f9bab995690efd4c");

string buf = "aaaaa";
buf += buf;
buf += buf;
buf += buf;
buf += buf;
buf += buf;
test_vector_MD5(HexToBase64Unpadded(buf) + "=",
llStringToBase64("Test Using Larger Than Block-Size Key - Hash Key First"),
"6b1ab7fe4bd7bf8f0b62e6ce61b9d0cd");
test_vector_MD5(HexToBase64Unpadded(buf) + "=",
llStringToBase64("Test Using Larger Than Block-Size Key and Larger Than One Block-Size Data"),
"6f630fad67cda0ee1fb1f562db3aa53e");

// Test vectors added by the author for zero-terminated data strings at different padding positions
// (generated with an independent program written in PHP):
test_vector_MD5("blah", "", "c10685c0953708077f6f4c7c5511ae53"); // ""
test_vector_MD5("blah", "AA==", "a761432a72606fd467aee08dd354d055"); // "\0"
test_vector_MD5("blah", "AAA=", "7ec1859fa4f3dc93557de5b6e0e6b579"); // "\0\0"
test_vector_MD5("blah", "AAAA", "daa25eabf94b653324a7d014bacf93ce"); // "\0\0\0"
test_vector_MD5("blah", "MQA=", "ed3a85846a50c499d0eee5789eb32f4d"); // "1\0"
test_vector_MD5("blah", "MQAA", "df9ebb2a9194f1ccc005016cd7b8d2c2"); // "1\0\0"
test_vector_MD5("blah", "MQAAAA==", "84106dafe40539b5b7d680cc05ee5836"); // "1\0\0\0"
test_vector_MD5("blah", "MTIA", "a2aaec505f58dc3267f39b7c1ad130ba"); // "12\0"
test_vector_MD5("blah", "MTIAAA==", "24b9ea69f29389136386c06632a0e4c2"); // "12\0\0"
test_vector_MD5("blah", "MTIAAAA=", "dbf936625759ada5eacc7f88f66ff20e"); // "12\0\0\0"
test_vector_MD5("blah", "MTIzAA==", "8f2b761ddcf87a60593bde245691b409"); // "123\0"
test_vector_MD5("blah", "MTIzAAA=", "9c196ba2c2dc1fa610800fd026e3f405"); // "123\0\0"
test_vector_MD5("blah", "MTIzAAAA", "a0331f1846fa6937347e62ec7414ee43"); // "123\0\0\0"

// Test vector added by the author
test_vector_MD5("", "", "74e6f7298a9c2d168935f58c001bad88");

// Test vectors added by the author to check for corner cases with the padding.
// Buffer exactly 54 bytes; needs 1+1 padding bytes, this should not be a problem.
test_vector_MD5("blah",
"012345670123456701234567012345670123456701234567012345670123",
"ed5accadc5138ea952d2cb519406f928");
// Buffer exactly 55 bytes; needs 1+0 padding bytes, this might be a problem if adding 0 bytes is a problem.
test_vector_MD5("blah",
"0123456701234567012345670123456701234567012345670123456701234A==",
"123d6892faec7f8d30844711b32be334");
// Buffer exactly 56 bytes; needs 1+7+56 padding bytes. Problematic only in case the detection of the corner case is flawed.
test_vector_MD5("blah",
"01234567012345670123456701234567012345670123456701234567012345A=",
"1651d80e8892463daa9aca2d0a9a2f76");
// Buffer exactly 63 bytes; needs 1+56 padding bytes. The first byte must be appended to the end of the buffer; the rest in the next buffer.
test_vector_MD5("blah",
"012345670123456701234567012345670123456701234567012345670123456701234567012345670123",
"3eb5654edd27e2441e7a521827ff6a77");
// Buffer exactly 64 bytes; needs 1+55 padding bytes added to the next buffer. Should not be a problem.
test_vector_MD5("blah",
"0123456701234567012345670123456701234567012345670123456701234567012345670123456701234A==",
"25fd54c13d95468e2f525163d7b6d63d");
llOwnerSay("End of tests.");
}
}
</source>

User:Pedro Oval/Mono code memory usage/CIL

2015-01-24T04:27:05Z

Pedro Oval: oops, LSL2, not LSL

Here's the CIL code generated by the script below, which gives some insight of what's happening under the hood.

Compilation was done using the viewer's built-in compiler as suggested by [[User:Becky Pippen/LSL Performance]]. Assembly was done using <code>ilasm</code> from the Mono suite.

Script that gets compiled:

<source lang="lsl2">
integer i;
u(){}

default
{
state_entry()
{
integer x;
integer y = 0;
integer z;
float f;
float g;
vector v;
list a;

;;;;;;;;;{{{{{{{{}}}}}}}}
return;
x;
(x);
(integer)x;
(float)x;
f;
(float)f;
(integer)f;
v;
v.z;
-x;
~x;
!x;
--x;
++x;
x--;
x++;
x=y;
x==y;
x=y=z;
f=x;
f=(float)x;
x!=y;
x+y;
x-y;
x+-y;
x*y;
x/y;
x%y;
x&y;
x&&y;
x|y;
x||y;
x^y;
x<<y;
x>>y;
x<y;
x>y;
x<=y;
x>=y;
x+=y;
x-=y;
x+=-y;
x*=y;
x/=y;
x%=y;
if (x) ;
if (x) ; else ;
0;
x^x;
1;
-1;
0xffffffff;
ALL_SIDES;
x|~x;
x+1;
-~x;
x-1;
x+-1;
~-x;
x*y+y-1;
(x+1)*y-1;
~(~x*y)
while (x) ;
do ; while (x);
for (;x;) ;
@label; if (x) jump label;
0.0;
f=0.0;
f=0;
<0.0, 0.0, 0.0>;
ZERO_VECTOR;
<0, 0, 0>;
<-1.0, -1.0, 0.0>;
TOUCH_INVALID_TEXCOORD;
<-1, -1, 0>;
<0xffffffff, 0xffffffff, 0>;
v+v;
v-v;
v*v;
v%v;
[];
a=[];
a+[x];
a+x;
[x]+a;
x+a;
[x];
[]+x;
(list)x;
[x,y];
[]+x+y;
(string)a;
i;
u();
}
}
</source>

Compiled and annotated result:

<pre>
.assembly extern mscorlib {.ver 1:0:5000:0}
.assembly extern LslLibrary {.ver 0:1:0:0}
.assembly extern LslUserScript {.ver 0:1:0:0}
.assembly extern ScriptTypes {.ver 0:1:0:0}
.assembly 'LSL_y' {.ver 0:0:0:0}
.class public auto ansi serializable beforefieldinit LSL_y extends [LslUserScript]LindenLab.SecondLife.LslUserScript
{
.field public int32 'i'
.method public hidebysig specialname rtspecialname instance default void .ctor () cil managed
{
.maxstack 500

// Globals initialization

// integer i;
02 ldarg.0
16 ldc.i4.0
7D 01 00 00 04 stfld int32 LSL_y::'i'

02 ldarg.0
28 01 00 00 0A call instance void [LslUserScript]LindenLab.SecondLife.LslUserScript::.ctor()
2A ret
}
.method public hidebysig instance default void 'gu'() cil managed
{
.maxstack 500
2A ret
}

.method public hidebysig instance default void edefaultstate_entry() cil managed
{
.maxstack 500
.locals init (int32, int32, int32, float32, float32, class [ScriptTypes]LindenLab.SecondLife.Vector, class [mscorlib]System.Collections.ArrayList)
// integer x;
16 ldc.i4.0
13 00 stloc.s 0

// integer y = 0;
20 00 00 00 00 ldc.i4 0
13 01 stloc.s 1

// integer z;
16 ldc.i4.0
13 02 stloc.s 2

// float f;
23 00 00 00 00 ldc.r8 0
00 00 00 00
13 03 stloc.s 3

// float g;
23 00 00 00 00 ldc.r8 0
00 00 00 00
13 04 stloc.s 4

// vector v;
23 00 00 00 00 ldc.r8 0
00 00 00 00
23 00 00 00 00 ldc.r8 0
00 00 00 00
23 00 00 00 00 ldc.r8 0
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
13 05 stloc.s 5

// list a;
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
13 06 stloc.s 6

// ;;; {{{ }}} generate no code

// return;
2A ret

// x;
11 00 ldloc.s 0
26 pop

// (x);
11 00 ldloc.s 0
26 pop

// (integer)x;
11 00 ldloc.s 0
26 pop

// (float)x;
11 00 ldloc.s 0
6C conv.r8
26 pop

// f;
11 03 ldloc.s 3
26 pop

// (float)f;
11 03 ldloc.s 3
26 pop

// (integer)f;
11 03 ldloc.s 3
28 04 00 00 0A call int32 [LslLibrary]LindenLab.SecondLife.LslRunTime::ToInteger(float32)
26 pop

// v;
11 05 ldloc.s 5
26 pop

// v.z;
12 05 ldloca.s 5
78 05 00 00 0A ldfld float32 class [ScriptTypes]LindenLab.SecondLife.Vector::z
26 pop

// -x;
11 00 ldloc.s 0
65 neg
26 pop

// ~x;
11 00 ldloc.s 0
66 not
26 pop

// !x;
11 00 ldloc.s 0
16 ldc.i4.0
FE 01 ceq
26 pop

// --x;
11 00 ldloc.s 0
17 ldc.i4.1
59 sub
25 dup
13 00 stloc.s 0
26 pop

// ++x;
11 00 ldloc.s 0
17 ldc.i4.1
58 add
25 dup
13 00 stloc.s 0
26 pop

// x--;
11 00 ldloc.s 0
11 00 ldloc.s 0
17 ldc.i4.1
59 sub
25 dup
13 00 stloc.s 0
26 pop
26 pop

// x++;
11 00 ldloc.s 0
11 00 ldloc.s 0
17 ldc.i4.1
58 add
25 dup
13 00 stloc.s 0
26 pop
26 pop

// x = y;
11 01 ldloc.s 1
25 dup
13 00 stloc.s 0
26 pop

// x == y;
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 01 ceq
26 pop

// x = y = z;
11 02 ldloc.s 2
25 dup
13 01 stloc.s 1
25 dup
13 00 stloc.s 0
26 pop

// f = x;
11 00 ldloc.s 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// f = (float)x;
11 00 ldloc.s 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// x != y; implemented as: !(x==y)
11 01 ldloc.s 1 // this part is x == y
11 00 ldloc.s 0
FE 01 ceq
16 ldc.i4.0 // this part is 'not'
FE 01 ceq
26 pop

// x + y;
11 01 ldloc.s 1
11 00 ldloc.s 0
58 add
26 pop

// x - y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// x + -y;
11 01 ldloc.s 1
65 neg
11 00 ldloc.s 0
58 add
26 pop

// x * y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
26 pop

// x / y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 07 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Divide(int32, int32)
26 pop

// x % y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 08 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Modulo(int32, int32)
26 pop

// x & y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5F and
26 pop

// x && y; implemented as: !(!x | !y)
11 01 ldloc.s 1 // !x
16 ldc.i4.0
FE 01 ceq
11 00 ldloc.s 0 // !y
16 ldc.i4.0
FE 01 ceq
60 or // !x | !y
16 ldc.i4.0 // !(!x | !y)
FE 01 ceq
26 pop

// x | y;
11 01 ldloc.s 1
11 00 ldloc.s 0
60 or
26 pop

// x || y; implemented as: !!(x | y)
11 01 ldloc.s 1 // x | y
11 00 ldloc.s 0
60 or
16 ldc.i4.0 // !(x | y)
FE 01 ceq
16 ldc.i4.0 // !!(x | y)
FE 01 ceq
26 pop

// x ^ y;
11 01 ldloc.s 1
11 00 ldloc.s 0
61 xor
26 pop

// x << y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 09 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::ShiftLeft(int32, int32)
26 pop

// x >> y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 0A 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::ShiftRight(int32, int32)
26 pop

// x < y; implemented as: y > x
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 02 cgt
26 pop

// x > y; implemented as: y < x;
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 04 clt
26 pop

// x <= y; implemented as: !(y < x)
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 04 clt
16 ldc.i4.0
FE 01 ceq
26 pop

// x >= y; implemented as: !(y > x)
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 02 cgt
16 ldc.i4.0
FE 01 ceq
26 pop

// x += y;
11 01 ldloc.s 1
11 00 ldloc.s 0
58 add
25 dup
13 00 stloc.s 0
26 pop

// x -= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// x += -y;
11 01 ldloc.s 1
65 neg
11 00 ldloc.s 0
58 add
25 dup
13 00 stloc.s 0
26 pop

// x *= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
25 dup
13 00 stloc.s 0
26 pop

// x /= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 07 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Divide(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// x %= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 08 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Modulo(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// if (x) ;
11 00 ldloc.s 0
39 00 00 00 00 brfalse LabelTempJump0
// THEN branch code goes here
LabelTempJump0:

// if (x) ; else ;
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump1
// THEN branch code would go here
38 00 00 00 00 br LabelTempJump2
// ELSE branch code would go here
LabelTempJump1:
LabelTempJump2:

// 0;
20 00 00 00 00 ldc.i4 0
26 pop

// x ^ x;
11 00 ldloc.s 0
11 00 ldloc.s 0
61 xor
26 pop

// 1;
20 01 00 00 00 ldc.i4 1
26 pop

// -1; note the negative sign takes code memory
20 01 00 00 00 ldc.i4 1
65 neg
26 pop

// 0xffffffff; note it equals -1 without the sign taking memory
20 FF FF FF FF ldc.i4 -1
26 pop

// ALL_SIDES; ditto
20 FF FF FF FF ldc.i4 -1
26 pop

// x | ~x;
11 00 ldloc.s 0
66 not
11 00 ldloc.s 0
60 or
26 pop

// x + 1;
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
58 add
26 pop

// -~x;
11 00 ldloc.s 0
66 not
65 neg
26 pop

// x - 1;
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// x + -1;
20 01 00 00 00 ldc.i4 1
65 neg
11 00 ldloc.s 0
58 add
26 pop

// ~-x;
11 00 ldloc.s 0
65 neg
66 not
26 pop

// x*y + y - 1;
20 01 00 00 00 ldc.i4 1
11 01 ldloc.s 1
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
58 add
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// (x + 1)*y - 1;
20 01 00 00 00 ldc.i4 1
11 01 ldloc.s 1
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
58 add
5A mul
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// ~(~x*y);
11 01 ldloc.s 1
11 00 ldloc.s 0
66 not
5A mul
66 not
26 pop

// while (x) ;
LabelTempJump3:
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump4
// Looped code would go here
38 F4 FF FF FF br LabelTempJump3
LabelTempJump4:

// do ; while (x);
LabelTempJump5:
// Looped code would go here
11 00 ldloc.s 0
3A F9 FF FF FF brtrue LabelTempJump5

// for (; x; ) ;
LabelTempJump6:
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump7
// Looped code would go here
38 F4 FF FF FF br LabelTempJump6
LabelTempJump7:

// @label; if (x) jump label;
'label':
// Looped code would go here
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump8
38 F4 FF FF FF br 'label'
LabelTempJump8:

// 0.0;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
26 pop

// f = 0.0;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
25 dup
13 03 stloc.s 3
26 pop

// f = 0;
20 00 00 00 00 ldc.i4 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// <0.0, 0.0, 0.0>;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// ZERO_VECTOR;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <0, 0, 0>;
20 00 00 00 00 ldc.i4 0
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <-1.0, -1.0, 0.0>;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 3f)
00 00 F0 3F
65 neg
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 3f)
00 00 F0 3F
65 neg
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// TOUCH_INVALID_TEXCOORD;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 bf)
00 00 F0 BF
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 bf)
00 00 F0 BF
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <-1, -1, 0>;
20 01 00 00 00 ldc.i4 1
65 neg
6C conv.r8
20 01 00 00 00 ldc.i4 1
65 neg
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <0xffffffff, 0xffffffff, 0>;
20 FF FF FF FF ldc.i4 -1
6C conv.r8
20 FF FF FF FF ldc.i4 -1
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// v + v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0B 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Add'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v - v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0C 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Subtract'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v * v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0D 00 00 0A call float32 class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Multiply'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v % v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0E 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Modulo'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// [];
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
26 pop

// a = [];
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
25 dup
13 06 stloc.s 6
26 pop

// a + [x];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
11 06 ldloc.s 6
28 10 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(class [mscorlib]System.Collections.ArrayList, class [mscorlib]System.Collections.ArrayList)
26 pop

// a + x;
11 00 ldloc.s 0
11 06 ldloc.s 6
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// [x] + a;
11 06 ldloc.s 6
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
28 10 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(class [mscorlib]System.Collections.ArrayList, class [mscorlib]System.Collections.ArrayList)
26 pop

// x + a;
11 06 ldloc.s 6
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 12 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(class [mscorlib]System.Collections.ArrayList, object)
26 pop

// [x];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
26 pop

// []+x;
11 00 ldloc.s 0
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// (list)x;
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 13 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList(object)
26 pop

// [x, y];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
11 01 ldloc.s 1
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
26 pop

// []+x+y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// (string)a;
11 06 ldloc.s 6
28 14 00 00 0A call string [LslLibrary]LindenLab.SecondLife.LslRunTime::ListToString(class [mscorlib]System.Collections.ArrayList)
26 pop

// i;
02 ldarg.0
7B 01 00 00 04 ldfld int32 LSL_y::'i'
26 pop

// u();
02 ldarg.0
28 02 00 00 06 call instance void class LSL_y::'gu'()

// end of event
2A ret
}

}
</pre>

===== Important notes: =====

* <code>ldloc.s 0</code> (opcode 11, argument 00) is probably contracted to the abbreviation <code>ldloc.0</code> (opcode 06) at assembly time, resulting in the length of 2 obtained in the [[User:Pedro Oval/Mono code memory usage|memory usage tests]]. Or possibly the server-side compiler added an optimization of this case (!). Either way, the evidence for this is confirmed by the fact that <code>x;</code> takes 2 bytes if it's one of the first four local variables (there are 1-byte opcodes for ldloc.0 through ldloc.3), and 3 bytes otherwise. This applies to all appearances of this opcode and the similar <code>stloc.s</code>.
* Local variable definitions seem to take a variable and big number of bytes (averaging about 47 bytes for local integers) if there is a function call anywhere in the event in which they are defined. Reason unknown.
* Backward jumps seem to take many more bytes than what the CIL result above suggests. Forward jumps, however, seem predictable enough.
* As things are now, having more than 256 local variables in a single function or event causes wraparound, making the 257th be an alias to the 1st, and so on. If they aren't the same type, the script crashes at runtime with an uncaught exception. That's a consequence of using <code>ldloc.s</code> / <code>stloc.s</code> without switching to the long version (<code>ldloc</code> / <code>stloc</code>) when the argument is greater than 255.

===== Additional memory usage notes: =====
* Global variable, function, and function parameter names do take code memory from the script (as part of some symbol table). Fortunately they take 1 byte per character only, as opposed to Mono strings, which take at least 2 bytes per character (they are UTF-16). That extra code is only taken once per variable, regardless of how many times it is used.
* In addition to the state code and state change command code, the state names themselves take code memory from the script, as follows:
** The state name by itself takes no code memory, but internally, each event name includes the state name. The internal name for the event is e.g. <code>edefaultstate_entry</code> (for state <code>default</code>, event <code>state_entry</code>), <code>eblahtimer</code> (for state blah, event <code>timer</code>). These names take 1 byte per character.
** If a state switch statement appears in the code, the state name takes additionally 2 bytes per character. (But these strings are reused, so multiple state switch statements don't take additional space for the strings.)

Although not mentioned above, every single-byte string needs an additional terminating zero byte, and every UTF-16 string needs an additional length prefix byte (or more if longer than 127 bytes, i.e. 63 characters if in the ASCII range) plus an additional terminating zero byte.

User:Pedro Oval/Mono code memory usage/CIL

2015-01-24T04:26:03Z

Pedro Oval: <lsl> to <source>

Here's the CIL code generated by the script below, which gives some insight of what's happening under the hood.

Compilation was done using the viewer's built-in compiler as suggested by [[User:Becky Pippen/LSL Performance]]. Assembly was done using <code>ilasm</code> from the Mono suite.

Script that gets compiled:

<source lang="lsl">
integer i;
u(){}

default
{
state_entry()
{
integer x;
integer y = 0;
integer z;
float f;
float g;
vector v;
list a;

;;;;;;;;;{{{{{{{{}}}}}}}}
return;
x;
(x);
(integer)x;
(float)x;
f;
(float)f;
(integer)f;
v;
v.z;
-x;
~x;
!x;
--x;
++x;
x--;
x++;
x=y;
x==y;
x=y=z;
f=x;
f=(float)x;
x!=y;
x+y;
x-y;
x+-y;
x*y;
x/y;
x%y;
x&y;
x&&y;
x|y;
x||y;
x^y;
x<<y;
x>>y;
x<y;
x>y;
x<=y;
x>=y;
x+=y;
x-=y;
x+=-y;
x*=y;
x/=y;
x%=y;
if (x) ;
if (x) ; else ;
0;
x^x;
1;
-1;
0xffffffff;
ALL_SIDES;
x|~x;
x+1;
-~x;
x-1;
x+-1;
~-x;
x*y+y-1;
(x+1)*y-1;
~(~x*y)
while (x) ;
do ; while (x);
for (;x;) ;
@label; if (x) jump label;
0.0;
f=0.0;
f=0;
<0.0, 0.0, 0.0>;
ZERO_VECTOR;
<0, 0, 0>;
<-1.0, -1.0, 0.0>;
TOUCH_INVALID_TEXCOORD;
<-1, -1, 0>;
<0xffffffff, 0xffffffff, 0>;
v+v;
v-v;
v*v;
v%v;
[];
a=[];
a+[x];
a+x;
[x]+a;
x+a;
[x];
[]+x;
(list)x;
[x,y];
[]+x+y;
(string)a;
i;
u();
}
}
</source>

Compiled and annotated result:

<pre>
.assembly extern mscorlib {.ver 1:0:5000:0}
.assembly extern LslLibrary {.ver 0:1:0:0}
.assembly extern LslUserScript {.ver 0:1:0:0}
.assembly extern ScriptTypes {.ver 0:1:0:0}
.assembly 'LSL_y' {.ver 0:0:0:0}
.class public auto ansi serializable beforefieldinit LSL_y extends [LslUserScript]LindenLab.SecondLife.LslUserScript
{
.field public int32 'i'
.method public hidebysig specialname rtspecialname instance default void .ctor () cil managed
{
.maxstack 500

// Globals initialization

// integer i;
02 ldarg.0
16 ldc.i4.0
7D 01 00 00 04 stfld int32 LSL_y::'i'

02 ldarg.0
28 01 00 00 0A call instance void [LslUserScript]LindenLab.SecondLife.LslUserScript::.ctor()
2A ret
}
.method public hidebysig instance default void 'gu'() cil managed
{
.maxstack 500
2A ret
}

.method public hidebysig instance default void edefaultstate_entry() cil managed
{
.maxstack 500
.locals init (int32, int32, int32, float32, float32, class [ScriptTypes]LindenLab.SecondLife.Vector, class [mscorlib]System.Collections.ArrayList)
// integer x;
16 ldc.i4.0
13 00 stloc.s 0

// integer y = 0;
20 00 00 00 00 ldc.i4 0
13 01 stloc.s 1

// integer z;
16 ldc.i4.0
13 02 stloc.s 2

// float f;
23 00 00 00 00 ldc.r8 0
00 00 00 00
13 03 stloc.s 3

// float g;
23 00 00 00 00 ldc.r8 0
00 00 00 00
13 04 stloc.s 4

// vector v;
23 00 00 00 00 ldc.r8 0
00 00 00 00
23 00 00 00 00 ldc.r8 0
00 00 00 00
23 00 00 00 00 ldc.r8 0
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
13 05 stloc.s 5

// list a;
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
13 06 stloc.s 6

// ;;; {{{ }}} generate no code

// return;
2A ret

// x;
11 00 ldloc.s 0
26 pop

// (x);
11 00 ldloc.s 0
26 pop

// (integer)x;
11 00 ldloc.s 0
26 pop

// (float)x;
11 00 ldloc.s 0
6C conv.r8
26 pop

// f;
11 03 ldloc.s 3
26 pop

// (float)f;
11 03 ldloc.s 3
26 pop

// (integer)f;
11 03 ldloc.s 3
28 04 00 00 0A call int32 [LslLibrary]LindenLab.SecondLife.LslRunTime::ToInteger(float32)
26 pop

// v;
11 05 ldloc.s 5
26 pop

// v.z;
12 05 ldloca.s 5
78 05 00 00 0A ldfld float32 class [ScriptTypes]LindenLab.SecondLife.Vector::z
26 pop

// -x;
11 00 ldloc.s 0
65 neg
26 pop

// ~x;
11 00 ldloc.s 0
66 not
26 pop

// !x;
11 00 ldloc.s 0
16 ldc.i4.0
FE 01 ceq
26 pop

// --x;
11 00 ldloc.s 0
17 ldc.i4.1
59 sub
25 dup
13 00 stloc.s 0
26 pop

// ++x;
11 00 ldloc.s 0
17 ldc.i4.1
58 add
25 dup
13 00 stloc.s 0
26 pop

// x--;
11 00 ldloc.s 0
11 00 ldloc.s 0
17 ldc.i4.1
59 sub
25 dup
13 00 stloc.s 0
26 pop
26 pop

// x++;
11 00 ldloc.s 0
11 00 ldloc.s 0
17 ldc.i4.1
58 add
25 dup
13 00 stloc.s 0
26 pop
26 pop

// x = y;
11 01 ldloc.s 1
25 dup
13 00 stloc.s 0
26 pop

// x == y;
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 01 ceq
26 pop

// x = y = z;
11 02 ldloc.s 2
25 dup
13 01 stloc.s 1
25 dup
13 00 stloc.s 0
26 pop

// f = x;
11 00 ldloc.s 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// f = (float)x;
11 00 ldloc.s 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// x != y; implemented as: !(x==y)
11 01 ldloc.s 1 // this part is x == y
11 00 ldloc.s 0
FE 01 ceq
16 ldc.i4.0 // this part is 'not'
FE 01 ceq
26 pop

// x + y;
11 01 ldloc.s 1
11 00 ldloc.s 0
58 add
26 pop

// x - y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// x + -y;
11 01 ldloc.s 1
65 neg
11 00 ldloc.s 0
58 add
26 pop

// x * y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
26 pop

// x / y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 07 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Divide(int32, int32)
26 pop

// x % y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 08 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Modulo(int32, int32)
26 pop

// x & y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5F and
26 pop

// x && y; implemented as: !(!x | !y)
11 01 ldloc.s 1 // !x
16 ldc.i4.0
FE 01 ceq
11 00 ldloc.s 0 // !y
16 ldc.i4.0
FE 01 ceq
60 or // !x | !y
16 ldc.i4.0 // !(!x | !y)
FE 01 ceq
26 pop

// x | y;
11 01 ldloc.s 1
11 00 ldloc.s 0
60 or
26 pop

// x || y; implemented as: !!(x | y)
11 01 ldloc.s 1 // x | y
11 00 ldloc.s 0
60 or
16 ldc.i4.0 // !(x | y)
FE 01 ceq
16 ldc.i4.0 // !!(x | y)
FE 01 ceq
26 pop

// x ^ y;
11 01 ldloc.s 1
11 00 ldloc.s 0
61 xor
26 pop

// x << y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 09 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::ShiftLeft(int32, int32)
26 pop

// x >> y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 0A 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::ShiftRight(int32, int32)
26 pop

// x < y; implemented as: y > x
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 02 cgt
26 pop

// x > y; implemented as: y < x;
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 04 clt
26 pop

// x <= y; implemented as: !(y < x)
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 04 clt
16 ldc.i4.0
FE 01 ceq
26 pop

// x >= y; implemented as: !(y > x)
11 01 ldloc.s 1
11 00 ldloc.s 0
FE 02 cgt
16 ldc.i4.0
FE 01 ceq
26 pop

// x += y;
11 01 ldloc.s 1
11 00 ldloc.s 0
58 add
25 dup
13 00 stloc.s 0
26 pop

// x -= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// x += -y;
11 01 ldloc.s 1
65 neg
11 00 ldloc.s 0
58 add
25 dup
13 00 stloc.s 0
26 pop

// x *= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
25 dup
13 00 stloc.s 0
26 pop

// x /= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 07 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Divide(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// x %= y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 08 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Modulo(int32, int32)
25 dup
13 00 stloc.s 0
26 pop

// if (x) ;
11 00 ldloc.s 0
39 00 00 00 00 brfalse LabelTempJump0
// THEN branch code goes here
LabelTempJump0:

// if (x) ; else ;
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump1
// THEN branch code would go here
38 00 00 00 00 br LabelTempJump2
// ELSE branch code would go here
LabelTempJump1:
LabelTempJump2:

// 0;
20 00 00 00 00 ldc.i4 0
26 pop

// x ^ x;
11 00 ldloc.s 0
11 00 ldloc.s 0
61 xor
26 pop

// 1;
20 01 00 00 00 ldc.i4 1
26 pop

// -1; note the negative sign takes code memory
20 01 00 00 00 ldc.i4 1
65 neg
26 pop

// 0xffffffff; note it equals -1 without the sign taking memory
20 FF FF FF FF ldc.i4 -1
26 pop

// ALL_SIDES; ditto
20 FF FF FF FF ldc.i4 -1
26 pop

// x | ~x;
11 00 ldloc.s 0
66 not
11 00 ldloc.s 0
60 or
26 pop

// x + 1;
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
58 add
26 pop

// -~x;
11 00 ldloc.s 0
66 not
65 neg
26 pop

// x - 1;
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// x + -1;
20 01 00 00 00 ldc.i4 1
65 neg
11 00 ldloc.s 0
58 add
26 pop

// ~-x;
11 00 ldloc.s 0
65 neg
66 not
26 pop

// x*y + y - 1;
20 01 00 00 00 ldc.i4 1
11 01 ldloc.s 1
11 01 ldloc.s 1
11 00 ldloc.s 0
5A mul
58 add
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// (x + 1)*y - 1;
20 01 00 00 00 ldc.i4 1
11 01 ldloc.s 1
20 01 00 00 00 ldc.i4 1
11 00 ldloc.s 0
58 add
5A mul
28 06 00 00 0A call int32 [LslUserScript]LindenLab.SecondLife.LslUserScript::Subtract(int32, int32)
26 pop

// ~(~x*y);
11 01 ldloc.s 1
11 00 ldloc.s 0
66 not
5A mul
66 not
26 pop

// while (x) ;
LabelTempJump3:
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump4
// Looped code would go here
38 F4 FF FF FF br LabelTempJump3
LabelTempJump4:

// do ; while (x);
LabelTempJump5:
// Looped code would go here
11 00 ldloc.s 0
3A F9 FF FF FF brtrue LabelTempJump5

// for (; x; ) ;
LabelTempJump6:
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump7
// Looped code would go here
38 F4 FF FF FF br LabelTempJump6
LabelTempJump7:

// @label; if (x) jump label;
'label':
// Looped code would go here
11 00 ldloc.s 0
39 05 00 00 00 brfalse LabelTempJump8
38 F4 FF FF FF br 'label'
LabelTempJump8:

// 0.0;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
26 pop

// f = 0.0;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
25 dup
13 03 stloc.s 3
26 pop

// f = 0;
20 00 00 00 00 ldc.i4 0
6C conv.r8
25 dup
13 03 stloc.s 3
26 pop

// <0.0, 0.0, 0.0>;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// ZERO_VECTOR;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <0, 0, 0>;
20 00 00 00 00 ldc.i4 0
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <-1.0, -1.0, 0.0>;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 3f)
00 00 F0 3F
65 neg
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 3f)
00 00 F0 3F
65 neg
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// TOUCH_INVALID_TEXCOORD;
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 bf)
00 00 F0 BF
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 f0 bf)
00 00 F0 BF
23 00 00 00 00 ldc.r8 (00 00 00 00 00 00 00 00)
00 00 00 00
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <-1, -1, 0>;
20 01 00 00 00 ldc.i4 1
65 neg
6C conv.r8
20 01 00 00 00 ldc.i4 1
65 neg
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// <0xffffffff, 0xffffffff, 0>;
20 FF FF FF FF ldc.i4 -1
6C conv.r8
20 FF FF FF FF ldc.i4 -1
6C conv.r8
20 00 00 00 00 ldc.i4 0
6C conv.r8
28 02 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'CreateVector'(float32, float32, float32)
26 pop

// v + v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0B 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Add'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v - v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0C 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Subtract'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v * v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0D 00 00 0A call float32 class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Multiply'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// v % v;
11 05 ldloc.s 5
11 05 ldloc.s 5
28 0E 00 00 0A call class [ScriptTypes]LindenLab.SecondLife.Vector class [LslUserScript]LindenLab.SecondLife.LslUserScript::'Modulo'(class [ScriptTypes]LindenLab.SecondLife.Vector, class [ScriptTypes]LindenLab.SecondLife.Vector)
26 pop

// [];
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
26 pop

// a = [];
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
25 dup
13 06 stloc.s 6
26 pop

// a + [x];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
11 06 ldloc.s 6
28 10 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(class [mscorlib]System.Collections.ArrayList, class [mscorlib]System.Collections.ArrayList)
26 pop

// a + x;
11 00 ldloc.s 0
11 06 ldloc.s 6
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// [x] + a;
11 06 ldloc.s 6
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
28 10 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(class [mscorlib]System.Collections.ArrayList, class [mscorlib]System.Collections.ArrayList)
26 pop

// x + a;
11 06 ldloc.s 6
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 12 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(class [mscorlib]System.Collections.ArrayList, object)
26 pop

// [x];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
26 pop

// []+x;
11 00 ldloc.s 0
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// (list)x;
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
28 13 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList(object)
26 pop

// [x, y];
11 00 ldloc.s 0
8C 01 00 00 1B box [mscorlib]System.Int32
11 01 ldloc.s 1
8C 01 00 00 1B box [mscorlib]System.Int32
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
28 0F 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Prepend(object, class [mscorlib]System.Collections.ArrayList)
26 pop

// []+x+y;
11 01 ldloc.s 1
11 00 ldloc.s 0
28 03 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::CreateList()
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
28 11 00 00 0A call class [mscorlib]System.Collections.ArrayList class [LslUserScript]LindenLab.SecondLife.LslUserScript::Append(int32, class [mscorlib]System.Collections.ArrayList)
26 pop

// (string)a;
11 06 ldloc.s 6
28 14 00 00 0A call string [LslLibrary]LindenLab.SecondLife.LslRunTime::ListToString(class [mscorlib]System.Collections.ArrayList)
26 pop

// i;
02 ldarg.0
7B 01 00 00 04 ldfld int32 LSL_y::'i'
26 pop

// u();
02 ldarg.0
28 02 00 00 06 call instance void class LSL_y::'gu'()

// end of event
2A ret
}

}
</pre>

===== Important notes: =====

* <code>ldloc.s 0</code> (opcode 11, argument 00) is probably contracted to the abbreviation <code>ldloc.0</code> (opcode 06) at assembly time, resulting in the length of 2 obtained in the [[User:Pedro Oval/Mono code memory usage|memory usage tests]]. Or possibly the server-side compiler added an optimization of this case (!). Either way, the evidence for this is confirmed by the fact that <code>x;</code> takes 2 bytes if it's one of the first four local variables (there are 1-byte opcodes for ldloc.0 through ldloc.3), and 3 bytes otherwise. This applies to all appearances of this opcode and the similar <code>stloc.s</code>.
* Local variable definitions seem to take a variable and big number of bytes (averaging about 47 bytes for local integers) if there is a function call anywhere in the event in which they are defined. Reason unknown.
* Backward jumps seem to take many more bytes than what the CIL result above suggests. Forward jumps, however, seem predictable enough.
* As things are now, having more than 256 local variables in a single function or event causes wraparound, making the 257th be an alias to the 1st, and so on. If they aren't the same type, the script crashes at runtime with an uncaught exception. That's a consequence of using <code>ldloc.s</code> / <code>stloc.s</code> without switching to the long version (<code>ldloc</code> / <code>stloc</code>) when the argument is greater than 255.

===== Additional memory usage notes: =====
* Global variable, function, and function parameter names do take code memory from the script (as part of some symbol table). Fortunately they take 1 byte per character only, as opposed to Mono strings, which take at least 2 bytes per character (they are UTF-16). That extra code is only taken once per variable, regardless of how many times it is used.
* In addition to the state code and state change command code, the state names themselves take code memory from the script, as follows:
** The state name by itself takes no code memory, but internally, each event name includes the state name. The internal name for the event is e.g. <code>edefaultstate_entry</code> (for state <code>default</code>, event <code>state_entry</code>), <code>eblahtimer</code> (for state blah, event <code>timer</code>). These names take 1 byte per character.
** If a state switch statement appears in the code, the state name takes additionally 2 bytes per character. (But these strings are reused, so multiple state switch statements don't take additional space for the strings.)

Although not mentioned above, every single-byte string needs an additional terminating zero byte, and every UTF-16 string needs an additional length prefix byte (or more if longer than 127 bytes, i.e. 63 characters if in the ASCII range) plus an additional terminating zero byte.

Talk:LlGetNumberOfSides

2014-10-04T12:47:31Z

Pedro Oval: Confirm and refine finding

Threshold of cut to detect its lips: for instance a cube , hollow 0.95, the cut must be smaller than 0.99. I have not checked the full rules, but it would be nice this to be specified somewhere[[User:Sigma Avro|Sigma Avro]] 22:23, 2 October 2014 (PDT)

:Hollow doesn't matter. I can confirm that the server won't create new faces unless <code>cut_end - cut_begin < 0.99</code>. That's an approximate rule, as <code>cut_begin = 0.000001</code> and <code>cut_end = 0.99</code> will ''not'' create a new face anyway, even if they meet the condition (not sure why, maybe the server is rounding values too close to zero or one). The viewer, on the other hand, won't create new faces unless <code>llRound(cut_end*65536) - llRound(cut_begin*65536) < 64880</code>; that formula makes sense because PathBegin and PathEnd are 16-bit unsigned elements when transmitted to the viewer through an [[ObjectUpdate]] message. --[[User:Pedro Oval|Pedro Oval]] 05:47, 4 October 2014 (PDT)

LlTargetOmega Replacement

2014-10-04T11:15:12Z

Pedro Oval: Style

{{LSL_Function
|func=KeyFramedOmega
|func_id
|func_sleep
|func_energy
|func_desc=Rotates the object/prim around axis at a rate of spinrate in radians per second
|func_footnote
|return_type
|return_text
|p1_type=vector
|p1_name=axis
|p1_desc=arbitrary axis to rotate the object around
|p1_hover
|p2_type=float
|p2_name=spinrate
|p2_desc=rate of rotation in radians per second
|p2_hover
|constants
|spec=
* This doesn't make [[llTargetOmega]] redundant but in some cases a Key Framed motion may be preferred
* The routine: "KeyFramedOmega" is easy to use for [[llTargetOmega]]: It takes the first two parameters in [[llTargetOmega]]: axis and spinrate
* All viewers will see the same spin and rotation
* The object will keep the rotation it has when spin is stopped
* A spin will continue even when the script is deleted
|caveats=
* The script must be in the root prim
* It can not spin child prims
* The object must be convex hull physics type
* Can not spin physical objects
* If the center of mass is not at the center of the root, the object will shake and jerk and drift erratically ([https://jira.secondlife.com/browse/BUG-7266 BUG-7266])
|examples=
This script shows how to use the routine to start, stop and reverse a spin on repeated touches
<lsl>
// llTargetOmega substitution by Dora Gustafson, Studio Dora 2014

integer P;

KeyFramedOmega( vector axis, float spinrate)
{
llSetKeyframedMotion( [], []);
if ( spinrate )
{
float v = TWO_PI/3.0;
if ( spinrate < 0 ) v = -v;
list L = [llAxisAngle2Rot( axis/llGetRot(), v), v/spinrate];
llSetKeyframedMotion( L+L+L, [KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_LOOP]);
}
}

default
{
state_entry()
{
llSetPrimitiveParams([PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);
}
touch_end( integer n)
{
P = ++P%4;
if ( P == 1 ) KeyFramedOmega( <0,0,1>, 2.0); // Positive spin
else if ( P == 3 ) KeyFramedOmega( <0,0,1>, -2.0); // Negative spin
else KeyFramedOmega( <0,0,1>, 0.0); // Stop spin
}
}
</lsl>
|helpers
|also_header
|also_functions=: [[llTargetOmega]]
: [[llSetKeyframedMotion]]
|also_tests
|also_events
|also_articles
|also_footer
|notes=The magnitude of ''axis'' do '''not''' influence the ''spinrate''
|mode=user
|deprecated
|location=[[User:Dora_Gustafson/Replacing_llTargetOmega/function|The Function]]
|cat1=Rotation
|cat2=Examples
|signature=[[User:Dora Gustafson|Dora Gustafson]] 04:36, 12 August 2014 (PDT)
}}

LlTargetOmega Replacement

2014-10-01T17:32:53Z

Pedro Oval: Bug caveat

{{LSL_Function
|func=KeyFramedOmega
|func_id
|func_sleep
|func_energy
|func_desc=Rotates the object/prim around axis at a rate of spinrate in radians per second
|func_footnote
|return_type
|return_text
|p1_type=vector
|p1_name=axis
|p1_desc=arbitrary axis to rotate the object around
|p1_hover
|p2_type=float
|p2_name=spinrate
|p2_desc=rate of rotation in radians per second
|p2_hover
|constants
|spec=
: This doesn't make [[llTargetOmega]] redundant but in some cases a Key Framed motion may be preferred
: The routine: "KeyFramedOmega" is easy to use for [[llTargetOmega]]: It takes the first two parameters in [[llTargetOmega]]: axis and spinrate
: All viewers will see the same spin and rotation
: The object will keep the rotation it has when spin is stopped
: A spin will continue even when the script is deleted
|caveats=
: The script must be in the root prim
: It can not spin child prims
: The object must be convex hull physics type
: Can not spin physical objects
: If the center of mass is not at the center of the root, the object will shake and jerk and drift erratically ([https://jira.secondlife.com/browse/BUG-7266 BUG-7266])
|examples=
This script shows how to use the routine to start, stop and reverse a spin on repeated touches
<lsl>
// llTargetOmega substitution by Dora Gustafson, Studio Dora 2014

integer P;

KeyFramedOmega( vector axis, float spinrate)
{
llSetKeyframedMotion( [], []);
if ( spinrate )
{
float v = TWO_PI/3.0;
if ( spinrate < 0 ) v = -v;
list L = [llAxisAngle2Rot( axis/llGetRot(), v), v/spinrate];
llSetKeyframedMotion( L+L+L, [KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_LOOP]);
}
}

default
{
state_entry()
{
llSetPrimitiveParams([PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);
}
touch_end( integer n)
{
P = ++P%4;
if ( P == 1 ) KeyFramedOmega( <0,0,1>, 2.0); // Positive spin
else if ( P == 3 ) KeyFramedOmega( <0,0,1>, -2.0); // Negative spin
else KeyFramedOmega( <0,0,1>, 0.0); // Stop spin
}
}
</lsl>
|helpers
|also_header
|also_functions=: [[llTargetOmega]]
: [[llSetKeyframedMotion]]
|also_tests
|also_events
|also_articles
|also_footer
|notes=The magnitude of ''axis'' do '''not''' influence the ''spinrate''
|mode=user
|deprecated
|location=[[User:Dora_Gustafson/Replacing_llTargetOmega/function|The Function]]
|cat1=Rotation
|cat2=Examples
|signature=[[User:Dora Gustafson|Dora Gustafson]] 04:36, 12 August 2014 (PDT)
}}

Talk:UTF-8

2014-10-01T17:22:45Z

Pedro Oval: /* Testing and Usage */ On the gritty little details

== Testing and Usage ==

Yeah I always stayed away from the weird ranges. These functions were mostly written with LSO in mind, and LSO did no special conversions. LSO was happy with 6 byte character codes (old UTF-8). Mono is another thing altogether. The only testing I did for Mono was to make sure it compiled correctly and the logic executed the same. I did not do the extensive testing for Mono that I did for LSO. For LSO these functions were pretty much mirrors but I always tested the range of characters I was going to be using to make sure, and I always stayed away from ranges that do things.

Should I make a version for surrogate pairs? (on second thought do I want to learn enough about surrogate pairs to write a function for them?) -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:08, 29 September 2014 (PDT)

:LSO uses byte strings and does not care about the validity of the Unicode codepoints they represent. You can even store an incomplete UTF-8 sequence such as <code>llUnescapeURL("%C3")</code> in LSO. For that reason, the conversion to/from integer is safe in LSO, being able to encode every code point between U+0001 and U+7FFFFFFF. This line works fine under LSO, proving the conversion is working flawlessly: <code>llOwnerSay((string)UTF8ToUnicodeInteger(UnicodeIntegerToUTF8(0x7FFFFFFF)));</code> displays 2147483647 as expected. Surrogates and U+FFFE are encoded and decoded without problems.
:Mono, on the other hand, uses UTF-16 internally for its strings, and respects Unicode rules with respect to validity. Thus surrogates and U+FFFE are invalid.
:I don't know how "a version for surrogate pairs" would look like. I don't see how a function can be made to work under Mono that allows mapping of the range U+D800-U+DFFF to a two-byte character in UTF-16 losslessly. Or that would allow the range above 0x10FFFF to be mapped to a valid Unicode string, for the matter. At least not without using escapes, i.e. reinventing the wheel. For the record, a UTF-8 sequence that would produce a surrogate (e.g. <code>llUnescapeURL("%ED%A0%80")</code>) translates to "???" in Mono. --[[User:Pedro Oval|Pedro Oval]] 03:40, 30 September 2014 (PDT)

::I'm really ok with you documenting every gritty little detail of Mono and where these functions fail. Seriously, please do. Its interesting stuff. You might, if you haven't already, want to look at how Mono implemented its string libraries. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:26, 30 September 2014 (PDT)

:::For the record, it's not what I intended to do. I was tempted to remove the whole section added by Ollj Oh, but decided to try to salvage the part that was not misleading and was perhaps useful. --[[User:Pedro Oval|Pedro Oval]] 10:22, 1 October 2014 (PDT)

UTF-8

2014-10-01T17:15:33Z

Pedro Oval: /* Limits under Mono */ Minor nitpick

{{LSL Header}}{{LSLC|User-Defined_Functions}}
Second Life uses {{Wikipedia|UTF-8|UTF-8}} for storing and transmitting [[String|strings]] and with these functions you can work with {{Wikipedia|Unicode|Unicode}} characters. See: [[Unicode In 5 Minutes]] for a brief introduction to {{Wikipedia|Unicode|Unicode}}.

These functions are part of the [[Combined Library]] written by {{User|Strife Onizuka}}.

== Limits under Mono ==

One of the side effects of using the Mono VM is that the string encoding used is not the archaic version of UTF-8 that the LSO VM uses, but instead is a much later version of UTF-16. The important difference is that some ranges of values that could be encoded in the old UTF-8 are not well supported in Mono's UTF-16 implementation. This means some values that worked with these functions in LSO, will not work under Mono.

Unless you are using these functions to pack data in strings you are unlikely to ever need to know or worry about this.

Some background: Unicode predominately contains simple characters. However some Unicode values do not represent characters but have special meaning within the Unicode Specification. Under Mono these results in one or more question marks ("?"). UnicodeIntegerToUTF8 and UTF8ToUnicodeInteger work perfectly for the simple characters; however not so well for the other values. More on these ranges can be found in the [http://unicode.org Unicode] specification and [http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29 Specials (Unicode block)]. While LSO doesn't care about these limitations, Mono does.

The following integer ranges are where UTF8ToUnicodeInteger() and UnicodeIntegerToUTF8() are NOT inverse functions of each other under Mono.
Converting these integers to utf8 and back to integer may likely result in the integer 63 (the Unicode codepoint for "?"), no longer guaranteeing uniqueness:

* [55296..57343] (2048 values). This corresponds to the surrogate area U+D800-U+DFFF, which is a reserved range because it's used by UTF-16 to represent the code points above U+FFFF.
* [65534] U+FFFE is in fact THE intentionally "INVALID CHARACTER" Unicode code point. It is invalid by design.
* [1114112 and above] can't be encoded because the Unicode range stops at U+10FFFF.

== Standard ==

This version of UnicodeIntegerToUTF8 complies to the latest standard. [[LSO]] on the other hand complies to an earlier standard. The newer standard includes only a subset of the older standard. The extended range of the old standard went unused so this incompleteness is moot.

<lsl>string UnicodeIntegerToUTF8(integer input)//Mono Safe, LSLEditor Safe, LSO Incomplete
{//LSO allows for the older UTF-8 range, this function only supports the new UTF-16 range.
if(input > 0)
{
if(input <= 0x7FF)
{//instead of a flat if else chain, this redistributes the fork load so that only the 4 byte characters result in 3 forks, all the other paths are 2 forks.
if(input <= 0x7F){
input = input << 24;
jump quick_return;//saves us from the implicit double jump that using an else would cause.
}
input = 0xC0800000 | ((input << 18) & 0x1F000000) | ((input << 16) & 0x3F0000);
}
else if(input <= 0xFFFF)
input = 0xE0808000 | ((input << 12) & 0x0F000000) | ((input << 10) & 0x3F0000) | ((input << 8) & 0x3F00);
else if(input <= 0x10FFFF)
input = 0xF0808080 | ((input << 06) & 0x07000000) | ((input << 04) & 0x3F0000) | ((input << 2) & 0x3F00) | (input & 0x3F);
else
jump error;//not in our range
@quick_return;
return llBase64ToString(llIntegerToBase64(input));
}
@error;
return "";
}</lsl>

== General Use ==

This version will work fine in [[LSO]] and [[Mono]] but not in LSLEditor.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:35:00" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Unsafe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000)//multibyte, continuing to use base64 is impractical because it requires smart shifting.
return ( ( 0x0000003f & result ) |
(( 0x00003f00 & result) >> 2 ) |
(( 0x003f0000 & result) >> 4 ) |
(( 0x3f000000 & (result = (integer)("0x"+llGetSubString(input,-8,-1)))) >> 6 ) |
(( 0x0000003f & result) << 24) |
(( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1)))) << 22)
) & ( 0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
// (( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input,-8,-1)))) << 22)
// ) & ( 0x7FFFFFFF >> (30 - (5 * (llStringLength(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[])) >> 1))));
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Unsafe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !(bytes = ((input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5))));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>

==LSLEditor Safe==

This version will work in [[Mono]], [[LSO]] & LSLEditor. There will be a slight performance hit in [[LSO]] as compared to the LSLEditor Unsafe version.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:38:13" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Safe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000){//multibyte, continuing to use base64 is impractical because it requires smart shifting.
integer end = (integer)("0x"+llGetSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1));
integer begin = (integer)("0x"+llDeleteSubString(input,-8,-1));
return ( ( 0x0000003f & end ) |
(( 0x00003f00 & end) >> 2 ) |
(( 0x003f0000 & end) >> 4 ) |
(( 0x3f000000 & end) >> 6 ) |
(( 0x0000003f & begin) << 24) |
(( 0x00000100 & begin) << 22)
) & (0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
}
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Safe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
bytes = (input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5;//adjust
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !bytes));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>

UTF-8

2014-09-30T11:12:36Z

Pedro Oval: /* Limits under Mono */ Remove the almost meaningless word salad

{{LSL Header}}{{LSLC|User-Defined_Functions}}
Second Life uses {{Wikipedia|UTF-8|UTF-8}} for storing and transmitting [[String|strings]] and with these functions you can work with {{Wikipedia|Unicode|Unicode}} characters. See: [[Unicode In 5 Minutes]] for a brief introduction to {{Wikipedia|Unicode|Unicode}}.

These functions are part of the [[Combined Library]] written by {{User|Strife Onizuka}}.

== Limits under Mono ==

Unicode predominately contains simple characters. For the vast majority of the range of values, Unicode values are simply characters. However some Unicode values do not represent any character and are not valid, which under Mono results in one or more question marks ("?"). UnicodeIntegerToUTF8 and UTF8ToUnicodeInteger work perfectly for the simple characters; however not so well for the other values. More on these ranges can be found in the [http://unicode.org Unicode] specification and [http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29 Specials (Unicode block)]. While LSO doesn't care about these limitations, Mono does.

These integer ranges are ranges where UTF8ToUnicodeInteger() and UnicodeIntegerToUTF8() are NOT inverse functions of each other under Mono.
Converting these integers to utf8 and back to integer may likely result in the integer 63 (the Unicode codepoint for "?"), no longer guaranteeing uniqueness:

* [55296..57343] (2048 values). This corresponds to the surrogate area U+D800-U+DFFF, which is a reserved range because it's used by UTF-16 to represent the code points above U+FFFF.
* [65534] U+FFFE is in fact THE intentionally "INVALID CHARACTER" UTF-8 code point. It is invalid by design.
* [1114112 and above] can't be encoded because the Unicode range stops at U+10FFFF.

== Standard ==

This version of UnicodeIntegerToUTF8 complies to the latest standard. [[LSO]] on the other hand complies to an earlier standard. The newer standard includes only a subset of the older standard. The extended range of the old standard went unused so this incompleteness is moot.

<lsl>string UnicodeIntegerToUTF8(integer input)//Mono Safe, LSLEditor Safe, LSO Incomplete
{//LSO allows for the older UTF-8 range, this function only supports the new UTF-16 range.
if(input > 0)
{
if(input <= 0x7FF)
{//instead of a flat if else chain, this redistributes the fork load so that only the 4 byte characters result in 3 forks, all the other paths are 2 forks.
if(input <= 0x7F){
input = input << 24;
jump quick_return;//saves us from the implicit double jump that using an else would cause.
}
input = 0xC0800000 | ((input << 18) & 0x1F000000) | ((input << 16) & 0x3F0000);
}
else if(input <= 0xFFFF)
input = 0xE0808000 | ((input << 12) & 0x0F000000) | ((input << 10) & 0x3F0000) | ((input << 8) & 0x3F00);
else if(input <= 0x10FFFF)
input = 0xF0808080 | ((input << 06) & 0x07000000) | ((input << 04) & 0x3F0000) | ((input << 2) & 0x3F00) | (input & 0x3F);
else
jump error;//not in our range
@quick_return;
return llBase64ToString(llIntegerToBase64(input));
}
@error;
return "";
}</lsl>

== General Use ==

This version will work fine in [[LSO]] and [[Mono]] but not in LSLEditor.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:35:00" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Unsafe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000)//multibyte, continuing to use base64 is impractical because it requires smart shifting.
return ( ( 0x0000003f & result ) |
(( 0x00003f00 & result) >> 2 ) |
(( 0x003f0000 & result) >> 4 ) |
(( 0x3f000000 & (result = (integer)("0x"+llGetSubString(input,-8,-1)))) >> 6 ) |
(( 0x0000003f & result) << 24) |
(( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1)))) << 22)
) & ( 0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
// (( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input,-8,-1)))) << 22)
// ) & ( 0x7FFFFFFF >> (30 - (5 * (llStringLength(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[])) >> 1))));
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Unsafe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !(bytes = ((input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5))));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>

==LSLEditor Safe==

This version will work in [[Mono]], [[LSO]] & LSLEditor. There will be a slight performance hit in [[LSO]] as compared to the LSLEditor Unsafe version.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:38:13" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Safe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000){//multibyte, continuing to use base64 is impractical because it requires smart shifting.
integer end = (integer)("0x"+llGetSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1));
integer begin = (integer)("0x"+llDeleteSubString(input,-8,-1));
return ( ( 0x0000003f & end ) |
(( 0x00003f00 & end) >> 2 ) |
(( 0x003f0000 & end) >> 4 ) |
(( 0x3f000000 & end) >> 6 ) |
(( 0x0000003f & begin) << 24) |
(( 0x00000100 & begin) << 22)
) & (0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
}
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Safe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
bytes = (input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5;//adjust
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !bytes));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>

UTF-8

2014-09-30T10:57:00Z

Pedro Oval: /* Limits */ Fix the mess a bit

{{LSL Header}}{{LSLC|User-Defined_Functions}}
Second Life uses {{Wikipedia|UTF-8|UTF-8}} for storing and transmitting [[String|strings]] and with these functions you can work with {{Wikipedia|Unicode|Unicode}} characters. See: [[Unicode In 5 Minutes]] for a brief introduction to {{Wikipedia|Unicode|Unicode}}.

These functions are part of the [[Combined Library]] written by {{User|Strife Onizuka}}.

== Limits under Mono ==

Unicode predominately contains simple characters. For the vast majority of the range of values, Unicode values are simply characters. However some Unicode values do not represent any character and are not valid, which under Mono results in one or more question marks ("?"). UnicodeIntegerToUTF8 and UTF8ToUnicodeInteger work perfectly for the simple characters; however not so well for the other values. More on these ranges can be found in the [http://unicode.org Unicode] specification and [http://en.wikipedia.org/wiki/Specials_%28Unicode_block%29 Specials (Unicode block)]. While LSO doesn't care about these limitations, Mono does.

These integer ranges are ranges where UTF8ToUnicodeInteger() and UnicodeIntegerToUTF8() are NOT inverse functions of each other under Mono.
Converting these integers to utf8 and back to integer may likely result in the integer 63 (the Unicode codepoint for "?"), no longer guaranteeing uniqueness:

* [55296..57343] (2048 values). This corresponds to the surrogate area U+D800-U+DFFF, which is a reserved range because it's used by UTF-16 to represent the code points above U+FFFF.
* [65534] U+FFFE is in fact THE intentionally "INVALID CHARACTER" UTF-8 code point. It is invalid by design.
* [1114112 and above] can't be encoded because the Unicode range stops at U+10FFFF.

Some characters within ranges where the two functions are inverse functions of each other may still behave VERY STRANGE if more than 1 character is stored in a string (of multiple characters). They may ...

* become double characters and mess up your indexing within a string. (this may even vary, depending on if a text field uses utf8 or utf16)
* merge with other characters into "super-mega-dino-mecha-character" (see "unicode combined characters")
* are reserved characters (especially for JSON-like string serializations but also for simple things like "\n")
* become invisible and may be skipped over by some functions (depending on compiler, VM, environment and programming language)

Because of that you quickly get down to a range of 65504 unique SINGLE characters (still working in LSO in case you unchecked the "mono" button by accident) (<2^16 due to avoiding a lot of reserved and invalid characters) being able to store 2^15 bits per character in a string within lsl (for mono and LSO compiler).

Storing 15 bits per character in a string quickly becomes more memory efficient than storing a list of 32-bit integers.
Each mono-integer taking 16 bytes to store 32 bit.
Each mono-character taking only 2 bytes to store 15 bit, + 18 taking bytes per string itself to store a string of characters.

== Standard ==

This version of UnicodeIntegerToUTF8 complies to the latest standard. [[LSO]] on the other hand complies to an earlier standard. The newer standard includes only a subset of the older standard. The extended range of the old standard went unused so this incompleteness is moot.

<lsl>string UnicodeIntegerToUTF8(integer input)//Mono Safe, LSLEditor Safe, LSO Incomplete
{//LSO allows for the older UTF-8 range, this function only supports the new UTF-16 range.
if(input > 0)
{
if(input <= 0x7FF)
{//instead of a flat if else chain, this redistributes the fork load so that only the 4 byte characters result in 3 forks, all the other paths are 2 forks.
if(input <= 0x7F){
input = input << 24;
jump quick_return;//saves us from the implicit double jump that using an else would cause.
}
input = 0xC0800000 | ((input << 18) & 0x1F000000) | ((input << 16) & 0x3F0000);
}
else if(input <= 0xFFFF)
input = 0xE0808000 | ((input << 12) & 0x0F000000) | ((input << 10) & 0x3F0000) | ((input << 8) & 0x3F00);
else if(input <= 0x10FFFF)
input = 0xF0808080 | ((input << 06) & 0x07000000) | ((input << 04) & 0x3F0000) | ((input << 2) & 0x3F00) | (input & 0x3F);
else
jump error;//not in our range
@quick_return;
return llBase64ToString(llIntegerToBase64(input));
}
@error;
return "";
}</lsl>

== General Use ==

This version will work fine in [[LSO]] and [[Mono]] but not in LSLEditor.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:35:00" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Unsafe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000)//multibyte, continuing to use base64 is impractical because it requires smart shifting.
return ( ( 0x0000003f & result ) |
(( 0x00003f00 & result) >> 2 ) |
(( 0x003f0000 & result) >> 4 ) |
(( 0x3f000000 & (result = (integer)("0x"+llGetSubString(input,-8,-1)))) >> 6 ) |
(( 0x0000003f & result) << 24) |
(( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1)))) << 22)
) & ( 0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
// (( 0x00000100 & (result = (integer)("0x"+llDeleteSubString(input,-8,-1)))) << 22)
// ) & ( 0x7FFFFFFF >> (30 - (5 * (llStringLength(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[])) >> 1))));
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Unsafe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !(bytes = ((input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5))));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>

==LSLEditor Safe==

This version will work in [[Mono]], [[LSO]] & LSLEditor. There will be a slight performance hit in [[LSO]] as compared to the LSLEditor Unsafe version.

<lsl>//===================================================//
// Combined Library //
// "Feb 4 2008", "08:38:13" //
// Copyright (C) 2004-2008, Strife Onizuka (cc-by) //
// http://creativecommons.org/licenses/by/3.0/ //
//===================================================//
//{

integer UTF8ToUnicodeInteger(string input)//LSLEditor Safe, LSO Safe
{
integer result = llBase64ToInteger(llStringToBase64(input = llGetSubString(input,0,0)));
if(result & 0x80000000){//multibyte, continuing to use base64 is impractical because it requires smart shifting.
integer end = (integer)("0x"+llGetSubString(input = (string)llParseString2List(llEscapeURL(input),(list)"%",[]),-8,-1));
integer begin = (integer)("0x"+llDeleteSubString(input,-8,-1));
return ( ( 0x0000003f & end ) |
(( 0x00003f00 & end) >> 2 ) |
(( 0x003f0000 & end) >> 4 ) |
(( 0x3f000000 & end) >> 6 ) |
(( 0x0000003f & begin) << 24) |
(( 0x00000100 & begin) << 22)
) & (0x7FFFFFFF >> (5 * ((integer)(llLog(~result) / 0.69314718055994530941723212145818) - 25)));
}
return result >> 24;
}

string UnicodeIntegerToUTF8(integer input)//LSLEditor Safe, LSO Safe
{
integer bytes = llCeil((llLog(input) / 0.69314718055994530941723212145818));
bytes = (input >= 0x80) * (bytes + ~(((1 << bytes) - input) > 0)) / 5;//adjust
string result = "%" + byte2hex((input >> (6 * bytes)) | ((0x3F80 >> bytes) << !bytes));
while (bytes)
result += "%" + byte2hex((((input >> (6 * (bytes = ~-bytes))) | 0x80) & 0xBF));
return llUnescapeURL(result);
}

string byte2hex(integer x)//LSLEditor Safe, LSO Safe
{//Helper function for use with unicode characters.
integer y = (x >> 4) & 0xF;
return llGetSubString(hexc, y, y) + llGetSubString(hexc, x & 0xF, x & 0xF);
}//This function would benefit greatly from the DUP opcode, it would remove 19 bytes.

string hexc="0123456789ABCDEF";

//} Combined Library</lsl>