Second Life Wiki - User contributions [en]

Limits

2016-07-14T01:51:41Z

Darien Caldwell: /* Groups */

<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.
* '''Maximum Age of a Group Notice:''' 14 days.

== [[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.
** <pre style="color: red">'''WARNING:''' This may soon change to 10k items per prim. If the change is implemented, prims with >10k items will no longer rez.</pre>
* '''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.

::Since viewer release 3.8.4, processing of meshes in the Collada file that have faces assigned to more than 8 materials has changed. Instead of simply dropping the extra material faces, the uploader now creates a new object to accommodate them. The result is that the single mesh is divided into multiple objects (prims) in a linkset. Thus the limitation to 8 materials is removed as far as input is concerned, but still applies to each of the resulting linked objects actually uploaded. As a consequence it is now possible to upload a mesh with more than 174,752 triangles, although it will be divided into multiple objects.

== 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.

LSL Protocol/OpenRadioCommunication

2016-06-26T03:36:57Z

Darien Caldwell:

Open Radio Communication (ORC for short) Is a "binary like" radio system designed for small simple applications, where part of the goal is to have equipments interfere with eachothers.
=Channels=
The channels used by ORC go from -797386 to -797186 with 200 independent frequencies.

Frequency "friendly" numbers go from 88.1 to 108.1.

=API=
<source lang="lsl2">
//Open Radio System v0.1

integer POWER_LOW = 0;//whisper
integer POWER_MED = 1;//say
integer POWER_HI = 2;//shout
integer POWER_MAX = 3;//region

integer CHANNEL = -798267; //ORC in decimal basically
integer giSubchannel;
//This function is used to trim/pad data to length
string Size(integer iData,integer iBytes)
{
string s = (string)iData;
while(llStringLength(s)<iBytes)
s = "0"+s;
if(llStringLength(s)>iBytes)
s = llGetSubString(s,-iBytes,-1);
return s;
}

//////////////////////////////////////////RECEIVER//////////////////////////////////////////
//Functions to listen and read an OpenRC datastream //
//////////////////////////////////////////RECEIVER//////////////////////////////////////////
integer giReceiverPointer;
integer giReceiverHandle = -1;
integer Receiver(float fFrequency)
{
integer iFrequency = llAbs((integer)(fFrequency*10));
//set frequency to zero to turn receiver off.
if(iFrequency == 0)
{
if(giReceiverHandle != -1)
llListenRemove(giReceiverHandle);
giReceiverHandle = -1;
return -1;
}

// 88.1 to 108.1 expressed as 881 to 1081 -> 200 possible frequencies
if(iFrequency < 881)
iFrequency = 881;
else if(iFrequency > 1081)
iFrequency = 1081;

if(giReceiverHandle != -1)
llListenRemove(giReceiverHandle);
giSubchannel = CHANNEL+iFrequency;
giReceiverHandle = llListen(giSubchannel,"","","");
return iFrequency;
}
ReceiverInit()
{
//init basically set the pointer to 0
giReceiverPointer = 0;
}
string ReceiverRead(string sDatastream,integer iBytes)
{
//Main stream reader, read the number of bytes and move the pointer forward.
string sData = llGetSubString(sDatastream,giReceiverPointer,giReceiverPointer + iBytes - 1);
giReceiverPointer+=iBytes;
return sData;
}
integer ReceiverReadInt(string sDatastream,integer iBytes)
{
return (integer)ReceiverRead(sDatastream,iBytes);
}
string ReceiverReadASCIIChar(string sDatastream)
{
return ASCII2Char(ReceiverReadInt(sDatastream,3));
}
string ReceiverReadASCIIWord(string sDatastream)
{
//first we attempt to read the header (charcount)
integer iLength = ReceiverReadInt(sDatastream,3);
if(iLength < 1)
iLength = 0;
string sBuffer = "";
integer i;
for(i=0;i<iLength;i++)
sBuffer += ReceiverReadASCIIChar(sDatastream);
return sBuffer;
}

string ReceiverReadMorseWord(string sDatastream)
{
//you should check the header manually! (000)
string sBuffer = "";
integer iInt;
do
{
iInt = ReceiverReadInt(sDatastream,1);
if(iInt)
sBuffer += (string)iInt;
}
while(iInt);

return sBuffer;
}

//////////////////////////////////////////SENDER//////////////////////////////////////////
//Functions to build and send an OpenRCsend datastream //
//////////////////////////////////////////SENDER//////////////////////////////////////////
string gsSendBuffer;

//Execute before building a datastream to ensure that the send buffer is clean.
SendInit()
{
gsSendBuffer = "";
}

//Used to add an integer to the datastream, only positive values, you can pick the number of bytes used
SendInt(integer iValue,integer iBytes)
{
gsSendBuffer += Size(llAbs(iValue),iBytes);
}

//Used to add an ASCII character to the datastream, each ascii char always use 3 bytes.
SendASCIIChar(string sChar)
{
gsSendBuffer += Char2ASCII(sChar);
}

//Used to add an ASCII word to the datastream, words use 3 bytes per character and 3 extra bytes as header.
SendASCIIWord(string sWord)
{
//count the number of chars
integer iCount = llStringLength(sWord) % 999; //max word size is 999 chars because 3 bytes max.
integer i;
SendInt(iCount,3); //header of a word is it's total character count.
for(i=0;i<iCount;i++)
SendASCIIChar(llGetSubString(sWord,i,i));
}

//Used to send a morse word on the datastream,this start with 000 and end with 000
//requires pre encoded morse!
SendMorseWord(string sWord)
{
//count the number of chars
integer iCount = llStringLength(sWord);
integer i;
SendInt(0,3);
for(i=0;i<iCount;i++)
SendInt((integer)llGetSubString(sWord,i,i),1);
SendInt(0,3);
}

//Send the buffer and purge it's content, you have to set power and frequency here.
SendEnd(float fFrequency,integer iPower)
{
integer iChannel = llAbs((integer)(fFrequency*10));
// 88.1 to 108.1 expressed as 881 to 1081 -> 200 possible frequencies
if(iChannel < 881)
iChannel = 881;
else if(iChannel > 1081)
iChannel = 1081;

iChannel += CHANNEL;
if(gsSendBuffer == "")
return;
if(iPower == POWER_LOW)
llWhisper(iChannel,gsSendBuffer);
else if(iPower == POWER_HI)
llShout(iChannel,gsSendBuffer);
else if(iPower == POWER_MAX)
llRegionSay(iChannel,gsSendBuffer);
else
llSay(iChannel,gsSendBuffer);
gsSendBuffer = "";
}

//////////////////////////////////////////CODEC//////////////////////////////////////////
//this is a basic ASCII coder/decoder toolset for char/word //
//////////////////////////////////////////CODEC//////////////////////////////////////////
//Conversion table to extended ascii, character index + 1 = value.
// 1 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 255 (nbsp)
string ASCII = "☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø×ƒáíóúñÑªº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýÝ¯´±‗¾¶§÷¸°¨·¹³²■ ";
//Turns the supplied character into a 3 byte integer.
string Char2ASCII(string sData)
{
return Size(llSubStringIndex(ASCII,llGetSubString(sData,0,0)) + 1,3);
}

//Turns the supplied integer into it's corresponding character. values wrap around at ORC_ASCII length.
string ASCII2Char(integer iCharcode)
{
iCharcode = llAbs(iCharcode) % (llStringLength(ASCII)+1);
if(iCharcode <= 0)
return "";
iCharcode--; //shifting of 1 to account for the "" that is at position zero.
return llGetSubString(ASCII,iCharcode,iCharcode);
}

integer MORSE_SPACE = 1;
integer MORSE_SHORT = 2;
integer MORSE_LONG = 3;

list MORSE_SYMBOLS = [""," ",".","-"];
string String2Morse(string sData)
{
string buffer;
integer i;
integer max = llStringLength(sData);
for(i=0;i<max;i++)
{
integer value = llListFindList(MORSE_SYMBOLS,[llGetSubString(sData,i,i)]);
if(value < 0)
value = 0;
buffer += (string)value;
}
return buffer;
}

string Morse2String(string sData)
{
string buffer;
integer i;
integer max = llStringLength(sData);
for(i=0;i<max;i++)
buffer += llList2String(MORSE_SYMBOLS,(integer)llGetSubString(sData,i,i));
return buffer;
}
</source>

=Examples=
==Sending a simple message with the API==
Note that in this example, we are sending int(5) and then a variable length ascii encoded text. It will have to be decoded in the same order to be reserved.
<source lang="lsl2">
state_entry()
{
SendInit(); //Required before any transmission to setup the radio systems.
SendInt(5000,5); //This will add a 5 digit long integer, containing the value 5000 to the buffer.
SendASCIIWord("Hello world!"); //This will add an ASCII encoded string of variable length to the sending buffer.
SendEnd(105.5,POWER_MED); //This will send the buffer over channel 105.5 with the "medium" power setting (20 meters range)
}
</source>

==Receiving a messages with the API==
The way variable length ascii encoded texts are stored, the first int(3) contains the length of the character chain, and then every subsequenct in(3) is a character.
<source lang="lsl2">
state_entry()
{
Receiver(105.5); //Will start listening for messages on channel 105.5
}
listen(integer channel,string name,key id,string datastream)
{
if(channel = giSubchannel && giReceiverHandle != -1)
{
ReceiverInit(); //setup the ORC system for reading the datastream

integer value = ReceiverReadInt(datastream,5); //read an Integer value of 5 digits.
string text = ReceiverReadASCIIWord(datastream); //read a variable length Ascii word.
}
}
</source>

LSL Protocol/OpenRadioCommunication

2016-06-26T03:31:00Z

Darien Caldwell:

Open Radio Communication (ORC for short) Is a "binary like" radio system designed for small simple applications, where part of the goal is to have equipments interfere with eachothers.
=Channels=
The channels used by ORC go from -797386 to -797186 with 200 independent frequencies.

Frequency "friendly" numbers go from 88.1 to 108.1.

=API=
<source lang="lsl2">
//Open Radio System v0.1

integer POWER_LOW = 0;//whisper
integer POWER_MED = 1;//say
integer POWER_HI = 2;//shout
integer POWER_MAX = 3;//region

integer CHANNEL = -798267; //ORC in decimal basically
integer giSubchannel;
//This function is used to trim/pad data to length
string Size(integer iData,integer iBytes)
{
string s = (string)iData;
while(llStringLength(s)<iBytes)
s = "0"+s;
if(llStringLength(s)>iBytes)
s = llGetSubString(s,-iBytes,-1);
return s;
}

//////////////////////////////////////////RECEIVER//////////////////////////////////////////
//Functions to listen and read an OpenRC datastream //
//////////////////////////////////////////RECEIVER//////////////////////////////////////////
integer giReceiverPointer;
integer giReceiverHandle = -1;
integer Receiver(float fFrequency)
{
integer iFrequency = llAbs((integer)(fFrequency*10));
//set frequency to zero to turn receiver off.
if(iFrequency == 0)
{
if(giReceiverHandle != -1)
llListenRemove(giReceiverHandle);
giReceiverHandle = -1;
return -1;
}

// 88.1 to 108.1 expressed as 881 to 1081 -> 200 possible frequencies
if(iFrequency < 881)
iFrequency = 881;
else if(iFrequency > 1081)
iFrequency = 1081;

if(giReceiverHandle != -1)
llListenRemove(giReceiverHandle);
giSubchannel = CHANNEL+iFrequency;
giReceiverHandle = llListen(giSubchannel,"","","");
return iFrequency;
}
ReceiverInit()
{
//init basically set the pointer to 0
giReceiverPointer = 0;
}
string ReceiverRead(string sDatastream,integer iBytes)
{
//Main stream reader, read the number of bytes and move the pointer forward.
string sData = llGetSubString(sDatastream,giReceiverPointer,giReceiverPointer + iBytes - 1);
giReceiverPointer+=iBytes;
return sData;
}
integer ReceiverReadInt(string sDatastream,integer iBytes)
{
return (integer)ReceiverRead(sDatastream,iBytes);
}
string ReceiverReadASCIIChar(string sDatastream)
{
return ASCII2Char(ReceiverReadInt(sDatastream,3));
}
string ReceiverReadASCIIWord(string sDatastream)
{
//first we attempt to read the header (charcount)
integer iLength = ReceiverReadInt(sDatastream,3);
if(iLength < 1)
iLength = 0;
string sBuffer = "";
integer i;
for(i=0;i<iLength;i++)
sBuffer += ReceiverReadASCIIChar(sDatastream);
return sBuffer;
}

string ReceiverReadMorseWord(string sDatastream)
{
//you should check the header manually! (000)
string sBuffer = "";
integer iInt;
do
{
iInt = ReceiverReadInt(sDatastream,1);
if(iInt)
sBuffer += (string)iInt;
}
while(iInt);

return sBuffer;
}

//////////////////////////////////////////SENDER//////////////////////////////////////////
//Functions to build and send an OpenRCsend datastream //
//////////////////////////////////////////SENDER//////////////////////////////////////////
string gsSendBuffer;

//Execute before building a datastream to ensure that the send buffer is clean.
SendInit()
{
gsSendBuffer = "";
}

//Used to add an integer to the datastream, only positive values, you can pick the number of bytes used
SendInt(integer iValue,integer iBytes)
{
gsSendBuffer += Size(llAbs(iValue),iBytes);
}

//Used to add an ASCII character to the datastream, each ascii char always use 3 bytes.
SendASCIIChar(string sChar)
{
gsSendBuffer += Char2ASCII(sChar);
}

//Used to add an ASCII word to the datastream, words use 3 bytes per character and 3 extra bytes as header.
SendASCIIWord(string sWord)
{
//count the number of chars
integer iCount = llStringLength(sWord) % 999; //max word size is 999 chars because 3 bytes max.
integer i;
SendInt(iCount,3); //header of a word is it's total character count.
for(i=0;i<iCount;i++)
SendASCIIChar(llGetSubString(sWord,i,i));
}

//Used to send a morse word on the datastream,this start with 000 and end with 000
//requires pre encoded morse!
SendMorseWord(string sWord)
{
//count the number of chars
integer iCount = llStringLength(sWord);
integer i;
SendInt(0,3);
for(i=0;i<iCount;i++)
SendInt((integer)llGetSubString(sWord,i,i),1);
SendInt(0,3);
}

//Send the buffer and purge it's content, you have to set power and frequency here.
SendEnd(float fFrequency,integer iPower)
{
integer iChannel = llAbs((integer)(fFrequency*10));
// 88.1 to 108.1 expressed as 881 to 1081 -> 200 possible frequencies
if(iChannel < 881)
iChannel = 881;
else if(iChannel > 1081)
iChannel = 1081;

iChannel += CHANNEL;
if(gsSendBuffer == "")
return;
if(iPower == POWER_LOW)
llWhisper(iChannel,gsSendBuffer);
else if(iPower == POWER_HI)
llShout(iChannel,gsSendBuffer);
else if(iPower == POWER_MAX)
llRegionSay(iChannel,gsSendBuffer);
else
llSay(iChannel,gsSendBuffer);
gsSendBuffer = "";
}

//////////////////////////////////////////CODEC//////////////////////////////////////////
//this is a basic ASCII coder/decoder toolset for char/word //
//////////////////////////////////////////CODEC//////////////////////////////////////////
//Conversion table to extended ascii, character index + 1 = value.
// 1 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 255 (nbsp)
string ASCII = "☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø×ƒáíóúñÑªº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýÝ¯´±‗¾¶§÷¸°¨·¹³²■ ";
//Turns the supplied character into a 3 byte integer.
string Char2ASCII(string sData)
{
return Size(llSubStringIndex(ASCII,llGetSubString(sData,0,0)) + 1,3);
}

//Turns the supplied integer into it's corresponding character. values wrap around at ORC_ASCII length.
string ASCII2Char(integer iCharcode)
{
iCharcode = llAbs(iCharcode) % (llStringLength(ASCII)+1);
if(iCharcode <= 0)
return "";
iCharcode--; //shifting of 1 to account for the "" that is at position zero.
return llGetSubString(ASCII,iCharcode,iCharcode);
}

integer MORSE_SPACE = 1;
integer MORSE_SHORT = 2;
integer MORSE_LONG = 3;

list MORSE_SYMBOLS = [""," ",".","-"];
string String2Morse(string sData)
{
string buffer;
integer i;
integer max = llStringLength(sData);
for(i=0;i<max;i++)
{
integer value = llListFindList(MORSE_SYMBOLS,[llGetSubString(sData,i,i)]);
if(value < 0)
value = 0;
buffer += (string)value;
}
return buffer;
}

string Morse2String(string sData)
{
string buffer;
integer i;
integer max = llStringLength(sData);
for(i=0;i<max;i++)
buffer += llList2String(MORSE_SYMBOLS,(integer)llGetSubString(sData,i,i));
return buffer;
}
</source>

=Examples=
==Sending a simple message with the API==
Note that in this example, we are sending int(5) and then a variable length ascii encoded text. It will have to be decoded in the same order to be reserved.
<source lang="lsl2">
state_entry()
{
SendInit(); //Required before any transmission to setup the radio systems.
SendInt(5,5000); //This will add a 5 digit long integer, containing the value 5000 to the buffer.
SendASCIIWord("Hello world!"); //This will add an ASCII encoded string of variable length to the sending buffer.
SendEnd(105.5,POWER_MED); //This will send the buffer over channel 105.5 with the "medium" power setting (20 meters range)
}
</source>

==Receiving a messages with the API==
The way variable length ascii encoded texts are stored, the first int(3) contains the length of the character chain, and then every subsequenct in(3) is a character.
<source lang="lsl2">
state_entry()
{
Receiver(105.5); //Will start listening for messages on channel 105.5
}
listen(integer channel,string name,key id,string datastream)
{
if(channel = giSubchannel && giReceiverHandle != -1)
{
ReceiverInit(); //setup the ORC system for reading the datastream

integer value = ReceiverReadInt(datastream,5); //read an Integer value of 5 digits.
string text = ReceiverReadASCIIWord(datastream); //read a variable length Ascii word.
}
}
</source>

Mesh/Avatar Shape XML Format

2016-03-28T19:20:23Z

Darien Caldwell: clarify what SSA is

{{Navbox/Mesh|tech}}
== History ==
The Shape XML format has been ingrained in the viewer since the early days, long before mesh existed. However, with the addition of rigged mesh and customized clothing, the file has become invaluable to creators. Sometimes called an "archetype file" due to it's default name "new_archetype.xml".

With the release of [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] in Early 2013, The XML format has inherited additional information. However, its XML version number is still 1.0, and it is still backward compatible with the original terse format. The additions will be outlined separately in the SSA Extensions section.

== Header ==
The file is standard XML, with 3 parameters:

* <source lang="xml"><?xml version="1.0" encoding="US-ASCII" standalone="yes"?></source>
** The <code>version</code> parameter sets the version of the XML markup. (should always be 1.0)
** The <code>encoding</code> parameter sets the character encoding for the file. (should always be US-ASCII)
** The <code>standalone</code> parameter informs that the file is self-containted, and not dependent on any external files. (should always be yes)

'''Note that some viewers''' set <code>standalone="true"</code>. This is technically incorrect via the XML standard. It should be <code>standalone="yes"</code>.

== Root Node ==

The root node is of type <code>linden_genepool</code> with one parameter:

* <source lang="xml"><linden_genepool version="1.0"></source>
** The <code>version</code> parameter sets the version of the data contained in the node. Currently LL's data is version 1.0. Future revisions may increment this version, so any implementation should check this version number before using the data.

== Data Body ==

The Root node contains one node of type <code>archetype</code> with one parameter.

*<source lang="xml"><archetype name="???"></source>
** The <code>name</code> parameter is a information parameter, and can contain anything, or nothing. Most commonly populated with 3 question marks.

== The Data ==

The data inside is a list of parameters and textures associated with the Avatar's appearance. These can be broken up into 4 categories:

* Shape
* Skin
* Hair
* Eyes

Each category will have several <code>param</code> nodes and possibly <code>texture</code> nodes included. More about these nodes in the next section.

== Param Nodes ==

<code>param</code> nodes correspond to sliders in the appearance pane. Each has 3 parameters:
*Example: <source lang="xml"><param id="649" name="torso muscles" value="0.500"/></source>
** The <code>id</code> parameter corresponds to an internal viewer table of possible sliders. These numbers are guaranteed to be unique, and always correspond to the same slider.
** The <code>name</code> parameter corresponds to internal 'driving elements' in the viewer. This can vary depending on the type of param. For shapes, it's often the name of the morph being controlled. For skins or eyes, it's usually a material that's being changed (color etc). For hair, a combination of both are present. These are '''not''' always unique. For example, there are two parameters called "torso muscles", with different IDs (one for male, one for female).
** The <code>value</code> parameter is the value of the slider. It is however in the internally used format, not the 0-100 value seen by Residents. Calculating what these values mean requires finding the Minimum and Maximum of that value from other sources, such as the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)

== Texture Nodes ==

<code>texture</code> nodes correspond to textures applied via the appearance pane. Each has two parameters:
*Example: <source lang="xml"><texture te="3" uuid="00000000-0000-4000-8000-000000000000"/></source>
** The <code>te</code> parameter corresponds to an internal viewer table of possible textures. These numbers are guaranteed to be unique.
** The <code>uuid</code> parameter corresponds to the [[UUID]] of the texture applied at the time of the XML creation.

'''Note that <code>texture</code> nodes are optional''' and not guaranteed to be present. Especially when the file is generated from 3rd party sources.

== Comments ==

Comments are styled in the standard HTML style, with the string <source lang="xml"></source> denoting the end of a comment. This is per the XML specification.
*Example: <source lang="xml"></source>

== File Termination ==

The file is terminated by the closing of the <code>archetype</code> and <code>linden_genepool</code> nodes:

*<source lang="xml"></archetype></linden_genepool></source>

== SSA Extensions ==
The Two main changes with [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] are the addition of '''many''' new <code>param</code> nodes , and the inclusion of new data in all <code>param</code> nodes.
*The additional <code>param</code> nodes now cover more than just the avatar's body shape and texture. Now, there is data for every possible avatar appearance modifier, including all clothes layers, alpha layers, tattoo layers, all internal morphs, and all settings for these items. In short there is every bit of data needed to completely recreate the entire avatar's 'look'.
*The new parameters included in the <code>param</code> nodes is ''in addition to'' the original parameters. All of the originally available parameters are still provided. The new parameters are as follows:
**The <code>u8</code> parameter is a short integer normalized representation of the displayed slider value. Whereas before some complex math was necessary to determine what 0-100 slider value was indicated by the morph value in the <code>value</code> parameter, now you can simply take the u8 value, divide it by 255, then multiply that value by 100. That will give you the displayed slider values. 255 would be a slider value of 100, 128 would be a slider value of 50, and 0 would of course be 0.
**The <code>type</code> parameter is a rough indication of what kind of data the <code>param</code> entry is associated with. There seem to be 5 distinct values, which likely correspond to entries in the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)
*** param_morph, param_driver, param_skeleton, param_color, param_alpha
** The <code>wearable</code> parameter further groups <code>param</code> entries into distinct groups. These clearly indicate what avatar component the <code>param</code> node is associated with. There seem to be 16 distinct values:
*** shape, hair, invalid, gloves, eyes, skin, pants, shoes, shirt, jacket, socks, underpants, undershirt, skirt, tattoo, physics
** The <code>invalid</code> wearable indicates a morph.

LlTeleportAgentGlobalCoords

2016-03-12T19:07:59Z

Darien Caldwell:

{{LSL_Function
|inject-2={{LSL Function/avatar|agent|region=*}}{{Issues/BUG-4062}}
|inject-3={{LSL_Function/permission|PERMISSION_TELEPORT|grant={{LSLP|agent}}}}
|func=llTeleportAgentGlobalCoords
|func_desc=Teleports an {{LSLP|agent}} to set of a {{LSLP|region_coordinates}} within a region at the specified {{LSLP|global_coordinates}}. The agent lands facing the position defined by {{LSLP|look_at}} local coordinates. A region's global coordinates can be retrieved using <code>[[llRequestSimulatorData]](region_name, DATA_SIM_POS)</code>
|func_footnote=The combination of [[llRequestSimulatorData]] and [[llTeleportAgentGlobalCoords]] allows agents to be teleported to regions by region name.
|p1_type=key|p1_name=agent|p1_desc= (avatar to be teleported)
|p2_type=vector|p2_name=global_coordinates|p2_desc=Global coordinates of the destination region. Can be retrieved by using [[llRequestSimulatorData]](region_name, DATA_SIM_POS).
|p3_type=vector|p3_name=region_coordinates|p3_desc=Destination position inside the target region, given in local coordinates.
|p4_type=vector|p4_name=look_at|p4_desc=Location avatar will face after completing the teleport, given in local coordinates.
|caveats=
* '''This function can only teleport the owner of the object''' (unless part of an [[:Category:Experience Tools|Experience]]).
* Teleports are throttled
* This function cannot be used in a script in an object attached using [[llAttachToAvatarTemp]].
* Sitting avatars cannot be teleported using this function. You must [[llUnSit]] them first.
* This function does not override a parcel's teleport settings, i.e. if the parcel has a landing zone enabled the agent will be teleported there.
* If the script is part of an experience that the avatar has granted permission, then this function may teleport them without being the owner and it will override parcel teleport routing.
* according to [[https://jira.secondlife.com/browse/SVC-7987]], the lookat vector for teleporting between sims is <llCos(facing), llSin(facing), 0.0> where facing is the angle towards which the arriving avatar is to look, *not* the coordinates of a point in the region.
|examples=<source lang="lsl2">
string simName = "Help Island Public";
vector simGlobalCoords;

vector landingPoint = <128.0, 128.0, 24.0>;

key owner;

default
{
on_rez(integer start_param)
{
llResetScript();
}

changed(integer change)
{
if (change & CHANGED_OWNER)
llResetScript();
}

state_entry()
{
owner = llGetOwner();

llRequestPermissions(owner, PERMISSION_TELEPORT);
llRequestSimulatorData(simName, DATA_SIM_POS);
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);

if (id == owner)
{
if (simGlobalCoords == ZERO_VECTOR)
{
llOwnerSay("Config error, tp request was denied. Please try again!");
llResetScript();
}
else
{
llOwnerSay("Teleporting you to: http://maps.secondlife.com/secondlife/"
+ llEscapeURL(simName) + "/" + (string)llRound(landingPoint.x)
+ "/" + (string)llRound(landingPoint.y) + "/" + (string)llRound(landingPoint.z) + "/");

llTeleportAgentGlobalCoords(owner, simGlobalCoords, landingPoint, ZERO_VECTOR);
}
}
else
{
// llRegionSayTo is faster than llInstantMessage and we can assume
// that the touching avatar is within the same sim

llRegionSayTo(id, PUBLIC_CHANNEL,
"Sorry, I can't tp you. You're NOT my owner!");
}
}

run_time_permissions(integer perm)
{
// if permission request has been denied (read ! as not)
if (!(perm & PERMISSION_TELEPORT))
{
llOwnerSay("I need permissions to teleport you!");
llRequestPermissions(owner, PERMISSION_TELEPORT);
}
}

// dataserver event only called if data is returned
// or in other words, if you request data for a sim that does
// not exist this event will NOT be called

dataserver(key query_id, string data)
{
simGlobalCoords = (vector)data;
// llOwnerSay("Sim global coords: " + (string)simGlobalCoords);
}
}
</source>
|also_functions=
{{LSL DefineRow||[[llRequestSimulatorData]]|Useful for requesting simulator position}}
{{LSL DefineRow||[[llTeleportAgent]]|Teleporting agents to a landmark or position in the region.}}
|cat1=Teleport
|cat2
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/12#12.07.24.262437 | 24/07/2012 ]]
}}

User:Darien Caldwell/HTTP-DNS

2015-08-29T16:38:53Z

Darien Caldwell:

{{void-box
|title=Dynamic DNS service for HTTP-IN via Google App Engine:
|content=

NOTE: While the original version of this code did not provide true DNS service, it has since been updated to do so. Please read the original thread to understand the evolution of the code. A lot of good information and workarounds are also provided in the old thread!

http://forums-archive.secondlife.com/54/33/323981/1.html

One of the big issues with HTTP-IN is the fact that the URLs are dynamic and can change under many conditions. Many have balked at the requirements of having an external server to manage a Dynamic DNS service to keep track of these ever changing URLs. So here's a free solution that anyone can use, and expand with their needs.

Using this DNS, you can have servers register their URL 'service' and allow other in-world (and out of world) applications discover the URL for this service in a consistent manner. The Google App Engine is free and offers resource limits which should be able to support small to mid range applications. Of course, for a small fee you can purchase more resources from Google as well.
(Resouce limits: http://developers.google.com/appengine/docs/quotas )

This is the basics, and has no verification or encryption, but should be fairly secure as long as you don't go around giving your service URL to people. Feel free to add on to it as you like. The code is released to the Public Domain. Enjoy.

NOTE: As of March 8th, 2013, Google has announced the depreciation of the Python 2.5 Runtime. I have updated the files here to use the newer Pythonn 2.7 Runtime. If you use this service, and have it on Python 2.5, you should consider migrating to 2.7 As well, To use Python 2.7, you must migrate from the Master/Slave datastore to the HRD (High Replication Datastore).

Migration Info here:

Migrating to HRD: https://developers.google.com/appengine/docs/adminconsole/migration

Migrating to Python 2.7: https://developers.google.com/appengine/docs/python/python25/migrate27

}}
{{void-box
|title=Setup and Installation
|content=
*First, download the files here:

http://home.comcast.net/~volfin/lsl-dns.zip

Or, you can find the contents of the zip file here:

http://wiki.secondlife.com/w/index.php?title=User:Darien_Caldwell/HTTP-DNS%20Code

Now, what to do with these files:

*Go to http://developers.google.com/appengine/ to sign up for a free account. Or if you already have a GMail or other Google account, use that.

*Go here to install Python 2.7 (if you don't already have it)
http://www.python.org/download/releases/2.7.5/ (Note that GAE updated to Python 2.7.5 on July 16th, 2013. other versions of 2.7.x can be used, but may lack newer features)

*Download and install the App Engine SDK for Python:

http://developers.google.com/appengine/downloads

The SDK will be installed into a subdirectory called 'google_appengine'.

*Create a directory under the 'google_appengine' directory called 'lsl-dns'

*Place the files from the zip file (dns.py and app.yaml) into this new directory.

*Edit the app.yaml file to change the name of the application to the name you specified when you signed up for the service (at https://appengine.google.com/ ):

application: YOUR-APP-NAME-HERE <-- Change this

*From the 'google_appengine' directory (where the SDK was installed), run this command from the console (DOS Prompt):

appcfg.py update lsl-dns/

This will install the application.

*You're done.
}}

{{void-box
|title=The API Calls
|content=
Once it's installed you can start using it:

*http://''yourappname''.appspot.com/?type=add&name=[NAME]&url=[URL]
Adds a new service named [NAME] with the HTTP-IN url [URL].
The URL must be converted to a string using llEscapeURL() first.
if the URL is added, returns the response 'Added', or 'Found' if the service
already exists.

*http://''yourappname''.appspot.com/?type=remove&name=[NAME]
Removes the given service named [NAME].
Returns 'Removed' if successful, or 'None' if the service wasn't found.

*http://''yourappname''.appspot.com/?type=update&name=[NAME]&url=[URL]
Updates the service named [NAME] with the HTTP-IN url [URL].
The URL must be converted to a string using llEscapeURL() first.
If the URL is updated the response 'Updated' is returned.
If the service doesn't exist, a new service is added and 'Added' is returned.

*http://''yourappname''.appspot.com/?type=retrieve&name=[NAME]
Retrieves the url of the given service named [NAME].
Returns the URL if the service is found, or 'None' if the service wasn't found.
the returned URL must be converted to a URL using llUnescapeURL()

*http://''yourappname''.appspot.com/?type=list
Lists the available services currently stored.
Returns a Comma seperated list of service names, ending with the word 'END'.
if no services are defined, 'Empty' is returned.

}}
{{void-box
|title=Optimizing to stay in the Free Quota
|content= Google App Engine is designed for high scalability, so it will try to use as much resources as it can to keep up with the load put on it. However, for someone in the free Quota, you may not want it to do that. :) So, to stay in the free quota you have to sacrifice some scalability and latency. But for SL this is generally okay to do.

The thing to do is make some simple changes to some Application configuration settings. Logging into your application dashboard (https://appengine.google.com/), on the left hand menu find Application Settings under the "Administration" subheading, and go there. Then change the settings shown below to match what you see here:

[[File:app_settings.jpg|Application Instance Settings]]

}}
{{void-box
|title=Using the DNS URL
|content=
Once a service has been entered, you can use the serivce name in the URL to do automatic redirection.

Example:

You establish a service named 'Intro1'

The URL for the service is:
http://''sim3015.aditi.lindenlab.com'':12046/cap/3ff4f3f2-ea08-76c1-cef6-a22b4a573a7c

By Navigating to http://''yourappname''.appspot.com/Intro1
The page will be automatically redirected to the service URL:

http://''sim3015.aditi.lindenlab.com'':12046/cap/3ff4f3f2-ea08-76c1-cef6-a22b4a573a7c

If the service name used in the URL is invalid, 'None' is returned.
}}
{{void-box
|title=Example LSL Script
|content=
<source lang="lsl2">

string url = "";
string service_name = "Intro1";
key URL_KEY;

setup()
{
llReleaseURL(url);
URL_KEY=llRequestURL();
}

default
{
state_entry()
{
llSetObjectName("HTTP Server");
setup();
}

on_rez(integer n)
{
setup();
}

changed(integer c)
{
if (c & (CHANGED_REGION | CHANGED_REGION_START | CHANGED_TELEPORT) )
{
setup();
}
}

//Response to our HTTPRequest
http_response(key id, integer status, list meta, string body)
{

if (status == 415) // The remote server did reply to your request but the Content-Type of the reply (such as XML, JSON, Atom, RSS, PLS)
// is not recognised by the LL server and so is not passed back to the script.
// You can assume that 415 means the server heard your request and did reply.
{
llInstantMessage(llGetOwner(),"Special Error Status 415 Encountered.");
return;
}
else if (status == 499) // Besides the usual HTTP status codes, SL implements a special status code 499.
// This code isn't generated by the remote web server but by SL's servers, it can indicate:
// Request timeout (60 seconds) -- SSL failure -- A space was present in the url (escape your URL with llEscapeURL).
{
llInstantMessage(llGetOwner(),"Special Error Status 499 Encountered.");
return;
}
else if (status == 502) // The proxy server received an invalid response from an upstream server.
// This error occurs when you send an llHTTPRequest to an object in-world, and it does not reply with an llHTTPResponse.
{
llInstantMessage(llGetOwner(),"Special Error Status 502 Encountered.");
return;
}

if (body=="Updated") llOwnerSay("DNS updated with Server Address.");
else llOwnerSay("Response code:"+(string)status+" Body:"+body); // Some other arbitrary response

}

http_request(key id, string method, string body)
{
if (id==URL_KEY)
{
if (method == URL_REQUEST_GRANTED)
{
// the '/' must be added to work around a quirk with LL's HTTP-in URLS (see forum thread)
url = body+"/";
// DON'T FORGET TO CHANGE 'yourappname' to the name of your specific App!!!
llHTTPRequest("http://yourappname.appspot.com/?type=update&name=" + service_name + "&url=" + llEscapeURL(url),[],"");
}
else
{
url="";
llOwnerSay("Error: HTTP-IN URL Request Denied.");
}
}
else
{
// Some other Request
llOwnerSay("Got:"+body);
string pathInfoHeader = llGetHTTPHeader(id, "x-path-info");
llOwnerSay("Path:"+pathInfoHeader);
string query = llGetHTTPHeader(id, "x-query-string");
llOwnerSay("Query:"+query);
}

// should always respond to prevent timeouts.
llHTTPResponse(id,200,"ACK");
}
}
</source>
}}
{{void-box
|title=Advanced Version
|content= There is an advanced version that has a very basic admin function, password protection, and verbose logging. Thanks goes to [[User:CrystalShard Foo|Crystalshard Foo]] for contributing her time to work with me on this.

The code can be found here:

http://wiki.secondlife.com/w/index.php?title=User:Darien_Caldwell/Advanced%20HTTP-DNS%20Code

}}
{{void-box
|title=Advanced API Calls
|content=
The API is much the same, but there are several new *optional* parameters that can be used.
*wpass: Write protect password. If an entry has a write protect password set, it can't be updated or deleted without specificying this password.
*rpass: Read Protect password. If an entry has a read protect password set, it can't be retrieved without specificying this password. It also can't be called via a DNS url.
*hidden: Hidden status. If an entry is marked as hidden, it will not show up in the Entry List. 'list'ing the services with the admin password included will show hidden entries.
*pass: A generic password parameter, takes the place of rpass, wpass, or both in various situations. If whien adding a service through an update, you specifiy 'pass', it will be set as the read and write passwords. specifying 'rpass' or 'wpass' will override this.
*admin: Admin Password. The hard-coded Admin password allows global overriding of some actions, regardless of the entry password set. If an Admin password is set, only Add requests that include the admin password will be accepted. 'admin' can also be used to override update,remove,retrieve,and list.

The Admin password is hard coded in the dns.py file:
<source lang="python">
admin_password = "adminpassword" # This password enables you to have unrestricted access to the DNS
</source>

*http://''yourappname''.appspot.com/?type=add&name=[NAME]&url=[URL]&hidden=[0/1]&admin=[ADMIN PASS]&wpass=[WRITE PASS]&rpass=[READ PASS]
Adds a new service named [NAME] with the HTTP-IN url [URL].
Can be 'hidden', 'wpass' protected, and/or 'rpass' protected.
The URL must be converted to a string using llEscapeURL() first.
if the URL is added, returns the response 'Added', or 'Found' if the service already exists.

*http://''yourappname''.appspot.com/?type=remove&name=[NAME]&admin=[ADMIN PASS]&pass=[WRITE PASS]
Removes the given service named [NAME].
If 'wpass' was set during creation/update, must be specificed as 'pass'. or overridden by admin=[ADMIN PASS]
Returns 'Removed' if successful, or 'None' if the service wasn't found.

*http://''yourappname''.appspot.com/?type=update&name=[NAME]&url=[URL]&hidden=[0/1]&admin=[ADMIN PASS]&wpass=[WRITE PASS]&rpass=[READ PASS]
Updates the service named [NAME] with the HTTP-IN url [URL].
Can be 'hidden', 'wpass' protected, and/or 'rpass' protected.
If 'wpass' was set during previous creation/update, must be specificed as 'pass', or overridden by admin=[ADMIN PASS]
The URL must be converted to a string using llEscapeURL() first.
If the URL is updated the response 'Updated' is returned.
If the service doesn't exist, a new service is added and 'Added' is returned.

*http://''yourappname''.appspot.com/?type=retrieve&name=[NAME]&pass=[READ PASS]&admin=[ADMIN PASS]
Retrieves the url of the given service named [NAME].
If 'rpass' was set during previous creation/update, must be specificed as 'pass', or overridden by admin=[ADMIN PASS]
Returns the URL if the service is found, or 'None' if the service wasn't found.
the returned URL must be converted to a URL using llUnescapeURL()

*http://''yourappname''.appspot.com/?type=list&admin=[ADMIN PASS]
Lists the available services currently stored.
Will only show entries not marked as 'hidden', Unless &admin=[ADMIN PASS] is included. then all are shown.
Returns a Comma seperated list of service names, ending with the word 'END'.
If no services are defined, 'Empty' is returned.

Enjoy :)
}}

Instant Message

2015-03-31T16:16:32Z

Darien Caldwell: Added info about new Premium cap increase/ removed dead link.

{{Help |Glossary=*|Communication=*}}The chat window that allows two [[Resident]]s to have a private conversation with each other.

Opposed to open chat, which is [[Limits|limited]] to a distance of 20 meter, instant messages (often abbrivated as IMs) reach [[grid]] wide. The length of an IM is limited to 1023 bytes/single-byte characters.

When a Resident is offline, up to 25 messages (50 if a premium account holder) will be stored and delivered at the next login. This limit includes [[inventory]] offers, [[group]] notices, group invitation and IMs. All messages above this limit will be ''capped'' and not delivered.

However, there is an IM to Email feature, which sends offline messages directly to the mailbox connected to your account. To activate it, go to '''Edit''' > '''Preferences''' (or press {{KeyCombo|ctrl=*|P}}), go to the '''Communication''' tab and check the '''Send IM to Email''' checkbox. Press '''Apply''' and close the window with '''OK'''.

When an offline message is received via Email, this message can also be answered via Email again. These mails will be converted back to IM and sent to the right Resident. Note that the Email to IM feature expires 5 days after the receival of the IM. Messages sent afterwards won't be received anymore. Also note that the length of properly delivered Email replies is limited to 1023 bytes/single-byte characters. Messages exceeding this limited will be truncated to fit the limit.

Note that, due to {{Jira|SVC-1144}}, replies to offline emails currently can't contain special unicode characters.

Also note that '''offline IMs are only retained for 31 days and discarded afterwards'''. For example, if someone sends you an Instant Message and the next time you login is 33 days later, you won't receive it.

== Conferences ==

A conference is a private conversation with two or more Residents, who can communicate gridwide. It is similar to group chat, but more dynamic, since everyone on your friends list can be invited, as well as everyone where you got a [[calling card]] from.

To start a conference by
* selecting several Residents in your friends list ({{Keypress|Ctrl|title=Control}}+LEFT CLICK) and press "IM/Call" button.
* dragging a Resident's calling card into an IM window.

Once conference is started you can invite new Residents by dragging their calling card in the conference window.

{{#widget:Vimeo|id=5937623|width=640|height=480}}

== Related Links ==
*[[IM to Email]]
*[[How do I Instant Message (IM) someone?]]
*[[Linden_Lab_Official:How do I log chat and instant messages|How do I log chat and instant messages?]]
*[[Where are my chat and IM logs stored?]]
*[[How do I Instant Message (IM) a group of people at once?]]
*[https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Blog: IM to E-mail Return Addresses Changing]
*[https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog: Premium Subscriber Cap Increase]

Instant Message

2015-03-31T16:15:13Z

Darien Caldwell:

{{Help |Glossary=*|Communication=*}}The chat window that allows two [[Resident]]s to have a private conversation with each other.

Opposed to open chat, which is [[Limits|limited]] to a distance of 20 meter, instant messages (often abbrivated as IMs) reach [[grid]] wide. The length of an IM is limited to 1023 bytes/single-byte characters.

When a Resident is offline, up to 25 messages (50 if a premium account holder) will be stored and delivered at the next login. This limit includes [[inventory]] offers, [[group]] notices, group invitation and IMs. All messages above this limit will be ''capped'' and not delivered.

However, there is an IM to Email feature, which sends offline messages directly to the mailbox connected to your account. To activate it, go to '''Edit''' > '''Preferences''' (or press {{KeyCombo|ctrl=*|P}}), go to the '''Communication''' tab and check the '''Send IM to Email''' checkbox. Press '''Apply''' and close the window with '''OK'''.

When an offline message is received via Email, this message can also be answered via Email again. These mails will be converted back to IM and sent to the right Resident. Note that the Email to IM feature expires 5 days after the receival of the IM. Messages sent afterwards won't be received anymore. Also note that the length of properly delivered Email replies is limited to 1023 bytes/single-byte characters. Messages exceeding this limited will be truncated to fit the limit.

Note that, due to {{Jira|SVC-1144}}, replies to offline emails currently can't contain special unicode characters.

Also note that '''offline IMs are only retained for 31 days and discarded afterwards'''. For example, if someone sends you an Instant Message and the next time you login is 33 days later, you won't receive it.

== Conferences ==

A conference is a private conversation with two or more Residents, who can communicate gridwide. It is similar to group chat, but more dynamic, since everyone on your friends list can be invited, as well as everyone where you got a [[calling card]] from.

To start a conference by
* selecting several Residents in your friends list ({{Keypress|Ctrl|title=Control}}+LEFT CLICK) and press "IM/Call" button.
* dragging a Resident's calling card into an IM window.

Once conference is started you can invite new Residents by dragging their calling card in the conference window.

{{#widget:Vimeo|id=5937623|width=640|height=480}}

== Related Links ==
*[[Instant Messaging (IM) FAQ]]
*[[IM to Email]]
*[[How do I Instant Message (IM) someone?]]
*[[Linden_Lab_Official:How do I log chat and instant messages|How do I log chat and instant messages?]]
*[[Where are my chat and IM logs stored?]]
*[[How do I Instant Message (IM) a group of people at once?]]
*[https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Blog: IM to E-mail Return Addresses Changing]
*[https://community.secondlife.com/t5/Featured-News/A-New-Perk-for-Premium-Subscribers/ba-p/2917357 Blog: Premium Subscriber Cap Increase]

Limits

2015-03-31T16:11:34Z

Darien Caldwell: Updated with information about new IM cap.

<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 March 2015, this is only available in project 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 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''' - Most women's shoes are designed for a size 0 (zero) foot. Men's generally scale up to 14.
** 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.
| [[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.

== [[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 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.

Mesh/Avatar Shape XML Format

2015-03-19T02:02:39Z

Darien Caldwell: Repair Syntax Highlighting from new Wiki software version.

{{Navbox/Mesh|tech}}
== History ==
The Shape XML format has been ingrained in the viewer since the early days, long before mesh existed. However, with the addition of rigged mesh and customized clothing, the file has become invaluable to creators. Sometimes called an "archetype file" due to it's default name "new_archetype.xml".

With the release of [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] in Early 2013, The XML format has inherited additional information. However, its XML version number is still 1.0, and it is still backward compatible with the original terse format. The additions will be outlined separately in the SSA Extensions section.

== Header ==
The file is standard XML, with 3 parameters:

* <source lang="xml"><?xml version="1.0" encoding="US-ASCII" standalone="yes"?></source>
** The <code>version</code> parameter sets the version of the XML markup. (should always be 1.0)
** The <code>encoding</code> parameter sets the character encoding for the file. (should always be US-ASCII)
** The <code>standalone</code> parameter informs that the file is self-containted, and not dependent on any external files. (should always be yes)

'''Note that some viewers''' set <code>standalone="true"</code>. This is technically incorrect via the XML standard. It should be <code>standalone="yes"</code>.

== Root Node ==

The root node is of type <code>linden_genepool</code> with one parameter:

* <source lang="xml"><linden_genepool version="1.0"></source>
** The <code>version</code> parameter sets the version of the data contained in the node. Currently LL's data is version 1.0. Future revisions may increment this version, so any implementation should check this version number before using the data.

== Data Body ==

The Root node contains one node of type <code>archetype</code> with one parameter.

*<source lang="xml"><archetype name="???"></source>
** The <code>name</code> parameter is a information parameter, and can contain anything, or nothing. Most commonly populated with 3 question marks.

== The Data ==

The data inside is a list of parameters and textures associated with the Avatar's appearance. These can be broken up into 4 categories:

* Shape
* Skin
* Hair
* Eyes

Each category will have several <code>param</code> nodes and possibly <code>texture</code> nodes included. More about these nodes in the next section.

== Param Nodes ==

<code>param</code> nodes correspond to sliders in the appearance pane. Each has 3 parameters:
*Example: <source lang="xml"><param id="649" name="torso muscles" value="0.500"/></source>
** The <code>id</code> parameter corresponds to an internal viewer table of possible sliders. These numbers are guaranteed to be unique, and always correspond to the same slider.
** The <code>name</code> parameter corresponds to internal 'driving elements' in the viewer. This can vary depending on the type of param. For shapes, it's often the name of the morph being controlled. For skins or eyes, it's usually a material that's being changed (color etc). For hair, a combination of both are present. These are '''not''' always unique. For example, there are two parameters called "torso muscles", with different IDs (one for male, one for female).
** The <code>value</code> parameter is the value of the slider. It is however in the internally used format, not the 0-100 value seen by Residents. Calculating what these values mean requires finding the Minimum and Maximum of that value from other sources, such as the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)

== Texture Nodes ==

<code>texture</code> nodes correspond to textures applied via the appearance pane. Each has two parameters:
*Example: <source lang="xml"><texture te="3" uuid="00000000-0000-4000-8000-000000000000"/></source>
** The <code>te</code> parameter corresponds to an internal viewer table of possible textures. These numbers are guaranteed to be unique.
** The <code>uuid</code> parameter corresponds to the [[UUID]] of the texture applied at the time of the XML creation.

'''Note that <code>texture</code> nodes are optional''' and not guaranteed to be present. Especially when the file is generated from 3rd party sources.

== Comments ==

Comments are styled in the standard HTML style, with the string <source lang="xml"></source> denoting the end of a comment. This is per the XML specification.
*Example: <source lang="xml"></source>

== File Termination ==

The file is terminated by the closing of the <code>archetype</code> and <code>linden_genepool</code> nodes:

*<source lang="xml"></archetype></linden_genepool></source>

== SSA Extensions ==
The Two main changes with SSA are the addition of '''many''' new <code>param</code> nodes , and the inclusion of new data in all <code>param</code> nodes.
*The additional <code>param</code> nodes now cover more than just the avatar's body shape and texture. Now, there is data for every possible avatar appearance modifier, including all clothes layers, alpha layers, tattoo layers, all internal morphs, and all settings for these items. In short there is every bit of data needed to completely recreate the entire avatar's 'look'.
*The new parameters included in the <code>param</code> nodes is ''in addition to'' the original parameters. All of the originally available parameters are still provided. The new parameters are as follows:
**The <code>u8</code> parameter is a short integer normalized representation of the displayed slider value. Whereas before some complex math was necessary to determine what 0-100 slider value was indicated by the morph value in the <code>value</code> parameter, now you can simply take the u8 value, divide it by 255, then multiply that value by 100. That will give you the displayed slider values. 255 would be a slider value of 100, 128 would be a slider value of 50, and 0 would of course be 0.
**The <code>type</code> parameter is a rough indication of what kind of data the <code>param</code> entry is associated with. There seem to be 5 distinct values, which likely correspond to entries in the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)
*** param_morph, param_driver, param_skeleton, param_color, param_alpha
** The <code>wearable</code> parameter further groups <code>param</code> entries into distinct groups. These clearly indicate what avatar component the <code>param</code> node is associated with. There seem to be 16 distinct values:
*** shape, hair, invalid, gloves, eyes, skin, pants, shoes, shirt, jacket, socks, underpants, undershirt, skirt, tattoo, physics
** The <code>invalid</code> wearable indicates a morph.

User:Darien Caldwell/New Materials

2014-07-29T16:18:23Z

Darien Caldwell:

•LSL support for materials

•Materials can be added to object faces with llSetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]

Wiki Pages: [[PRIM_NORMAL]], [[PRIM_SPECULAR]], and [[PRIM_ALPHA_MODE]]

•Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

•Materials can be read with the various llGetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

•Behavior for both getting and setting materials parameters should basically correspond to behavior with PRIM_TEXTURE

•The color vectors use 0.0-1.0 as the range, as with llSetColor()

•The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool

•Components of a material can be ‘reset’ as follows:

•
•PRIM_NORMAL and PRIM_SPECULAR settings are set to ‘default’ values by setting the texture to NULL_KEY

•PRIM_ALPHA_MODE settings are set to ‘default’ values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND

•mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK

•When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to ‘default’ values, the material is deleted from that prim face, and LI may be updated accordingly

•Known issues

•There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187),

•If the viewer has ALM enabled

•and a prim face has a material on it

•and PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)

•and the diffuse texture does not have an alpha channel (e.g. plywood)

User:Darien Caldwell/New Materials

2014-07-29T16:16:45Z

Darien Caldwell:

•LSL support for materials

•Materials can be added to object faces with llSetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]

•Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

•Materials can be read with the various llGetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

•Behavior for both getting and setting materials parameters should basically correspond to behavior with PRIM_TEXTURE

•The color vectors use 0.0-1.0 as the range, as with llSetColor()

•The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool

•Components of a material can be ‘reset’ as follows:

•
•PRIM_NORMAL and PRIM_SPECULAR settings are set to ‘default’ values by setting the texture to NULL_KEY

•PRIM_ALPHA_MODE settings are set to ‘default’ values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND

•mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK

•When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to ‘default’ values, the material is deleted from that prim face, and LI may be updated accordingly

•Known issues

•There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187),

•If the viewer has ALM enabled

•and a prim face has a material on it

•and PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)

•and the diffuse texture does not have an alpha channel (e.g. plywood)

User:Darien Caldwell

2014-07-04T19:46:05Z

Darien Caldwell:

If you have to ask, It's not important enough to know. :)

HTTP-IN Dynamic DNS service for Google App Engine: https://wiki.secondlife.com/wiki/User:Darien_Caldwell/HTTP-DNS

Original Code: https://wiki.secondlife.com/wiki/User:Darien_Caldwell/HTTP-DNS_Code

Enchanced Security code: https://wiki.secondlife.com/w/index.php?title=User:Darien_Caldwell/Advanced%20HTTP-DNS%20Code

The old forum post: http://forums-archive.secondlife.com/54/33/323981/1.html

https://wiki.secondlife.com/wiki/User:Darien_Caldwell/New_Materials

[[Category:SL Certification Participant|Darien Caldwell]]

User:Darien Caldwell/New Materials

2014-07-04T19:45:45Z

Darien Caldwell:

•LSL support for materials is in testing

•Certain Aditi regions (DRTSIM-253 channel, presently) have LSL support for materials

•Regions “roller-test102″ and “roller-test103″ are on this channel

•This is still a work-in-progress – testing is still underway

•Materials can be added to object faces with llSetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]

•Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

•Materials can be read with the various llGetPrimitiveParams() functions

•[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]

•[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]

•[PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

•Behavior for both getting and setting materials parameters should basically correspond to behavior with PRIM_TEXTURE

•The color vectors use 0.0-1.0 as the range, as with llSetColor()

•The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool

•Components of a material can be ‘reset’ as follows:

•
•PRIM_NORMAL and PRIM_SPECULAR settings are set to ‘default’ values by setting the texture to NULL_KEY

•PRIM_ALPHA_MODE settings are set to ‘default’ values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND

•mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK

•When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to ‘default’ values, the material is deleted from that prim face, and LI may be updated accordingly

•Known issues

•There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187),

•If the viewer has ALM enabled

•and a prim face has a material on it

•and PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)

•and the diffuse texture does not have an alpha channel (e.g. plywood)

•The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly

User:Darien Caldwell/New Materials

2014-07-04T19:44:01Z

Darien Caldwell:

•LSL support for materials is in testing
•Certain Aditi regions (DRTSIM-253 channel, presently) have LSL support for materials
•Regions “roller-test102″ and “roller-test103″ are on this channel
•This is still a work-in-progress – testing is still underway

•Materials can be added to object faces with llSetPrimitiveParams() functions
•[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
•[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
•[PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]
•Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

•Materials can be read with the various llGetPrimitiveParams() functions
•[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
•[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
•[PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

•Behavior for both getting and setting materials parameters should basically correspond to behavior with PRIM_TEXTURE
•The color vectors use 0.0-1.0 as the range, as with llSetColor()
•The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
•Components of a material can be ‘reset’ as follows:
•
•PRIM_NORMAL and PRIM_SPECULAR settings are set to ‘default’ values by setting the texture to NULL_KEY
•PRIM_ALPHA_MODE settings are set to ‘default’ values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND •mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK

•When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to ‘default’ values, the material is deleted from that prim face, and LI may be updated accordingly

•Known issues
•There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187),
•If the viewer has ALM enabled
•and a prim face has a material on it
•and PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
•and the diffuse texture does not have an alpha channel (e.g. plywood)

•The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly

User:Darien Caldwell/New Materials

2014-07-04T19:42:51Z

Darien Caldwell: Created page with "•LSL support for materials is in testing •Certain Aditi regions (DRTSIM-253 channel, presently) have LSL support for materials •Regions “roller-test102″ and “roller-t…"

•LSL support for materials is in testing •Certain Aditi regions (DRTSIM-253 channel, presently) have LSL support for materials •Regions “roller-test102″ and “roller-test103″ are on this channel
•This is still a work-in-progress – testing is still underway

•Materials can be added to object faces with llSetPrimitiveParams() functions •[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
•[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
•[PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff] •Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

•Materials can be read with the various llGetPrimitiveParams() functions •[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
•[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
•[PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

•Behavior for both getting and setting materials parameters should basically correspond to behavior with PRIM_TEXTURE
•The color vectors use 0.0-1.0 as the range, as with llSetColor()
•The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
•Components of a material can be ‘reset’ as follows:
• •PRIM_NORMAL and PRIM_SPECULAR settings are set to ‘default’ values by setting the texture to NULL_KEY
•PRIM_ALPHA_MODE settings are set to ‘default’ values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND •mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK

•When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to ‘default’ values, the material is deleted from that prim face, and LI may be updated accordingly

•Known issues •There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187), •If the viewer has ALM enabled
•and a prim face has a material on it
•and PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
•and the diffuse texture does not have an alpha channel (e.g. plywood)

•The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly

Material Data

2014-06-14T18:33:42Z

Darien Caldwell:

[[Category:Materials]]

{{RightToc}}

This page describes how the various parameters and texture data used to define a material in Second Life are interpreted for rendering. It is intended to help content creators and external tool developers to better understand how to create images to achieve good visual results.

There are as many as two colors and three images associated with a face.
For a more detailed explanation of the fundamentals of materials, see Pedro Toledo's [http://www.manufato.com/?p=902 Brief Considerations About Materials]
{{KBnote|'''Setting any of the materials properties on an object causes its Land Impact to be calculated using the current algorithm.'''

The additional textures used for Normal and Specular maps add to the Download Weight of the object.

If the object was previously using the legacy accounting (prim count), setting a material property on it may increase costs significantly due to other properties (such as complex shapes) that are more accurately accounted for in the current system.

For details, see [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 Calculating land impact] and [[Physics Optimization]].
}}

==Colors==

;Color
:a solid color for the surface; Tints the color of the diffuse map.

;Specular Color
:this is a color that ‘tints’ any reflections from the face; see also [[#Specular Map|Specular Map]]

==Textures==

===Texture===

Also called the '''Diffuse Map''', this is an image that is displayed on the surface. The way the texture is applied to the face is controlled by

====Positioning & Scaling Properties====
Note that each image (diffuse/texture, normal map, specular map) has its own values for these parameters.
:;Mapping
::''Default'' or ''Planar''
:;Horizontal Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Vertical Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Rotation:clockwise degrees the image is rotated
:;Repeats Per Meter:number of repeats of the image per in-world meter of the surface (used only in planar mapping)
:;Horizontal Offset:distance in meters the image is shifted right on the surface
:;Vertical Offset:distance in meters the image is shifted up on the surface

===Normal Map===

An image whose color data encodes changes to the "normal" for each pixel on the surface. The normal is the direction that the pixel "faces" for the purpose of determining how it is illuminated by and reflects light sources (imagine that each pixel is turned on tiny pivots). The alpha channel of the Normal Map may contain a specular exponent value that is mutilplied by the "Glossiness" parameter. A higher alpha value will result in specular highlights that are brighter and tighter. Keep in mind these are OpenGL style normal maps, where bright green is up and bright red is right. (or to put in Industry terms, the normal maps are X+, Y+, Z+ normal maps)

For details on what a normal map is and for a sample normal map see http://en.wikipedia.org/wiki/Normal_mapping. See also the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

;Positioning:The Normal Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Specular Map===

This encodes the color of the light reflected by each pixel on the surface. See the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

The Alpha channel value of the Specular Map encodes the environment intensity. A lower value in the alpha channel will diminish the impact of the environment map reflections on the surface of the object.

;Positioning:The Specular Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Texture Channel Encoding===

{|border="1" style="width: 100%; border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0;"
|+How the renderer will treat each color value in a texture image channel
|-
!Parameter
!Red
!Green
!Blue
!Alpha
|+
!Diffuse Map
|Red
|Green
|Blue
|''selectable''
see [[#Alpha Mode|Alpha Mode]]
|+
!Normal Map
|Normal X Axis
|Normal Y Axis
|Normal Z Axis
|Specular exponent
|+
!Specular Map
|Red
|Green
|Blue
|Environment intensity
|}

==Additional Parameters==

;Alpha Mode
:This controls the interpretation of the Alpha channel data in the Diffuse Map. It can have one of four values:
:;None:Alpha channel data is not used
:;Transparency (blended):The value is a degree of transparency (255 = opaque, 0 = fully transparent)
:;Alpha Mask (cutoff):The value (0...255) is compared to the Alpha Cutoff parameter (below); if the pixel is greater than the cutoff, it is fully opaque; if not, it is fully transparent.
:;Emissive:The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness
:''Note that using any alpha mode other than Transparency may cause problems when rendered with viewers that do not yet support materials because they will be rendered as blended transparency. We expect that support for materials will be adopted quickly in most viewers, so this is acceptable.''

;Alpha Cutoff
:Used only when Alpha Mode is Alpha Mask (see description of that mode above)

;Specular Light Color
:Tints the light reflected from the object; this value is combined with any value from the color for the pixel as specified in the Specular Map, if any.

;Environment Intensity
:Modulates the intensity of the environment on the surface as a whole.

;Glossiness
:This controls the “glossiness”, or the roughness, of the reflected light on a surface. The lower this value is, the “rougher” the light reflectance is, while the higher the value the “sharper” the light reflectance is. When the normal map’s alpha channel is present, the specular exponent map contained in it is modulated by this parameter.

Material Data

2014-06-14T18:33:07Z

Darien Caldwell: added terminology clarification

[[Category:Materials]]

{{RightToc}}

This page describes how the various parameters and texture data used to define a material in Second Life are interpreted for rendering. It is intended to help content creators and external tool developers to better understand how to create images to achieve good visual results.

There are as many as two colors and three images associated with a face.
For a more detailed explanation of the fundamentals of materials, see Pedro Toledo's [http://www.manufato.com/?p=902 Brief Considerations About Materials]
{{KBnote|'''Setting any of the materials properties on an object causes its Land Impact to be calculated using the current algorithm.'''

The additional textures used for Normal and Specular maps add to the Download Weight of the object.

If the object was previously using the legacy accounting (prim count), setting a material property on it may increase costs significantly due to other properties (such as complex shapes) that are more accurately accounted for in the current system.

For details, see [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 Calculating land impact] and [[Physics Optimization]].
}}

==Colors==

;Color
:a solid color for the surface; Tints the color of the diffuse map.

;Specular Color
:this is a color that ‘tints’ any reflections from the face; see also [[#Specular Map|Specular Map]]

==Textures==

===Texture===

Also called the '''Diffuse Map''', this is an image that is displayed on the surface. The way the texture is applied to the face is controlled by

====Positioning & Scaling Properties====
Note that each image (diffuse/texture, normal map, specular map) has its own values for these parameters.
:;Mapping
::''Default'' or ''Planar''
:;Horizontal Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Vertical Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Rotation:clockwise degrees the image is rotated
:;Repeats Per Meter:number of repeats of the image per in-world meter of the surface (used only in planar mapping)
:;Horizontal Offset:distance in meters the image is shifted right on the surface
:;Vertical Offset:distance in meters the image is shifted up on the surface

===Normal Map===

An image whose color data encodes changes to the "normal" for each pixel on the surface. The normal is the direction that the pixel "faces" for the purpose of determining how it is illuminated by and reflects light sources (imagine that each pixel is turned on tiny pivots). The alpha channel of the Normal Map may contain a specular exponent value that is mutilplied by the "Glossiness" parameter. A higher alpha value will result in specular highlights that are brighter and tighter. Keep in mind these are OpenGL style normal maps, where bright green is up and bright red is right.(or to put in Industry terms, the normal maps are X+, Y+, Z+ normal maps) For details on what a normal map is and for a sample normal map see http://en.wikipedia.org/wiki/Normal_mapping. See also the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

;Positioning:The Normal Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Specular Map===

This encodes the color of the light reflected by each pixel on the surface. See the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

The Alpha channel value of the Specular Map encodes the environment intensity. A lower value in the alpha channel will diminish the impact of the environment map reflections on the surface of the object.

;Positioning:The Specular Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Texture Channel Encoding===

{|border="1" style="width: 100%; border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0;"
|+How the renderer will treat each color value in a texture image channel
|-
!Parameter
!Red
!Green
!Blue
!Alpha
|+
!Diffuse Map
|Red
|Green
|Blue
|''selectable''
see [[#Alpha Mode|Alpha Mode]]
|+
!Normal Map
|Normal X Axis
|Normal Y Axis
|Normal Z Axis
|Specular exponent
|+
!Specular Map
|Red
|Green
|Blue
|Environment intensity
|}

==Additional Parameters==

;Alpha Mode
:This controls the interpretation of the Alpha channel data in the Diffuse Map. It can have one of four values:
:;None:Alpha channel data is not used
:;Transparency (blended):The value is a degree of transparency (255 = opaque, 0 = fully transparent)
:;Alpha Mask (cutoff):The value (0...255) is compared to the Alpha Cutoff parameter (below); if the pixel is greater than the cutoff, it is fully opaque; if not, it is fully transparent.
:;Emissive:The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness
:''Note that using any alpha mode other than Transparency may cause problems when rendered with viewers that do not yet support materials because they will be rendered as blended transparency. We expect that support for materials will be adopted quickly in most viewers, so this is acceptable.''

;Alpha Cutoff
:Used only when Alpha Mode is Alpha Mask (see description of that mode above)

;Specular Light Color
:Tints the light reflected from the object; this value is combined with any value from the color for the pixel as specified in the Specular Map, if any.

;Environment Intensity
:Modulates the intensity of the environment on the surface as a whole.

;Glossiness
:This controls the “glossiness”, or the roughness, of the reflected light on a surface. The lower this value is, the “rougher” the light reflectance is, while the higher the value the “sharper” the light reflectance is. When the normal map’s alpha channel is present, the specular exponent map contained in it is modulated by this parameter.

Material Data

2014-05-21T19:44:43Z

Darien Caldwell:

[[Category:Materials]]

{{RightToc}}

This page describes how the various parameters and texture data used to define a material in Second Life are interpreted for rendering. It is intended to help content creators and external tool developers to better understand how to create images to achieve good visual results.

There are as many as two colors and three images associated with a face.
For a more detailed explanation of the fundamentals of materials, see Pedro Toledo's [http://www.manufato.com/?p=902 Brief Considerations About Materials]
{{KBnote|'''Setting any of the materials properties on an object causes its Land Impact to be calculated using the current algorithm.'''

The additional textures used for Normal and Specular maps add to the Download Weight of the object.

If the object was previously using the legacy accounting (prim count), setting a material property on it may increase costs significantly due to other properties (such as complex shapes) that are more accurately accounted for in the current system.

For details, see [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 Calculating land impact] and [[Physics Optimization]].
}}

==Colors==

;Color
:a solid color for the surface; Tints the color of the diffuse map.

;Specular Color
:this is a color that ‘tints’ any reflections from the face; see also [[#Specular Map|Specular Map]]

==Textures==

===Texture===

Also called the '''Diffuse Map''', this is an image that is displayed on the surface. The way the texture is applied to the face is controlled by

====Positioning & Scaling Properties====
Note that each image (diffuse/texture, normal map, specular map) has its own values for these parameters.
:;Mapping
::''Default'' or ''Planar''
:;Horizontal Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Vertical Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Rotation:clockwise degrees the image is rotated
:;Repeats Per Meter:number of repeats of the image per in-world meter of the surface (used only in planar mapping)
:;Horizontal Offset:distance in meters the image is shifted right on the surface
:;Vertical Offset:distance in meters the image is shifted up on the surface

===Normal Map===

An image whose color data encodes changes to the "normal" for each pixel on the surface. The normal is the direction that the pixel "faces" for the purpose of determining how it is illuminated by and reflects light sources (imagine that each pixel is turned on tiny pivots). The alpha channel of the Normal Map may contain a specular exponent value that is mutilplied by the "Glossiness" parameter. A higher alpha value will result in specular highlights that are brighter and tighter. Keep in mind these are OpenGL style normal maps, where bright green is up and bright red is right. For details on what a normal map is and for a sample normal map see http://en.wikipedia.org/wiki/Normal_mapping. See also the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

;Positioning:The Normal Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Specular Map===

This encodes the color of the light reflected by each pixel on the surface. See the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

The Alpha channel value of the Specular Map encodes the environment intensity. A lower value in the alpha channel will diminish the impact of the environment map reflections on the surface of the object.

;Positioning:The Specular Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Texture Channel Encoding===

{|border="1" style="width: 100%; border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0;"
|+How the renderer will treat each color value in a texture image channel
|-
!Parameter
!Red
!Green
!Blue
!Alpha
|+
!Diffuse Map
|Red
|Green
|Blue
|''selectable''
see [[#Alpha Mode|Alpha Mode]]
|+
!Normal Map
|Normal X Axis
|Normal Y Axis
|Normal Z Axis
|Specular exponent
|+
!Specular Map
|Red
|Green
|Blue
|Environment intensity
|}

==Additional Parameters==

;Alpha Mode
:This controls the interpretation of the Alpha channel data in the Diffuse Map. It can have one of four values:
:;None:Alpha channel data is not used
:;Transparency (blended):The value is a degree of transparency (255 = opaque, 0 = fully transparent)
:;Alpha Mask (cutoff):The value (0...255) is compared to the Alpha Cutoff parameter (below); if the pixel is greater than the cutoff, it is fully opaque; if not, it is fully transparent.
:;Emissive:The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness
:''Note that using any alpha mode other than Transparency may cause problems when rendered with viewers that do not yet support materials because they will be rendered as blended transparency. We expect that support for materials will be adopted quickly in most viewers, so this is acceptable.''

;Alpha Cutoff
:Used only when Alpha Mode is Alpha Mask (see description of that mode above)

;Specular Light Color
:Tints the light reflected from the object; this value is combined with any value from the color for the pixel as specified in the Specular Map, if any.

;Environment Intensity
:Modulates the intensity of the environment on the surface as a whole.

;Glossiness
:This controls the “glossiness”, or the roughness, of the reflected light on a surface. The lower this value is, the “rougher” the light reflectance is, while the higher the value the “sharper” the light reflectance is. When the normal map’s alpha channel is present, the specular exponent map contained in it is modulated by this parameter.

Material Data

2014-05-21T19:44:27Z

Darien Caldwell:

[[Category:Materials]]

{{RightToc}}

This page describes how the various parameters and texture data used to define a material in Second Life are interpreted for rendering. It is intended to help content creators and external tool developers to better understand how to create images to achieve good visual results.

There are as many as two colors and three images associated with a face.
For a more detailed explanation of the fundamentals of materials, see Pedro Toledo's [http://www.manufato.com/?p=902 Brief Considerations About Materials]

{{KBnote|'''Setting any of the materials properties on an object causes its Land Impact to be calculated using the current algorithm.'''

The additional textures used for Normal and Specular maps add to the Download Weight of the object.

If the object was previously using the legacy accounting (prim count), setting a material property on it may increase costs significantly due to other properties (such as complex shapes) that are more accurately accounted for in the current system.

For details, see [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 Calculating land impact] and [[Physics Optimization]].
}}

==Colors==

;Color
:a solid color for the surface; Tints the color of the diffuse map.

;Specular Color
:this is a color that ‘tints’ any reflections from the face; see also [[#Specular Map|Specular Map]]

==Textures==

===Texture===

Also called the '''Diffuse Map''', this is an image that is displayed on the surface. The way the texture is applied to the face is controlled by

====Positioning & Scaling Properties====
Note that each image (diffuse/texture, normal map, specular map) has its own values for these parameters.
:;Mapping
::''Default'' or ''Planar''
:;Horizontal Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Vertical Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Rotation:clockwise degrees the image is rotated
:;Repeats Per Meter:number of repeats of the image per in-world meter of the surface (used only in planar mapping)
:;Horizontal Offset:distance in meters the image is shifted right on the surface
:;Vertical Offset:distance in meters the image is shifted up on the surface

===Normal Map===

An image whose color data encodes changes to the "normal" for each pixel on the surface. The normal is the direction that the pixel "faces" for the purpose of determining how it is illuminated by and reflects light sources (imagine that each pixel is turned on tiny pivots). The alpha channel of the Normal Map may contain a specular exponent value that is mutilplied by the "Glossiness" parameter. A higher alpha value will result in specular highlights that are brighter and tighter. Keep in mind these are OpenGL style normal maps, where bright green is up and bright red is right. For details on what a normal map is and for a sample normal map see http://en.wikipedia.org/wiki/Normal_mapping. See also the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

;Positioning:The Normal Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Specular Map===

This encodes the color of the light reflected by each pixel on the surface. See the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

The Alpha channel value of the Specular Map encodes the environment intensity. A lower value in the alpha channel will diminish the impact of the environment map reflections on the surface of the object.

;Positioning:The Specular Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Texture Channel Encoding===

{|border="1" style="width: 100%; border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0;"
|+How the renderer will treat each color value in a texture image channel
|-
!Parameter
!Red
!Green
!Blue
!Alpha
|+
!Diffuse Map
|Red
|Green
|Blue
|''selectable''
see [[#Alpha Mode|Alpha Mode]]
|+
!Normal Map
|Normal X Axis
|Normal Y Axis
|Normal Z Axis
|Specular exponent
|+
!Specular Map
|Red
|Green
|Blue
|Environment intensity
|}

==Additional Parameters==

;Alpha Mode
:This controls the interpretation of the Alpha channel data in the Diffuse Map. It can have one of four values:
:;None:Alpha channel data is not used
:;Transparency (blended):The value is a degree of transparency (255 = opaque, 0 = fully transparent)
:;Alpha Mask (cutoff):The value (0...255) is compared to the Alpha Cutoff parameter (below); if the pixel is greater than the cutoff, it is fully opaque; if not, it is fully transparent.
:;Emissive:The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness
:''Note that using any alpha mode other than Transparency may cause problems when rendered with viewers that do not yet support materials because they will be rendered as blended transparency. We expect that support for materials will be adopted quickly in most viewers, so this is acceptable.''

;Alpha Cutoff
:Used only when Alpha Mode is Alpha Mask (see description of that mode above)

;Specular Light Color
:Tints the light reflected from the object; this value is combined with any value from the color for the pixel as specified in the Specular Map, if any.

;Environment Intensity
:Modulates the intensity of the environment on the surface as a whole.

;Glossiness
:This controls the “glossiness”, or the roughness, of the reflected light on a surface. The lower this value is, the “rougher” the light reflectance is, while the higher the value the “sharper” the light reflectance is. When the normal map’s alpha channel is present, the specular exponent map contained in it is modulated by this parameter.

Material Data

2014-05-21T19:44:04Z

Darien Caldwell: removed unnecessary warning: materials has been released for at least a year.

[[Category:Materials]]

{{RightToc}}

This page describes how the various parameters and texture data used to define a material in Second Life are interpreted for rendering. It is intended to help content creators and external tool developers to better understand how to create images to achieve good visual results.

There are as many as two colors and three images associated with a face.
For a more detailed explanation of the fundamentals of materials, see Pedro Toledo's [http://www.manufato.com/?p=902 Brief Considerations About Materials]

{{KBnote|'''Setting any of the materials properties on an object causes its Land Impact to be calculated using the current algorithm.'''

The additional textures used for Normal and Specular maps add to the Download Weight of the object.

If the object was previously using the legacy accounting (prim count), setting a material property on it may increase costs significantly due to other properties (such as complex shapes) that are more accurately accounted for in the current system.

For details, see [http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163 Calculating land impact] and [[Physics Optimization]].
}}

==Colors==

;Color
:a solid color for the surface; Tints the color of the diffuse map.

;Specular Color
:this is a color that ‘tints’ any reflections from the face; see also [[#Specular Map|Specular Map]]

==Textures==

===Texture===

Also called the '''Diffuse Map''', this is an image that is displayed on the surface. The way the texture is applied to the face is controlled by

====Positioning & Scaling Properties====
Note that each image (diffuse/texture, normal map, specular map) has its own values for these parameters.
:;Mapping
::''Default'' or ''Planar''
:;Horizontal Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Vertical Repeats:number of repeats of the image over the surface (used only in default mapping)
:;Rotation:clockwise degrees the image is rotated
:;Repeats Per Meter:number of repeats of the image per in-world meter of the surface (used only in planar mapping)
:;Horizontal Offset:distance in meters the image is shifted right on the surface
:;Vertical Offset:distance in meters the image is shifted up on the surface

===Normal Map===

An image whose color data encodes changes to the "normal" for each pixel on the surface. The normal is the direction that the pixel "faces" for the purpose of determining how it is illuminated by and reflects light sources (imagine that each pixel is turned on tiny pivots). The alpha channel of the Normal Map may contain a specular exponent value that is mutilplied by the "Glossiness" parameter. A higher alpha value will result in specular highlights that are brighter and tighter. Keep in mind these are OpenGL style normal maps, where bright green is up and bright red is right. For details on what a normal map is and for a sample normal map see http://en.wikipedia.org/wiki/Normal_mapping. See also the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

;Positioning:The Normal Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Specular Map===

This encodes the color of the light reflected by each pixel on the surface. See the [[#Texture Channel Encoding|Texture Channel Encoding]] table below.

The Alpha channel value of the Specular Map encodes the environment intensity. A lower value in the alpha channel will diminish the impact of the environment map reflections on the surface of the object.

;Positioning:The Specular Map has its own set of the same [[#Positioning & Scaling Properties|Positioning & Scaling Properties]] properties as the [[#Texture|Texture]].

===Texture Channel Encoding===

{|border="1" style="width: 100%; border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0;"
|+How the renderer will treat each color value in a texture image channel
|-
!Parameter
!Red
!Green
!Blue
!Alpha
|+
!Diffuse Map
|Red
|Green
|Blue
|''selectable''
see [[#Alpha Mode|Alpha Mode]]
|+
!Normal Map
|Normal X Axis
|Normal Y Axis
|Normal Z Axis
|Specular exponent
|+
!Specular Map
|Red
|Green
|Blue
|Environment intensity
|}

==Additional Parameters==

;Alpha Mode
:This controls the interpretation of the Alpha channel data in the Diffuse Map. It can have one of four values:
:;None:Alpha channel data is not used
:;Transparency (blended):The value is a degree of transparency (255 = opaque, 0 = fully transparent)
:;Alpha Mask (cutoff):The value (0...255) is compared to the Alpha Cutoff parameter (below); if the pixel is greater than the cutoff, it is fully opaque; if not, it is fully transparent.
:;Emissive:The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness
:''Note that using any alpha mode other than Transparency may cause problems when rendered with viewers that do not yet support materials because they will be rendered as blended transparency. We expect that support for materials will be adopted quickly in most viewers, so this is acceptable.''

;Alpha Cutoff
:Used only when Alpha Mode is Alpha Mask (see description of that mode above)

;Specular Light Color
:Tints the light reflected from the object; this value is combined with any value from the color for the pixel as specified in the Specular Map, if any.

;Environment Intensity
:Modulates the intensity of the environment on the surface as a whole.

;Glossiness
:This controls the “glossiness”, or the roughness, of the reflected light on a surface. The lower this value is, the “rougher” the light reflectance is, while the higher the value the “sharper” the light reflectance is. When the normal map’s alpha channel is present, the specular exponent map contained in it is modulated by this parameter.

Mesh/Download Weight

2014-04-15T19:31:06Z

Darien Caldwell: /* Equation */

{{Navbox/Mesh|tech}}
== Motivation ==
Previously used methods of [[Mesh_and_LOD#Level_Of_Detail|LOD]] enforcement and [[Mesh]] cost have proved ineffective and difficult to adhere to. Proposed here is an algorithm for determining cost of a [[Mesh/Mesh_Asset_Format|Mesh asset]] (in terms of prim parcel cost) that correlates strongly to the actual load of streaming and displaying a [[Mesh]] in a general way, without making assumptions about triangle/vertex limits and ratios between levels of detail. The artist need not adhere to any arbitrary restrictions with respect to what [[Mesh_and_LOD#Level_Of_Detail|LODs]] must be supplied and what the parameters of those [[Mesh_and_LOD#Level_Of_Detail|LODs]] are, but providing proper [[Mesh_and_LOD#Level_Of_Detail|LODs]] will greatly reduce the cost of an [[Object|object]] in terms of parcel limits, effectively allowing regions with efficient content to carry more content, while regions with inefficient content can carry less. This should allow greater control from Linden Lab in terms of acceptable rendering and streaming budgets while also giving artists complete control over how they build.

== Concept ==
The streaming and rendering cost of a [[Mesh]] is directly related to the number of bytes in a [[Mesh/Mesh_Asset_Format|Mesh asset]] [[Mesh_and_LOD#Level_Of_Detail|LOD]] slot, and the likelihood that a given [[Mesh_and_LOD#Level_Of_Detail|LOD]] will be downloaded and displayed can be computed based on the size of the object. Imagine a set of 3 concentric circles centered on an object where each circle represents the transition boundary between [[Mesh_and_LOD#Level_Of_Detail|LODs]]. The streaming/rendering cost of that object can be determined by examining the size of those circles vs the number of bytes in the relevant [[Mesh_and_LOD#Level_Of_Detail|LODs]]. Uploading a high [[Mesh_and_LOD#Level_Of_Detail|LOD]] only will result in the load of the high lod being applied to the entire 256m, while uploading appropriate [[Mesh_and_LOD#Level_Of_Detail|LODs]] will result in the lion's share of 256m being applied to the lowest [[Mesh_and_LOD#Level_Of_Detail|LOD]].

== Equation ==
# Compute the distance at which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is displayed
# Compute the area in which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is relevant
# Adjust for missiing [[Mesh_and_LOD#Level_Of_Detail|LODs]]
# Scale relative weights of each [[Mesh_and_LOD#Level_Of_Detail|LOD]] based on what percentage of the [[Region|region]] each [[Mesh_and_LOD#Level_Of_Detail|LOD]] covers.
# Compute cost based on relevant range and bytes in [[Mesh_and_LOD#Level_Of_Detail|LOD]]

Traditional parametric prims have their streaming weights capped at 1.0. Sculpted prims are capped at 2.0. This only holds true as long as the Traditional prims remain under the Legacy Prim accounting system. Changing to Convex Hull Physics type, or applying Advanced Materials (Normal maps and/or Specular maps) will take Traditional prims out of Legacy prim accounting and place under the New accounting. Under New accounting their streaming cost will not be capped, and will be calculated as explained here.[[Release Notes/Second Life Server/12#12.07.31.262785|1]]
=== [[Mesh_and_LOD#Level_Of_Detail|LOD]] Transition Distances ===
To compute the distance at which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is displayed, take the radius of the [[Object|object]]'s bounding box (R) and divide by the [[Mesh_and_LOD#Level_Of_Detail|LOD]] ratios used in the viewer:

<pre>
Dlowest = distance at which lowest LOD begins to be displayed.
Dlow = distance at which low LOD begins to be displayed.
Dmid = distance at which mid LOD begins to be displayed.
Dhigh = distance at which high LOD begins to be displayed.

Dlowest = R / 0.03
Dlow = R / 0.06
Dmid = R / 0.24
Dhigh = 0.0

lowest_circle = max area
low_circle = PI * Dlowest ^2
mid_circle = PI * Dlow ^2
high_circle = PI * Dmid^2

lowest_area = lowest_circle - low_circle
low_area = low_circle - mid_circle
mid_area = mid_circle - high_circle
high_area = high_circle
</pre>

=== Relevant [[Mesh_and_LOD#Level_Of_Detail|LOD]] Ranges ===
The relevant range of each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is the distance between which that [[Mesh_and_LOD#Level_Of_Detail|LOD]] becomes visible and the distance at which that [[Mesh_and_LOD#Level_Of_Detail|LOD]] is no longer displayed, clamped to a 256m circle.

<pre>
Example:
For an object with a bounding box R of 10m,
The Dhigh LOD will be displayed while the camera is within 0m to 42m from the object's center.
The Dmid LOD will be displayed while the camera is within 42m to 166.67m (10/0.24) from the object's center.
The Dlow LOD will be displayed while the camera is within 166.67m to 333.3m from the object's center.
The Dlowest LOD will be displayed while the camera is further than 333.37m from the object's center.
</pre>

==== Adjusting for missing [[Mesh_and_LOD#Level_Of_Detail|LODs]] ====
if any lod is missing, substitute bytes in next highest available [[Mesh_and_LOD#Level_Of_Detail|LOD]]. That is, if <code>BYTES_IN_MID</code> is zero, substitute <code>BYTES_IN_HIGH</code> for <code>BYTES_IN_MID</code>, and so on.

==== Computing Cost ====
At the simplest level, streaming cost is computed as:

<pre>
Streaming Cost =
( (lowest_area / total_area) * bytes_in_lowest
+ (low_area / total_area) * bytes_in_low
+ (mid_area / total_area) * bytes_in_mid
+ (high_area / total_area) * bytes_in_high ) * cost_scalar
</pre>

In the details of the implementation, the <code>cost_scalar</code> is based on a target triangle budget, and efforts are made to convert <code>bytes_in_foo</code> to an estimated triangle count.

=== Implementation ===
<cpp>
// Get the streaming cost for the given mesh
// header -- header of mesh as described in mesh asset format
// radius -- magnitude of the mesh object scale, divided by two
// bytes -- if not NULL, gets number of bytes in this mesh (for debugging)
// bytes_visible -- if not NULL, gets number of bytes in specified lod (for debugging)
// lod -- currently visible lod (for debugging)

F32 LLMeshRepository::getStreamingCost(LLSD& header, F32 radius, S32* bytes, S32* bytes_visible, S32 lod)
{
F32 max_distance = 512.f;

F32 dlowest = llmin(radius/0.03f, max_distance);
F32 dlow = llmin(radius/0.06f, max_distance);
F32 dmid = llmin(radius/0.24f, max_distance);

// discount 128 bytes to cover the cost of LLSD tags and compression domain overhead
F32 METADATA_DISCOUNT = (F32) gSavedSettings.getU32("MeshMetaDataDiscount");
// make sure nothing is "free"
F32 MINIMUM_SIZE = (F32) gSavedSettings.getU32("MeshMinimumByteSize");

F32 bytes_per_triangle = (F32) gSavedSettings.getU32("MeshBytesPerTriangle");

S32 bytes_lowest = header["lowest_lod"]["size"].asInteger();
S32 bytes_low = header["low_lod"]["size"].asInteger();
S32 bytes_mid = header["medium_lod"]["size"].asInteger();
S32 bytes_high = header["high_lod"]["size"].asInteger();

if (bytes_high == 0)
{
return 0.f;
}

if (bytes_mid == 0)
{
bytes_mid = bytes_high;
}

if (bytes_low == 0)
{
bytes_low = bytes_mid;
}

if (bytes_lowest == 0)
{
bytes_lowest = bytes_low;
}

F32 triangles_lowest = llmax((F32) bytes_lowest-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_low = llmax((F32) bytes_low-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_mid = llmax((F32) bytes_mid-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_high = llmax((F32) bytes_high-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;

if (bytes)
{
*bytes = 0;
*bytes += header["lowest_lod"]["size"].asInteger();
*bytes += header["low_lod"]["size"].asInteger();
*bytes += header["medium_lod"]["size"].asInteger();
*bytes += header["high_lod"]["size"].asInteger();
}

if (bytes_visible)
{
lod = LLMeshRepository::getActualMeshLOD(header, lod);
if (lod >= 0 && lod <= 3)
{
*bytes_visible = header[header_lod[lod]]["size"].asInteger();
}
}

F32 max_area = 102932.f; //area of circle that encompasses region
F32 min_area = 1.f;

F32 high_area = llmin(F_PI*dmid*dmid, max_area);
F32 mid_area = llmin(F_PI*dlow*dlow, max_area);
F32 low_area = llmin(F_PI*dlowest*dlowest, max_area);
F32 lowest_area = max_area;

lowest_area -= low_area;
low_area -= mid_area;
mid_area -= high_area;

high_area = llclamp(high_area, min_area, max_area);
mid_area = llclamp(mid_area, min_area, max_area);
low_area = llclamp(low_area, min_area, max_area);
lowest_area = llclamp(lowest_area, min_area, max_area);

F32 total_area = high_area + mid_area + low_area + lowest_area;
high_area /= total_area;
mid_area /= total_area;
low_area /= total_area;
lowest_area /= total_area;

F32 weighted_avg = triangles_high*high_area +
triangles_mid*mid_area +
triangles_low*low_area +
triangles_lowest*lowest_area;

return weighted_avg/gSavedSettings.getU32("MeshTriangleBudget")*15000.f;
}
</cpp>

== Issues ==
* Providing identical models for every [[Mesh_and_LOD#Level_Of_Detail|LOD]] results in a cost identical to providing a single [[Mesh_and_LOD#Level_Of_Detail|LOD]], but results in 4x the bandwidth usage.
* Changing the scale of an object changes its cost, which can be confusing.
* For viewers with a view distance greater than 256m, the clamping to 256m is unrealistic.
* Some validating of [[Mesh_and_LOD#Level_Of_Detail|LODs]] is still necessary.
** The highest [[Mesh_and_LOD#Level_Of_Detail|LOD]] must be specified.
** Each [[Mesh_and_LOD#Level_Of_Detail|LOD]] must have the same number of faces as the highest [[Mesh_and_LOD#Level_Of_Detail|LOD]].

== Related Articles ==
* [[Mesh Accounting Test]]
* [[Mesh/Mesh physics|Mesh physics]]

Mesh/Download Weight

2014-04-15T19:30:00Z

Darien Caldwell:

{{Navbox/Mesh|tech}}
== Motivation ==
Previously used methods of [[Mesh_and_LOD#Level_Of_Detail|LOD]] enforcement and [[Mesh]] cost have proved ineffective and difficult to adhere to. Proposed here is an algorithm for determining cost of a [[Mesh/Mesh_Asset_Format|Mesh asset]] (in terms of prim parcel cost) that correlates strongly to the actual load of streaming and displaying a [[Mesh]] in a general way, without making assumptions about triangle/vertex limits and ratios between levels of detail. The artist need not adhere to any arbitrary restrictions with respect to what [[Mesh_and_LOD#Level_Of_Detail|LODs]] must be supplied and what the parameters of those [[Mesh_and_LOD#Level_Of_Detail|LODs]] are, but providing proper [[Mesh_and_LOD#Level_Of_Detail|LODs]] will greatly reduce the cost of an [[Object|object]] in terms of parcel limits, effectively allowing regions with efficient content to carry more content, while regions with inefficient content can carry less. This should allow greater control from Linden Lab in terms of acceptable rendering and streaming budgets while also giving artists complete control over how they build.

== Concept ==
The streaming and rendering cost of a [[Mesh]] is directly related to the number of bytes in a [[Mesh/Mesh_Asset_Format|Mesh asset]] [[Mesh_and_LOD#Level_Of_Detail|LOD]] slot, and the likelihood that a given [[Mesh_and_LOD#Level_Of_Detail|LOD]] will be downloaded and displayed can be computed based on the size of the object. Imagine a set of 3 concentric circles centered on an object where each circle represents the transition boundary between [[Mesh_and_LOD#Level_Of_Detail|LODs]]. The streaming/rendering cost of that object can be determined by examining the size of those circles vs the number of bytes in the relevant [[Mesh_and_LOD#Level_Of_Detail|LODs]]. Uploading a high [[Mesh_and_LOD#Level_Of_Detail|LOD]] only will result in the load of the high lod being applied to the entire 256m, while uploading appropriate [[Mesh_and_LOD#Level_Of_Detail|LODs]] will result in the lion's share of 256m being applied to the lowest [[Mesh_and_LOD#Level_Of_Detail|LOD]].

== Equation ==
# Compute the distance at which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is displayed
# Compute the area in which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is relevant
# Adjust for missiing [[Mesh_and_LOD#Level_Of_Detail|LODs]]
# Scale relative weights of each [[Mesh_and_LOD#Level_Of_Detail|LOD]] based on what percentage of the [[Region|region]] each [[Mesh_and_LOD#Level_Of_Detail|LOD]] covers.
# Compute cost based on relevant range and bytes in [[Mesh_and_LOD#Level_Of_Detail|LOD]]

Traditional parametric prims have their streaming weights capped at 1.0. Sculpted prims are capped at 2.0. This only holds true as long as the Traditional prims remain under the Legacy Prim accounting system. Changing to Convex Hull Physics type, or applying Advanced Materials (Normal maps and/or Specular maps) will take Traditional prims out of Legacy prim accounting and place under the New accounting. Under New accounting their streaming cost will not be capped. [[Release Notes/Second Life Server/12#12.07.31.262785|1]]
=== [[Mesh_and_LOD#Level_Of_Detail|LOD]] Transition Distances ===
To compute the distance at which each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is displayed, take the radius of the [[Object|object]]'s bounding box (R) and divide by the [[Mesh_and_LOD#Level_Of_Detail|LOD]] ratios used in the viewer:

<pre>
Dlowest = distance at which lowest LOD begins to be displayed.
Dlow = distance at which low LOD begins to be displayed.
Dmid = distance at which mid LOD begins to be displayed.
Dhigh = distance at which high LOD begins to be displayed.

Dlowest = R / 0.03
Dlow = R / 0.06
Dmid = R / 0.24
Dhigh = 0.0

lowest_circle = max area
low_circle = PI * Dlowest ^2
mid_circle = PI * Dlow ^2
high_circle = PI * Dmid^2

lowest_area = lowest_circle - low_circle
low_area = low_circle - mid_circle
mid_area = mid_circle - high_circle
high_area = high_circle
</pre>

=== Relevant [[Mesh_and_LOD#Level_Of_Detail|LOD]] Ranges ===
The relevant range of each [[Mesh_and_LOD#Level_Of_Detail|LOD]] is the distance between which that [[Mesh_and_LOD#Level_Of_Detail|LOD]] becomes visible and the distance at which that [[Mesh_and_LOD#Level_Of_Detail|LOD]] is no longer displayed, clamped to a 256m circle.

<pre>
Example:
For an object with a bounding box R of 10m,
The Dhigh LOD will be displayed while the camera is within 0m to 42m from the object's center.
The Dmid LOD will be displayed while the camera is within 42m to 166.67m (10/0.24) from the object's center.
The Dlow LOD will be displayed while the camera is within 166.67m to 333.3m from the object's center.
The Dlowest LOD will be displayed while the camera is further than 333.37m from the object's center.
</pre>

==== Adjusting for missing [[Mesh_and_LOD#Level_Of_Detail|LODs]] ====
if any lod is missing, substitute bytes in next highest available [[Mesh_and_LOD#Level_Of_Detail|LOD]]. That is, if <code>BYTES_IN_MID</code> is zero, substitute <code>BYTES_IN_HIGH</code> for <code>BYTES_IN_MID</code>, and so on.

==== Computing Cost ====
At the simplest level, streaming cost is computed as:

<pre>
Streaming Cost =
( (lowest_area / total_area) * bytes_in_lowest
+ (low_area / total_area) * bytes_in_low
+ (mid_area / total_area) * bytes_in_mid
+ (high_area / total_area) * bytes_in_high ) * cost_scalar
</pre>

In the details of the implementation, the <code>cost_scalar</code> is based on a target triangle budget, and efforts are made to convert <code>bytes_in_foo</code> to an estimated triangle count.

=== Implementation ===
<cpp>
// Get the streaming cost for the given mesh
// header -- header of mesh as described in mesh asset format
// radius -- magnitude of the mesh object scale, divided by two
// bytes -- if not NULL, gets number of bytes in this mesh (for debugging)
// bytes_visible -- if not NULL, gets number of bytes in specified lod (for debugging)
// lod -- currently visible lod (for debugging)

F32 LLMeshRepository::getStreamingCost(LLSD& header, F32 radius, S32* bytes, S32* bytes_visible, S32 lod)
{
F32 max_distance = 512.f;

F32 dlowest = llmin(radius/0.03f, max_distance);
F32 dlow = llmin(radius/0.06f, max_distance);
F32 dmid = llmin(radius/0.24f, max_distance);

// discount 128 bytes to cover the cost of LLSD tags and compression domain overhead
F32 METADATA_DISCOUNT = (F32) gSavedSettings.getU32("MeshMetaDataDiscount");
// make sure nothing is "free"
F32 MINIMUM_SIZE = (F32) gSavedSettings.getU32("MeshMinimumByteSize");

F32 bytes_per_triangle = (F32) gSavedSettings.getU32("MeshBytesPerTriangle");

S32 bytes_lowest = header["lowest_lod"]["size"].asInteger();
S32 bytes_low = header["low_lod"]["size"].asInteger();
S32 bytes_mid = header["medium_lod"]["size"].asInteger();
S32 bytes_high = header["high_lod"]["size"].asInteger();

if (bytes_high == 0)
{
return 0.f;
}

if (bytes_mid == 0)
{
bytes_mid = bytes_high;
}

if (bytes_low == 0)
{
bytes_low = bytes_mid;
}

if (bytes_lowest == 0)
{
bytes_lowest = bytes_low;
}

F32 triangles_lowest = llmax((F32) bytes_lowest-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_low = llmax((F32) bytes_low-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_mid = llmax((F32) bytes_mid-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;
F32 triangles_high = llmax((F32) bytes_high-METADATA_DISCOUNT, MINIMUM_SIZE)/bytes_per_triangle;

if (bytes)
{
*bytes = 0;
*bytes += header["lowest_lod"]["size"].asInteger();
*bytes += header["low_lod"]["size"].asInteger();
*bytes += header["medium_lod"]["size"].asInteger();
*bytes += header["high_lod"]["size"].asInteger();
}

if (bytes_visible)
{
lod = LLMeshRepository::getActualMeshLOD(header, lod);
if (lod >= 0 && lod <= 3)
{
*bytes_visible = header[header_lod[lod]]["size"].asInteger();
}
}

F32 max_area = 102932.f; //area of circle that encompasses region
F32 min_area = 1.f;

F32 high_area = llmin(F_PI*dmid*dmid, max_area);
F32 mid_area = llmin(F_PI*dlow*dlow, max_area);
F32 low_area = llmin(F_PI*dlowest*dlowest, max_area);
F32 lowest_area = max_area;

lowest_area -= low_area;
low_area -= mid_area;
mid_area -= high_area;

high_area = llclamp(high_area, min_area, max_area);
mid_area = llclamp(mid_area, min_area, max_area);
low_area = llclamp(low_area, min_area, max_area);
lowest_area = llclamp(lowest_area, min_area, max_area);

F32 total_area = high_area + mid_area + low_area + lowest_area;
high_area /= total_area;
mid_area /= total_area;
low_area /= total_area;
lowest_area /= total_area;

F32 weighted_avg = triangles_high*high_area +
triangles_mid*mid_area +
triangles_low*low_area +
triangles_lowest*lowest_area;

return weighted_avg/gSavedSettings.getU32("MeshTriangleBudget")*15000.f;
}
</cpp>

== Issues ==
* Providing identical models for every [[Mesh_and_LOD#Level_Of_Detail|LOD]] results in a cost identical to providing a single [[Mesh_and_LOD#Level_Of_Detail|LOD]], but results in 4x the bandwidth usage.
* Changing the scale of an object changes its cost, which can be confusing.
* For viewers with a view distance greater than 256m, the clamping to 256m is unrealistic.
* Some validating of [[Mesh_and_LOD#Level_Of_Detail|LODs]] is still necessary.
** The highest [[Mesh_and_LOD#Level_Of_Detail|LOD]] must be specified.
** Each [[Mesh_and_LOD#Level_Of_Detail|LOD]] must have the same number of faces as the highest [[Mesh_and_LOD#Level_Of_Detail|LOD]].

== Related Articles ==
* [[Mesh Accounting Test]]
* [[Mesh/Mesh physics|Mesh physics]]

LlDialog

2014-03-14T19:08:13Z

Darien Caldwell: clarified language.

{{LSL_Function
|func=llDialog
|sort=Dialog
|func_id=247|func_sleep=1.0|func_energy=10.0
|inject-2=
{{Issues/VWR-17064}}
{{Issues/VWR-14537}}
{{Issues/SVC-1815}}
{{Issues/SCR-43}}
{{LSL_Function/avatar|avatar|sim=*}}
{{LSL_Function/chat|channel|message|dialog=dialog box}}
|p1_type=key|p1_name=avatar|p1_desc
|p2_type=string|p2_name=message|p2_desc
|p3_type=list|p3_name=buttons|p3_desc=button labels
|p4_type=integer|p4_name=channel|p4_desc
|func_desc=Shows a dialog box in the lower right corner of the {{LSLP|avatar}}'s screen (upper right in Viewer 1.x) with a {{LSLP|message}} and choice {{LSLP|buttons}}, as well as an ignore button. This has many uses ranging from simple message delivery to complex menu systems.
|func_footnote=When a button is pressed, the {{LSLP|avatar}} says the text of the button label on {{LSLP|channel}}. The position where the chat is generated is where the root prim of the dialog generating object was when the dialog button was pressed.
|spec
|caveats=
*This function '''only''' opens a dialog box. The script must then also register a listener on the same ''channel'' using [[llListen]] and have a [[listen]] event handler to receive the response.
*There is no way by script to kill a dialog box.
*There is no way for the script to detect if the user clicked the small <code>["Ignore"]</code> button (no chat is generated as a result of pressing this button).
*There is no way to distinguish the input from a dialog box and regular chat made by the same user.
**It is important to expect that the response may not be one of the buttons.
*In most cases, the listener will be in the same script as the llDialog, however if not, the distance between the root prim of the [[listen]]ing object and the dialog generating prim becomes a factor. If this distance greater than 20 meters when a button is pressed, the response will not be heard. See [[#Limits]].
**This limitation affects attachments too if the wearer moves more than 20 meters from where the listener is located. See [[#Limits]].
**If the [[listen]]er resides in the same script that created the dialog, then the dialog button is heard sim-wide.
----
*The '''dialog response''' (the generated chat) has its in world location at the '''root prim's global position'''.
: It can generate a listen event within 20 meters from that position.
*The listening location for a child prim in the object is either at the child prim's location or at the root prim's location
: see bugtrace JIRA [https://jira.secondlife.com/browse/SCR-43 SCR-43]

===<tt>message</tt> limits===
*{{LSLP|message}} must be fewer than 512 bytes in length and be not empty. If it is empty, [[llDialog]] will shout <code>"[[llDialog]]: must supply a message"</code> on the [[DEBUG_CHANNEL]]. If you want to create an empty message, however, you can do it legally by using a line feed as your message, as in <lsl>llDialog(avatar_key," \n",button_list,dialog_channel);</lsl> If the message length is greater than or equal to 512 bytes, it shouts (again on the [[DEBUG_CHANNEL|debug channel]]): <code>"[[llDialog]]: message too long, must be less than 512 characters"</code>; in both instances, the dialog box will not be created for {{LSLP|avatar}}.
*The client only displays 8 lines of {{LSLP|message}}. If it is longer, the dialog has a scroll bar. See [[#Appearance]].
Note: this should be 7 lines in message; one of the 8 lines is the owner and name of the object.

===<tt>buttons</tt> limits===
*If {{LSLP|buttons}} is an empty list, it will default to as if it were <code>["OK"]</code>
*If a button is named <code>["Ignore"]</code>, it will behave like the small <code>["Ignore"]</code> button of the menu (i.e. pressing it will '''not''' get <code>["Ignore"]</code> sent to the menu channel). If you need an <code>["Ignore"]</code> button in your menu and wish to have its name sent back to the script when you press it, then use spaces in the button name (e.g. <code>[" Ignore "]</code>).
*An error will be shouted on [[DEBUG_CHANNEL]], if...
**there are more than 12 buttons.
**any list item is not a string.
**any list item string length (measured in bytes, using UTF-8 encoding) is zero or greater than 24.
***In other words, a button's text when encoded as UTF-8 cannot be longer than 24 bytes or a empty string.
***This snippet can be used to truncate the string without giving an error: <code>[[llBase64ToString]]([[llGetSubString]]([[llStringToBase64]](theString), 0, 31))</code>
*The client will not display all the characters of a button if the text is wider than the text space of the button. See [[#Appearance]].
*If the script generates button labels from outside sources like inventory or object names, take care to avoid the special string <code>"!!llTextBox!!"</code>. This text, in button 0, will cause [[llDialog]] to behave as [[llTextBox]] instead.
|examples=
<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
{
touch_start(integer total_number)
{
// Kill off any outstanding listener, to avoid any chance of multiple listeners being active
llListenRemove(gListener);
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Listen to any reply from that user only, and only on the same channel to be used by llDialog
// It's best to set up the listener before issuing the dialog
gListener = llListen(-99, "", user, "");
// 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);
// Start a one-minute timer, after which we will stop listening for responses
llSetTimerEvent(60.0);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
// The user did not click "Yes" ...
// Make the timer fire immediately, to do clean-up actions
llSetTimerEvent(0.1);
}
timer()
{
// Stop listening. It's wise to do this to reduce lag
llListenRemove(gListener);
// Stop the timer now that its job is done
llSetTimerEvent(0.0);// you can use 0 as well to save memory
}
}
</lsl>
{{LSL Tip|Please make sure that you close open listeners where possible. You'll make the Second Life experience so much better when paying attention to details here.}}
{{LSL Tip|There are no built-in submenus nor pagination (like in a list with "previous" and "next") when using [[llDialog]]. You simply get one page with a max of 12 buttons, that's it. If you want a different dialog menu layout (other info and/or other buttons), you'll have to build that functionality into your script as the example below demonstrates. }}
<lsl>
string mainMenuDialog = "\nWhich settings would you like to access?\nClick \"Close\" to close the menu.\n\nYou are here:\nMainmenu";
list mainMenuButtons = ["sub 01", "sub 02", "Close"];

string subMenu_01_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 01";
list subMenu_01_Buttons = ["action 01a", "action 01b", "Close", "-Main-"];

string subMenu_02_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 02";

list subMenu_02_Buttons = ["action 02a", "action 02b", "Close", "-Main-"];

integer dialogChannel;
integer dialogHandle;

open_menu(key inputKey, string inputString, list inputList)
{
dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
dialogHandle = llListen(dialogChannel, "", inputKey, "");
llDialog(inputKey, inputString, inputList, dialogChannel);
llSetTimerEvent(30.0);
}

close_menu()
{
llSetTimerEvent(0.0);// you can use 0 as well to save memory
llListenRemove(dialogHandle);
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);
// Ensure any outstanding listener is removed before creating a new one
close_menu();
open_menu(id, mainMenuDialog, mainMenuButtons);
}

listen(integer channel, string name, key id, string message)
{
if(channel != dialogChannel)
return;

close_menu();

if(message == "-Main-")
open_menu(id, mainMenuDialog, mainMenuButtons);

else if(message == "sub 01")
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);

else if(message == "sub 02")
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);

else if (message == "action 01a")
{
//do something
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 01b")
{
//do something else

//maybe not re-open the menu for this option?
//open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 02a")
{
//do something
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
else if (message == "action 02b")
{
//do something else
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
}

timer()
{
close_menu();
}
}
</lsl>
|helpers=<lsl>//Compact function to put buttons in "correct" human-readable order
integer channel;

list order_buttons(list buttons)
{
return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4)
+ llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

default
{
state_entry()
{ // Create random channel within range [-1000000000,-2000000000]
channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llListen(channel,"", "","");
}

touch_start(integer total_number)
{
llDialog(llDetectedKey(0),"\nPlease choose an option:\n",
order_buttons(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]),channel);
}

listen(integer _chan, string _name, key _id, string _option)
{
llSay(0, _name + " selected option " + _option);
}
}</lsl>
<lsl>
list make_ordered_buttons(integer input)
{
string output;

if (input == 12) output = "10, 11, 12, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 11) output = "10, 11, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 10) output = "10, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 9) output = "7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 8) output = "7, 8, 4, 5, 6, 1, 2, 3";
else if (input == 7) output = "7, 4, 5, 6, 1, 2, 3";
else if (input == 6) output = "4, 5, 6, 1, 2, 3";
else if (input == 5) output = "4, 5, 1, 2, 3";
else if (input == 4) output = "4, 1, 2, 3";
else if (input == 3) output = "1, 2, 3";
else if (input == 2) output = "1, 2";
else if (input == 1) output = "1";

// when we want to return [] avoid returning [""] here

if (output == "") return [];
/* else convert output */ return llCSV2List(output);
}

// Usage:

llDialog(id, "dialog message", make_ordered_buttons(5), -37812);

// Output:

// - - -
// - - -
// - [ 4 ] [ 5 ]
// [ 1 ] [ 2 ] [ 3 ]
</lsl>
=== Helper Functions ===
{{{!}}
{{LSL DefineRow||[[User:Void_Singer/Functions#uDlgBtnPagList|uDlgBtnPagList]]|Compact Pagination for [[llDialog]] lists, remenu, and multi-user support}}
{{!}}}
|constants={{#vardefine:constants_nb}}
{{{!}}
{{!}}- valign="top"
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="4" {{!}} Button Order
{{!}}-
{{!}}9  
{{!}}10
{{!}}11
{{!}}-
{{!}}6
{{!}}7
{{!}}8  
{{!}}-
{{!}}3
{{!}}4
{{!}}5
{{!}}-
{{!}}0
{{!}}1
{{!}}2
{{!}}}
{{!}}
{{!}}}
|related
|notes=
To use dialog boxes to make menu systems, see [[Dialog Menus|Dialog Menus: A step by step guide]] (aimed at learners).

===Tips===
It is a good idea to use a very negative channel (if never more negative than the most negative 32-bit integer that is -2,147,483,648), ''e.g.'',
<lsl>// Create random channel within range [-1000000000,-2000000000]
integer channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llDialog(llDetectedKey(0), "Please choose one of the below options:",
["Yes", "No", "0", "1"], channel);</lsl>
Negative channels are popular for script communications because the standard SL client is unable to chat directly on those channels. The only way to do so prior to [[llTextBox]] was to use [[llDialog]] which was limited to 24 bytes. (Several third party viewers can access them from the chat bar.)

You can be reasonably confident that all of your scripted objects have a unique chat channel with this small function:

<lsl>integer dialog_channel; // top of script in variables

integer channel() { // top of script in functions
return (integer)("0x"+llGetSubString((string)llGetKey(),-8,-1));
}

dialog_channel = channel(); // somewhere in actual script execution, such as state_entry()</lsl>

'''Note:''' Since this function uses public information to generate the channel number it should by no means considered secret.

The preceding code can produce both positive and negative channels, depending on the 8th to last character of the key.
The following examples will always produce negative channels:-
<lsl>
gChannel = 0x80000000 | (integer)("0x"+(string)llGetKey());
gChannel = 0x80000000 | (integer)("0x"+(string)llGetOwner());
</lsl>

This next version returns a channel number between -1073741823 (0xBFFFFFFF) and -2147483648 (0x80000000). It is also only one line of code.
<lsl>privchan = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;</lsl>

===Appearance===

If {{LSLP|message}} requires more than 8 lines, a vertical scroll bar will appear in the dialog.
: In viewer 3 there is no scroll bar, only the 512 chars message limit is effective, so you may show more than 40 short lines in the message
: Too many lines will hide some of the buttons or all of them outside the window though

The message text can be formatted somewhat using "\n" (for newline) and "\t" (for tab). If URLs are in the text, they will appear as clickable links, and some [[Viewer URI Name Space|viewer application URLs]] will receive special formatting. (Clickable links were not available before Viewer 2.) You can do nothing though to influence the font face, size or weight.

There is no way to change the actual size of the dialog, nor change its color.

The average number of characters that can be displayed on a dialog line is about 35 characters per line in ASCII7 characters. It depends upon the width of the characters, the viewer version, and font settings.

The number of characters that can be displayed in a button depends upon the width of the characters. You should expect around 10 chars, give or take, not the full 24 in the button definition. The full button definition IS said, up to 24 chars, into the chat channel even though fewer characters may be displayed in the button itself.

===Limits===

My testing shows the a Dialog box now works anywhere in the same Region as the object OR any region it hands you off to (e.g. the region you teleport to). It will not work for any subsequent hand offs. I have tested this with teleport only, I haven't tested it walking between regions.

I've tested from the next SIM with an Alt, and from 2 SIMs away myself. Both worked without restriction apart from some lag on the messages. (OQ).

|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
{{LSL DefineRow||[[llRegionSay]]|}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the specified user}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Dialog Menus|Dialog Menus: A step by step guide]]|A walk through of the entire dialog menu process (aimed at learners).}}
|cat1=Chat
|cat2=Communications
|cat3=Dialog
|cat4}}

User talk:Omei Qunhua

2014-02-05T21:30:31Z

Darien Caldwell: /* Memory Module */

An appeal:

When submitting sample scripts (or editing existing samples) PLEASE ensure you've tested the resulting script.
There can be no excuse for blindly editing and not testing, and certainly no excuse for submitting scripts that won't even compile!
[[User:Omei Qunhua|Omei Qunhua]] 09:02, 9 December 2012 (PST)

:I wholeheartedly agree. I have been guilty of the sin but I agree. lslint and lsleditor are our friends. I noticed you mentioned that some edits have been breaking examples. If that happens, please make a note of it somewhere, we need to keep track of this so we can halt any negative trends. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 08:34, 14 December 2012 (PST)

::Well if you want to observe a negative trend, the following Wiki pages / examples were all corrupted by the same person :)
<pre>
Wiki Page Date Corrupted Nature of Error

Gun Script 18-Oct-12 Compile error

llGetAgentList 8-Dec-12 Compile error

llGetAgentList 9-Dec-12 Run-time bad results

llDialog 24-Sept-12 Compile error

11SetLinkAlpha 30-Sept-12 Compile error

llGetLinkInventoryPermMask 25-Nov-12 Compile error

llResetOtherScript 24-Sept-12 Run-time error

llGetSimStats 8-Dec-12 Compile error

llRequestURL 24-Sep-12 Compile error

llSetKeyframedMotion 24-Sep-12 Run-time error

llEvade 4-Dec-12 Compile error

llGetClosestNavPoint 4-Dec-12 Compile error

llGetNotecardLine 23-Sept-12 Run-time bad results

StringIsNum 7-Oct-12 Compile error

Sensor 28-Oct-12 Compile error and Run time wrong results

</pre>

(I've also corrected 4 other non-compilable or faulty example scripts by other editors, where the errors have existed since July 2012, March 2008, and Sept 2007)

[[User:Omei Qunhua|Omei Qunhua]] 15:26, 18 December 2012 (PST)

:I have take a look at all his changeings in the example scripts and do not agree with the most, Everywhere he remove inside the sub-if's the clamps and resort the events. The most of the experienced scripters do not realy read it, but for beginners i think its bad when they not see where are the clamps necessary and where not. [[User:Daemonika Nightfire|Daemonika Nightfire]] 10:19, 20 December 2012 (PST)

:I disagree with the way you say a script is "faulty" You do not clearly state your reasoning which is debatable because it's based on your own personal preference. --[[User:Ackley Bing|Ackley Bing]] 10:12, 14 February 2013 (PST)

::It's not a matter of "personal preference". If a script doesn't compile, or gives wrong results at run-time, then it's faulty. [[User:Omei Qunhua|Omei Qunhua]] 03:22, 15 February 2013 (PST)

== More size constructs ==

I've confirmed your results and made a few more tests of size optimization constructs.

x=-~x; 6 bytes (equivalent to ++x)
x=~-x; 6 bytes (equivalent to --x)
y=-~x; 6 bytes (equivalent to y=x+1)
if(~x); 7 bytes (equivalent to if(x!=-1))
x*2; 8 bytes (equivalent to x<<1)
x=-~-~x; 8 bytes (equivalent to x+=2)
x=~-~-x; 8 bytes (equivalent to x-=2)
y=x+1; 10 bytes
x=x*2; 10 bytes (equivalent to x=x<<1)
x*=2; 10 bytes
if (!~x); 10 bytes (equivalent to if(x==-1))
if(x&0x80000000) 12 bytes (equivalent to if(x<0) for integers)
if(x<0); 13 bytes
x=x<<1; 14 bytes
if(x!=-1); 17 bytes

For float x:

x=0; 9 bytes
x=0.0; 12 bytes

For vector x:

x=<0, 0, 0>; 27 bytes
x=<0.0, 0.0, 0.0>; 36 bytes
x=ZERO_VECTOR; 36 bytes

for list x:

llGetListLength(x); 40 bytes
x!=[]; 13 bytes (note: only list LENGTH is compared - actually subtracted. That returns 0 for empty list.)
x==[]; 13 bytes
if(x==[]); 17 bytes
if(x!=[]); 17 bytes
x!=[""]; 23 bytes (note: only list LENGTH is compared - actually subtracted. That returns -1 for empty list.)
x==[""]; 23 bytes (true if x has 1 element)
x!=[[]]; 23 bytes (list may not contain lists but this is allowed?!?!)
x==[[]]; 23 bytes
if(x==[""]); 27 bytes
x!=[1]; 28 bytes (true if x has 1 element)
if(x==["","",""]); 47 bytes
if(x!=["","",""]); 47 bytes
if(llGetListLengt(x)==1); 53 bytes
if(llGetListLengt(x)!=1); 56 bytes
if(x==["","","",""]); 57 bytes

Some of those may be worth being included in [[LSL Hacks]], which I'd say is the place for code size optimization. Your list results are run time size related and thus worth being included as an update to [[LSL Script Memory]]. --[[User:Pedro Oval|Pedro Oval]] 09:35, 29 December 2012 (PST)

:Wow some of those are really interesting. I would venture the reason float zero is so expensive is how it's being encoded (there are several ways to encode floats in IL). They haven't optimized the zero case. I'm very surprised that x * 2 is less than x << 2. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:28, 29 December 2012 (PST)
::Well try these for size ... x+x; 4 bytes, x=x+x; 6 bytes, x=x^x; 6 bytes. Food for thought! [[User:Omei Qunhua|Omei Qunhua]] 06:05, 30 December 2012 (PST)
:::VERY interesting, thank you!!! --[[User:Pedro Oval|Pedro Oval]] 12:11, 30 December 2012 (PST)

Some more interesting results (all for LOCAL variables) [WITHDRAWN - SEE BELOW]

<strike>integer a; 49 bytes
integer a=0; 53 bytes
string a=""; 53? 55? bytes (I'm unsure if there's a preexisting instance of "" or not - my measuring method can't tell)
string a; 53? 55? bytes
string a="a"; 53 bytes plus 2*(num characters+1) per each different string (equal strings are referenced just once)
float a=0; 54 bytes
list a; 55 bytes
list a=[]; 55 bytes
float a; 57 bytes
float a=0.0; 57 bytes
key a=""; 60? 61? 62? bytes (same problem as string)
key a="string"; 60? bytes + 2*(num_characters+1) per each different string</strike>

Braces don't seem to add anything: <code>{integer a;}</code> occupies the same size as <code>integer a;</code> and so on. Since the string case is complex, let me put an example. <code>string a="aaa"; string b="aaa";</code> will use 53+53+2*(3+1)=114 bytes, because the string is the same in both cases and it's reused, but <code>string a="aaa"; string b="bbb";</code> will use 53+53+2*(3+1)+2*(3+1)=122 bytes because the strings are different.

I'm getting inconsistent results with the keys. Something else seems to be going on. I get 61 bytes sometimes and 60 others. Wonder if there's a byte alignment problem. If so, that could make some of the previous measurements incorrect, even if they looked consistent. --[[User:Pedro Oval|Pedro Oval]] 13:40, 29 December 2012 (PST)

:Using the measurement method you suggested (or perhaps a variation), I have determined that an empty string uses 6 bytes always, while a 1 or 2 character string uses 10 bytes for the first appearance and 6 for the rest, and a 3 or 4 character string uses 14 bytes for the first appearance and 6 for the rest. Further testing suggests that string constants in code are allocated 4 bytes at a time.

:The previous results for local variable declarations can't be considered reliable. With this measurement method I get many variations for keys and strings: 132 bytes for the first appearance of <code>key x=""</code>, 56 for the second, 66 for the third... and also crazy for strings. I just withdraw the results. With integer I also got inconsistencies.: 43 bytes when measured with this method. What seems clear is that there's one implicit assumption wrong and I don't know which one or why. I guess a better understanding of CIL would help me interpret those results. Not sure if I'm willing to dive into that though. --[[User:Pedro Oval|Pedro Oval]] 14:44, 1 January 2013 (PST)

== llGetSubString ==

I obviously did not review that edit! wtf were they thinking? Thank you. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:08, 3 January 2013 (PST)

== UTF-8 ==

UTF-8 characters can be more than 2 bytes, by the original standard, used by LSO, they can by 5 bytes. UTF-8 supported by Mono supports up to 4 bytes per character. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:31, 14 January 2013 (PST)

::Yes I know. That's why I quoted an example of a 2-byte UTF-8 when giving 512 as a UTF-8 limit. I didn't want to go into a full explanation on every page. Just wanted to give some clue that 1024 bytes doesn't necessarily give 1024 characters (and an opportunity to correct the 1023 to 1024). Maybe a link to a page on UTF-8 would be appropriate. But I think the current UTF-8 page needs overhauling. It starts by saying "SL uses UTF-8 for storing and transmitting strings" which I think is no longer always true (i.e. storage in Mono) then the UTF-8 page gets hijacked with complex code examples concerning Unicode which maybe appeal to 0.1% of Wiki's users. We need to sort the basics out on SO MANY Wiki pages, before leaping into hyperspace. And that's been the impetus behind my sudden burst of editing activity over 5 weeks. (IMHO, LOL) [[User:Omei Qunhua|Omei Qunhua]] 00:26, 15 January 2013 (PST)

== Wiki editing ==

I'm not sure why you feel the need to insult other editors with every other edit summary but I wish you all the best and merry christmas. Hopefully you can find some time to loosen up during the holidays. Best regards -- [[User:Kireji Haiku|Kireji Haiku]] 14:29, 19 December 2013 (PST)

::I just stated a fact. If you find that insulting, well ....

::I don't understand why you are intent on driving the Wiki further and further from reality. You're just making it an academic non-practical source of your own personal preferences, at odds with what 99.9% of coders do and I'm sure will continue to do. [[User:Omei Qunhua|Omei Qunhua]] 16:00, 21 December 2013 (PST)

I personally don't care either way with PUBLIC_CHANNEL and I didn't view the edit comments as insulting (the field encourages brevity, which can be mistaken as insult). I don't use it myself and I doubt many people do but many people don't use <code>~llSubStringIndex()</code>, they use <code>llSubStringIndex() != -1</code> or the new fangled <code>llSubStringIndex() != [[ERR_GENERIC]]</code>. Just because it's "ugly" doesn't make it wrong. So that we don't fight over these trivialities we should take the viewpoint that if they are already existing in articles we should not change them unless we are replacing the entire line. I'm ok with grammar and punctuation getting corrected but do keep in mind that grammar and punctuation are artificial rules created by man, and these rules can be redefined at anytime as well. What is grammatically incorrect today may be grammatically correct tomorrow, so grammatical correctness isn't the most important thing. There are however about 600 unloved articles in {{LSLGC|Needs Example}} (I'm amazed it's only 600 btw). So if you get bored and feel the desire to correct something minor, consider writing an example and spread a little joy to the unloved. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 15:15, 19 December 2013 (PST)

::I feel passionately that PUBLIC_CHANNEL should NOT be promoted in the Wiki - and this is NOT because that is my own personal preference, but it is the established preference of thousands of scripters as demonstrated in millions of scripts in-world and on script libraries. Kireji I am sure feels passionately that PUBLIC_CHANNEL should be promoted - but I venture to suggest that that IS due to his own individual and personal preference. I've noticed ERR_GENERIC creeping in, and that again is at odds with practically all actual scripts, although I'm less unhappy about it, in some situations. Sure I love mnemonics like CHANGED_REGION_START as most scripters would. As I say, the Wiki is in danger of becoming an academic tome, divorced from reality. :( Also, as pointed out before, we tend to have to explain that PUBLIC_CHANNEL means 0, whereas for example one would need to explain that 0x400 means CHANGED_REGION_START. That difference highlights the problem in a nutshell. Oh, and following on from your comments, Strife, the same logic dictates that where llSay(0, .... etc. exist in Wiki articles, they shouldn't be routinely changed to PUBLIC_CHANNEL. [[User:Omei Qunhua|Omei Qunhua]] 16:04, 19 December 2013 (PST)

:::Yes, the logic does, my condemnation is not aimed at any one party. But we have bigger problems. Dryness is one of those problems. The small number of editors is another. I'd say that Examples should be a top priority but I've never been able to make it one of mine. I don't have solutions to these problems. At some point we should have a meeting. My current projects include: parameter/subtype categories and haiku. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:04, 19 December 2013 (PST)

::::"unless we are replacing the whole line" - and please, only replace that line if it's faulty, not just to propagate a personal style. Unfortunately that propagation has been going on for 15 months without anyone commenting until I started squirming a bit and seemed to become the target for criticism (the current condemnatory remarks appear in my own talk page). You say you have no preference, Strife, but your consistent use of llSay(0, in your own examples does suggest a preference. There are so many other unnecessary edits that have taken place over the same period, where there has been no corrective aspect. (float) FALSE is horrid, as are inserted lines of // { or // } ... or just adding the //. Awful. By all means, let's use our favoured styles on our own pages, or in examples that we originate ourselves. Enough. I'll go look at your list of the 600 unloved ... LOL. (But perhaps all those corrupted examples should be returned to their pristine states ^^). [[User:Omei Qunhua|Omei Qunhua]] 09:19, 20 December 2013 (PST)

:::::Yeah the (float)FALSE thing... I have trouble seeing a good reason to use it. Oh I can understand that it might uses less bytecode but for the love of monkeys put it in the optimization article. That said, I am guilty of using (integer)"" in the past in code that was highly optimized (for LSO, yes I really did need every byte). Not really keen on whitespace changes either but I don't have a strong feeling. I wonder if we should considering protecting the diversity of programming styles in the articles. This way it gives the wiki a feel that real people actually wrote the examples and that they weren't extruded from some hideous creature's bum. It will be dangerous as it will be hard to define what is good diversity and what is bad content but it should be interesting. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:30, 20 December 2013 (PST)

::"What is grammatically incorrect today may be grammatically correct tomorrow" - LOL. So that's an excuse to write appallingly? No thanks! But I do think there could be a lot of merit in preserving the programming styles exhibited by example originators, as you suggest. [[User:Omei Qunhua|Omei Qunhua]] 16:00, 21 December 2013 (PST)

:::Fixed a bug in Constants, fewer articles should be showing up now in {{LSLGC|Needs Example}}. {{LSLGC|FixMe}} if you are wondering is where all the broken articles go. Most are constants in need of descriptions (others are constants in need of syntax examples like you would see on the like [[PRIM_NAME]]). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:28, 23 December 2013 (PST)
:::P.S. Yeah it's a slippery slope and I don't buy it entirely either.

Further to suggesting that editors try to stick with the coding style used by an article originator, I was going to say that first of all the original writers should abide by an overall style guide agreed for the Wiki, such as [[https://wiki.secondlife.com/w/index.php?title=LSL_Style_Guide&oldid=1181778 StyleGuide]]. Unfortunately I see that that page has been 'hijacked' to promote one person's eccentric views. Proposed changes to the main style guide should FIRST be discussed in the corresponding discussion page. We can't have one person unilaterally declaring a style without discussion. So ... first we seriously need a 'committee' approach to defining an overall style guide. It's been said elsewhere that contributors are not going to want to rewrite their programs to comply with a Wiki style different to their usual practice. Personally I don't find that onerous, and I favour a more rigorous insistence on a unified style throughout. [[User:Omei Qunhua|Omei Qunhua]] 04:04, 24 December 2013 (PST)

: I do not know how I overlooked this but It appears I forgot to codify any syntax guidelines into the [[LSL Portal Guidelines]]. For now I'll just shove something onto [[LSL_Style_Guide#LSL_Portal_Style]]. Thoughts? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 02:19, 25 December 2013 (PST)

I started tackling some of the "need examples" pages, but quickly felt that adding an example for each individual mnemonic constant was not necessary. Indeed having a separate page for each seems seriously OTT. [[User:Omei Qunhua|Omei Qunhua]] 06:01, 27 December 2013 (PST)

:Do what you think is best, if it doesn't really need an example, skip it. I will not deny it was OCD to mandate that every constant have an article, nor that it might be a tiny bit excessive but I will argue with it being Over The Top.

:For some constants there is no benefit to having individual articles. If we were to deny all constant articles, we would end up with all function articles being at best [[llParticleSystem]] and at worst double what [[llSetPrimitiveParams]] (because llSetPrimitiveParams would become even worse). In the beginning I pushed for articles for constants because on the LSL Wiki it was hard to find information about constants. Not only was the information buried in function articles (which had no unifying layout so it could by literally be anywhere in the article), if the constant was used by multiple overlapping functions the information might be out of sync. It made maintaining the content very annoying. Personally I'd rather fill the wiki with stubs and let people flesh them out into articles if they want, than leave them digging and wishing for more. While we could come up with rules o how to decide which constants get articles and which don't, I don't think we gain anything by doing so ([[llParticleSystem]] is not one of my articles and I view it as grandfathered).

:Trying to shoe horn information about constants into articles has always been hard and it was especially hard on the LSL Wiki. You might want to add a single sentence of information but to do so might require refactoring a significant amount of the article. Here you can just post the sentence to the dedicated article and not have to worry so much about squeezing it in. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:08, 27 December 2013 (PST)

:Again, not sure why you feel the need to undo wiki contributions. Replacing channel 0 with [[PUBLIC_CHANNEL]] does not change the code style. If you strongly believe such edits shouldn't be done by others, same would go for your edits ... which go the other way around. The reason using constants is to enhance readability, making it easier for beginners. It's a lot easier to do a find and replace to get rid of [[PUBLIC_CHANNEL]] and to save byte-code than to look up what channel 0 is. Just my two cents. -- [[User:Kireji Haiku|Kireji Haiku]] 06:54, 31 December 2013 (PST)

::Kireji, YOU are the one undoing Wiki contributions. I am merely agreeing that the original style (I use the word loosely) chosen by contributors should be preserved unless there is a very good reason (basically an error) that needs correction. Your use of PUBLIC_CHANNEL is nothing more than a personal fad, and the Wiki is not the place for such indulgences. [[User:Omei Qunhua|Omei Qunhua]] 07:28, 31 December 2013 (PST)

== PUBLIC_CHANNEL vs Zero ==
Seeing as this topic hasn't settled down, it's time for the larger community to choose. I view their decision (even if it's Pie) as binding.
http://www.sluniverse.com/php/vb/scripting/91061-wiki-public_channel-vs-zero.html
-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:15, 1 January 2014 (PST)

:It isn't just about PUBLIC_CHANNEL. It is about one individual tampering with hundreds of perfectly valid existing scripts, purely to impose exceptional ideas they originated, regardless of the demonstrated preferences of hundreds of contributors, many of whom are probably no longer here to defend themselves. I thought you and I had agreed, Strife, that edits should not unnecessarily change script examples unless to correct definite errors. So, if I vote in your survey, it will be for zero, but the survey misses the important point. The survey should be "Should one individual be allowed to edit script examples purely to impose personal preferences, and not in order to fix problems?" A Wiki is supposed to be a collaborative project. When one person rampages through it, insisting on their own views on every conceivable page, it ceases to be collaborative. [[User:Omei Qunhua|Omei Qunhua]] 02:19, 1 January 2014 (PST)

::My goal is to start small and work our way up. If this gets things moving in a positive direction, good. If things degrade, the stage is set for the next act. Look at what Void said, we've got the community thinking. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:50, 1 January 2014 (PST)

== llRezAtRoot ==

I think you missed the context, which is "offline building rights", you can't be offline and on the land at the same time. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 01:42, 4 January 2014 (PST)

:hummm. Well then, what is the correct wording for the note that effectively says "To have offline building rights, you need to allow everyone to build" ? And "Be" doesn't necessarily have to apply to an avatar, it can apply to the script doing the rezzing. No? [[User:Omei Qunhua|Omei Qunhua]] 03:46, 4 January 2014 (PST)

::Ahhh. I see my issue. I focused on the wrong part. It's still screwed up. I'll fix it. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 21:07, 4 January 2014 (PST)

:That does look better. But i still don't fully understand (excuse me for being a bit thick). Why do I need OFFLINE building rights to run a script with llRezAtRoot? Only if I'm actually offline surely. Not while I'm scripting and testing while online? [[User:Omei Qunhua|Omei Qunhua]] 08:27, 5 January 2014 (PST)

::I can't think of a situation where you would have build rights online and not offline but there may be one. There may be a gray goo restriction. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 11:16, 5 January 2014 (PST)

:Oh dear :( Then what is the significance of calling it "offline"? I had started to think this related to the observed situation where a script of mine can't rezz a prim unless I'm online. If there's no difference between online and offline building rights, then just call it building rights, as it is usually known. No? [[User:Omei Qunhua|Omei Qunhua]] 11:54, 5 January 2014 (PST)

Thank you. Yes, English is not my native language. I know about my ortographic problems, but I don't know how to activate a corrector or something similar. How do I make errors to be highlighted? Please tell me, that will be a great help.

--[[User:Anaimfinity Resident|Rays of green light. Bright and proud to be a Circassian]] 10:44, 3 February 2014 (PST)

== Memory Module ==
I'm afraid your characterization of sim and viewer events as 'rare' is inaccurate. It happens to thousands on a daily basis. Not to mention, the statement "such an event is likely to be more catastrophic than just the loss of variables would imply, it may not be worth trying guard against it." is extremely misleading, bad practice, and really amounts to nothing more than an opinion. Script state rollbacks are not catastrophic. They only result in a lack of data. Data which could be safeguarded against with the techniques described on the page. They certainly aren't the *only* way such safeguards can be implemented, but they are a valid way. If you think you know a better way, it would be more constructive to make a page about that, instead of vandalizing someone else's page.

I had many problems with your original statements, but I had enough respect for you that I did not change any of your wording. I only added on balance. I expect the same respect from you. But if you touch it again, Gloves off.

User talk:Omei Qunhua

2014-02-05T21:27:28Z

Darien Caldwell:

LlSetMemoryLimit

2014-01-31T04:25:23Z

Darien Caldwell: Undo revision 1187387 by Darien Caldwell (Talk) Was correct to begin with.

{{LSL_Function
|func_id=???|func_sleep=0.0|func_energy=???
|func=llSetMemoryLimit
|p1_type=integer|p1_name=limit
|return_type=integer|return_subtype=boolean
|func_desc=Request {{LSLP|limit}} bytes to be reserved for this script.
|Return_text=[[TRUE]] if the memory limit was successfully set (or [[FALSE]] if not).
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM.

;Mono:Sets the memory limit for the script.
* The memory limit can be set up to 64k.
* The memory limit can not be set lower than the memory currently in use by the script.
* All new scripts start with a limit of 64k
* All existing scripts have a limit of 64k
* A lower limit will effect the amount of memory reported in the viewer UI and by [[llGetObjectDetails]].
* The memory limit is not the amount of real memory actually used by the script, just the upper limit on it.

;LSO:Has no effect on LSO scripts which will always use exactly 16k
|caveats=
;Mono:When '''''n''''' is too small, llSetMemoryLimit('''''n''''') is ignored and the memory limit is not changed
|examples=
<lsl>
// Memory-walkthrough by Daemonika Nightfire (daemonika.nightfire)

integer limit = 20000; // <- bytes

Test()
{
llSetText("Limited Memory " + (string)llGetMemoryLimit() +
"\nUsed Memory " + (string)llGetUsedMemory() +
"\nFree Memory " + (string)llGetFreeMemory(),<1,1,1>,1);
}

default
{
state_entry()
{
llSetMemoryLimit(limit);

llScriptProfiler(PROFILE_SCRIPT_MEMORY);
Test();
llScriptProfiler(PROFILE_NONE);

llSay(0,"This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test.");
}
}

// Result:

// Floating Text:
// Limited Memory 20000
// Used Memory 4972
// Free Memory 15100

// Chat:
// [05:11] Object: This script used at most 4972 bytes of memory during Test.
</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llScriptProfiler]]|}}
{{LSL DefineRow||[[llGetSPMaxMemory]]|}}
{{LSL DefineRow||[[llGetMemoryLimit]]|}}
{{LSL DefineRow||[[llGetFreeMemory]]|}}
{{LSL DefineRow||[[llGetUsedMemory]]|}}
{{LSL DefineRow||[[llGetObjectDetails]]|}}
|also_events
|also_tests
|also_articles
|notes
|history=*Scheduled for [[Beta/Magnum|RC Magnum]] channel, week of August 3, 2011.
|lso
|cat1=Script
|cat2=Memory
|cat3=Script Profiler
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/11#11.08.10.238207 | 10/08/2011 ]]
}}

LlGetObjectDetails

2014-01-31T04:23:56Z

Darien Caldwell: Fixed the fix (oops)

{{LSL_Function
|inject-2=
{{LSL_Function/limits}}{{LSL_Function/uuid|id|sim=*}}
{{Issues/SCR-87}}{{Issues/SVC-7592}}
|func_id=332|func_sleep=0.0|func_energy=10.0
|func=llGetObjectDetails
|p1_type=key|p1_name=id|p1_desc= or adjacent regions[[#id_Parameter|*]]
|p2_type=list|p2_name=params|p2_desc=OBJECT_* flags
|return_type=list|return_text=of the details for '''id''', specifically those requested in '''params'''.
|func_footnote=An empty list if '''id''' is not found.{{PBR}}
{{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is returned when passed an invalid integer parameter.
|spec=<div style="padding: 1px; float: left;">[[Image:LlGetObjectdetails-avatar-range.png|thumb|none|250px|Avatar detection range for SL Server 1.34]]</div>
<h5 style="margin:0;">id Parameter</h5>
'''id''' holds the UUID of the avatar or prim this function is going to get the details of.

If '''id''' is not found in the region, adjacent regions are searched for avatars which match '''id'''. An avatar is only considered to have been found if it is inside the region, or within a 34 meter zone outside the region boundaries (see diagram). A single valid result may be returned after the avatar leaves this zone.

<h5 style="margin:0;">params Parameter</h5>
The '''params''' list is used to indicate which object attributes of interest. The order they are supplied in determines the order of the corresponding return values in the return list.
{{{!}} cellpadding="0" cellspacing="0"
{{!}}
*If '''params''' contains unsupported integer values, {{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is placed in the output list.
*If '''params''' contains non-[[integer]] types, those values will be silently ignored.
{{!}}}
<div style="clear:both;"></div>
|caveats=

*OBJECT_ROT will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise.
*Adjacent regions are not searched for prims which match '''id'''.
*Information for avatars that can no longer be found will still be available for a short period (about 45 seconds) but it is not updated.
*Items in '''params''' that are not integers are silently ignored, {{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is not returned.
*This function does not return information about items in inventory.
*[[llTargetOmega]] will only effect the return of [[OBJECT_ROT]] if the object is [[STATUS_PHYSICS|physical]]. If the object is not physical then the original start rotation is returned, [[llTargetOmega]] is a {{LSLGC|Effects|client side effect}}.
*{{LSL Const|OBJECT_SCRIPT_MEMORY|integer|11|c=}} reports the actual memory that all scripts in an object use. Mono scripts can set a memory limit lower than the maximum by using [[llSetMemoryLimit]]. As this value is accurately reported, the value returned by [[llGetObjectDetails]] is accurate to within 1024 bytes.
*{{LSL Const|OBJECT_RUNNING_SCRIPT_COUNT|integer|9|c=}} includes crashed scripts in its count.
|examples=
<lsl>default
{
collision_start(integer i)
{
list a = llGetObjectDetails(llDetectedKey(0), ([OBJECT_NAME,
OBJECT_DESC, OBJECT_POS, OBJECT_ROT, OBJECT_VELOCITY,
OBJECT_OWNER, OBJECT_GROUP, OBJECT_CREATOR]));
llWhisper(0,"UUID: " + (string)llDetectedKey(0) +
"\nName: \"" + llList2String(a,0) + "\"" +
"\nDescription: \"" + llList2String(a,1) + "\"" +
"\nPosition: " + llList2String(a,2) +
"\nRotation: " + llList2String(a,3) +
"\nVelocity: " + llList2String(a,4) +
"\nOwner: " + llList2String(a,5) +
"\nGroup: " + llList2String(a,6) +
"\nCreator: " + llList2String(a,7));
}
}</lsl>
<lsl>
// group join inviter
// gets the name of the object's active group from the online group profile

key groupNameRequestId;
key groupKey;
string groupName;

init()
{
// WARNING:
// different prims can have different active groups!!!

// get the key of the root prim's group
groupKey = llList2Key(llGetObjectDetails(llGetLinkKey(LINK_ROOT), [OBJECT_GROUP]), 0);

// request the name of the root prim's group
groupNameRequestId = llHTTPRequest("http://world.secondlife.com/group/" + (string)groupKey, [], "");
}

default
{
state_entry()
{
init();
}

touch_start(integer num_detected)
{
if (groupKey == NULL_KEY || groupName == "")
return;

key id = llDetectedKey(0);
llInstantMessage(id,
"Click the link to join the group '" + groupName + "'\n"
+ "secondlife:///app/group/" + (string)groupKey + "/about");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id != groupNameRequestId)
return;

list args = llParseString2List(body, ["title"], []);
groupName = llList2String(llParseString2List(llList2String(args, 1), [">", "<", "/"], []), 0);
}
}
</lsl>
<lsl>// aim & shoot
default
{ state_entry()
{ llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}
control(key id, integer pressed, integer change)
{ if(change & pressed & CONTROL_ML_LBUTTON)
llSensor("", "", AGENT|PASSIVE|ACTIVE, 96.0, PI/16.0);
}
run_time_permissions(integer perm)
{ if(perm&PERMISSION_TAKE_CONTROLS)
llTakeControls(CONTROL_ML_LBUTTON, TRUE, TRUE);
}
sensor(integer n)
{ key uuid=llDetectedKey(0);
list a = llGetObjectDetails(uuid, ([
OBJECT_NAME, OBJECT_DESC, OBJECT_POS, OBJECT_ROT,
OBJECT_VELOCITY,OBJECT_OWNER, OBJECT_GROUP, OBJECT_CREATOR]));
llOwnerSay("UUID: " + (string)uuid +
"\nName: \"" + llList2String(a,0)+ "\"" +
"\nDecription: \"" + llList2String(a,1) + "\"" +
"\nPosition: " + llList2String(a,2) +
"\nRotation: " + llList2String(a,3) +
"\nVelocity: " + llList2String(a,4) +
"\nOwner: " + llList2String(a,5) +
"\nGroup: " + llList2String(a,6) +
"\nCreator: " + llList2String(a,7)
);
}
}</lsl>
<lsl>// Object Script Time
default
{
touch_start(integer num_detected)
{
llOwnerSay(llGetObjectName()+" Script Time: "+llList2String(llGetObjectDetails(llGetKey(), [OBJECT_SCRIPT_TIME]), 0));
}
}
</lsl>
|spec
|constants={{LSL Constants/Object Details}}
|helpers=See {{LSLGC|Link/Get}} for some {{LSLGC|Link|link}} related helper functions. Also see [[llGetLinkPrimitiveParams]] if you need to get the position and rotation of a linked prim.
<lsl>
integer isLindenTreeOrGrass(key id){
//Check if it's an OPT_OTHER and not an attachment, which makes it a Linden tree or grass!
list out = llGetObjectDetails(id, [OBJECT_PATHFINDING_TYPE, OBJECT_ATTACHED_POINT]);
return (llList2Integer(out, 0) == OPT_OTHER) && !llList2Integer(out, 1);
}
</lsl>
|also_functions={{LSL DefineRow||[[llKey2Name]]}}
{{LSL DefineRow||[[llGetPrimitiveParams]]}}
{{LSL DefineRow||[[llSetLinkPrimitiveParams]]}}
{{LSL DefineRow||[[llSetPrimitiveParams]]}}
{{LSL DefineRow||[[llGetParcelDetails]]}}
|also_tests
|also_events
|also_articles={{LSL DefineRow||{{LSLGC|Detected}}}}
{{LSL DefineRow||[[Prim Attribute Overloading]]}}
|notes
|history=
*Introduced in SL 1.18.3(2)
*Date of Release [[Release_Notes/Second_Life_Release/1.18#Release_Notes_for_Second_Life_1.18.3.285.29_September_28.2C_2007 | 28-09-2007 ]]
|cat1=Object
|cat2=Prim
|cat3=Avatar
|cat4=Owner
|cat5=Creator
|cat6=Group
|cat7=Link
|cat8
}}

LlGetObjectDetails

2014-01-31T04:09:58Z

Darien Caldwell: Corrected reference to Mono Memory limiting, removed opinion.

{{LSL_Function
|inject-2=
{{LSL_Function/limits}}{{LSL_Function/uuid|id|sim=*}}
{{Issues/SCR-87}}{{Issues/SVC-7592}}
|func_id=332|func_sleep=0.0|func_energy=10.0
|func=llGetObjectDetails
|p1_type=key|p1_name=id|p1_desc= or adjacent regions[[#id_Parameter|*]]
|p2_type=list|p2_name=params|p2_desc=OBJECT_* flags
|return_type=list|return_text=of the details for '''id''', specifically those requested in '''params'''.
|func_footnote=An empty list if '''id''' is not found.{{PBR}}
{{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is returned when passed an invalid integer parameter.
|spec=<div style="padding: 1px; float: left;">[[Image:LlGetObjectdetails-avatar-range.png|thumb|none|250px|Avatar detection range for SL Server 1.34]]</div>
<h5 style="margin:0;">id Parameter</h5>
'''id''' holds the UUID of the avatar or prim this function is going to get the details of.

If '''id''' is not found in the region, adjacent regions are searched for avatars which match '''id'''. An avatar is only considered to have been found if it is inside the region, or within a 34 meter zone outside the region boundaries (see diagram). A single valid result may be returned after the avatar leaves this zone.

<h5 style="margin:0;">params Parameter</h5>
The '''params''' list is used to indicate which object attributes of interest. The order they are supplied in determines the order of the corresponding return values in the return list.
{{{!}} cellpadding="0" cellspacing="0"
{{!}}
*If '''params''' contains unsupported integer values, {{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is placed in the output list.
*If '''params''' contains non-[[integer]] types, those values will be silently ignored.
{{!}}}
<div style="clear:both;"></div>
|caveats=

*OBJECT_ROT will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise.
*Adjacent regions are not searched for prims which match '''id'''.
*Information for avatars that can no longer be found will still be available for a short period (about 45 seconds) but it is not updated.
*Items in '''params''' that are not integers are silently ignored, {{LSL Const|OBJECT_UNKNOWN_DETAIL|integer|-1|c=}} is not returned.
*This function does not return information about items in inventory.
*[[llTargetOmega]] will only effect the return of [[OBJECT_ROT]] if the object is [[STATUS_PHYSICS|physical]]. If the object is not physical then the original start rotation is returned, [[llTargetOmega]] is a {{LSLGC|Effects|client side effect}}.
*{{LSL Const|OBJECT_SCRIPT_MEMORY|integer|11|c=}} reports the maximum memory that all scripts in an object could use, not the actual amount of real memory currently used. In particular, Mono scripts could have set a memory limit lower than the maximum by using [[llSetMemoryLimit]]. In practice, this makes the number reported a worst case scenario.
*{{LSL Const|OBJECT_RUNNING_SCRIPT_COUNT|integer|9|c=}} includes crashed scripts in its count.
|examples=
<lsl>default
{
collision_start(integer i)
{
list a = llGetObjectDetails(llDetectedKey(0), ([OBJECT_NAME,
OBJECT_DESC, OBJECT_POS, OBJECT_ROT, OBJECT_VELOCITY,
OBJECT_OWNER, OBJECT_GROUP, OBJECT_CREATOR]));
llWhisper(0,"UUID: " + (string)llDetectedKey(0) +
"\nName: \"" + llList2String(a,0) + "\"" +
"\nDescription: \"" + llList2String(a,1) + "\"" +
"\nPosition: " + llList2String(a,2) +
"\nRotation: " + llList2String(a,3) +
"\nVelocity: " + llList2String(a,4) +
"\nOwner: " + llList2String(a,5) +
"\nGroup: " + llList2String(a,6) +
"\nCreator: " + llList2String(a,7));
}
}</lsl>
<lsl>
// group join inviter
// gets the name of the object's active group from the online group profile

key groupNameRequestId;
key groupKey;
string groupName;

init()
{
// WARNING:
// different prims can have different active groups!!!

// get the key of the root prim's group
groupKey = llList2Key(llGetObjectDetails(llGetLinkKey(LINK_ROOT), [OBJECT_GROUP]), 0);

// request the name of the root prim's group
groupNameRequestId = llHTTPRequest("http://world.secondlife.com/group/" + (string)groupKey, [], "");
}

default
{
state_entry()
{
init();
}

touch_start(integer num_detected)
{
if (groupKey == NULL_KEY || groupName == "")
return;

key id = llDetectedKey(0);
llInstantMessage(id,
"Click the link to join the group '" + groupName + "'\n"
+ "secondlife:///app/group/" + (string)groupKey + "/about");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id != groupNameRequestId)
return;

list args = llParseString2List(body, ["title"], []);
groupName = llList2String(llParseString2List(llList2String(args, 1), [">", "<", "/"], []), 0);
}
}
</lsl>
<lsl>// aim & shoot
default
{ state_entry()
{ llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}
control(key id, integer pressed, integer change)
{ if(change & pressed & CONTROL_ML_LBUTTON)
llSensor("", "", AGENT|PASSIVE|ACTIVE, 96.0, PI/16.0);
}
run_time_permissions(integer perm)
{ if(perm&PERMISSION_TAKE_CONTROLS)
llTakeControls(CONTROL_ML_LBUTTON, TRUE, TRUE);
}
sensor(integer n)
{ key uuid=llDetectedKey(0);
list a = llGetObjectDetails(uuid, ([
OBJECT_NAME, OBJECT_DESC, OBJECT_POS, OBJECT_ROT,
OBJECT_VELOCITY,OBJECT_OWNER, OBJECT_GROUP, OBJECT_CREATOR]));
llOwnerSay("UUID: " + (string)uuid +
"\nName: \"" + llList2String(a,0)+ "\"" +
"\nDecription: \"" + llList2String(a,1) + "\"" +
"\nPosition: " + llList2String(a,2) +
"\nRotation: " + llList2String(a,3) +
"\nVelocity: " + llList2String(a,4) +
"\nOwner: " + llList2String(a,5) +
"\nGroup: " + llList2String(a,6) +
"\nCreator: " + llList2String(a,7)
);
}
}</lsl>
<lsl>// Object Script Time
default
{
touch_start(integer num_detected)
{
llOwnerSay(llGetObjectName()+" Script Time: "+llList2String(llGetObjectDetails(llGetKey(), [OBJECT_SCRIPT_TIME]), 0));
}
}
</lsl>
|spec
|constants={{LSL Constants/Object Details}}
|helpers=See {{LSLGC|Link/Get}} for some {{LSLGC|Link|link}} related helper functions. Also see [[llGetLinkPrimitiveParams]] if you need to get the position and rotation of a linked prim.
<lsl>
integer isLindenTreeOrGrass(key id){
//Check if it's an OPT_OTHER and not an attachment, which makes it a Linden tree or grass!
list out = llGetObjectDetails(id, [OBJECT_PATHFINDING_TYPE, OBJECT_ATTACHED_POINT]);
return (llList2Integer(out, 0) == OPT_OTHER) && !llList2Integer(out, 1);
}
</lsl>
|also_functions={{LSL DefineRow||[[llKey2Name]]}}
{{LSL DefineRow||[[llGetPrimitiveParams]]}}
{{LSL DefineRow||[[llSetLinkPrimitiveParams]]}}
{{LSL DefineRow||[[llSetPrimitiveParams]]}}
{{LSL DefineRow||[[llGetParcelDetails]]}}
|also_tests
|also_events
|also_articles={{LSL DefineRow||{{LSLGC|Detected}}}}
{{LSL DefineRow||[[Prim Attribute Overloading]]}}
|notes
|history=
*Introduced in SL 1.18.3(2)
*Date of Release [[Release_Notes/Second_Life_Release/1.18#Release_Notes_for_Second_Life_1.18.3.285.29_September_28.2C_2007 | 28-09-2007 ]]
|cat1=Object
|cat2=Prim
|cat3=Avatar
|cat4=Owner
|cat5=Creator
|cat6=Group
|cat7=Link
|cat8
}}

LlSetMemoryLimit

2014-01-31T03:55:23Z

Darien Caldwell: Corrected erroneous statement concerning Memory size reporting in the viewer and with llGetObjectDetails.

{{LSL_Function
|func_id=???|func_sleep=0.0|func_energy=???
|func=llSetMemoryLimit
|p1_type=integer|p1_name=limit
|return_type=integer|return_subtype=boolean
|func_desc=Request {{LSLP|limit}} bytes to be reserved for this script.
|Return_text=[[TRUE]] if the memory limit was successfully set (or [[FALSE]] if not).
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM.

;Mono:Sets the memory limit for the script.
* The memory limit can be set up to 64k.
* The memory limit can not be set lower than the memory currently in use by the script.
* All new scripts start with a limit of 64k
* All existing scripts have a limit of 64k
* A lower limit will '''not''' effect the amount of memory reported in the viewer UI and by [[llGetObjectDetails]].
* The memory limit is not the amount of real memory actually used by the script, just the upper limit on it.

;LSO:Has no effect on LSO scripts which will always use exactly 16k
|caveats=
;Mono:When '''''n''''' is too small, llSetMemoryLimit('''''n''''') is ignored and the memory limit is not changed
|examples=
<lsl>
// Memory-walkthrough by Daemonika Nightfire (daemonika.nightfire)

integer limit = 20000; // <- bytes

Test()
{
llSetText("Limited Memory " + (string)llGetMemoryLimit() +
"\nUsed Memory " + (string)llGetUsedMemory() +
"\nFree Memory " + (string)llGetFreeMemory(),<1,1,1>,1);
}

default
{
state_entry()
{
llSetMemoryLimit(limit);

llScriptProfiler(PROFILE_SCRIPT_MEMORY);
Test();
llScriptProfiler(PROFILE_NONE);

llSay(0,"This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test.");
}
}

// Result:

// Floating Text:
// Limited Memory 20000
// Used Memory 4972
// Free Memory 15100

// Chat:
// [05:11] Object: This script used at most 4972 bytes of memory during Test.
</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llScriptProfiler]]|}}
{{LSL DefineRow||[[llGetSPMaxMemory]]|}}
{{LSL DefineRow||[[llGetMemoryLimit]]|}}
{{LSL DefineRow||[[llGetFreeMemory]]|}}
{{LSL DefineRow||[[llGetUsedMemory]]|}}
{{LSL DefineRow||[[llGetObjectDetails]]|}}
|also_events
|also_tests
|also_articles
|notes
|history=*Scheduled for [[Beta/Magnum|RC Magnum]] channel, week of August 3, 2011.
|lso
|cat1=Script
|cat2=Memory
|cat3=Script Profiler
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/11#11.08.10.238207 | 10/08/2011 ]]
}}

PUBLIC CHANNEL

2014-01-11T20:20:15Z

Darien Caldwell: Something for the art lovers.

<onlyinclude>{{#vardefine:PUBLIC_CHANNEL|{{LSL Const|PUBLIC_CHANNEL|integer|ihex=0|hex=0x0|c={{#if:{{{direct|}}}|Chat channel used to broadcast to a specific user or prim. This channel is sometimes referred to as: open chat, local chat and public chat.|Chat channel that broadcasts to all nearby users. This channel is sometimes referred to as: open chat, local chat and public chat.}}}}}}</onlyinclude>{{LSL Constant
|name={{#var:cname}}
|type={{#var:type}}
|hvalue=0x0
|value=0
|desc=Chat channel that broadcasts to all nearby users & objects. This channel is sometimes referred to as: open chat, local chat and public chat.

If used with a [[llRegionSayTo]], it goes to the specified user or prim. Unlike private channels, the user's attachments do not receive the message.
|comment={{#var:comment}}
|examples=
<lsl>
default
{
touch_start(integer num_detected)
{
llSay(PUBLIC_CHANNEL, "Hello there, I'm talking in local chat on channel 0.");
}
}
</lsl>
|constants=
{{LSL DefineRow|1=|2={{LSL Const|DEBUG_CHANNEL}}|3={{#var:comment}}}}
|functions=
{{LSL DefineRow||[[llWhisper]]|}}
{{LSL DefineRow||[[llSay]]|}}
{{LSL DefineRow||[[llShout]]|}}
{{LSL DefineRow||[[llRegionSayTo]]|}}
{{LSL DefineRow||[[llDialog]]|}}
{{LSL DefineRow||[[llListen]]|}}
|events=
{{LSL DefineRow||[[listen]]|}}
|haiku={{Haiku|Oh woeful constant,|the focus of much Strife,|value, no, but priceless.}}
|cat1=Chat
|cat2
|cat3
|cat4
}}

PUBLIC CHANNEL

2014-01-10T19:58:27Z

Darien Caldwell: Undoing revision that broke Constant tables.

LlRegionSay

2014-01-09T00:14:45Z

Darien Caldwell:

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg|np=*}}
|func_id=331
|func_sleep=0.0
|func_energy=10.0
|func=llRegionSay
|p1_type=integer|p1_name=channel|p1_desc
|p2_type=string|p2_name=msg|p2_desc
|func_desc=Says the string {{LSLP|msg}} on channel number {{LSLP|channel}} that can be heard anywhere in the [[region]] by a script [[listen|listening]] on {{LSLP|channel}}.
|func_footnote=Regardless of where the prim is, the message will not travel over region borders.
|return_text
|spec
|constants
|caveats=*This function cannot transmit on the {{#var:PUBLIC_CHANNEL}} (channel 0), this is a design feature and not a bug.
*If {{LSLP|msg}} is longer than 1024 characters it is truncated to 1024 characters. (Note that in Mono, each character occupies 2 memory bytes).
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=<lsl>default
{
state_entry()
{
llRegionSay(25,"This is an incredibly useless program." );
}
}</lsl>
To avoid making your object spam its neighborhood, use [[llOwnerSay]] or [[llInstantMessage]].
|helpers
|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llRegionSayTo]]|Sends chat directly to specified target within region}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|}}
{{LSL DefineRow||[[llDialog]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
|also_tests
|also_articles
|notes=If one object 'says' something to another object (e.g., a button that, when touched,
turns on a lamp), it is a good idea to use a very negative channel, e.g.,
<lsl> llRegionSay(-5243212,"turn on");</lsl>
Negative channels are popular for script communications because the standard SL client is unable to chat directly on those channels ("/-xxxx message" won't chat "message" on channel "-xxxx", it will chat "/-xxxx message" on channel zero). The only way to do so prior to [[llTextBox]] was to use [[llDialog]] which was limited to 24 bytes.

If {{#var:DEBUG_CHANNEL}} is used as {{LSLP|channel}}, the script will say {{LSLP|msg}} to the Script Warning/Error window.

If you wish two objects owned by the same person to communicate within a SIM, one idea is to make both scripts compute the channel based on the owner UUID. e.g. :-
<lsl>
gChannel = 0x80000000 | (integer) ( (string) llGetOwner() );
</lsl>

* As of 1.18.3, using llRegionSay on the {{#var:DEBUG_CHANNEL}} will wrap around and display on channel 0, with a range of 100m.
|history=
*Introduced with SL 1.16.0
|cat1=Communications
|cat2=Chat
|cat3
|cat4
}}

LlRegionSay

2014-01-09T00:14:31Z

Darien Caldwell:

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg|np=*}}
|func_id=331
|func_sleep=0.0
|func_energy=10.0
|func=llRegionSay
|p1_type=integer|p1_name=channel|p1_desc
|p2_type=string|p2_name=msg|p2_desc
|func_desc=Says the string {{LSLP|msg}} on channel number {{LSLP|channel}} that can be heard anywhere in the [[region]] by a script [[listen|listening]] on {{LSLP|channel}}.
|func_footnote=Regardless of where the prim is, the message will not travel over region borders.
|return_text
|spec
|constants
|caveats=*This function cannot transmit on the {{#var:PUBLIC_CHANNEL}}(channel 0), this is a design feature and not a bug.
*If {{LSLP|msg}} is longer than 1024 characters it is truncated to 1024 characters. (Note that in Mono, each character occupies 2 memory bytes).
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=<lsl>default
{
state_entry()
{
llRegionSay(25,"This is an incredibly useless program." );
}
}</lsl>
To avoid making your object spam its neighborhood, use [[llOwnerSay]] or [[llInstantMessage]].
|helpers
|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llRegionSayTo]]|Sends chat directly to specified target within region}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|}}
{{LSL DefineRow||[[llDialog]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
|also_tests
|also_articles
|notes=If one object 'says' something to another object (e.g., a button that, when touched,
turns on a lamp), it is a good idea to use a very negative channel, e.g.,
<lsl> llRegionSay(-5243212,"turn on");</lsl>
Negative channels are popular for script communications because the standard SL client is unable to chat directly on those channels ("/-xxxx message" won't chat "message" on channel "-xxxx", it will chat "/-xxxx message" on channel zero). The only way to do so prior to [[llTextBox]] was to use [[llDialog]] which was limited to 24 bytes.

If {{#var:DEBUG_CHANNEL}} is used as {{LSLP|channel}}, the script will say {{LSLP|msg}} to the Script Warning/Error window.

If you wish two objects owned by the same person to communicate within a SIM, one idea is to make both scripts compute the channel based on the owner UUID. e.g. :-
<lsl>
gChannel = 0x80000000 | (integer) ( (string) llGetOwner() );
</lsl>

* As of 1.18.3, using llRegionSay on the {{#var:DEBUG_CHANNEL}} will wrap around and display on channel 0, with a range of 100m.
|history=
*Introduced with SL 1.16.0
|cat1=Communications
|cat2=Chat
|cat3
|cat4
}}

LlSay

2014-01-09T00:13:22Z

Darien Caldwell:

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg}}
|func_id=23
|func_sleep=0.0
|func_energy=10.0
|func=llSay
|sort=Say
|p1_type=integer|p1_name=channel
|p2_type=string|p2_name=msg
|func_desc=Says the text supplied in string {{LSLP|msg}} on channel supplied in integer {{LSLP|channel}}.
|return_text
|spec
|constants
|caveats=
*{{LSLP|msg}} can only be heard within 20 meters of the speaking prim (rather than the root). This is contrary to how the event [[listen]] works, where a {{LSLP|msg}} can only be heard by any prim in the object if and only if the root prim is capable of hearing it.
*{{LSLP|msg}} can be a maximum of 1024 bytes. This can convey 1024 ASCII characters, or 512 UTF-8 characters such as <code>á</code>.
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llSay(PUBLIC_CHANNEL, "Hello, Avatar!");
}
}
</lsl>
To avoid making your object spam its neighborhood, use [[llInstantMessage]], [[llOwnerSay]] or [[llRegionSayTo]].
|helpers
|also_events=
{{LSL DefineRow||[[listen]]                |Receives chat}}
|also_functions=
{{LSL DefineRow||[[llListen]]|Ask for listen events}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the owner only (or to some other user only) to avoid spamming the [[PUBLIC_CHANNEL]]}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only to avoid spamming the [[PUBLIC_CHANNEL]]}}
{{LSL DefineRow||[[llRegionSay]]|Sends chat region wide}}
{{LSL DefineRow||[[llRegionSayTo]]|Sends chat region wide to a specific avatar, or their attachments, or to a rezzed object of known UUID}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Hello Avatar]]}}
|notes=
* Channel {{HoverText|0|Zero}} is the [[PUBLIC_CHANNEL]]. Everyone can hear chat transmitted on this channel. All other channels are private channels (not sent to users, with the exception of [[DEBUG_CHANNEL]]).
* Consider using [[llInstantMessage]], [[llOwnerSay]], or the [[DEBUG_CHANNEL]] for debugging purposes. If [[DEBUG_CHANNEL]] is used as {{LSLP|channel}}, the script will say {{LSLP|msg}} to the Script Warning/Error window.
* If one object 'says' something to another object (''e.g''., a button that, when touched, turns on a lamp), it is a good idea to use a very negative channel, ''e.g.'', <code>-5243212</code> but don't just use any number take a look at the [[User-Defined Protocols & APIs]] and choose one that won't interfere with other protocols. If you are going to sell your script widely please add it to the appropriate [[LSL_Protocol#Known_negative_chat_channels|known chat channels list]] so others won't interfere with your product (do keep in mind you should build your product so that it handles interference appropriately).
<lsl>
llSay(-5243212,"turn on");
</lsl>
Negative channels are popular for script communications because the standard SL client is unable to chat directly on those channels (<code>/-xxxx message</code> won't chat <code>message</code> on channel <code>-xxxx</code>, it will chat <code>/-xxxx message</code> on channel [[PUBLIC_CHANNEL]]). The only way to do so prior to [[llTextBox]] was to use [[llDialog]] which was limited to 24 bytes.
|cat1
|cat2
|cat3
|cat4
}}

User talk:Kireji Haiku

2014-01-09T00:11:01Z

Darien Caldwell:

== Unnecessary Edits ==

Kindly desist from your inane paranoid obsession with a personal fad. Strife and I have discussed the purpose of edits and agree that edits should not unnecessarily change the style chosen by the example code originators. And don't split hairs with me about what constitutes "style". I will continue to revert unneeded edits back to what the originator intended. [[User:Omei Qunhua|Omei Qunhua]] 07:13, 31 December 2013 (PST)

I obviously have not explained myself simply or clearly enough. Let's try again. There have been thousands of scripts contributed to this Wiki, by hundreds if not thousands of contributors. There have apparently been a million scripts written in LSL and there are tens of thousands of scripts in public libraries. You, I believe, are almost alone among this vast horde of experience in insisting on PUBLIC_CHANNEL and ERROR_GENERIC, (float) FALSE etc. That places you a minuscule minority. You have NO RIGHT to impose your most exceptional view on the rest of us. I personally consider it OBSCENE that you dare to suggest my contributions are in error sufficiently to warrant you getting your sticky little fingers on them, just because I didn't adhere to a very individual quirk of yours in my otherwise totally correct script. What on earth do you think gives you this right? I am sure you are ABSOLUTELY convinced of the advantages of your preferences. By all means feel free to exercise your preferences in your own creations, and I will honour your right to write what you wish in your own creations, so long as they are accurate (i.e. compile and produce correct results). But that does not give you the right as one individual to impose your ways on thousands of the rest of us. The way to convince others is not to trample rough-shod over years of work by the dedicated majority. That only alienates you, certainly from me. I repeat, I will continue to try and ensure that the valid preferences of script originators are preserved. What's your excuse? [[User:Omei Qunhua|Omei Qunhua]] 09:43, 31 December 2013 (PST)

== JSON_APPEND and JSON_DELETE ==

I can't get on right now to test this but what happens if you use [[JSON_APPEND]] with [[JSON_DELETE]]? If the world were a wonderful place it would delete the last value.
<lsl>llOwnerSay(llJsonSetValue("[0,1]", [JSON_APPEND], JSON_DELETE));</lsl>
--'''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 06:19, 4 October 2013 (PDT)

:What do you think happens if it's NOT an array?
:<lsl>llOwnerSay(llJsonSetValue("{a:1}", [JSON_APPEND], JSON_DELETE));</lsl>
:-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 06:23, 4 October 2013 (PDT)

::They both output [[JSON_INVALID]]. I'll erm... test and see if there's a better example script :P -- [[User:Kireji Haiku|Kireji Haiku]] 06:29, 4 October 2013 (PDT)

:::JSON_DELETE I think is still only in RC. Thanks for looking into this. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 06:32, 4 October 2013 (PDT)

:::I think I'll just make a feature suggestion for JSON_LAST so there is no ambiguity. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 06:35, 4 October 2013 (PDT)

::::I tested both on <code>LeTigre Sandbox 1</code> which runs <code>3.6.7.281331</code>. It seems that is before the one introducing [[JSON_DELETE]]. So yeah... will wait and see. I removed the example script for now. -- [[User:Kireji Haiku|Kireji Haiku]] 06:39, 4 October 2013 (PDT)

:::::<.< sorry for wasting your time. [[JSON_LAST]] = {{JIRA|BUG-4075}} -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 06:47, 4 October 2013 (PDT)

:::::Thanks for the useless link. I'd have taken a look, but no perms. So I'll just hope someone will react to that. Not that anybody would to then ones I report. Have a nice one ;) -- [[User:Kireji Haiku|Kireji Haiku]] 06:54, 4 October 2013 (PDT)

:::::: ^^; sorry -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 07:05, 4 October 2013 (PDT)

:::::::Nah, it's all good. I just don't like the way some of the Linden Lab staff reacts to user reports by first acknowledging bugs and then ignoring any help provided to actually get them fixed. Closing down the JIRA from the public doesn't help either. Anyhow, I'll stop rambling off-topic. Cya -- [[User:Kireji Haiku|Kireji Haiku]] 08:30, 4 October 2013 (PDT)

:::::::: BUG-4075 is a feature request for a parameter "JSON_LAST" ;) --[[User:MartinRJ Fayray|MartinRJ Fayray]] 15:32, 18 October 2013 (PDT)

== Vendor systems comparison ==

Hi.
I've tried to find the Titan vending system. It seems its no longer available. The SLURL ends in midair of a sim and you don't land at the vending center, as announced in the creators profile picks. Remove the system from the table?
--[[User:Mo Noel|Mo Noel]] 09:19, 25 November 2013 (PST)

:Did you try contacting the creator? I personally wouldn't remove the system from the table as long as it still is working and people are using it. -- [[User:Kireji Haiku|Kireji Haiku]] 03:25, 8 December 2013 (PST)

== PUBLIC_CHANNEL vs Zero ==

Seeing as this topic hasn't settled down, it's time for the larger community to choose. I view their decision (even if it's Pie) as binding.
http://www.sluniverse.com/php/vb/scripting/91061-wiki-public_channel-vs-zero.html
-- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:15, 1 January 2014 (PST)

All these attempts to hide the value of PUBLIC_CHANNEL need to stop. It's just spiteful Wiki editing. Any I find I'm reverting. [[User:Darien Caldwell|Darien Caldwell]] 16:11, 8 January 2014 (PST)

Mesh/Avatar Shape XML Format

2014-01-08T23:56:04Z

Darien Caldwell: Undo revision 1186198 by Kireji Haiku (Talk)

{{Navbox/Mesh|tech}}
== History ==
The Shape XML format has been ingrained in the viewer since the early days, long before mesh existed. However, with the addition of rigged mesh and customized clothing, the file has become invaluable to creators. Sometimes called an "archetype file" due to it's default name "new_archetype.xml".

With the release of [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] in Early 2013, The XML format has inherited additional information. However, it's XML version number is still 1.0, and it is still backward compatible with the original terse format. The additions will be outlined separately in the SSA Extensions section.

== Header ==
The file is standard XML, with 3 parameters:

* <xml><?xml version="1.0" encoding="US-ASCII" standalone="yes"?></xml>
** The <code>version</code> parameter sets the version of the XML markup. (should always be 1.0)
** The <code>encoding</code> parameter sets the character encoding for the file. (should always be US-ASCII)
** The <code>standalone</code> parameter informs that the file is self-containted, and not dependent on any external files. (should always be yes)

'''Note that some viewers''' set <code>standalone="true"</code>. This is technically incorrect via the XML standard. It should be <code>standalone="yes"</code>.

== Root Node ==

The root node is of type <code>linden_genepool</code> with one parameter:

* <xml><linden_genepool version="1.0"></xml>
** The <code>version</code> parameter sets the version of the data contained in the node. Currently LL's data is version 1.0. Future revisions may increment this version, so any implementation should check this version number before using the data.

== Data Body ==

The Root node contains one node of type <code>archetype</code> with one parameter.

*<xml><archetype name="???"></xml>
** The <code>name</code> parameter is a information parameter, and can contain anything, or nothing. Most commonly populated with 3 question marks.

== The Data ==

The data inside is a list of parameters and textures associated with the Avatar's appearance. These can be broken up into 4 categories:

* Shape
* Skin
* Hair
* Eyes

Each category will have several <code>param</code> nodes and possibly <code>texture</code> nodes included. More about these nodes in the next section.

== Param Nodes ==

<code>param</code> nodes correspond to sliders in the appearance pane. Each has 3 parameters:
*Example: <xml><param id="649" name="torso muscles" value="0.500"/></xml>
** The <code>id</code> parameter corresponds to an internal viewer table of possible sliders. These numbers are guaranteed to be unique, and always correspond to the same slider.
** The <code>name</code> parameter corresponds to internal 'driving elements' in the viewer. This can vary depending on the type of param. For shapes, it's often the name of the morph being controlled. For skins or eyes, it's usually a material that's being changed (color etc). For hair, a combination of both are present. These are '''not''' always unique. For example, there are two parameters called "torso muscles", with different IDs (one for male, one for female).
** The <code>value</code> parameter is the value of the slider. It is however in the internally used format, not the 0-100 value seen by Residents. Calculating what these values mean requires finding the Minimum and Maximum of that value from other sources, such as the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)

== Texture Nodes ==

<code>texture</code> nodes correspond to textures applied via the appearance pane. Each has two parameters:
*Example: <xml><texture te="3" uuid="00000000-0000-4000-8000-000000000000"/></xml>
** The <code>te</code> parameter corresponds to an internal viewer table of possible textures. These numbers are guaranteed to be unique.
** The <code>uuid</code> parameter corresponds to the [[UUID]] of the texture applied at the time of the XML creation.

'''Note that <code>texture</code> nodes are optional''' and not guaranteed to be present. Especially when the file is generated from 3rd party sources.

== Comments ==

Comments are styled in the standard HTML style, with the string <xml></xml> denoting the end of a comment. This is per the XML specification.
*Example: <xml></xml>

== File Termination ==

The file is terminated by the closing of the <code>archetype</code> and <code>linden_genepool</code> nodes:

*<xml></archetype></linden_genepool></xml>

== SSA Extensions ==
The Two main changes with SSA are the addition of '''many''' new <code>param</code> nodes , and the inclusion of new data in all <code>param</code> nodes.
*The additional <code>param</code> nodes now cover more than just the avatar's body shape and texture. Now, there is data for every possible avatar appearance modifier, including all clothes layers, alpha layers, tattoo layers, all internal morphs, and all settings for these items. In short there is every bit of data needed to completely recreate the entire avatar's 'look'.
*The new parameters included in the <code>param</code> nodes is ''in addition to'' the original parameters. All of the originally available parameters are still provided. The new parameters are as follows:
**The <code>u8</code> parameter is a short integer normalized representation of the displayed slider value. Whereas before some complex math was necessary to determine what 0-100 slider value was indicated by the morph value in the <code>value</code> parameter, now you can simply take the u8 value, divide it by 255, then multiply that value by 100. That will give you the displayed slider values. 255 would be a slider value of 100, 128 would be a slider value of 50, and 0 would of course be 0.
**The <code>type</code> parameter is a rough indication of what kind of data the <code>param</code> entry is associated with. There seem to be 5 distinct values, which likely correspond to entries in the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)
*** param_morph, param_driver, param_skeleton, param_color, param_alpha
** The <code>wearable</code> parameter further groups <code>param</code> entries into distinct groups. These clearly indicate what avatar component the <code>param</code> node is associated with. There seem to be 16 distinct values:
*** shape, hair, invalid, gloves, eyes, skin, pants, shoes, shirt, jacket, socks, underpants, undershirt, skirt, tattoo, physics
** The <code>invalid</code> wearable indicates a morph.

Mesh/Avatar Shape XML Format

2014-01-08T23:55:24Z

Darien Caldwell: Undo revision 1186194 by Kireji Haiku (Talk)

{{Navbox/Mesh|tech}}
== History ==
The Shape XML format has been ingrained in the viewer since the early days, long before mesh existed. However, with the addition of rigged mesh and customized clothing, the file has become invaluable to creators. Sometimes called an "archetype file" due to it's default name "new_archetype.xml".

With the release of [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] in Early 2013, The XML format has inherited additional information. However, it's XML version number is still <code>1.0</code>, and it is still backward compatible with the original terse format. The additions will be outlined separately in the SSA Extensions section.

== Header ==
The file is standard XML, with 3 parameters:

* <xml><?xml version="1.0" encoding="US-ASCII" standalone="yes"?></xml>
** The <code>version</code> parameter sets the version of the XML markup. (should always be set to <code>1.0</code>)
** The <code>encoding</code> parameter sets the character encoding for the file. (should always be set to <code>US-ASCII</code>)
** The <code>standalone</code> parameter informs that the file is self-containted, and not dependent on any external files. (should always be set to <code>yes</code>)

'''Note that some viewers''' set <code>standalone="true"</code>. This is technically incorrect via the XML standard. It should be <code>standalone="yes"</code>.

== Root Node ==

The root node is of type <code>linden_genepool</code> with one parameter:

* <xml><linden_genepool version="1.0"></xml>
** The <code>version</code> parameter sets the version of the data contained in the node. Currently LL's data is version <code>1.0</code>. Future revisions may increment this version, so any implementation should check this version number before using the data.

== Data Body ==

The Root node contains one node of type <code>archetype</code> with one parameter.

*<xml><archetype name="???"></xml>
** The <code>name</code> parameter is a information parameter, and can contain anything, or nothing. Most commonly populated with 3 question marks.

== The Data ==

The data inside is a list of parameters and textures associated with the Avatar's appearance. These can be broken up into 4 categories:

* Shape
* Skin
* Hair
* Eyes

Each category will have several <code>param</code> nodes and possibly <code>texture</code> nodes included. More about these nodes in the next section.

== Param Nodes ==

<code>param</code> nodes correspond to sliders in the appearance pane. Each has 3 parameters:
*Example: <xml><param id="649" name="torso muscles" value="0.500"/></xml>
** The <code>id</code> parameter corresponds to an internal viewer table of possible sliders. These numbers are guaranteed to be unique, and always correspond to the same slider.
** The <code>name</code> parameter corresponds to internal 'driving elements' in the viewer. This can vary depending on the type of param. For shapes, it's often the name of the morph being controlled. For skins or eyes, it's usually a material that's being changed (color etc). For hair, a combination of both are present. These are '''not''' always unique. For example, there are two parameters called "torso muscles", with different IDs (one for male, one for female).
** The <code>value</code> parameter is the value of the slider. It is however in the internally used format, not the 0-100 value seen by Residents. Calculating what these values mean requires finding the Minimum and Maximum of that value from other sources, such as the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)

== Texture Nodes ==

<code>texture</code> nodes correspond to textures applied via the appearance pane. Each has two parameters:
*Example: <xml><texture te="3" uuid="00000000-0000-4000-8000-000000000000"/></xml>
** The <code>te</code> parameter corresponds to an internal viewer table of possible textures. These numbers are guaranteed to be unique.
** The <code>uuid</code> parameter corresponds to the [[UUID]] of the texture applied at the time of the XML creation.

'''Note that <code>texture</code> nodes are optional''' and not guaranteed to be present. Especially when the file is generated from 3rd party sources.

== Comments ==

Comments are styled in the standard HTML style, with the string <xml></xml> denoting the end of a comment. This is per the XML specification.
*Example: <xml></xml>

== File Termination ==

The file is terminated by the closing of the <code>archetype</code> and <code>linden_genepool</code> nodes:

*<xml></archetype></linden_genepool></xml>

== SSA Extensions ==
The Two main changes with SSA are the addition of '''many''' new <code>param</code> nodes , and the inclusion of new data in all <code>param</code> nodes.
*The additional <code>param</code> nodes now cover more than just the avatar's body shape and texture. Now, there is data for every possible avatar appearance modifier, including all clothes layers, alpha layers, tattoo layers, all internal morphs, and all settings for these items. In short there is every bit of data needed to completely recreate the entire avatar's 'look'.
*The new parameters included in the <code>param</code> nodes is ''in addition to'' the original parameters. All of the originally available parameters are still provided. The new parameters are as follows:
**The <code>u8</code> parameter is a short integer normalized representation of the displayed slider value. Whereas before some complex math was necessary to determine what 0-100 slider value was indicated by the morph value in the <code>value</code> parameter, now you can simply take the u8 value, divide it by 255, then multiply that value by 100. That will give you the displayed slider values. 255 would be a slider value of 100, 128 would be a slider value of 50, and 0 would of course be 0.
**The <code>type</code> parameter is a rough indication of what kind of data the <code>param</code> entry is associated with. There seem to be 5 distinct values, which likely correspond to entries in the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)
*** param_morph, param_driver, param_skeleton, param_color, param_alpha
** The <code>wearable</code> parameter further groups <code>param</code> entries into distinct groups. These clearly indicate what avatar component the <code>param</code> node is associated with. There seem to be 16 distinct values:
*** shape, hair, invalid, gloves, eyes, skin, pants, shoes, shirt, jacket, socks, underpants, undershirt, skirt, tattoo, physics
** The <code>invalid</code> wearable indicates a morph.

LlGetObjectName

2014-01-08T23:53:47Z

Darien Caldwell: Undo revision 1186176 by Kireji Haiku (Talk)

{{LSL_Function
|inject-2={{LSL_Function/limits}}
|func_id=202|func_sleep=0.0|func_energy=10.0
|func=llGetObjectName
|return_type=string
|func_footnote
|func_desc
|return_text=that is the name of the prim the script is attached to.
|spec
|caveats=*The prim name is limited to 63 bytes, any string longer than that will be truncated. This truncation does not always happen when the attribute is set or read.
{{LSL Tip|This function '''does not''' get the name of the object's rootprim, but the name of the prim containing the script. Please use [[llGetLinkName]]([[LINK_ROOT]]); instead.}}
|constants
|examples=
{{{!}} class="sortable" width="100%" {{Prettytable}}
{{!}}- {{Hl2}}
! '''Get this prim's name'''
! '''Get the root prim's name'''
{{!}}-
{{!!}}<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llSay(PUBLIC_CHANNEL, "This prim's name: " + llGetObjectName() );
}
}
</lsl>
{{!!}}
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llSay(PUBLIC_CHANNEL, "Root prim's name: "
+ llGetLinkName(LINK_ROOT));
}
}
</lsl>
{{!}}}
|helpers
|also_functions=
{{LSL DefineRow||[[llSetObjectName]]|Set the prims name}}
{{LSL DefineRow||[[llGetLinkName]]|Get a linked prims name}}
{{LSL DefineRow||[[llGetObjectDesc]]|Get the prims description}}
{{LSL DefineRow||[[llSetObjectDesc]]|Sets the prims description}}
{{LSL DefineRow||[[llGetObjectDetails]]}}
|also_tests
|also_events
|also_articles=
{{LSL DefineRow||[[Prim Attribute Overloading]]}}
|notes=*This function may return "(Waiting)" sometimes.
Presumably the function queries the asset server for a predetermined time and returns "(Waiting)" if that elapses.
It then silently proceeds to the next instruction.
A work around therefore, might be to test object name is not "(Waiting)" after calling llGetObjectName.
|cat1=Prim
|cat2
|cat3
|cat4
}}

LlGetObjectDesc

2014-01-08T23:52:58Z

Darien Caldwell: Undo revision 1186174 by Kireji Haiku (Talk)

{{LSL_Function
|inject-2={{LSL_Function/prim-desc}}
|func_id=270|func_sleep=0.0|func_energy=10.0
|func=llGetObjectDesc
|return_type=string
|func_footnote=To get the ''object's'' description (not the current prim's), use [[PRIM_DESC]] or [[OBJECT_DESC]].
|func_desc
|return_text=containing the description of the prim the script is attached to.
|spec
|caveats=
{{LSL Tip|This function '''does not''' get the description of the object's rootprim, but the description of the prim containing the script. Please use [[llList2String]]([[llGetLinkPrimitiveParams]]([[LINK_ROOT]], [ [[PRIM_DESC]] ]), 0); instead.}}
|constants
|examples=
{{{!}} class="sortable" width="100%" {{Prettytable}}
{{!}}- {{Hl2}}
! '''Get this prim's description'''
{{!}}-
{{!!}}<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llSay(PUBLIC_CHANNEL, "This prim's description: " + llGetObjectDesc() );
}
}
</lsl>
{{!}}}

{{{!}} class="sortable" width="100%" {{Prettytable}}
{{!}}- {{Hl2}}
! '''Get the root prim's description'''
{{!}}-
{{!!}}
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llSay(PUBLIC_CHANNEL, "Rootprim's description: "
+ llList2String(llGetLinkPrimitiveParams(LINK_ROOT, [ PRIM_DESC ]), 0));
}
}
</lsl>
{{!}}}
|helpers
|also_functions=
{{LSL DefineRow||[[llSetObjectDesc]]|Sets the prim description.}}
{{LSL DefineRow||[[llGetObjectName]]|Gets the prim name.}}
{{LSL DefineRow||[[llSetObjectName]]|Sets the prim name.}}
{{LSL DefineRow||[[llGetObjectDetails]]}}
|also_events
|also_articles=
{{LSL DefineRow||[[Prim Attribute Overloading]]}}
|notes
|cat1=Prim
|cat2=Description
|cat3
|cat4
}}

LlWhisper

2014-01-08T23:52:06Z

Darien Caldwell: Undo revision 1186170 by Kireji Haiku (Talk)

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg}}
|func_id=22
|func_sleep=0.0
|func_energy=10.0
|func=llWhisper
|sort=Whisper
|p1_type=integer|p1_name=channel
|p2_type=string|p2_name=msg
|func_desc=Whispers the text supplied in string {{LSLP|msg}} on channel supplied in integer {{LSLP|channel}}.
|return_text
|spec
|constants
|caveats=*Text can be a maximum of 1024 bytes. This can convey 1024 ASCII characters, or 512 UTF-8 characters such as á
*Whispers can only be heard within 10 meters of the speaking prim (rather than the root). This is contrary to how [[listen]]s work, where a message can only be heard by any prim in the object if and only if the root prim is capable of hearing it.
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=
For better readability of your code, you can make use of certain mnemonic constants such as [[PUBLIC_CHANNEL]] instead of channel 0 and [[DEBUG_CHANNEL]] instead of channel +2,147,483,647.
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llWhisper(PUBLIC_CHANNEL, "This is an incredibly useless program.");
}
}
</lsl>
For communicating with the user or owner it is preferable to use [[llOwnerSay]] or [[llInstantMessage]] or [[llRegionSayTo]] as they won't spam other users.
|helpers
|also_events={{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llOwnerSay]]|}}
{{LSL DefineRow||[[llRegionSay]]|Sends chat region wide}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|}}
|also
|notes
|cat1=Communications
|cat2=Chat
|cat3
|cat4
}}

LlShout

2014-01-08T23:51:47Z

Darien Caldwell: Undo revision 1186171 by Kireji Haiku (Talk)

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg}}
|func_id=24
|func_sleep=0.0
|func_energy=10.0
|func=llShout
|sort=Shout
|p1_type=integer|p1_name=channel
|p2_type=string|p2_name=msg
|func_desc=Shouts the text supplied in string {{LSLP|msg}} on channel supplied in integer {{LSLP|channel}}.
|spec
|constants
|caveats=*Text can be a maximum of 1024 bytes. This can convey 1024 ASCII characters, or 512 UTF-8 characters such as á
*Shouts can be heard within 100 meters of the speaking prim (rather than the root). This is contrary to how [[listen]]s work, where a message can only be heard by any prim in the object if and only if the root prim is capable of hearing it.
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=
For better readability of your code, you can make use of certain mnemonic constants such as [[PUBLIC_CHANNEL]] instead of channel 0 and [[DEBUG_CHANNEL]] instead of channel +2,147,483,647.
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llShout(PUBLIC_CHANNEL,"I scream icecream!");
}
}
</lsl>
For communicating with a user or owner it is preferable to use [[llOwnerSay]] or [[llInstantMessage]] or [[llRegionSayTo]] as they won't spam other users.
The latter is also an excellent choice for communicating to an attachment of a known avatar, or to an object of known UUID.
|helpers
|also_events={{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llOwnerSay]]|}}
{{LSL DefineRow||[[llRegionSay]]|Sends chat region wide}}
{{LSL DefineRow||[[llRegionSayTo]]|Sends chat region wide to a specific avatar, or their attachments, or to a rezzed object of known UUID}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llInstantMessage]]|}}
|also_tests
|also_articles
|notes
|cat1=Communications
|cat2=Chat
|cat3
|cat4
}}

LlWhisper

2014-01-08T23:51:28Z

Darien Caldwell: Undo revision 1186169 by Kireji Haiku (Talk)

{{LSL_Function
|inject-2={{LSL_Function/chat|channel|msg}}
|func_id=22
|func_sleep=0.0
|func_energy=10.0
|func=llWhisper
|sort=Whisper
|p1_type=integer|p1_name=channel
|p2_type=string|p2_name=msg
|func_desc=Whispers the text supplied in string {{LSLP|msg}} on channel supplied in integer {{LSLP|channel}}.
|return_text
|spec
|constants
|caveats=*Text can be a maximum of 1024 bytes. This can convey 1024 ASCII characters, or 512 UTF-8 characters such as á
*Whispers can only be heard within 10 meters of the speaking prim (rather than the root). This is contrary to how [[listen]]s work, where a message can only be heard by any prim in the object if and only if the root prim is capable of hearing it.
*A prim can '''not''' hear itself, this to prevent problems with recursion. It can however hear other prims within the same object.
|examples=
<lsl>
default
{
state_entry()
{
// PUBLIC_CHANNEL has the integer value 0
llWhisper(PUBLIC_CHANNEL, "This is an incredibly useless program.");
}
}
</lsl>
For communicating with the user or owner it is preferable to use [[llOwnerSay]] or [[llInstantMessage]] or [[llRegionSayTo]] as they won't spam other users.
|helpers
|also_events={{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llOwnerSay]]|}}
{{LSL DefineRow||[[llRegionSay]]|Sends chat region wide}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|}}
|also
|notes
|cat1=Communications
|cat2=Chat
|cat3
|cat4
}}

Mesh/Rigging Fitted Mesh

2013-12-19T22:47:16Z

Darien Caldwell: Added lower/upper back bones to list

{{Navbox/Mesh-all}}
__TOC__
<div style="margin: 10px; padding: 0 10px 10px 10px; border: 1px solid #dddddd; background-color: #f9f9f9; width: 256px;">
===Download links===
[http://lecs.opensource.secondlife.com/fittedmesh/SecondLifeAvatarSkeleton.zip Second Life Skeletons]

Includes the male and female models in the following formats:
.ma
.fbx
.blend
.dae
</div>

===What is Fitted Mesh?===
Fitted Mesh is a technique in which an avatar's collision bones are used to add further deformation detail to an avatar or clothing. The benefit of this technique is that it allows [http://wiki.secondlife.com/wiki/Mesh/Basics Mesh] clothing and avatars to be adjusted using an avatar's Body Shape sliders in the Appearance Editor. This results in clothing that can adjust and fit to your avatar's own personal body shape and style.

For content creators, the key difference between a Fitted Mesh skeleton and the previous standard skeleton is that a Fitted Mesh skeleton has more bones. The rigging workflow is the same except that the additional collision bones are also included in the skinning/binding process. Note that unlike the mBones, you do not need to include all of the collision bones, rather only the ones you wish to use.

{{KBtip|For the best results and to avoid unsightly clipping, you should use [http://nicolaescher.com/tutorials/alpha-channel-primer alpha masks] to hide areas covered by mesh on your avatar.}}
{{KBnote|As of November 20, 2013, Fitted Mesh requires Second Life Project Viewer version 3.6.11.283899, which can be downloaded [https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_FittedMesh/3.6.11.283899 here].}}

===Collision bones===
====List of original collision bones:====
* PELVIS
* BELLY
* CHEST
* NECK
* HEAD
* L_CLAVICLE
* L_UPPER_ARM
* L_LOWER_ARM
* L_HAND
* R_CLAVICLE
* R_UPPER_ARM
* R_LOWER_ARM
* R_HAND
* L_UPPER_LEG
* L_LOWER_LEG
* L_FOOT
* R_UPPER_LEG
* R_LOWER_LEG
* R_FOOT

====Collision bones added with Fitted Mesh====
* BUTT *
* LEFT_PEC *
* RIGHT_PEC *
* LEFT_HANDLE
* RIGHT_HANDLE
* LOWER_BACK
* UPPER_BACK

{{KBnote|BUTT, LEFT_PEC, and RIGHT_PEC are affected by [http://community.secondlife.com/t5/English-Knowledge-Base/Controlling-your-avatar-s-appearance/ta-p/700709#Section_.3 avatar physics].}}

===Rigging using the Fitted Mesh technique===
# Download one of the [[#Download_links|skeleton files]].
# Follow one of the many tutorials for rigging avatars in your modeling program of choice.
#* Links to video tutorials on rigging mesh avatars in Maya and Blender can be found in [http://wiki.secondlife.com/wiki/Mesh/Uploading_and_wearing_a_rigged_mesh#Creating_a_rigged_avatar Uploading and wearing a rigged mesh].
# Export your new rigged mesh from your modeling program of choice:
#* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Blender Exporting a mesh from Blender]
#* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_3ds_Max Exporting a mesh from 3DS Max]
#* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Maya Exporting a mesh from Maya]
# Import the rigged mesh to Second Life and wear the model, as described in [http://wiki.secondlife.com/wiki/Mesh/Uploading_and_wearing_a_rigged_mesh Uploading an wearing a rigged mesh].
# Adjust your body shape, make sure to save your changes, and enjoy your creation.
#* Information on changing your avatar’s appearance and body shape can be found in the Second Life Knowledge Base, under [http://community.secondlife.com/t5/English-Knowledge-Base/Controlling-your-avatar-s-appearance/ta-p/700709#Section_.2 Controlling your avatar’s appearance], and by clicking the '''?''' button at the top of the Appearance editor.

===Additional resources===
* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Blender Exporting a mesh from Blender]
* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_3ds_Max Exporting a mesh from 3DS Max]
* [http://wiki.secondlife.com/wiki/Mesh/Exporting_a_mesh_from_Maya Exporting a mesh from Maya]
* [http://wiki.secondlife.com/wiki/Mesh/Uploading_and_wearing_a_rigged_mesh Uploading and wearing a rigged mesh]
* [http://community.secondlife.com/t5/Mesh/Ways-to-fix-a-problematic-Avatar-Rig/td-p/1947773 Ways to fix a problematic Avatar Rig]
* [http://wiki.secondlife.com/wiki/Clothing_Tutorials Clothing Tutorials]
* [http://community.secondlife.com/t5/English-Knowledge-Base/Controlling-your-avatar-s-appearance/ta-p/700709 Controlling your avatar's appearance]

PRIM TYPE

2013-11-27T00:50:09Z

Darien Caldwell: fix typo

<onlyinclude>{{#if:

{{#vardefine:p_type_flag_desc|PRIM_TYPE_* flag}}
{{#vardefine:p_type_parameters_hover|a list consisting of the parameters of the PRIM_TYPE_* flag}}
{{#vardefine:p_type_parameters_desc|a list consisting of the parameters of {{LSLP|flag}}}}

{{#vardefine:p_hole_shape_desc|PRIM_HOLE_* flag}}
{{#vardefine:p_cut_desc|x and y range from 0.0 to 1.0, x must be at least 0.05 smaller than y (z is ignored)}}
{{#vardefine:p_hollow_desc|ranges from 0.0 (solid) to 0.95 (maximum hollowed)}}
{{#vardefine:p_twist_box_desc|ranges from -0.5 (-180 degree in the edit window) to 0.5 (+180 degree in the edit window) for both x and y (z is ignored)}}
{{#vardefine:p_twist_torus_desc|ranges from -1.0 (-360 degree in the edit window) to 1.0 (+360 degree in the edit window) for both x and y (z is ignored)}}
{{#vardefine:p_hole_size_desc|x ranges from 0.05 to 1.0; y ranges from 0.05 (large hole) to 0.50 (no hole)}}

{{#vardefine:p_top_size_hover|ranges from 0.0 (top fully tapered) to 1.0 (no tapering) for both x and y (z is ignored); see Caveats about the differences between the client and scripting range for this value}}
{{#vardefine:p_top_size_desc|ranges from {{HoverText|0.0|Top fully tapered}} to {{HoverText|1.0|No tapering}} for both x and y (z is ignored)[[#z_taper|!]]}}
{{#vardefine:p_z_taper_hover|ranges from 0.0 (top fully tapered) to 1.0 (no tapering) to 2.0 (bottom fully tapered) for both x and y (z is ignored); see Caveats about the differences between the client and scripting range for this value}}
{{#vardefine:p_z_taper_desc|ranges from {{HoverText|0.0|Top fully tapered}} to {{HoverText|1.0|No tapering}} to {{HoverText|2.0|Bottom fully tapered}} for both x and y (z is ignored)[[#z_taper|!]]}}

{{#vardefine:p_top_shear_desc|ranges from -0.5 to 0.5 for both x and y (z is ignored)}}
{{#vardefine:p_taper_desc|ranges from -1.0 to 1.0 for both x and y (z is ignored)}}
{{#vardefine:p_revolutions_desc|ranges from 1.0 to 4.00}}
{{#vardefine:p_radius_offset_desc|depends on holesize.y and revolutions}}
{{#vardefine:p_skew_desc|ranges from -1.0 to 1.0}}


{{#vardefine:p_twist_end_desc|ranges from -0.5 (-180 degree in the edit window) to 0.5 (+180 degree in the edit window)}}
{{#vardefine:p_hole_size_y_desc|ranges from 0.05 (large hole) to 0.50 (no hole)}}
{{#vardefine:p_topshear_x_desc|ranges from 0.05 to 0.50}}

{{#vardefine:type_const|{{LSL Const|PRIM_TYPE|integer|9|c=Used to {{GetSet|{{{1|}}}|get|set|/}} the the type of prim.}}}}

{{#vardefine:caveats-set|{{#var:caveats-set}}
* {{#var:type_const}} can only be used with [[LINK_SET]] if the object contains 10 or fewer prims. It can only be used with [[LINK_ALL_OTHERS]] or [[LINK_ALL_CHILDREN]] if the object contains 11 or fewer prims. If there are more prims, the operation will fail and an error will be shouted to [[DEBUG_CHANNEL]]. Work around this by looping through the prims with [[llSetLinkPrimitiveParamsFast]].
* {{#var:type_const}} will silently fail when executed by a script placed inside a mesh, whether the affect object is the mesh or not (in linksets for example),use a normal prim as your root prim.
}}

{{#switch:{{{1|}}}
|get={{#vardefine:caveats|{{#var:caveats}}
{{#var:caveats-get}}{{#vardefine:caveats-get}}}}
|set={{#vardefine:caveats|{{#var:caveats}}
{{#var:caveats-set}}{{#vardefine:caveats-set}}}}

}}

}}</onlyinclude>{{#if:

{{:PRIM_TYPE_SCULPT|{{{1|}}}}}

}}{{LSL Constant
|inject-2={{LSL PrimitiveParam Categorize|Prim}}
|name=PRIM_TYPE
|type=integer
|value=9
|desc=Gets or sets the {{LSLP|type_flag|type}} of the prim and associated type {{LSLP|type_parameters|parameters}}.
|examples
|pa={{LSL Constant/List|i_front=[ {{#var:type_const}}, |i_end= ] + {{LSLPT|type_parameters|flag_parameters}}
|text=Used with [[llSetPrimitiveParams]] & [[llSetLinkPrimitiveParams]].

The values needed for {{LSLP|type_parameters|flag_parameters}} is dependent on {{LSLP|type_flag|flag}}, please refer to the individual PRIM_TYPE_* articles for additional information.
{{LSL Generic/Caveats|caveats={{#var:caveats-set}}|title=*}}
|toc=llSetPrimitiveParams
|i1_type=integer|i1_name=type_flag|i1_disp=flag
}}
|pb={{LSL Constant/List|i_front=[[llGetPrimitiveParams]]([ {{#var:type_const}}|i_end= ]);|
|r_front=Returns the list <code>[ |r_end= ] + {{LSL Param|type_parameters|flag_parameters}}</code>
|text=The values that follow after {{LSLP|type_flag|flag}}, the {{LSLP|type_parameters|flag_parameters}}, are dependent on the value of {{LSLP|flag}}, please refer to the individual PRIM_TYPE_* articles for further information.

|toc=llGetPrimitiveParams
|r1_type=integer|r1_name=type_flag|r1_disp=flag
}}
|pc=
{{LSL_Constants/PrimitiveParams/type|table=*|simple=*|sortable=*|style=margin-top:0; margin-right:0;|{{LSLPT|type_parameters|flag_parameters}}}}
{{LSL Constants/PrimitiveParams/hole shape|table=*|simple=*|sortable=*|style=margin-top:0; margin-right:0;}}
|constants=
{{LSL ConstRow|CHANGED_SHAPE}}
|functions=
{{LSL DefineRow||[[llSetPrimitiveParams]]|}}
{{LSL DefineRow||[[llSetLinkPrimitiveParams]]|}}
{{LSL DefineRow||[[llGetPrimitiveParams]]|}}
|events=
{{LSL DefineRow||[[changed]]|}}
|location
|cat1
|cat2
}}

LSL Alternate Editors

2013-11-22T21:07:25Z

Darien Caldwell: /* Notepad++ */

{{LSL Header|ml=*}}

There are several off-world editors available for free or purchase. Some have syntax highlighting for LSL that will make your code easier to follow. At least two will compile and execute a large subset of LSL. Below are some of the more popular editors for use with LSL.

If you have a favorite that is missing from the list, '''please''' feel free to add it.

==Why use an alternate editor?==

Alternate editors with syntax highlighting color the code you write based on its syntax, some even let you use the colors used in the Second Life viewer. This greatly improves the readability of your code (for yourself!) and helps you to quickly scan the code for a particular part during review.

But these editors don't just help you with code review, but with writing code. Autocompletion lets you write scripts faster, with less typos and greatly improves readability by preformatting your code with the snippets you use.

Below is a screen cast that shows syntax highlighting and autocompletion.

[[File:Pareto_principle_scripting.gif|thumb|700px|center|Not only writing, but especially fixing scripts takes time and effort. '''Readability is key to being more productive!''' Shown above is Sublime Text.]]

==Colors used in the Second Life viewer by Linden Lab:==

 
{| class="wikitable sortable" style="font-size: 85%; text-align: center; width: auto; border=1px;"
|-
! '''part of LSL grammar'''
! '''hexadecimal triple'''
! '''RGB Decimal'''
! '''RGB Percentage'''
|- style="background:#000000;color:#ffffff"
| default text
| #000000
| 0, 0, 0
| 0, 0, 0
|- style="background:#cd4d26;color:#ffffff"
| comments
| #cd4d26
| 205, 77, 38
| 0.804, 0.302, 0.149
|- style="background:#801a4d;color:#ffffff"
| states
| #801a4d
| 128, 26, 77
| 0.502, 0.102, 0.302
|- style="background:#004d80;color:#ffffff"
| events
| #004d80
| 0, 77, 128
| 0, 0.302, 0.502
|- style="background:#820124;color:#ffffff"
| functions
| #820124
| 130, 1, 36
| 0.510, 0.004, 0.141
|- style="background:#1a1a80;color:#ffffff"
| integer constants
| #1a1a80
| 26, 26, 128
| 0.102, 0.102, 0.502
|- style="background:#1a4d80;color:#ffffff"
| string constants
| #1a4d80
| 26, 77, 128
| 0.102, 0.302, 0.502
|- style="background:#4d1a80;color:#ffffff"
| float constants
| #4d1a80
| 77, 26, 128
| 0.302, 0.102, 0.502
|- style="background:#663366;color:#ffffff"
| vector & rotation constants
| #663366
| 102, 51, 102
| 0.400, 0.200, 0.400
|- style="background:#000000;color:#ffffff"
| operators
| #000000
| 0, 0, 0
| 0, 0, 0
|- style="background:#1a4d1a;color:#ffffff"
| storage type
| #1a4d1a
| 26, 77, 26
| 0.102, 0.302, 0.102
|- style="background:#003300;color:#ffffff"
| strings
| #003300
| 0, 51, 0
| 0, 0.200, 0
|- style="background:#ff0000;color:#ffffff"
| numbers
| #ff0000
| 255, 0, 0
| 1, 0, 0
|- style="background:#0000cd;color:#ffffff"
| keywords
| #0000cd
| 0, 0, 205
| 0, 0, 0.804
|}

== Online LSL Generators ==
Online LSL generators create and edit LSL scripts via a website, some may have syntax highlighting for better reading.
Sites are multi-platform editors without downloads:
*[http://conwylie.co.uk/ScriptGenerator/ Con Wylie's LSL Script Generator]

== Syntax Highlighting Files ==
These projects may have more current LSL highlighting files:
*[http://adammarker.org/shill Shill project]
*[http://hilitelsl.googlecode.com HiLiteLSL.GoogleCode.com]

== Syntax highlighting and code completion files by the [http://www.buildersbrewery.com Builder's Brewery]: ==

{| class="wikitable sortable" style="font-size: 85%; text-align: center; width: auto; border=1px;"
|-
! '''Software:'''
! '''Commercial software:'''
! '''Windows:'''
! '''Mac:'''
! '''Linux:'''
! '''Browser'''
! '''Direct URL:'''
! '''Issue tracker:'''
! '''Autocomplete:'''
! '''Syntax highlight:'''
|-
| [http://ace.c9.io Ace Editor for the web]
| {{no}}
| {{maybe|requires a browser}}
| {{maybe|requires a browser}}
| {{maybe|requires a browser}}
| {{yes}}
| [https://github.com/ajaxorg/ace/ Ace Editor for the web]
| [https://github.com/ajaxorg/ace/issues/ Issue tracker]
| {{yes}}
| {{maybe|yes, doesn't include LL viewer theme}}
|-
| [http://www.contexteditor.org/ ConTEXT Text Editor]
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-context/ Files for ConTEXT]
| [https://github.com/buildersbrewery/lsl-for-context/issues/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://projects.gnome.org/gedit/ gedit Text Editor]
| {{no}}
| {{yes}}
| {{yes}}
| {{maybe|for GNOME}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-gedit/ Files for gedit]
| [https://github.com/buildersbrewery/lsl-for-gedit/issues/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi GeSHi SyntaxHighlight - wikimedia extension]
| {{no}}
| {{maybe|requires a browser}}
| {{maybe|requires a browser}}
| {{maybe|requires a browser}}
| {{yes}}
| [https://github.com/buildersbrewery/lsl-for-geshi/ Files for GeSHi]
| [https://github.com/buildersbrewery/lsl-for-geshi/issues/ Issue tracker]
| {{no|no, static web view only}}
| {{yes}}
|-
| [http://www.jedit.org/ jEdit]
| {{no}}
| {{maybe|requires JavaVM}}
| {{maybe|requires JavaVM}}
| {{maybe|requires JavaVM}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-jedit/ Files for jEdit]
| [https://github.com/buildersbrewery/lsl-for-jedit/issues/ Issue tracker]
| {{yes}}
| {{maybe|yes, doesn't include LL viewer theme}}
|-
| [http://www.kate-editor.org/ Kate Editor]
| {{no}}
| {{maybe|via KDE for Windows}}
| {{maybe|via KDE for Mac}}
| {{yes}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-kate-editor/ Files for Kate Editor]
| [https://github.com/buildersbrewery/lsl-for-kate-editor/issues/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://www.notepad-plus-plus.org/ Notepad++]
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-notepadplusplus/ Files for Notepad++]
| [https://github.com/buildersbrewery/lsl-for-notepadplusplus/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://www.codingmonkeys.de/subethaedit/ SubEthaEdit]
| {{yes}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-subethaedit/ Files for SubEthaEdit]
| [https://github.com/buildersbrewery/lsl-for-subethaedit/issues/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://www.ultraedit.com/ UltraEdit]
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-ultraedit/ Files for UltraEdit]
| [https://github.com/buildersbrewery/lsl-for-ultraedit/issues/ Issue tracker]
| {{yes}}
| {{yes}}
|-
| [http://www.vim.org/ Vim Text Editor]
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}
| [https://github.com/buildersbrewery/lsl-for-vim/ Files for Vim]
| [https://github.com/buildersbrewery/lsl-for-vim/issues/ Issue tracker]
| {{yes}}
| {{maybe|yes, doesn't include LL viewer theme}}
|}

==LSL Integrated Development Environments (coding and testing environments) ==

===[[Con-Wylies-Script-Generator]]===

*[http://conwylie.co.uk/ScriptGenerator/ Con Wylie's LSL Script Generator] has been ported from a website into a free downloadable program, anyone can use the program as it is very easy to use.

Con Wylie's LSL program is multi-platform on Windows, Linux and Mac. The generator, editor and compiler has been build from the ground up to give the user ease of use.

===[[LslPre]]===
* [http://lsl.dreamjammers.net http://lsl.dreamjammers.net]
LslPre is a full featured LSL script editor, preprocessor and optimiser for windows.

===[[LSL Editor Community Edition]]===

LSL Editor Community Edition '''for Windows''' is a standalone LSL script '''editor, compiler and debugger'''. Binary and Source as of 2013-03-14.

Its compiler and debugger are already now reasonably accurate. Please blog any LSL-Editor bugs you find into such places as our [[LSLEditorBugs|LSL-Editor Bugs]] article or via the project's SourceForge bug tracker located at: [http://sourceforge.net/tracker/?group_id=319248 Bug Tracker].

* Alphons van der Heijden, author of LSLEditor, the great off-line editor and debugging tool for scripting in Second Life, has donated his opus magnum to the free and open source community where it can grow and keep pace with the SL platform!

*Details, executable and source can be found at [http://sourceforge.net/projects/lsleditor/ http://sourceforge.net/projects/lsleditor/]

Development of LSL-Editor was originally done by Alphons van der Heijden at [http://www.lsleditor.org/ http://www.lsleditor.org/].

=== [[LSL-Plus]] ===

[http://lslplus.sourceforge.net/ LSL PLus Eclipse Plugin]

'''For Windows, Mac, and Linux''', the LSL Plus Eclipse plugin is a Editor/Unit Test environment for LSL implemented in Eclipse. It is a FLOSS project (Free/Libre Open Source Software). The latest release (0.13.0 - 2010-01-06) features multi-script execution with '''source level debugging''' (setting breakpoints, single stepping through code, examining variables on the call stack, etc.), making it unique among LSL IDEs. It now supports both multi-script execution in a simulated environment (with avatars, prims, inventory, (limited) physics, etc.) and '''unit''' testing - allowing you to test individual handlers and functions by precisely controlling the setup/teardown and interaction with the execution environment (including support for 'mocking' the LL function call that interact with the script environment). It also has some additional code management features that encourage code re-use without having to cut-and-paste, as well as code '''optimization''' (inlining, constant folding).

By using the Eclipse IDE you get features such as integration with source code control systems like CVS or Subversion, task management, integration with 3rd party bug tracking software, and so on. It supports development on Windows, Mac, and Linux platforms.
* Missing bracket matching and certain highlighting features.

=== [[LSLForge]] ===

[http://code.google.com/p/lslforge/ LSLForge Eclipse]
'''For Windows/Linux/OS X''', LSLForge is a derivative of [[LSL-Plus]], forked in September 2011. LSLForge aims to further advance and mature the LSL-Plus project and support the Eclipse LSL developer community.

=== [[MiceOnABeam Visual Scripting Tool]] [{{HoverText|''C''|Commercial Software}}]===

* [http://www.miceonabeam.com/ MiceOnABeam Visual Scripting Tool]
MiceOnABeam is a visual programming tool that generates LSL scripts for SL. You choose among graphical modeling components to specify the program flow of your script in terms of states and the events that transition between the states. You can then use the built-in LSL Action Wizard or insert your own LSL code to specify what happens when an event occurs. The program then generates the LSL code for the model to form a complete script for the SL environment. Check out the demo video '''[http://bit.ly/ihCqyf here]''' or on '''[http://www.youtube.com/watch?v=LBA8wvoA9EI YouTube]'''. A Free version can be downloaded from '''[http://www.miceonabeam.com here]'''.

==Off-world syntax checker==
You can build a syntax checker yourself and hook it into whatever editor you fancy if you have the viewer source installed and compiled on your machine. The C++ source to build one yourself is [[User:JB_Kraft#Offline_LSL_Syntax_Checker|here (JB Kraft)]].

==Multi-platform Editors==

===ByronStar SL===
Based on [http://eclipse.org Eclipse], the [http://byronstar-sl.sourceforge.net/ ByronStar SL IDE] includes most modern program editor features. It also includes custom features for LSL, such as variable checking, error markers, and code formatting. Eclipse is available for Macintosh, Linux, Windows, and many UNIX flavors.
* No longer maintained.

===Emacs===
There's an [[Emacs LSL Mode]] available on this wiki, which provides syntax highlighting and indentation features. If you want some tips on writing LSL in emacs, read [http://xahlee.org/sl/ls-emacs.html Xah Lee's page]. Emacs is available for many Unix flavors, Macintosh and Windows.

You may come across (and attempt to use) Gary Evan's [http://www.cs.iastate.edu/~leavens/emacs/lsl-mode.el LSL major mode]. It won't work with the Linden Scripting Language, as Gary wrote it for the [http://www.cs.iastate.edu/larch-faq-webboy.html Larch Shared Language].

===vim===
[http://www.vim.org/ vim:] vi improved. A multi-platform evolution of the most classical of the editors: vi. GPL code.
 [http://www.secondlifelab.it/index.php?option=com_remository&Itemid=77&func=select&id=7 Plugins for VIM] for install the syntax, autocompletion, autoident for LSL script into vim

===JOE===
[http://joe-editor.sourceforge.net/ Joe's Own Editor (a.k.a. Joe)] is a comand line editor for unixoid systems. See [[User:Zai Lynch/LSL highlighting in Joe]] for a manual and syntax file download.

===SciTE===
Easy to use, features syntax highlighting, folding, auto complete, help that opens the appropriate wiki page, and is setup to use the c preprocessor, and lslint. 
Windows only [https://sdfjkl.org/hack/scite-ez/] 

Files for Linux or Windows [http://forums.secondlife.com/showthread.php?t=209219 Forum thread] [http://dimension128.homelinux.net/scite_lsl.tar.gz scite_lsl.tar.gz]

===jEdit===
Developed in Java, this mature, cross-platform editor runs on any operating system with a Java 2 version 1.3 or higher virtual machine. It has all the features you'd expect from a full-GUI text editor. Syntax highlighting and tailored editing behavior is supported through "modes." (You can get the LSL 'modes' file [https://gist.github.com/GitSkunk/5327522 here] {{WFont|fstyle=italic|color=orange|text=updated 18-Apr-13}}.) The editor supports a rich plug-in API; many third-party plug-ins exist to facility editing, formatting, communications, etc. 
You can find jEdit [http://www.jedit.org/ here].

===Shill - LSL syntax files for a variety of editors===
The [http://adammarker.org/shill Shill project] provides up-to-date syntax files for many LSL editors. You might find files there that are more current than those here on the wiki. Last update: 19Aug09 for Second Life 1.23.4. New in this release: lslint

===Midnight Commander===
[http://www.midnight-commander.org/ GNU Midnight Commander (mc)] is a free cross-platform orthodox file manager and a clone of Norton Commander. 
Midnight Commander is a console application with a text user interface. 
OS: Unix-like, Microsoft Windows 
For Linux see [[User:Kuraiko_Yoshikawa/sandbox/LSL_Goodies/mc]] for a manual and syntax file download.

===UltraEdit-32/UEStudio [{{HoverText|''C''|Commercial Software}}]===
[http://www.ultraedit.com/ UltraEdit-32/UEStudio] is a powerful text, HTML, and HEX editor. It is a commercial editor with a 30 day trial version available at the website. Important features:
* column/block mode editing
* brackets/braces matching
* code-folding
* configurable syntax highlighting via custom [http://www.ultraedit.com/index.php?name=Content&pa=showpage&pid=40#wordfiles wordfiles]
* autocomplete (using keywords defined in the wordfile)
* bookmarks, incremental searching, CTAG support
* automatic conversion between Unix/Dos/MAC/UTF-8, etc
* built-in FTP/SFTP client

OS: Linux, Mac and Windows.

The following syntax files are available for UltraEdit
* [[User:Lum Pfohl/LSL Syntax Highlighting For UltraEdit]] Last updated November 28th, 2007.

===Sublime Text [{{HoverText|''C''|Commercial Software}}]===
[http://www.sublimetext.com/ Sublime Text] is a sophisticated text editor for code, markup and prose.
You'll love the slick user interface, extraordinary features and amazing performance. Key Bindings, Menus, Snippets, Macros, Completions and more - just about everything in Sublime Text is customizable with simple JSON files. This system gives you flexibility as settings can be specified on a per-file type and per-project basis. Sublime Text uses a custom UI toolkit, optimized for speed and beauty, while taking advantage of native functionality on each platform.

Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use. There is no enforced time limit for the evaluation.

The following syntax highlighting files are available for Sublime Text.
* [https://github.com/JKolya/sublime-text-2-lsl Sublime Text 2 LSL Syntex] Last updated October 28, 2012.

What you will get via Package Control is the following. Simply go "Package Control: Install Package" and search for "LSL". (including not only syntax highlighting, but also smooth LSL functions/events/constants completions, lslint as build system, and inworld editor look-and-feel theme)
* [https://github.com/Makopo/sublime-text-lsl LSL Bundle for Sublime Text 2] Active as of June 21, 2013.

Sublime Text is available for OS X, Windows and Linux.

==Windows Editors==

===e===
The [http://www.e-texteditor.com/ e Editor] is a port of TextMate to Windows, and can use the TextMate LSL bundle listed below.
===Notepad++===
[http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] is probably one of the best Windows editor around. Packed with features, extremely powerful and easy to use for beginners too. Best of all, it is GPL code.

Shan Bright's Notepad++ LSL syntax file 'BrightLSL' is at the Bright Corporation website: [http://www.brightcorporation.net/brightlsl BrightLSL] (Updated December 10, 2010)

Nexii Malthus's Notepad++ LSL syntax file, includes latest functions and constants [http://c438644.r44.cf2.rackcdn.com/userDefineLang.xml] (3rd December, 2011)

WhiteStar Magic's Notepad++ LSL syntax file is being updated regularly, and is available on Github: [https://github.com/WhiteStar-Magic/NotePad---userdef/archives/master NotePad---userdef] (Last Update: May.03.2012)

Gwen Setzer's Notepad++ (6.3 and above) LSL Syntax Files: (Generated from Firestorm 4.4.0)
Language description: [http://pastebin.com/2AsRuKjh lslLanguage.xml] (Language->Define your Language->Import)
Autocompletion support: [http://pastebin.com/FcjNVDyb lsl.xml] (Copy the file lsl.xml in the API plugin directory of Notepad++. ex: C:\Program Files\Notepad++\plugins\APIs, I also recommend enabling Settings->Preferences->Autocompletion->Function parameters hint on input)

Dari's Better Highlighting for Notepad++ (6.3 and above): [http://home.comcast.net/~volfin/LSL.XML LSL.XML] (updated 11/22/2013) [[User:Darien Caldwell|Darien Caldwell]] 12:11, 9 July 2013 (PDT)

Hint: to ensure code folding works properly, change line endings to Windows style if they are not already set as such. (Edit / EOL conversion / Windows format)

===ConTEXT===
[http://www.context.cx/component/option,com_frontpage/Itemid,1/ ConTEXT] is a small, fast and powerful freeware text editor, developed mainly to serve as secondary tool for software developers.

The following syntax files are available for ConTEXT.
* [http://blogic14.blogspot.com/ Last Activity] July 2012
* [http://archive.is/Wm3B Last Announcement by developer of ConTEXT] Friday, 07 September 2007
* [http://www.contexteditor.org/ Site and Newsletter Sign Up - '''DOWNLOAD'''] September 2007
* [http://forum.context.cx/index.php?action=dlattach;topic=1775.0;id=359 Shyan Graves] Last updated March 01, 2007.
* [http://adammarker.org/shill/context/lsl.chl Sir.Grelling] Last updated July 10, 2006.

===Crimson Editor===
[http://www.crimsoneditor.com/ Crimson Editor] is a professional source code editor for Windows.
The following syntax files are available for Crimson Editor.

* Aakanaar - Last updated September 10, 2006 for Second Life version 1.10.0.
* [http://sourceforge.net/projects/emeraldeditor/files/crimsoneditor/ Emerald Editor] '''2011''' Open Source version of Crimson Editor

===[[LSL-Editor]]===

* [http://www.lsleditor.org/ http://www.lsleditor.org/]

[[LSL-Editor]] is a standalone Windows LSL '''editor, compiler and debugger'''.
All the usual editing, plus you can compile and execute.
* This project is no longer maintained at LSLEditor.org. See below.

===LSL Editor Community Addition===

* [http://sourceforge.net/projects/lsleditor/ Source Forge: LSL Editor]

[[LSL-Editor]] is the '''frequently''' updated version of the LSL Editor with editing, compiling, and debugging abilities.
When the path to the editor is added to the viewer's Debug Setting: ''ExternalEditor'' one can have a nice round trip external editor. See the LSL-Editor entry just above, above in the Integrated section, and the wiki page [[LSL-Editor]] for more information.

===TextPad [{{HoverText|''C''|Commercial Software}}]===
[http://www.textpad.com/products/textpad/index.html TextPad] is a powerful, but easy to use general purpose text editor. It is a commercial product, but there is a 30 day trial version available for free on the website.

The following syntax files are available for TextPad.
* [[LSL_Editor_TextPad_ClipBook_Events | Events ClipBook]] Last updated March 5, 2007. Based on the LSL Portal event entries.
* [[LSL_Editor_TextPad_Syntax | Prodigal Maeterlinck & Patrick2 Chama]] Last updated February 20, 2007. Extracted from the Second Life viewer source code.
* [http://www.textpad.com/add-ons/files/syntax/lsl_.zip Ben Gray] Last updated August 23, 2006. As of version 1.12.0, with the deprecated functions in a separate keyword list.
* [http://www.textpad.com/add-ons/files/syntax/lsl.zip Matthias Huber] Last updated September 23, 2004.

===EditPad Pro [{{HoverText|''C''|Commercial Software}}]===
[http://www.editpadpro.com/ EditPad Pro] is a text editor with many great features for programming. It is a commercial program, with a demo version available. There is also a Lite version, but that has no syntax-highlighting support.

There is an LSL syntax file available for download from inside the program. However, it is from October 2006 so some new features may not be available.

==Macintosh Editors==
===TextMate [{{HoverText|''C''|Commercial Software}}]===

TextMate is a commercial text/program editor from [http://macromates.com/ Macromates] (30 day trial available). You can find details about Piero Padar's well-maintained LSL bundle in the [http://forums-archive.secondlife.com/54/ae/89389/1.html Scripting Tips forum archive].

===SubEthaEdit [{{HoverText|''C''|Commercial Software}}]===
This a great text editor with extensible language support. It also happens to be an incredible collaborative editor. Info at: http://www.subethaedit.net/

There is a contributed LSL mode by Zarf Vantongerloo. The mode is a little out of date and could use some love. But in general works great, doing syntax hilighting of LSL funcitons and adding a pop-up menu of all functions, states and event handlers to the top of the window.

An updated LSL mode by Mark Lentczner is available now from the SubEthaEditor [http://www.subethaedit.net/modes.html User contributed modes Repository].

An updated (but still out of date) version of Mark Lentczner's mode is available on Solo Mornington's Github: https://github.com/SoloMornington/LSL_mode Note that this mode was developed for Coda 1.

===Coda [{{HoverText|''C''|Commercial Software}}]===

Coda is 'one-window web development,' but it's a very pleasing text editor for a wide variety of uses. You can set up 'sites' which are web sites, but can represent any remote filesystem, which is echoed locally through ftp and/or subversion.

Coda can use SubEthaEdit syntax coloring 'modes,' so LSL is supported. Also available is a plug-in editor which lets you run arbitrary scripts on the selection or document.

http://www.panic.com/coda/

===BBEdit and TextWrangler ===

You can get an LSL language plugin for all versions of BBEdit and TextWrangler at [http://blog.elitecoderz.net/lsl-linden-script-language-plugin-for-bbedit/2008/12/ Erik Scholtz' Blog]

For older versions of BBEdit (7.0 or less) and TextWrangler (1.0 only), there is a module available at [http://adammarker.org/bbedit http://adammarker.org/bbedit]

==Linux Editors==
===Kate===
[http://kate-editor.org/ Kate] is an advanced text editor for KDE. Usually included in all KDE based distributions. 
A [[Kate LSL Mode]] is available on this wiki.
===Gedit===
[http://www.gnome.org/projects/gedit/ Gedit] is an advanced text editor for GNOME. 
See [[User:Kuraiko_Yoshikawa/sandbox/LSL_Goodies/gedit]] for a manual, syntax file and Color Theme download.
===Nano===
Nano is a curses-based text editor for Unix and Unix-like systems. 
Since February 2001, nano is an official part of the GNU Project. 
See [[User:Kuraiko_Yoshikawa/sandbox/LSL_Goodies/nano]] for a manual and syntax file download.
===Vim===
Based on the vi editor common to Unix-like systems, [http://vim.sourceforge.net/ Vim] is designed for use both from a command line interface and as a standalone application in a graphical user interface. 
Vim comes standard with LSL hilighting support.

== Features Table ==

{| class="wikitable sortable" style="font-size: 85%; text-align: center; width: auto; border=1px;"
|-
! Name
! Integrated development environment
! Platforms
! Code Completion
! Highlighting
! Actively Maintained
|-
! [[LSL_Alternate_Editors#Con-Wylies-Script-Generator|Con-Wylies-Script-Generator]]
| {{yes}}
| Windows/Linux/Mac
| {{yes}}
| {{yes}}
| {{Yes}}
|-
|-
! [[LSL_Alternate_Editors#LSL-Plus|LSL-Plus]]
| {{yes}}
| Multi-Platform
| {{yes}}
| {{yes}}
| {{no}}
|-
|-
! [[LSL_Alternate_Editors#LSLForge|LSLForge]]
| {{yes}}
| Windows/Linux/OS X
| {{yes}}
| {{yes}}
| {{Yes}}
|-
|-
! [[LSL_Alternate_Editors#LSL Editor Community Edition|LSL Editor Community Edition]]
| {{yes}}
| Windows-Only
| {{yes | Custom Vars and Functions also}}
| {{yes}}
| {{yes}}
|-
|-
! [[LSL_Alternate_Editors#LslPre|LslPre]]
| {{yes}}
| Windows(.Net)
| {{yes}}
| {{yes}}
| {{yes}}
|-
|-
! [[LSL_Alternate_Editors#MiceOnABeam Visual Scripting Tool|MiceOnABeam Visual Scripting Tool]]
| {{yes}}
| Windows(.Net)
| {{yes | Custom Vars and Functions also}}
| {{yes}}
| {{yes}}
|-
|}

User talk:Darien Caldwell

2013-11-22T21:03:00Z

Darien Caldwell: /* Oh, and... */

== URL(En|De)code ==

I like your idea of referencing similar functions from other languages. Maybe an optional collapsible table (collapsed by default) in the Summary section with function names as links for the other languages? An added bonus of this feature is that it would allow people to search the documentation for LSL functionality based on the names from other languages. Thoughts? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 13:23, 23 August 2012 (PDT)

Yes I don't think it needs to be prominent. You hit upon the exact idea behind it, as every time I want to find the two functions mentioned, I'm always looking for llURLEncode() llURLDecode(), It's just exactly what I expect from other languages. Then I spend a lot of time trying to remember what LL calls them. I figured referencing the common function name would help people like me who often confuse with other languages. So I think your idea is a fine one. [[User:Darien Caldwell|Darien Caldwell]] 22:43, 23 August 2012 (PDT)

I don't have a good idea as to how this should be templatized (not to mention the entire template & information sprawl issue does gnaw upon me, and I don't have a good solution for that, and I'm sorry for it). I'm thinking includable subtemplates like the Signature section. Has potential, I'll do a mockup tomorrow (or when I have time). -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 23:00, 23 August 2012 (PDT)

Take a gander at [[Template:LSL_Other_Languages]]. I'll transclude it when if you think it's ready. Do you think it's important that this is in the Summary section? From a users perspective knowing it's similar to a function you already know really speeds up learning about it, but only if you know of the function. So having the most popular alternate names visible helps, but having the full table of names does does not. It should be compact and informative at the same time. As a stop gap solution, it is currently showing the first three other function names in the text. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 09:22, 24 August 2012 (PDT)

:To answer my own question, yes I think it's important enough to be in the summary section. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 09:30, 24 August 2012 (PDT)

Yes I think that's perfect. As long as the search can index the whole table, showing only a few makes sense. Ship it, I say. :) [[User:Darien Caldwell|Darien Caldwell]] 11:11, 24 August 2012 (PDT)

== PRIM_LINK_TARGET ==

I didn't know you could use [[PRIM_LINK_TARGET]] with [[llGetPrimitiveParams]]. That is cool. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 20:54, 28 August 2012 (PDT)

Yeah i needed it today, and wasn't sure myself. But it worked. :) [[User:Darien Caldwell|Darien Caldwell]] 00:13, 29 August 2012 (PDT)

== Animation Length Limit Update ==

Thank you for your update to the [[Animation Length Limit]] article I wrote. I wrote several articles linked in [[Talk:How to create animations]]. I still keep an eye on them. I hope no others are out of date.

I hope someday all the bugs with the animation system will be fixed, and someone will update the information on that. I even submitted patches for some, but to my knowledge, they are still unapplied.

[[User:Coaldust Numbers|Coaldust Numbers]] 05:43, 30 June 2013 (PDT)

== Template:LSL Constants/ReturnError ==

I don't know what I was channeling when I wrote those descriptions. With ERR_GENERIC, I think I started channeling Zork. Which lead me to lookup and then recompose some of the haiku that you will find in the HTML comments in the table. I'm thinking about writing one for each constant. Does that make me insane? -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 22:02, 9 July 2013 (PDT)

LOL, I think it just means you have a sense of humor. :) I shall have to peruse these works. Are you sure you saved it? The template seems to be unmodified, even from source view.[[User:Darien Caldwell|Darien Caldwell]] 18:12, 10 July 2013 (PDT)

User talk:Darien Caldwell

2013-10-06T20:51:27Z

Darien Caldwell: Fixed, thanks ;)

Mesh/Avatar Shape XML Format

2013-09-07T18:29:47Z

Darien Caldwell:

{{Navbox/Mesh|tech}}
== History ==
The Shape XML format has been ingrained in the viewer since the early days, long before mesh existed. However, with the addition of rigged mesh and customized clothing, the file has become invaluable to creators. Sometimes called an "archetype file" due to it's default name "new_archetype.xml".

With the release of [[Project_Sunshine-Server_Side_Appearance|Server Side Appearance]] in Early 2013, The XML format has inherited additional information. However, it's XML version number is still 1.0, and it is still backward compatible with the original terse format. The additions will be outlined separately in the SSA Extensions section.

== Header ==
The file is standard XML, with 3 parameters:

* <?xml version="1.0" encoding="US-ASCII" standalone="yes"?>
** The 'version' parameter sets the version of the XML markup. (should always be 1.0)
** The 'encoding' parameter sets the character encoding for the file. (should always be US-ASCII)
** The 'standaline' parameter informs that the file is self-containted, and not dependent on any external files. (should always be yes)
(note that some viewers set standalone="true". This is technically incorrect via the XML standard. It should be "yes")

== Root Node ==
The root node is of type 'linden_genepool' witih 1 parameter:

* <linden_genepool version="1.0">
** The 'version' parameter sets the version of the data contained in the node. Currently LL's data is version 1.0. Future revisions may increment this version, so any implementation should check this version number before using the data.

== Data Body ==
The Root node contains one node of type 'archetype' with one parameter.

*<archetype name="???">
** The 'name' parameter is a information parameter, and can contain anything, or nothing. Most commonly populated with 3 question marks.

== The Data ==
The data inside is a list of parameters and textures associated with the Avatar's appearance. These can be broken up into 4 categories:

* Shape
* Skin
* Hair
* Eyes

Each category will have several "param" nodes and possibly "texture" nodes included. More about these nodes in the next section.

== Param Nodes ==
"param" nodes correspond to sliders in the appearance pane. Each has 3 parameters:
*Example: <param id="649" name="torso muscles" value="0.500"/>
** The 'id' parameter corresponds to an internal viewer table of possible sliders. These numbers are guaranteed to be unique, and always correspond to the same slider.
** The 'name' parameter corresponds to internal 'driving elements' in the viewer. This can vary depending on the type of param. For shapes, it's often the name of the morph being controlled. For skins or eyes, it's usually a material that's being changed (color etc). For hair, a combination of both are present. These are *not* always unique. For example, there are two parameters called "torso muscles", with different IDs (one for male, one for female).
** The 'value' parameter is the value of the slider. It is however in the internally used format, not the 0-100 value seen by Residents. Calculating what these values mean requires finding the Minimum and Maximum of that value from other sources, such as the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)

== Texture Nodes ==
"texture" nodes correspond to textures applied via the appearance pane. Each has 2 parameters:
*Example: <texture te="3" uuid="00000000-0000-0000-0000-000000000000"/>
** The 'te' parameter corresponds to an internal viewer table of possible textures. These numbers are guaranteed to be unique.
** The 'uuid' parameter corresponds to the UUID of the texture applied at the time of the XML creation.
Note that 'texture' nodes are optional and not guaranteed to be present. Especially when the file is generated from 3rd party sources.

== Comments ==
Comments are styled in the standard HTML style, with the string <html4strict></html4strict> denoting the end of a comment. This is per the XML specification.
*Example: <html4strict></html4strict>

== File Termination ==
The file is terminated by the closing of the 'archetype' and 'linden_genepool' nodes:

*</archetype></linden_genepool>

== SSA Extensions ==
The Two main changes with SSA are the addition of *many* new 'Param' nodes , and the inclusion of new data in all 'Param' nodes.
*The additional 'param' nodes now cover more than just the avatar's body shape and texture. Now, there is data for every possible avatar appearance modifier, including all clothes layers, alpha layers, tattoo layers, all internal morphs, and all settings for these items. In short there is every bit of data needed to completely recreate the entire avatar's 'look'.
*The new parameters included in the 'Param' nodes is *in addition to* the original parameters. All of the originally available parameters are still provided. The new parameters are as follows:
**The 'u8' parameter is a short integer normalized representation of the displayed slider value. Whereas before some complex math was necessary to determine what 0-100 slider value was indicated by the morph value in the 'value' parameter, now you can simply take the u8 value, divide it by 255, then multiply that value by 100. That will give you the displayed slider values. 255 would be a slider value of 100, 128 would be a slider value of 50, and 0 would of course be 0.
**The 'type' parameter is a rough indication of what kind of data the 'param' entry is associated with. There seem to be 5 distinct values, which likely correspond to entries in the [[Avatar_Appearance#Linden_avatar_definition_file|Linden Avatar Definition File]] (avatar_lad.xml)
*** param_morph, param_driver, param_skeleton, param_color, param_alpha
** The 'wearable' parameter further groups 'param' entries into distinct groups. These clearly indicate what avatar component the 'param' node is associated with. There seem to be 16 distinct values:
*** shape, hair, invalid, gloves, eyes, skin, pants, shoes, shirt, jacket, socks, underpants, undershirt, skirt, tattoo, physics
** The 'invalid' wearable indicates a morph.

Mesh/Avatar Shape XML Format

2013-09-07T18:06:10Z

Darien Caldwell: /* History */ Adding info about SSA expansion of format