Second Life Wiki - User contributions [en]

LlHTTPRequest

2025-07-23T18:26:00Z

Monty Linden: Trivial edit to test save

{{LSL_Function
|func=llHTTPRequest
|func_id=230
|func_energy=10.0
|func_sleep=0.0
|func_desc=Sends an HTTP request to the specified URL with the body of the request and parameters. When the response is received, a [[http_response]] event is raised.
|sort=HTTPRequest
|func_footnote=
|return_type=key|return_subtype=handle
|return_text=identifying the HTTP request made.
|p1_type=string|p1_name=url|p1_desc=A valid HTTP/HTTPS URL.
|p2_type=list|p2_subtype=instructions|p2_name=parameters|p2_desc=configuration parameters, specified as HTTP_* flag-value pairs
[ parameter1, value1, parameter2, value2, . . . parameterN, valueN]
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|constants={{LSL_Constants_HTTP}}
{{LSL_Constants/HTTP_Headers}}
{{LSL_Extended_Error_HTTP}}
|spec=
|caveats=
*Spaces, control characters, and other characters that are not allowed in URLs will cause a run time error.
*The corresponding [[http_response]] event will be triggered in all scripts in the [[prim]], not just in the requesting script.
*Requests must fully complete after 60 seconds, or else the response will be thrown away and the [[http_response]] status code will be 499.
*The response body is limited to 2048 bytes by default, see [[HTTP_BODY_MAXLENGTH]] above to increase it. If the response is longer, it will be truncated.
*The request body size (e.g., of POST and PUT requests) is limited only by available script memory. Scripts can hold at most 32k characters in a string, under [[Mono]], as characters are two bytes each, so, scripts cannot upload over 32k UTF-8 characters
*Cannot be used to load textures or images from the internet, <strike>for more information see [[Web Textures]]</strike>{{Footnote|'''Note:''' Web textures have been made obsolete for many reasons, and the link has been archived; nevertheless, the reference might be interesting for historical reasons.}}.
*If the accessed site is relying on the LSL script to report [[L$]] transactions, then it '''must''' check the <code>X-SecondLife-Shard</code> header to see if the script is running on the beta grid.
* Some servers will return a <code>405</code> error if you send POST to a file that can't accept metadata, such as a text or HTML file. Make sure you use the GET method to ensure success in any environment.
* While the HTTP status code from the server is provided to the script, redirect codes such as <code>302</code> will result in the redirect being automatically and transparently followed ONLY IF the [[HTTP_METHOD]] is GET, with the resulting response being returned. If the [[HTTP_METHOD]] is anything other than GET then you'll get back an [[http_response]] with a status code of <code>302</code>, but without any way to view the headers, you can't know where you were being redirected to unless that was also included in the body.
* The following applies when making a request to a script using HTTP-In:
**When appending a query string to a cap URL there '''MUST''' be a trailing slash between the cap guid and the query string token <code>"?"</code>. For example: [https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322?arg=gra {{HoverTextStyle|style=color:green;|<nowiki>https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322</nowiki>|2={{String|x-script-url}} = {{String|https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322}}}}?{{HoverTextStyle|style=color:red;|1=arg=gra|2={{String|x-query-string}} = {{String|1=arg=gra}}}}] will return a 500 HTTP status {{Wikipedia|List_of_HTTP_status_codes#5xx_Server_Error|Server Error code}}, but [https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322/?arg=gra {{HoverTextStyle|style=color:green;|<nowiki>https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322</nowiki>|2={{String|x-script-url}} = {{String|https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322}}}}{{HoverTextStyle|style=color:blue;|/|2={{String|x-path-info}} = {{String|/}}}}?{{HoverTextStyle|style=color:red;|1=arg=gra|2={{String|x-query-string}} = {{String|1=arg=gra}}}}] will succeed.
* <code>X-SecondLife-Owner-Name</code> may return <code>"(Loading...)"</code> instead of owner name (still true, 30th of March, 2022)
* Requests made at approx 0625 SLT may fail with a <code>503</code> status code, with <code>"ERROR: The requested URL could not be retrieved"</code>, and <code>"(111) Connection refused"</code> in the body of the response. This has been confirmed as expected behavior by Kelly, due to the nightly maintenance and log rotation. It does reliably impact object to object HTTP at that time, and quite probably may impact object to/from web around the same time. The interruption in service is fairly brief, and the precise timing may vary as LL adjust their nightly maintenance processes, or due to server load.
* Use <code>HTTP_MIMETYPE</code> to set the <code>Content-Type</code> header. Attempts to use <code>HTTP_CUSTOM_HEADER</code> to set it will cause a runtime script error.
* If the origin server does not include a content-type header in its response, LSL will attempt to treat the incoming data as "text/plain; charset=utf-8". This behavior diverges from [https://datatracker.ietf.org/doc/html/rfc2616#section-7.2.1 RFC 2616].

==== Throttles ====

The LSL function [[llHTTPRequest]] is throttled in three ways: by object, by owner, and by http error. All group-owned objects are considered together in the same throttle.

The current limits are:
* 25 requests in 20 seconds for each object
* 1000 requests in 20 seconds for each owner with higher limits for some regions
* Five HTTP errors (500 or higher) in 60 seconds for each script
These may change in the future if needed to prevent problems in regions.

It is possible for a large collection of objects or scripts to make many calls to [[llHTTPRequest]] and reach one or more throttles. When a script calls [[llHTTPRequest]] with a throttle blocking the request, it will return [[NULL_KEY]].

The calling script must check for the [[NULL_KEY]] result and react properly for the script and object to function correctly. Some things to consider:

* Pause further requests until the throttle clears
* Do not make any additional [[llHTTPRequest]] calls until enough time has passed for the throttle to reset. They will fail and continue to return [[NULL_KEY]] otherwise.
* Once reached, the throttles will remain in effect as long as requests continue, but will clear if there is a silent period with no requests at least twice the throttle interval, in the common case 2 * 20 or 40 seconds.‎

:Consider how a group of objects behaves. Developers must consider how multiple objects will interact and how that will affect clearing the throttle.‎

:The [[llHTTPRequest]] throttle is most likely to be an issue with a large number of objects in a region making requests. To clear the throttle fastest, when an object encounters the throttle, it should broadcast a region-wide chat message to other objects informing them of the event and stopping their requests. If those objects continue making requests, those requests will fail and just prolong recovery.‎

:If an object waits and still gets a failure, it may be a good idea to increase the time before the next request and/or add a small random value to the wait time. This may help prevent failures caused by large groups of objects acting nearly in unison.

* Object requests are throttled at approximately 25 requests per 20 seconds. This is to support a sustained rate of one per second or a maximum burst of up to 25 every 40 seconds (twice the interval for maximum burst), smaller bursts are recommended.
* [[NULL_KEY]] is returned if the request is throttled.
* See [http://forums-archive.secondlife.com/139/72/108960/1.html this thread] and [http://forums-archive.secondlife.com/139/2c/109571/1.html this thread] for older details.
----
|examples=

*[[Writing Headers and HTTP POST Body to a File]]

<syntaxhighlight lang="lsl2">
key http_request_id;

default
{
state_entry()
{
http_request_id = llHTTPRequest("url", [], "");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id != http_request_id) return;// exit if unknown

vector COLOR_BLUE = <0.0, 0.0, 1.0>;
float OPAQUE = 1.0;

llSetText(body, COLOR_BLUE, OPAQUE);
}
}
</syntaxhighlight>

Example PHP test script:
<syntaxhighlight lang="php">
<?php header("content-type: text/plain; charset=utf-8"); ?>
Headers received:
<?php

/**
* @author Wouter Hobble
* @copyright 2008
*/

foreach ($_SERVER as $k => $v)
{
if( substr($k, 0, 5) == 'HTTP_')
{
print "\n". $k. "\t". $v;
}
}
?>
</syntaxhighlight>

Example PHP wrapper script both capturing Apache headers and global methods
<syntaxhighlight lang="php">
<?php
// Author Waster Skronski.
// General Public License (GPL).
// Mind that some headers are not included because they're either useless or unreliable.

$USE_APACHE_HEADERS = TRUE;// switch to false if you need CGI methods

if ($USE_APACHE_HEADERS)
{
$headers = apache_request_headers();
$objectgrid = $headers["X-SecondLife-Shard"];
$objectname = $headers["X-SecondLife-Object-Name"];
$objectkey = $headers["X-SecondLife-Object-Key"];
$objectpos = $headers["X-SecondLife-Local-Position"];
$ownerkey = $headers["X-SecondLife-Owner-Key"];
$ownername = $headers["X-SecondLife-Owner-Name"];
$regiondata = $headers["X-SecondLife-Region"];
$regiontmp = explode ("(",$regiondata); // cut coords off
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1); // cut last space from region name
} else {
$db = $GLOBALS;
$headers = $db['$_ENV'];
$objectgrid = $headers["HTTP_X_SECONDLIFE_SHARD"];
$objectname = $headers["HTTP_X_SECONDLIFE_OBJECT_NAME"];
$objectkey = $headers["HTTP_X_SECONDLIFE_OBJECT_KEY"];
$ownerkey = $headers["HTTP_X_SECONDLIFE_OWNER_KEY"];
$objectpos = $headers["HTTP_X_SECONDLIFE_LOCAL_POSITION"];
$ownername = $headers["HTTP_X_SECONDLIFE_OWNER_NAME"];
$regiondata = $headers["HTTP_X_SECONDLIFE_REGION"];
$regiontmp = explode ("(",$regiondata);
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1);
}
?>
</syntaxhighlight>

Example wrapper script for GoDaddy.com Linux PHP servers (fix made by Thomas Conover):
<syntaxhighlight lang="php">
<?php
// FETCH HEADERS START

if (!function_exists('apache_request_headers'))
{
function apache_request_headers() {
foreach($_SERVER as $key=>$value) {
if (substr($key,0,5)=="HTTP_") {
$key=str_replace(" ","-",ucwords(strtolower(str_replace("_"," ",substr($key,5)))));
$out[$key]=$value;
}else{
$out[$key]=$value;
}
}
return $out;
}
}
// Mind that some headers are not included because they're either useless or unreliable (e.g. X-Secondlife-Local-Position)
$headers = apache_request_headers();
$objectgrid = $headers["X-Secondlife-Shard"];
$objectname = $headers["X-Secondlife-Object-Name"];
$objectkey = $headers["X-Secondlife-Object-Key"];
$objectpos = $headers["X-Secondlife-Local-Position"];
$ownerkey = $headers["X-Secondlife-Owner-Key"];
$ownername = $headers["X-Secondlife-Owner-Name"];
$regiondata = $headers["X-Secondlife-Region"];
$regiontmp = explode ("(",$regiondata); // cut coords off
$regionname = substr($regiontmp[0],0,-1); // cut last space from region name
$regiontmp = explode (")",$regiontmp[1]);
$regionpos = $regiontmp[0];

// FETCH HEADERS END
?>
</syntaxhighlight>

|helpers
|also_header
|also_events={{LSL DefineRow||[[http_response]]}}
|also_functions={{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llHTTPResponse]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_articles={{LSL DefineRow||[[Simulator IP Addresses]]}}
|also_footer
|notes=If for some reason while using the function [[llHTTPRequest]] or the event [[http_response]] you are unable to parse a known good RSS feed or some other form of web contents, you will need to work around it outside of Second Life. This is unlikely to change in the near future since checking the headers requires more overhead at the simulator level.

You may find that some web servers return either a null or a nonsensical result when [[llHTTPRequest]] is used, even though the same URL in a PC web browser returns the expected result. This may be due to the fact that the [[llHTTPRequest]] User Agent string is not recognised by some web servers as it does not contain <code>"Mozilla"</code>, which would identify it as a web browser instead of, for example, a [https://www.shoutcast.com/ Shoutcast] or an RSS client. This is also true when the PHP script relies on [https://www.php.net/manual/en/reserved.variables.cookies.php $_COOKIE]. Neither can the function [[llHTTPRequest]] set a cookie nor can the event [[http_request]] retrieve them.

CGI environments may place the headers into variables by capitalizing the entire name, replacing dashes with underscores, and prefixing the name with <code>HTTP_</code>, e.g. <code>HTTP_X_SECONDLIFE_OBJECT_NAME</code>. PHP <code>$_SERVER</code> variables do this as well, and so does PHP running inside PHP-FPM (as opposed to an Apache module), which is the standard way to configure PHP on non-Apache webservers (such as [https://nginx.org/nginx {{code|nginx}}]).

Apache can include the headers in its logs, using the <code>CustomLog</code> and <code>LogFormat</code> directives. See [https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#formats the docs] for details on the syntax.

|mode
|deprecated
|permission
|cat1=HTTP
|cat2=XML-RPC
|cat3=Communications
|cat4=HTTP/Client
|haiku={{Haiku|Shining break of day|Lov'ly web, carefully spun|Of bytes and prims}}
}}

Lua Alpha

2025-03-13T21:30:34Z

Monty Linden: /* How to Get Started with SLua */

{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.}}

= Second Life Lua (SLua) Alpha =

[[File:Luau.png|720px|thumb|right|Luau logo]]

We're thrilled to announce the launch of the SLua Alpha for Second Life! This significant update introduces the Lua scripting language, offering creators enhanced performance, improved memory efficiency, and a more versatile scripting environment.

== What is SLua? ==

SLua is scripting for Second Life based on Luau, a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.

== Why Lua? ==

The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].

== How to Get Started with SLua ==

In order to play with SLua, you'll need to download our Lua project viewer, and log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid].

* Access the latest build of the SLua-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer/7.1.12.13526902562.html here].

Once you've got the new viewer and have logged onto the beta grid, head over to these SLua-enabled regions:

* [secondlife://Aditi/secondlife/SLua%20Yardang/241/235/27 SLua Yardang]
* [secondlife://Aditi/secondlife/SLua%20Tombolo/241/235/27 SLua Tombolo]
* [secondlife://Aditi/secondlife/SLua%20Mesa/241/235/27 SLua Mesa]
* [secondlife://Aditi/secondlife/SLua%20Tideland/241/235/27 SLua Tideland]

When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).

[[File:Compiler_dropdown.png|Compiler selection dropdown]]

Compiler drop-down options:

* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''Lua''' - Scripts written in Lua, to be run on the SLua VM
* '''LSL/Luau'''- Scripts written in LSL, to be run on the SLua VM

=== Transitioning from LSL to SLua ===
* '''Function Namespacing:'''
** In SLua, Linden Lab functions have been moved under the '''ll''' namespace.
** For example:
*** ''llSay'' becomes ''ll.Say''
*** ''llGetPos'' becomes ''ll.GetPos''
* '''Lists'''
** Lua indexes begin from 1, unlike LSL where indexes begin from 0.
** Lua uses <code>{}</code> for ''tables'', unlike LSL where <code>[]</code> is used for ''lists''.
** When calling LL functions in SLua, lists often have type-strict requirements, unlike Luau in general.
*** For example, <code>ll.SetPrimitiveParams({PRIM_GLOW, 0, 1})</code> will cause a type-error because <code>0</code> is a Luau <code>number</code> type, instead of the LSL <code>integer</code> type expected by [[llSetPrimitiveParams]]. For cases like this, there are special functions which provide the correct data types.
*** Correct: <code>ll.SetPrimitiveParams({PRIM_GLOW, integer(0), 1})</code>
*** Similar functions exist for: '''integer''', '''uuid''' (key), '''vector''', '''quaternion''' (rotation)

=== SLua Libraries ===
* '''Coroutines:'''
** SLua supports coroutines, allowing for cooperative multitasking within scripts.
** Key functions include:
*** ''coroutine.create''
*** ''coroutine.status''
*** ''coroutine.resume''
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
* '''Bitwise Operations:'''
** SLua includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
* '''Standard Library:'''
** SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.

== Feedback and Support ==

We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].

== Example Scripts ==

To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!

=== default_script.lua ===
This script is roughly equivalent to the default "new script" that gets created for LSL.
<source lang="lua">
function state_entry()
ll.Say(0, "Hello, Avatar!")
end

-- Called when the object is touched.
function touch_start(total_number)
ll.Say(0, "Touched.")
end

-- Invoke state_entry on startup, since simulator doesn't invoke
-- it like it does in LSL
state_entry()
</source>

=== dialog.lua ===
This script demonstrates how one can interact with dialog menus.
<source lang="lua">
-- Define the menu buttons and dialog message.
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

local ToucherID = nil
local dialogChannel = nil
local listenHandle = nil

-- This function is called when the script first starts.
function state_entry()
-- Get the object's key and compute a dialog channel number.
local key = ll.GetKey()
-- Extract the last 7 characters of the key and convert it from hex.
dialogChannel = -1 - tonumber(string.sub(tostring(key), -7, -1), 16)
end

-- Called when the object is touched.
function touch_start(num_detected)
ToucherID = ll.DetectedKey(0)
-- If there is already a listen handle, then remove it
if listenHandle then
ll.ListenRemove(listenHandle)
end
listenHandle = ll.Listen(dialogChannel, "", ToucherID, "")
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
-- Set a 60-second timer for response.
ll.SetTimerEvent(60.0)
end

-- Called when a dialog response is received.
function listen(channel, name, sender_id, message)
if message == "-" then
-- Redisplay the dialog if the "-" option is selected.
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
return
end
-- Stop the timer, and stop the listening handler.
ll.ListenRemove(listenHandle)
ll.SetTimerEvent(0)
-- Let the user know what they selected
ll.Say(0, `You selected {message}`)
end

-- Called when the timer expires.
function timer()
-- Stop the timer and clean up the listener.
if listenHandle then
ll.SetTimerEvent(0)
ll.ListenRemove(listenHandle)
ll.Whisper(0, "Sorry. You snooze; you lose.")
end
end

-- Invoke state_entry on startup, since simulator doesn't invoke
-- it like it does in LSL
state_entry()
</source>

=== user_input_coroutine.lua ===
This script demonstrates [https://www.lua.org/pil/9.html coroutines] and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.
<source lang="lua">
-- Wait for user input mid-function before doing something useful with it.
main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")
local event = touch_start -- save function for later
touch_start = nil -- disable touch_start

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield() -- pause the routine's execution here
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
touch_start = event -- restore touch_start
end

function touch_start(total_num)
local toucher = ll.DetectedKey(0)
routine = coroutine.create(main) -- new coroutine
coroutine.resume(routine, toucher) -- run coroutine (with one argument)
end

-- When the coroutine is suspended, incoming events can be handled
-- and we can resume() execution of the routine
-- and pass any number of arguments to be returned by yield()
function listen(channel, name, id, message)
coroutine.resume(routine, message)
end
</source>

=== multi_user_input_coroutine.lua ===
Following from the above example, how can we handle multiple users? This is where coroutines shine.

Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.
<source lang="lua">
-- Key: avatar uuid; Value: coroutine thread
routines = {}

main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield()
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
routines[toucher] = nil -- Remove from collection
end

function touch_start(total_num)
local toucher = ll.DetectedKey(0)
local routine = routines[toucher]
if not routine then -- New user needs new routine
routine = coroutine.create(main)
routines[toucher] = routine -- Add to collection
coroutine.resume(routine, toucher)
end
end

function listen(channel, name, id, message)
coroutine.resume(routines[id], message) -- Resume a specific coroutine
end
</source>

=== More Examples ===

* Find more example scripts at [[Luau Example Scripts]]

* [https://roblox.github.io/lua-style-guide/gotchas/ Lua Gotchas, Footguns and Other Hazards]

EventQueueGet

2025-01-23T07:54:38Z

Monty Linden: Fill out the message list a bit

[[Category:Capabilities]]
The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

After the client closes the connection to the simulator (with a DisableSimulator packet), further attempts to poll the EventQueueGet cap will result in a 404 response. This tells the client to stop polling the cap. On the Debug Console, you'll see a nice message paraphrased: EventPollResponder: {1} https://CAPADDRESS/ stop 404

The client will keep polling the EventQueueGet cap until you give it a 404 even after you've left the region!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===AgentDropGroup===
===AgentGroupDataUpdate===
===AgentPreferencesUpdate===
===AgentStateUpdate===
===ChatterBoxInvitation===
===ChatterBoxSessionEventReply===
===ChatterBoxSessionStartLeaveReply===
===ChatterBoxSessionStartReply===
===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
{
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
}
]
},
message : 'EnableSimulator'
}

===DisplayNameUpdate===
===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
]
},
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===EstablishAgentCommunication===
===ForceCloseChatterBoxSession===
===NavMeshStatusUpdates===
===OpenCircuit===
===ParcelVoiceInfo===
===RequiredVoiceVersion===
===SetDisplayNameReply===
===SimConsoleResponse===
===TeleportFinish===
This tells the client that the serverside processing for teleport is complete and that the client should begin the client side portion of the teleport.
{
body : {
Info : [
{
AgentID : UUID,
LocationID : integer,
RegionHandle : binary,
SeedCapability : string,
SimAccess : integer,
SimIP : binary,
SimPort : integer,
TeleportFlags : binary
}
]
},
message : 'TeleportFinish'
}

You can find additional information on : [http://www.libsecondlife.org/wiki/EventQueueGet a page from libsecondlife.org].

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]

VoiceSignalingRequest

2025-01-15T03:55:20Z

Monty Linden: Initial version

[ Note: Don't trust this yet. Mostly just placeholder content to get it started. ]

'''POST:'''
<pre>
<llsd>
<map>
<key>viewer_session</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>
<key>candidates</key>
...
<key>candidate</key>
...
<key>jsep</key>
<map>
<key>type</key>
...
<key>sdp</key>
...
</map>
<key>parcel_local_id</key>
<string>...</string>
<key>parcel_id</key>
<string>...</string>
</map>
</llsd>
</pre>

On success, the response is an empty LLSD value. On error, you get an HTTP status code and short text description in the body.

'''Response:'''
<pre>
<llsd></llsd>
</pre>

=== History ===

{| class="wikitable"
|-
| 2024 || Introduced for WebRTC support
|}

[[Category:Capabilities]]

Current Sim Capabilities

2025-01-15T03:25:44Z

Monty Linden: Added VoiceSignalingRequest

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[AcceptFriendship Capability|AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentProfile]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[DeclineFriendship Capability|DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]] (Removed)
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]] (Removed)
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[InventoryThumbnailUpload]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[ModifyMaterialParams]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RegionObjects]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]] (Removed)
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateMaterialAgentInventory]]
* [[UpdateMaterialTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadAgentProfileImage]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]
* [[VoiceSignalingRequest]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

SimulatorFeatures

2024-11-21T18:13:45Z

Monty Linden: /* Response */

[[Category:Capabilities]]
==SimulatorFeatures Capability==

===Request===

Basic syntax for getting display name data structures for a given uuid or slid:

GET getCapability("SimulatorFeatures")

===Response===

<?xml version="1.0"?>
<llsd>
<map>
<key>AnimatedObjects</key>
<map>
<key>AnimatedObjectMaxTris</key>
<integer>100000</integer>
<key>MaxAgentAnimatedObjectAttachments</key>
<integer>2</integer>
</map>
<key>AvatarHoverHeightEnabled</key>
<boolean>1</boolean>
<key>BakesOnMeshEnabled</key>
<boolean>1</boolean>
<key>DeadReckoningDistance</key>
<real>20</real>
<key>DeadReckoningTime</key>
<real>1</real>
<key>DynamicPathfindingEnabled</key>
<boolean>0</boolean>
<key>GLTFEnabled</key>
<boolean>0</boolean>
<key>HostName</key>
<string>simhost-01d3500f306966b31.agni.secondlife.io</string>
<key>LSLSyntaxId</key>
<uuid>2d3d4b45-e4c0-d890-a49c-ca4745af1f70</uuid>
<key>MaxAgentAttachments</key>
<integer>38</integer>
<key>MaxAgentGroups</key>
<integer>70</integer>
<key>MaxAgentGroupsBasic</key>
<integer>42</integer>
<key>MaxAgentGroupsPremium</key>
<integer>70</integer>
<key>MaxEstateAccessIds</key>
<integer>750</integer>
<key>MaxEstateManagers</key>
<integer>20</integer>
<key>MaxMaterialsPerTransaction</key>
<integer>50</integer>
<key>MaxTextureResolution</key>
<integer>2048</integer>
<key>MeshRezEnabled</key>
<boolean>1</boolean>
<key>MeshUploadEnabled</key>
<boolean>1</boolean>
<key>MeshXferEnabled</key>
<boolean>1</boolean>
<key>MirrorsEnabled</key>
<boolean>1</boolean>
<key>NoModBypassSupport</key>
<boolean>1</boolean>
<key>PBRMaterialSwatchEnabled</key>
<boolean>1</boolean>
<key>PBRTerrainEnabled</key>
<boolean>1</boolean>
<key>PBRTerrainTransformsEnabled</key>
<boolean>1</boolean>
<key>PhysicsMaterialsEnabled</key>
<boolean>1</boolean>
<key>PhysicsShapeTypes</key>
<map>
<key>convex</key>
<boolean>1</boolean>
<key>none</key>
<boolean>1</boolean>
<key>prim</key>
<boolean>1</boolean>
</map>
<key>RenderMaterialsCapability</key>
<real>4</real>
</map>
</llsd>

SimulatorFeatures

2024-11-21T18:11:48Z

Monty Linden: Initial version - example from a 2024 BBQ simulator

GroupMemberData

2024-10-26T21:53:22Z

Monty Linden: Service fixed

'''POST:'''
<pre>
<llsd>
<map>
<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>
</map>
</llsd>
</pre>

The response is a map containing the requesting agent's ID, the group ID, the member count, a map of member data, a map of group defaults, and an array of group titles.

'''Response:'''
<pre>
<llsd>
<map>
<key>agent_id</key>
<uuid>00112233-4455-6677-8899-aabbccddeeff</uuid>

<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>

<key>member_count</key>
<integer>10</integer>

<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<integer>4</integer>

<key>last_login</key>
<string>2012/20/03</string>

<key>powers</key>
<string>FFFFFFFF</string>

<key>title</key>
<integer>1</integer>

<key>owner</key>
<bool>True</bool>
</map>
</map>

<map> 
<key>default_powers</key>
<string>01c00000</string>
</map>

<array> 
<string>Group Default Title</string>
<string>Group Title 1</string>
<string>Group Title 2</string>
<string>Group Owner Title</string>
<string>Group Title 3</string>
</array>

</map>
</llsd>
</pre>
'''Note:''' the ''powers'' value is a string and must be converted to a U64.

To reduce the amount of data being transferred, default member information is omitted from the member list. This may result in a member information block with an empty map.
<pre>
<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<key>last_login</key>
<key>powers</key>
<key>title</key>
<key>owner</key>
</map>
</map>
</pre>

If any of the above keys do not exist, use the following default values:
* '''donated_square_meters''': 0
* '''last_login''': "unknown"
* '''powers''': ''default_powers'' from the ''defaults'' map
* '''title''': the first element from the ''titles'' array
* '''owner''': ''false''

=== History ===

{| class="wikitable"
|-
| 2024 || Fixed. Note that large groups can return an enormous amount of data.
|-
| 2017 || Broken. May return data for other group. Callers should verify 'group_id' in response matches that in request and re-issue if different. SL-16849.
|-
| ~2012 || Introduced
|}

[[Category:Capabilities]]

LlHTTPRequest

2024-06-28T14:31:19Z

Monty Linden: Update the throttling details. Still not what it should be but the basics are now correct.

{{LSL_Function
|func=llHTTPRequest
|func_id=230
|func_energy=10.0
|func_sleep=0.0
|func_desc=Sends an HTTP request to the specified URL with the body of the request and parameters. When the response is received, a [[http_response]] event is raised.
|sort=HTTPRequest
|func_footnote=
|return_type=key|return_subtype=handle
|return_text=identifying the HTTP request made.
|p1_type=string|p1_name=url|p1_desc=A valid HTTP/HTTPS URL.
|p2_type=list|p2_subtype=instructions|p2_name=parameters|p2_desc=configuration parameters, specified as HTTP_* flag-value pairs
[ parameter1, value1, parameter2, value2, . . . parameterN, valueN]
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|constants={{LSL_Constants_HTTP}}
{{LSL_Constants/HTTP_Headers}}
{{LSL_Extended_Error_HTTP}}
|spec=
|caveats=
*Spaces, control characters, and other characters that are not allowed in URLs will cause a run time error.
*The corresponding [[http_response]] event will be triggered in all scripts in the [[prim]], not just in the requesting script.
*Requests must fully complete after 60 seconds, or else the response will be thrown away and the [[http_response]] status code will be 499.
*The response body is limited to 2048 bytes by default, see [[HTTP_BODY_MAXLENGTH]] above to increase it. If the response is longer, it will be truncated.
*The request body size (e.g., of POST and PUT requests) is limited only by available script memory. Scripts can hold at most 32k characters in a string, under [[Mono]], as characters are two bytes each, so, scripts cannot upload over 32k UTF-8 characters
*Cannot be used to load textures or images from the internet, for more information see [[Web Textures]].
*If the accessed site is relying on the LSL script to report [[L$]] transactions, then it '''must''' check the <code>X-SecondLife-Shard</code> header to see if the script is running on the beta grid.
* Some servers will return a <code>405</code> error if you send POST to a file that can't accept metadata, such as a text or HTML file. Make sure you use the GET method to ensure success in any environment.
* While the HTTP status code from the server is provided to the script, redirect codes such as <code>302</code> will result in the redirect being automatically and transparently followed ONLY IF the [[HTTP_METHOD]] is GET, with the resulting response being returned. If the [[HTTP_METHOD]] is anything other than GET then you'll get back an [[http_response]] with a status code of <code>302</code>, but without any way to view the headers, you can't know where you were being redirected to unless that was also included in the body.
* The following applies when making a request to a script using HTTP-In:
**When appending a query string to a cap URL there '''MUST''' be a trailing slash between the cap guid and the query string token <code>"?"</code>. For example: [https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322?arg=gra {{HoverTextStyle|style=color:green;|<nowiki>https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322</nowiki>|2={{String|x-script-url}} = {{String|https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322}}}}?{{HoverTextStyle|style=color:red;|1=arg=gra|2={{String|x-query-string}} = {{String|1=arg=gra}}}}] will return a 500 HTTP status {{Wikipedia|List_of_HTTP_status_codes#5xx_Server_Error|Server Error code}}, but [https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322/?arg=gra {{HoverTextStyle|style=color:green;|<nowiki>https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322</nowiki>|2={{String|x-script-url}} = {{String|https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322}}}}{{HoverTextStyle|style=color:blue;|/|2={{String|x-path-info}} = {{String|/}}}}?{{HoverTextStyle|style=color:red;|1=arg=gra|2={{String|x-query-string}} = {{String|1=arg=gra}}}}] will succeed.
* <code>X-SecondLife-Owner-Name</code> may return <code>"(Loading...)"</code> instead of owner name (still true, 30th of March, 2022)
* Requests made at approx 0625 SLT may fail with a <code>503</code> status code, with <code>"ERROR: The requested URL could not be retrieved"</code>, and <code>"(111) Connection refused"</code> in the body of the response. This has been confirmed as expected behavior by Kelly, due to the nightly maintenance and log rotation. It does reliably impact object to object HTTP at that time, and quite probably may impact object to/from web around the same time. The interruption in service is fairly brief, and the precise timing may vary as LL adjust their nightly maintenance processes, or due to server load.
* Use <code>HTTP_MIMETYPE</code> to set the <code>Content-Type</code> header. Attempts to use <code>HTTP_CUSTOM_HEADER</code> to set it will cause a runtime script error.
* If the origin server does not include a content-type header in its response, LSL will attempt to treat the incoming data as "text/plain; charset=utf-8". This behavior diverges from [https://datatracker.ietf.org/doc/html/rfc2616#section-7.2.1 RFC 2616].

==== Throttles ====

The LSL function [[llHTTPRequest]] is throttled in three ways: by object, by owner, and by http error. All group-owned objects are considered together in the same throttle.

The current limits are:
* 25 requests in 20 seconds for each object
* 1000 requests in 20 seconds for each owner with higher limits for some regions
* Five HTTP errors (500 or higher) in 60 seconds for each script
These may change in the future if needed to prevent problems in regions.

It is possible for a large collection of objects or scripts to make many calls to [[llHTTPRequest]] and reach one or more throttles. When a script calls [[llHTTPRequest]] with a throttle blocking the request, it will return [[NULL_KEY]].

The calling script must check for the [[NULL_KEY]] result and react properly for the script and object to function correctly. Some things to consider:

* Pause further requests until the throttle clears
* Do not make any additional [[llHTTPRequest]] calls until enough time has passed for the throttle to reset. They will fail and continue to return [[NULL_KEY]] otherwise.
* Once reached, the throttles will remain in effect as long as requests continue, but will clear if there is a silent period with no requests at least twice the throttle interval, in the common case 2 * 20 or 40 seconds.‎

:Consider how a group of objects behaves. Developers must consider how multiple objects will interact and how that will affect clearing the throttle.‎

:The [[llHTTPRequest]] throttle is most likely to be an issue with a large number of objects in a region making requests. To clear the throttle fastest, when an object encounters the throttle, it should broadcast a region-wide chat message to other objects informing them of the event and stopping their requests. If those objects continue making requests, those requests will fail and just prolong recovery.‎

:If an object waits and still gets a failure, it may be a good idea to increase the time before the next request and/or add a small random value to the wait time. This may help prevent failures caused by large groups of objects acting nearly in unison.

* Object requests are throttled at approximately 25 requests per 20 seconds. This is to support a sustained rate of one per second or a maximum burst of up to 25 every 40 seconds (twice the interval for maximum burst), smaller bursts are recommended.
* [[NULL_KEY]] is returned if the request is throttled.
* See [http://forums-archive.secondlife.com/139/72/108960/1.html this thread] and [http://forums-archive.secondlife.com/139/2c/109571/1.html this thread] for older details.
----
|examples=

*[[Writing Headers and HTTP POST Body to a File]]

<syntaxhighlight lang="lsl2">
key http_request_id;

default
{
state_entry()
{
http_request_id = llHTTPRequest("url", [], "");
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id != http_request_id) return;// exit if unknown

vector COLOR_BLUE = <0.0, 0.0, 1.0>;
float OPAQUE = 1.0;

llSetText(body, COLOR_BLUE, OPAQUE);
}
}
</syntaxhighlight>

Example PHP test script:
<syntaxhighlight lang="php">
<?php header("content-type: text/plain; charset=utf-8"); ?>
Headers received:
<?php

/**
* @author Wouter Hobble
* @copyright 2008
*/

foreach ($_SERVER as $k => $v)
{
if( substr($k, 0, 5) == 'HTTP_')
{
print "\n". $k. "\t". $v;
}
}
?>
</syntaxhighlight>

Example PHP wrapper script both capturing Apache headers and global methods
<syntaxhighlight lang="php">
<?php
// Author Waster Skronski.
// General Public License (GPL).
// Mind that some headers are not included because they're either useless or unreliable.

$USE_APACHE_HEADERS = TRUE;// switch to false if you need CGI methods

if ($USE_APACHE_HEADERS)
{
$headers = apache_request_headers();
$objectgrid = $headers["X-SecondLife-Shard"];
$objectname = $headers["X-SecondLife-Object-Name"];
$objectkey = $headers["X-SecondLife-Object-Key"];
$objectpos = $headers["X-SecondLife-Local-Position"];
$ownerkey = $headers["X-SecondLife-Owner-Key"];
$ownername = $headers["X-SecondLife-Owner-Name"];
$regiondata = $headers["X-SecondLife-Region"];
$regiontmp = explode ("(",$regiondata); // cut coords off
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1); // cut last space from region name
} else {
$db = $GLOBALS;
$headers = $db['$_ENV'];
$objectgrid = $headers["HTTP_X_SECONDLIFE_SHARD"];
$objectname = $headers["HTTP_X_SECONDLIFE_OBJECT_NAME"];
$objectkey = $headers["HTTP_X_SECONDLIFE_OBJECT_KEY"];
$ownerkey = $headers["HTTP_X_SECONDLIFE_OWNER_KEY"];
$objectpos = $headers["HTTP_X_SECONDLIFE_LOCAL_POSITION"];
$ownername = $headers["HTTP_X_SECONDLIFE_OWNER_NAME"];
$regiondata = $headers["HTTP_X_SECONDLIFE_REGION"];
$regiontmp = explode ("(",$regiondata);
$regionpos = explode (")",$regiontmp[1]);
$regionname = substr($regiontmp[0],0,-1);
}
?>
</syntaxhighlight>

Example wrapper script for GoDaddy.com Linux PHP servers (fix made by Thomas Conover):
<syntaxhighlight lang="php">
<?php
// FETCH HEADERS START

if (!function_exists('apache_request_headers'))
{
function apache_request_headers() {
foreach($_SERVER as $key=>$value) {
if (substr($key,0,5)=="HTTP_") {
$key=str_replace(" ","-",ucwords(strtolower(str_replace("_"," ",substr($key,5)))));
$out[$key]=$value;
}else{
$out[$key]=$value;
}
}
return $out;
}
}
// Mind that some headers are not included because they're either useless or unreliable (e.g. X-Secondlife-Local-Position)
$headers = apache_request_headers();
$objectgrid = $headers["X-Secondlife-Shard"];
$objectname = $headers["X-Secondlife-Object-Name"];
$objectkey = $headers["X-Secondlife-Object-Key"];
$objectpos = $headers["X-Secondlife-Local-Position"];
$ownerkey = $headers["X-Secondlife-Owner-Key"];
$ownername = $headers["X-Secondlife-Owner-Name"];
$regiondata = $headers["X-Secondlife-Region"];
$regiontmp = explode ("(",$regiondata); // cut coords off
$regionname = substr($regiontmp[0],0,-1); // cut last space from region name
$regiontmp = explode (")",$regiontmp[1]);
$regionpos = $regiontmp[0];

// FETCH HEADERS END
?>
</syntaxhighlight>

|helpers
|also_header
|also_events={{LSL DefineRow||[[http_response]]}}
|also_functions={{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llHTTPResponse]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_articles={{LSL DefineRow||[[Simulator IP Addresses]]}}
|also_footer
|notes=If for some reason while using the function [[llHTTPRequest]] or the event [[http_response]] you are unable to parse a known good RSS feed or some other form of web contents, you will need to work around it outside of Second Life. This is unlikely to change in the near future since checking the headers requires more overhead at the simulator level.

You may find that some web servers return either a null or a nonsensical result when [[llHTTPRequest]] is used, even though the same URL in a PC web browser returns the expected result. This may be due to the fact that the [[llHTTPRequest]] User Agent string is not recognised by some web servers as it does not contain <code>"Mozilla"</code>, which would identify it as a web browser instead of, for example, a [https://www.shoutcast.com/ Shoutcast] or an RSS client. This is also true when the PHP script relies on [https://www.php.net/manual/en/reserved.variables.cookies.php $_COOKIE]. Neither can the function [[llHTTPRequest]] set a cookie nor can the event [[http_request]] retrieve them.

CGI environments may place the headers into variables by capitalizing the entire name, replacing dashes with underscores, and prefixing the name with <code>HTTP_</code>, e.g. <code>HTTP_X_SECONDLIFE_OBJECT_NAME</code>. PHP <code>$_SERVER</code> variables do this as well, and so does PHP running inside PHP-FPM (as opposed to an Apache module), which is the standard way to configure PHP on non-Apache webservers (such as [https://nginx.org/nginx {{code|nginx}}]).

Apache can include the headers in its logs, using the <code>CustomLog</code> and <code>LogFormat</code> directives. See [https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#formats the docs] for details on the syntax.

|mode
|deprecated
|permission
|cat1=HTTP
|cat2=XML-RPC
|cat3=Communications
|cat4=HTTP/Client
|haiku={{Haiku|Shining break of day|Lov'ly web, carefully spun|Of bytes and prims}}
}}

InventoryThumbnailUpload

2024-05-05T17:45:35Z

Monty Linden: Created page with "Category:Capabilities The InventoryThumbnailUpload Capability performs a function... === History === {| class="wikitable" |- | 2023 || Introduced |}"

[[Category:Capabilities]]
The InventoryThumbnailUpload Capability performs a function...

=== History ===

{| class="wikitable"
|-
| 2023 || Introduced
|}

ModifyMaterialParams

2024-05-05T17:45:05Z

Monty Linden: Created page with "Category:Capabilities The ModifyMaterialParams Capability performs a function... === History === {| class="wikitable" |- | 2023 || Introduced |}"

[[Category:Capabilities]]
The ModifyMaterialParams Capability performs a function...

=== History ===

{| class="wikitable"
|-
| 2023 || Introduced
|}

UpdateMaterialTaskInventory

2024-05-05T17:43:57Z

Monty Linden: Created page with "Category:Capabilities The UpdateMaterialTaskInventory Capability performs a function... === History === {| class="wikitable" |- | 2023 || Introduced |}"

[[Category:Capabilities]]
The UpdateMaterialTaskInventory Capability performs a function...

=== History ===

{| class="wikitable"
|-
| 2023 || Introduced
|}

UpdateMaterialAgentInventory

2024-05-05T17:43:30Z

Monty Linden: Created page with "Category:Capabilities The UpdateMaterialAgentInventory Capability performs a function... === History === {| class="wikitable" |- | 2023 || Introduced |}"

[[Category:Capabilities]]
The UpdateMaterialAgentInventory Capability performs a function...

=== History ===

{| class="wikitable"
|-
| 2023 || Introduced
|}

Current Sim Capabilities

2024-05-05T17:39:32Z

Monty Linden: Add some missing materials caps

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[AcceptFriendship Capability|AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentProfile]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[DeclineFriendship Capability|DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]] (Removed)
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]] (Removed)
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[InventoryThumbnailUpload]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[ModifyMaterialParams]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RegionObjects]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]] (Removed)
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateMaterialAgentInventory]]
* [[UpdateMaterialTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadAgentProfileImage]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

Simulator Main Loop

2024-03-12T18:17:30Z

Monty Linden:

{{OSWikiLearnBox}}

Common to time simulations, the Linden simulators have a main loop where time deltas occur and state changes and housekeeping tasks are organized. Most of this is simply hidden from view and is experienced as either "laggy today" or "not too laggy today." Some phases of the loop are reported back to the Viewer and displayed on the Statistics floater and are the subject of much interest and debate. So here is a high-level breakdown of the loop and a description that relates simulation back to the Statistics floater.

[[File:Simulator Main Loop Breakdown.png|800px|||Main Loop Breakdown]]

== Columns ==
=== App State ===
The Simulator, like the Viewer, defines numerous application states which serve as an internal marker of progress of context while executing. Labels are mostly self-describing and occur once but there are exceptions. The 'SVC_PUMP_*' and 'SVC_CB_*' labels mark repetitions of the same I/O logic at four different points in a single pass through the loop.

=== Operations ===
Each state is broken down, where possible, into discrete steps tagged with function and method names, some real, some imaginary.

=== Bounds ===
A simulation frame does not execute every possible step on every frame. Bounding of execution load is performed in several ways to avoid unnecessary computation and improve overall framerate behavior. These bounds take several forms.

Frequency bound. This indicates how often the step is invoked. As indicated by the key, there are roughly four schemes in play:
* Every frame (green). The most common case, the step is invoked on every frame.
* Skipped frames (yellow). Invoked on every Nth frame of simulation.
* Scheduled on the clock (pink). Invoked after a time interval has passed.
* Selectively run based on random logic (red). Complex or opaque skipping logic is applied.

Time bound. Once started, a simulation step does not always run to completion. Early exit from the step may be performed to get on with the frame or as a result of not-yet-arrived data. Breakdown:
* Run to completion (green).
* Run to a clock target (yellow). Usually something more complicated than a simple deadline but the idea is to limit damage to the frametime.
* Run to complex time target (pink). Rococo schemes for early termination.
* Run to simple clock target (red). Basic deadline stop.

Other bounds. Other system state can lead to early termination of a step. This can literally be anything but we have a few 'common' cases:
* No other bound (green).
* Run until HTTP request throttles invokes (yellow). Back off the HTTP when using it too hard.
* Run until agent limits hit (pink). Simulation step has a related agent limit controlling execution.
* Run until random logic fires (red). Some complex case allowing early termination of step.

=== Viewer Statistics ===
The remaining column involves the reporting of loop statistics to interested viewers. Metrics collection in the simulator is mostly used for internal processes and is kept there. But the SimStats message, used to populate the Statistics floater, communicates some of these back to the Viewer. These are indicated by green bars in the four reporting columns which are also tagged with the text from the Statistics floater.

There are gaps in the simulation frame that aren't reported to the Viewer. These are indicated in yellow and are simply gathered internally. There are also some additional metrics being reported to the Viewer that aren't on the Statistics floater. (Something to be documented in the future.)

Finally, the 'Physics Step' and 'Physics Other' spans aren't precisely as indicated. They're collected somewhat independently as part of Havok simulation but this will do for representational purposes.

Server architecture

2024-03-12T15:30:38Z

Monty Linden:

{{OSWikiLearnBox}}

This wiki is mainly focused on the viewer, since that is the portion of the system that is open source. However, because the viewer interacts with the Second Life servers in somewhat complicated ways, it is helpful to have an understanding of what components do what on the server side.

Much of what you'll need to understand is actually covered in the [[protocol|protocol documentation]]. In particular, take a look at [[Authentication Flow]], which outlines the process by which the viewer establishes connections with a number of components.

''(obsolete)'' if you want to see what the architecture may look like in the future, or if you would like to help shape it, visit the [[Architecture Working Group]].

== Components ==
=== Login server ===
CGI script running on login.agni.lindenlab.com. Handles verification of user name and password. Determines the login region based on home vs. last location vs. URL specified location. Finds the simulator process running that region and verifies user is allowed to connect there. Alerts the simulator to expect a connection. Informs the viewer of where to connect.

=== Spaceserver ===
Handles routing of messages based on grid x,y locations. Simulator talks to Space Server to *register* and also find who the neighbors are.

=== Dataserver ===
Handles connections to the central database, log database, inventory database(s) and search database(s). Performs queries on behalf of the simulator process.

=== Simulator ===
The primary SL server process. Each simulator process simulates one 256x256 meter region. There are about 31,000 regions in total currently. Each one has to be hosted on a server running copies of the Simulator program. There is one simulator per region, 4 or more sims per server, 8000 or so servers. As the viewer moves through the world it is handled off from one simulator to another. It handles storing object state, land parcel state, and terrain height-map state. It performs visibility calculations on objects and land and transmits the data to the client. It transmits image data in a prioritized queue. Physics simulation is handled with the Havok physics library. Chat and instant messages are processed here.

Running at full tilt, a simulator will run at 45 frames/sec. If it can't keep up, it will attempt time dialation without reducing frame rate. More details on work performed during a frame are in [[Simulator Main Loop]].

Simulators communicate with one another using a [[circuit]] via UDP. A "circuit" is a UDP network connection. Circuits are maintained between adjacent simulators.

==== Simulator vs. Viewer ====

It helps to understand the division of labor between the simulator and the viewer, since the split in Second Life is very different than most other virtual environments:

* Simulator's job:
** Runs physics engine
** Collision detection
** keeps track of where everything is
** Sends locations of stuff to viewer
** Sends updates to viewers only when needed (only when collision occurs or other changes in direction, velocity etc.)
* Viewer's job:
** Handle locations of objects
** Gets velocities and other physics information, and does simple physics to keep track of what is moving where
** No collision detection

=== Other servers ===

* Central Backbone
* Agent Database
** Agent DB keeps track of metadata<->item id (UUID) mapping
* Central DB (CDB)
** a list of who owns what, used for billing, etc
* Find DB (replica of Central DB used for search)
* Map server - renders overall map with OpenGL
* RPC server
** API for developers to manupulate Second Life without using the viewer
** Translates XMLRPC server into in-world requests
** Communicates with space server and CDB
* Region Conductor
** Looks for regions that should be running, but are down
** Start those regions on a sim host that has room for it
** Grid Restart Modes
*** Startup Mode: Regions are stuck on the current sim host
*** Normal Mode: Regions are sent to a random sim host

Simulator Main Loop

2024-03-12T15:27:26Z

Monty Linden: Add lucidchart diagram

{{OSWikiLearnBox}}

Common to time simulations, the Linden simulators have a main loop where time deltas occur and state changes and housekeeping tasks are organized. Most of this is simply hidden from view and is experienced as either "laggy" or "not too laggy today." Some phases of the loop are reported back to the Viewer and displayed on the Statistics floater and are the subject of much interest and debate. So here is a high-level breakdown of the loop and a description that relates simulation back to the Statistics floater.

[[File:Simulator Main Loop Breakdown.png|800px|||Main Loop Breakdown]]

== Columns ==
=== App State ===
The Simulator, like the Viewer, defines numerous application states which serve as an internal marker of progress of context while executing. Labels are mostly self-describing and occur once but there are exceptions. The 'SVC_PUMP_*' and 'SVC_CB_*' labels mark repetitions of the same I/O logic at four different points in a single pass through the loop.

=== Operations ===
Each state is broken down, where possible, into discrete steps tagged with function and method names, some real, some imaginary.

=== Bounds ===
A simulation frame does not execute every possible step on every frame. Bounding of execution load is performed in several ways to avoid unnecessary computation and improve overall framerate behavior. These bounds take several forms.

Frequency bound. This indicates how often the step is invoked. As indicated by the key, there are roughly four schemes in play:
* Every frame (green). The most common case, the step is invoked on every frame.
* Skipped frames (yellow). Invoked on every Nth frame of simulation.
* Scheduled on the clock (pink). Invoked after a time interval has passed.
* Selectively run based on random logic (red). Complex or opaque skipping logic is applied.

Time bound. Once started, a simulation step does not always run to completion. Early exit from the step may be performed to get on with the frame or as a result of not-yet-arrived data. Breakdown:
* Run to completion (green).
* Run to a clock target (yellow). Usually something more complicated than a simple deadline but the idea is to limit damage to the frametime.
* Run to complex time target (pink). Rococo schemes for early termination.
* Run to simple clock target (red). Basic deadline stop.

Other bounds. Other system state can lead to early termination of a step. This can literally be anything but we have a few 'common' cases:
* No other bound (green).
* Run until HTTP request throttles invokes (yellow). Back off the HTTP when using it too hard.
* Run until agent limits hit (pink). Simulation step has a related agent limit controlling execution.
* Run until random logic fires (red). Some complex case allowing early termination of step.

=== Viewer Statistics ===
The remaining column involves the reporting of loop statistics to interested viewers. Metrics collection in the simulator is mostly used for internal processes and is kept there. But the SimStats message, used to populate the Statistics floater, communicates some of these back to the Viewer. These are indicated by green bars in the four reporting columns which are also tagged with the text from the Statistics floater.

There are gaps in the simulation frame that aren't reported to the Viewer. These are indicated in yellow and are simply gathered internally. There are also some additional metrics being reported to the Viewer that aren't on the Statistics floater. (Something to be documented in the future.)

Finally, the 'Physics Step' and 'Physics Other' spans aren't precisely as indicated. They're collected somewhat independently as part of Havok simulation but this will do for representational purposes.

File:Simulator Main Loop Breakdown.svg

2024-03-12T15:22:39Z

Monty Linden: Source material for this is in Lucidchart.

== Summary ==
Source material for this is in Lucidchart.

File:Simulator Main Loop Breakdown.png

2024-03-12T15:21:18Z

Monty Linden:

Simulator Main Loop

2024-03-12T15:18:57Z

Monty Linden: Create 'Simulator Main Loop' page

{{OSWikiLearnBox}}

Common to time simulations, the Linden simulators have a main loop where time deltas occur and state changes and housekeeping tasks are organized. Most of this is simply hidden from view and is experienced as either "laggy" or "not too laggy today." Some phases of the loop are reported back to the Viewer and displayed on the Statistics floater and are the subject of much interest and debate. So here is a high-level breakdown of the loop and a description that relates simulation back to the Statistics floater.

== Columns ==
=== App State ===
The Simulator, like the Viewer, defines numerous application states which serve as an internal marker of progress of context while executing. Labels are mostly self-describing and occur once but there are exceptions. The 'SVC_PUMP_*' and 'SVC_CB_*' labels mark repetitions of the same I/O logic at four different points in a single pass through the loop.

=== Operations ===
Each state is broken down, where possible, into discrete steps tagged with function and method names, some real, some imaginary.

=== Bounds ===
A simulation frame does not execute every possible step on every frame. Bounding of execution load is performed in several ways to avoid unnecessary computation and improve overall framerate behavior. These bounds take several forms.

Frequency bound. This indicates how often the step is invoked. As indicated by the key, there are roughly four schemes in play:
* Every frame (green). The most common case, the step is invoked on every frame.
* Skipped frames (yellow). Invoked on every Nth frame of simulation.
* Scheduled on the clock (pink). Invoked after a time interval has passed.
* Selectively run based on random logic (red). Complex or opaque skipping logic is applied.

Time bound. Once started, a simulation step does not always run to completion. Early exit from the step may be performed to get on with the frame or as a result of not-yet-arrived data. Breakdown:
* Run to completion (green).
* Run to a clock target (yellow). Usually something more complicated than a simple deadline but the idea is to limit damage to the frametime.
* Run to complex time target (pink). Rococo schemes for early termination.
* Run to simple clock target (red). Basic deadline stop.

Other bounds. Other system state can lead to early termination of a step. This can literally be anything but we have a few 'common' cases:
* No other bound (green).
* Run until HTTP request throttles invokes (yellow). Back off the HTTP when using it too hard.
* Run until agent limits hit (pink). Simulation step has a related agent limit controlling execution.
* Run until random logic fires (red). Some complex case allowing early termination of step.

=== Viewer Statistics ===
The remaining column involves the reporting of loop statistics to interested viewers. Metrics collection in the simulator is mostly used for internal processes and is kept there. But the SimStats message, used to populate the Statistics floater, communicates some of these back to the Viewer. These are indicated by green bars in the four reporting columns which are also tagged with the text from the Statistics floater.

There are gaps in the simulation frame that aren't reported to the Viewer. These are indicated in yellow and are simply gathered internally. There are also some additional metrics being reported to the Viewer that aren't on the Statistics floater. (Something to be documented in the future.)

Finally, the 'Physics Step' and 'Physics Other' spans aren't precisely as indicated. They're collected somewhat independently as part of Havok simulation but this will do for representational purposes.

Texture Console

2022-09-22T17:50:31Z

Monty Linden: Delete 3.4.3 and earlier console descriptions.

TPVD/Developers Group Agenda

2022-05-06T15:22:30Z

Monty Linden:

Schedule: '''See [https://second.life/calendar SL Public Calendar]'''
{{RightToc}}

== Viewer Pipeline ==

See repository links on [https://releasenotes.secondlife.com/repositories.html Viewer Source Repositories] and downloads on [https://releasenotes.secondlife.com/viewer.html Alternate Viewers]

* Maint L has been promoted
* Merges in progress
* In RC:
** Performance Improvements Viewer
** MFA Viewer

==Ongoing and Upcoming==

* {{JiraIssue|DRTSIM-537|Restoring offline friendship and group membership offers}}
** Aditi regions available for testing include: "Animesh1", "Animesh Adult", and "PerfTest 2".

== New Topics: ==

:''Attendees should add agenda items here as needed - see comments when you edit the page''

* Viewer builds now use python 3 and autobuild 3



== Meeting Notes ==
https://modemworld.me/tag/tpv-developer-meetings/

[[Category:Third Party Viewers]]

TPVD/Developers Group Agenda

2022-04-22T13:31:40Z

Monty Linden:

Next meeting: '''1:00 PM SLT, March 18 [http://maps.secondlife.com/secondlife/Hippotropolis/242/6/25 Hippo Theater]'''
{{RightToc}}

== Viewer Pipeline ==

See repository links on [https://releasenotes.secondlife.com/repositories.html Viewer Source Repositories] and downloads on [https://releasenotes.secondlife.com/viewer.html Alternate Viewers]

* Maint JK has been promoted
* Merges in progress
* Performance Improvements viewer coming to RC soon

==Ongoing and Upcoming==

== New Topics: ==

:''Attendees should add agenda items here as needed - see comments when you edit the page''

* DRTSIM-537. Restoring offline friendship and group membership offers.
** New (temporary?) implementations of the ReadOfflineMsgs, AcceptFriendship, DeclineFriendship, AcceptGroupInvite, and DeclineGroupInvite Capabilities.
** Revival of the [[Current_Sim_Capabilities]] page with a few updates.
* Viewer builds now use python 3 and autobuild 3
* Possible time change for TPV meetings?



== Meeting Notes ==
https://modemworld.me/tag/tpv-developer-meetings/

[[Category:Third Party Viewers]]

ReadOfflineMsgs

2022-04-01T16:46:26Z

Monty Linden: Still documenting the past.

[[Category:Capabilities]]
The ReadOfflineMsgs Capability performs a function similar to the RetrieveInstantMessages LLMessage.
It retrieves offline Instant Messages and returns them to the caller. Those IMs are returned directly
in the response body rather than in individual messages. As a side-effect of the retrieval, certain
offers, such as friendship, may become active and available to the caller.

Client Request GET ->
<empty>

; 200 Response <-
[
[
{
asset_id: UUID,
binary_bucket: Binary,
dialog: Integer,
estate_id: Integer,
from_agent_id: UUID,
from_agent_name: String,
from_group: Boolean,
message: String,
message_time: String,
offline: Integer,
parent_estate_id: Integer,
position: [ Real, Real, Real ],
region_id: UUID,
timestamp: Integer,
to_agent_id: UUID,
transaction-id: UUID
},
{
},
...
{
}
]
]

An early form of the service had a response structure of:

{
messages: [
{
<IM_0>
},
{
<IM_1>
},
...
{
<IM_n>
}
]
}

but that should not be encountered anymore.

Side Effects. The GET operation currently deletes all of an agent's stored IMs and subsequent calls will return empty arrays until new IMs are stored.

=== History ===

{| class="wikitable"
|-
| ~2018 || Introduced
|}

DeclineFriendship Capability

2022-04-01T16:10:07Z

Monty Linden:

[[Category:Capabilities]]
The DeclineFriendship Capability performs a function similar to the [[DeclineFriendship]] LLMessage. It allows the
recipient of a friendship offer, restored from the retrieval of an instant message, to be actively declined. This
interface comes with usage contraints not present in the LLMessage interface:

* The friendship offer must have been retrieved from offline/stored instant messages. Offers from online agents cannot be declined with this interface.
* The friendship offer must have been retrieved using the ReadOfflineMsgs Capability. Offers that arise from events in response to a RetrieveInstantMessages LLMessage will likely be ignored if declined using this capability.

One query term is required when invoking the cap:
* 'from' must provide the UUID of the agent offering friendship

Client Request DEL <path>?from=<uuid> ->
<empty>

; 200 Response <-
{
success: Boolean
}

; 4xx/5xx codes as well

=== History ===

{| class="wikitable"
|-
| ~2018 || Introduced
|}

AcceptFriendship Capability

2022-04-01T16:09:46Z

Monty Linden:

[[Category:Capabilities]]
The AcceptFriendship Capability performs a function similar to the [[AcceptFriendship]] LLMessage. It allows the
recipient of a friendship offer, restored from the retrieval of an instant message, to be accepted. This
interface comes with usage contraints not present in the LLMessage interface:

* The friendship offer must have been retrieve from offline/stored instant messages. Offers from online agents cannot be accepted with this interface.
* The friendship offer must have been retrieved using the ReadOfflineMsgs Capability. Offers that arise from events in response to a RetrieveInstantMessages LLMessage will likely be ignored if accepted using this capability.

Two query terms are required when invoking the cap:
* 'from' must provide the UUID of the agent offering friendship
* 'agent_name' is the 'full name' of the recipient

Client Request POST <path>?from=<uuid>&agent_name=<string> ->
<empty>

; 200 Response <-
{
success: Boolean
}

; 4xx/5xx codes as well

=== History ===

{| class="wikitable"
|-
| ~2018 || Introduced
|}

ReadOfflineMsgs

2022-04-01T16:09:17Z

Monty Linden:

[[Category:Capabilities]]
The ReadOfflineMsgs Capability performs a function similar to the RetrieveInstantMessages LLMessage.
It retrieves offline Instant Messages and returns them to the caller. Those IMs are returned directly
in the response body rather than in individual messages. As a side-effect of the retrieval, certain
offers, such as friendship, may become active and available to the caller.

Client Request GET ->
<empty>

; 200 Response <-
[
[
{
asset_id: UUID,
binary_bucket: Binary,
dialog: Integer,
estate_id: Integer,
from_agent_id: UUID,
from_agent_name: String,
from_group: Boolean,
message: String,
message_time: String,
offline: Integer,
parent_estate_id: Integer,
position: [ Real, Real, Real ],
region_id: UUID,
timestamp: Integer,
to_agent_id: UUID,
transaction-id: UUID
},
{
},
...
{
}
]
]

An early form of the service had a response structure of:

{
messages: [
{
<IM_0>
},
{
<IM_1>
},
...
{
<IM_n>
}
]
}

but that should not be encountered anymore.

=== History ===

{| class="wikitable"
|-
| ~2018 || Introduced
|}

GroupMemberData

2022-04-01T16:07:54Z

Monty Linden:

'''POST:'''
<pre>
<llsd>
<map>
<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>
</map>
</llsd>
</pre>

The response is a map containing the requesting agent's ID, the group ID, the member count, a map of member data, a map of group defaults, and an array of group titles.

'''Response:'''
<pre>
<llsd>
<map>
<key>agent_id</key>
<uuid>00112233-4455-6677-8899-aabbccddeeff</uuid>

<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>

<key>member_count</key>
<integer>10</integer>

<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<integer>4</integer>

<key>last_login</key>
<string>2012/20/03</string>

<key>powers</key>
<string>FFFFFFFF</string>

<key>title</key>
<integer>1</integer>

<key>owner</key>
<bool>True</bool>
</map>
</map>

<map> 
<key>default_powers</key>
<string>01c00000</string>
</map>

<array> 
<string>Group Default Title</string>
<string>Group Title 1</string>
<string>Group Title 2</string>
<string>Group Owner Title</string>
<string>Group Title 3</string>
</array>

</map>
</llsd>
</pre>
'''Note:''' the ''powers'' value is a string and must be converted to a U64.

To reduce the amount of data being transferred, default member information is omitted from the member list. This may result in a member information block with an empty map.
<pre>
<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<key>last_login</key>
<key>powers</key>
<key>title</key>
<key>owner</key>
</map>
</map>
</pre>

If any of the above keys do not exist, use the following default values:
* '''donated_square_meters''': 0
* '''last_login''': "unknown"
* '''powers''': ''default_powers'' from the ''defaults'' map
* '''title''': the first element from the ''titles'' array
* '''owner''': ''false''

=== History ===

{| class="wikitable"
|-
| 2017 || Broken. May return data for other group. Callers should verify 'group_id' in response matches that in request and re-issue if different. SL-16849.
|-
| ~2012 || Introduced
|}

[[Category:Capabilities]]

GroupMemberData

2022-04-01T16:04:02Z

Monty Linden:

'''POST:'''
<pre>
<llsd>
<map>
<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>
</map>
</llsd>
</pre>

The response is a map containing the requesting agent's ID, the group ID, the member count, a map of member data, a map of group defaults, and an array of group titles.

'''Repsonse:'''
<pre>
<llsd>
<map>
<key>agent_id</key>
<uuid>00112233-4455-6677-8899-aabbccddeeff</uuid>

<key>group_id</key>
<uuid>01234567-89ab-cdef-fedc-ba9876543210</uuid>

<key>member_count</key>
<integer>10</integer>

<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<integer>4</integer>

<key>last_login</key>
<string>2012/20/03</string>

<key>powers</key>
<string>FFFFFFFF</string>

<key>title</key>
<integer>1</integer>

<key>owner</key>
<bool>True</bool>
</map>
</map>

<map> 
<key>default_powers</key>
<string>01c00000</string>
</map>

<array> 
<string>Group Default Title</string>
<string>Group Title 1</string>
<string>Group Title 2</string>
<string>Group Owner Title</string>
<string>Group Title 3</string>
</array>

</map>
</llsd>
</pre>
'''Note:''' the ''powers'' value is a string and must be converted to a U64.

To reduce the amount of data being transferred, default member information is omitted from the member list. This may result in a member information block with an empty map.
<pre>
<map> 
<key>ffeeddcc-bbaa-9988-7766-554433221100</key>
<map>
<key>donated_square_meters</key>
<key>last_login</key>
<key>powers</key>
<key>title</key>
<key>owner</key>
</map>
</map>
</pre>

If any of the above keys do not exist, use the following default values:
* '''donated_square_meters''': 0
* '''last_login''': "unknown"
* '''powers''': ''default_powers'' from the ''defaults'' map
* '''title''': the first element from the ''titles'' array
* '''owner''': ''false''

=== History ===

{| class="wikitable"
|-
| 2017 || Broken. May return data for other group. Callers should verify 'group_id' in response matches that in request and re-issue if different. SL-16849.
|-
| ~2012 || Introduced
|}

[[Category:Capabilities]]

Current Sim Capabilities

2022-04-01T13:27:26Z

Monty Linden:

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[AcceptFriendship Capability|AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[DeclineFriendship Capability|DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]]
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]]
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]]
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

Capability DeclineFriendship

2022-04-01T13:20:43Z

Monty Linden: Monty Linden moved page Capability DeclineFriendship to DeclineFriendship Capability: Better indexing

#REDIRECT [[DeclineFriendship Capability]]

DeclineFriendship Capability

2022-04-01T13:20:43Z

Monty Linden: Monty Linden moved page Capability DeclineFriendship to DeclineFriendship Capability: Better indexing

Capability AcceptFriendship

2022-04-01T13:20:06Z

Monty Linden: Monty Linden moved page Capability AcceptFriendship to AcceptFriendship Capability: Indexes better this way

#REDIRECT [[AcceptFriendship Capability]]

AcceptFriendship Capability

2022-04-01T13:20:06Z

Monty Linden: Monty Linden moved page Capability AcceptFriendship to AcceptFriendship Capability: Indexes better this way

Current Sim Capabilities

2022-04-01T13:10:35Z

Monty Linden: /* External Links */

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[Capability AcceptFriendship|AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[Capability DeclineFriendship|DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]]
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]]
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]]
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

DeclineFriendship Capability

2022-04-01T13:07:43Z

Monty Linden: Created page with "Category:Capabilities The DeclineFriendship Capability performs a function similar to the DeclineFriendship LLMessage. It allows the recipient of a friendship offer,..."

AcceptFriendship Capability

2022-04-01T13:07:09Z

Monty Linden: Initial Version

Current Sim Capabilities

2022-04-01T13:06:14Z

Monty Linden:

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[Capability AcceptFriendship|AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[Capability DeclineFriendship|DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]]
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]]
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]]
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet|Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

Current Sim Capabilities

2022-04-01T13:04:08Z

Monty Linden: Same name for llmessage and capabilities. Needs to be distinguished.

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[Capability AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[Capability DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]]
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]]
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]]
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet|Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

ReadOfflineMsgs

2022-04-01T13:02:37Z

Monty Linden:

ReadOfflineMsgs

2022-04-01T13:02:11Z

Monty Linden: Created page with "Category:Capabilities The ReadOfflineMsgs Capability performs a function similar to the RetrieveInstantMessages LLMessage. It retrieves offline Instant Messages and return..."

Current Sim Capabilities

2022-04-01T12:57:56Z

Monty Linden: Update list of sub-subcapabilities. Believe it is now complete except for the unnamed caps generated by caps-generating-caps (sub-sub-capabilities).

=Introduction=

In the current protocols, there appear to be at least 2 kinds of [[Capabilities|capabilities]]: [[Current_Sim_Capabilities#Sim capabilities|Sim capabilities]] and [[Current_Sim_Capabilities#Sub-Capabilities|Sub-Capabilities]] obtained from the Sim Capability. The [[Current_login_protocols|current login protocols]] return a "seed-capability" which is actually the Sim-Capability of the sim the avatar enters upon performing a full login. This will change with the new [[Login_Protocol|login protocols]].

The following slides are from an October, 2007 presentation by Tess Linden. Though it was an internal Linden Lab presentation, the slides may be useful for those residents trying to learn Second Life's messaging and capability systems. [[Message_System_and_Capabilities]]

=Accessing Capabilities=

A typical capability is of the form: https://sim1234.agni.lindenlab.com:12345/cap/UUID

In the current client, sim capabilities are accessed via an https request of the form:

https request {POST, URL:port, path, body, header}

where

:• URL:port is of the form: sim1234.agni.lindenlab.com:12345;
:• path is of the form: /cap/UUID;
:• body is an xml-encoded LLSD array of the form: <llsd><array><string>request1</string><string>request2</string></array></llsd>
:• Header is of the form: "content-type": "application/llsd+xml";

The response from a sim capability transaction is an xml-encoded LLSD dictionary with key, value pairs in the form:

:• <llsd><map><key>request1</key><string>Capability1</string><key>request2</key><string>Capability2</string</map></llsd>

sub-capabilities apparently use the same protocol, but the body of the https request is dependent on which capability is used, as is the result.

=Sub Capabilities=
The following are among the sub-capabilities returned by the sim cap. Each has its own protocols which will be discussed in separate pages:

* [[AbuseCategories]]
* [[AcceptFriendship]]
* [[AcceptGroupInvite]]
* [[AgentExperiences]]
* [[AgentPreferences]]
* [[AgentState]]
* [[AttachmentResources]]
* [[AvatarPickerSearch]]
* [[AvatarRenderInfo]]
* [[CharacterProperties]]
* [[ChatSessionRequest]]
* [[CopyInventoryFromNotecard]]
* [[CreateInventoryCategory]]
* [[DeclineFriendship]]
* [[DeclineGroupInvite]]
* [[DirectDelivery]]
* [[DispatchRegionInfo]]
* [[EnvironmentSettings]]
* [[EstateAccess]]
* [[EstateChangeInfo]]
* [[EventQueueGet]]
* [[ExperiencePreferences]]
* [[ExperienceQuery]]
* [[ExtEnvironment]]
* [[FacebookConnect]]
* [[FetchInventory2]]
* [[FetchInventoryDescendents2]]
* [[FetchLib2]]
* [[FetchLibDescendents2]]
* [[FindExperienceByName]]
* [[FlickrConnect]]
* [[GetAdminExperiences]]
* [[GetCreatorExperiences]]
* [[GetDisplayNames]]
* [[GetExperienceInfo]]
* [[GetExperiences]]
* [[GetMesh]]
* [[GetMesh2]]
* [[GetMetadata]]
* [[GetObjectCost]]
* [[GetObjectPhysicsData]]
* [[GetTexture]]
* [[GroupAPIv1]]
* [[GroupExperiences]]
* [[GroupMemberData]]
* [[GroupProposalBallot]]
* [[HomeLocation]]
* [[IncrementCOFVersion]]
* [[InterestList]]
* [[InventoryAPIv1]]
* [[InventoryAPIv3]]
* [[IsExperienceAdmin]]
* [[IsExperienceContributor]]
* [[LandResources]]
* [[LibraryAPIv3]]
* [[LSLSyntax]]
* [[MapLayer]]
* [[MapLayerGod]]
* [[MeshUploadFlag]]
* [[NavMeshGenerationStatus]]
* [[NewFileAgentInventory]]
* [[ObjectAnimation]]
* [[ObjectMedia]]
* [[ObjectMediaNavigate]]
* [[ObjectNavMeshProperties]]
* [[ParcelPropertiesUpdate]]
* [[ParcelVoiceInfoRequest]]
* [[ProductInfoRequest]]
* [[ProvisionVoiceAccountRequest]]
* [[ReadOfflineMsgs]]
* [[RegionExperiences]]
* [[RemoteParcelRequest]]
* [[RenderMaterials]]
* [[RequestTextureDownload]]
* [[ResourceCostSelected]]
* [[RetrieveNavMeshSrc]]
* [[ScriptPermissions]]
* [[SearchStatRequest]]
* [[SearchStatTracking]]
* [[SendPostcard]]
* [[SendUserReport]]
* [[SendUserReportWithScreenshot]]
* [[ServerReleaseNotes]]
* [[SetDisplayName]]
* [[SimConsoleAsync]]
* [[SimulatorFeatures]]
* [[StartGroupProposal]]
* [[TerrainNavMeshProperties]]
* [[TextureStats]]
* [[TwitterConnect]]
* [[UntrustedSimulatorMessage]]
* [[UpdateAgentInformation]]
* [[UpdateAgentLanguage]]
* [[UpdateAvatarAppearance]]
* [[UpdateExperience]]
* [[UpdateGestureAgentInventory]]
* [[UpdateGestureTaskInventory]]
* [[UpdateNotecardAgentInventory]]
* [[UpdateNotecardTaskInventory]]
* [[UpdateScriptAgent]]
* [[UpdateScriptTask]]
* [[UpdateSettingsAgentInventory]]
* [[UpdateSettingsTaskInventory]]
* [[UploadBakedTexture]]
* [[UserInfo]]
* [[ViewerAsset]]
* [[ViewerBenefits]]
* [[ViewerMetrics]]
* [[ViewerStartAuction]]
* [[ViewerStats]]

=External Links=
[http://www.libsecondlife.org/wiki/EventQueueGet] -- EventQueueGet - libsecondlife - [https://web.archive.org/web/20080502154101/http://www.libsecondlife.org/wiki/EventQueueGet|Wayback Machine]

[http://www.libsecondlife.org/wiki/MapLayer] -- MapLayer - libsecondlife

[http://www.libsecondlife.org/wiki/NewAgentInventory] -- NewAgentInventory - libsecondlife

[http://www.libsecondlife.org/wiki/UpdateNotecardAgentInventory] -- UpdateNotecardAgentInventory - libsecondlife

[[Category: AW Groupies]][[Category:Capabilities]]

Release Notes/Second Life Project Refresh/3.7.12.291799

2014-07-10T20:36:04Z

Monty Linden: Fixup for llibpng error message text

__NOTOC__
{{KnownIssuesHeader}}
{{GenericDownloadBox|Project|Released on July 10, 2014.|type=project|windows=http://download.cloud.secondlife.com/Viewer_3/Second_Life_Project_Refresh_3_7_12_291799_i686_Setup.exe|macintosh=http://download.cloud.secondlife.com/Viewer_3/Second_Life_Project_Refresh_3_7_12_291799_i386.dmg|linux=http://download.cloud.secondlife.com/Viewer_3/Second_Life_Project_Refresh_3_7_12_291799_i686.tar.bz2|version=3.7.12.291799}}
{{GreenCheckbox|title=Release Notes|body=This release contains an update to a large set of libraries to provide security, stability and consistency improvements to this and future viewers.

====MAC OS X 10.5====

The libraries below have been built with a minimum OS level of 10.6. Viewers based on this release will not run on OS X 10.5 or earlier releases.

====SSA/Avatar Baking Service and Various ISPs and Networking Gear====

A few users have experienced problems with avatar appearance due to their very specific network configuration. Gray avatars are accompanied by ‘Transferred a partial file’ errors in the SecondLife.log file. Linden has not been able to reproduce this internally but a possible workaround is found in this release. Relevant Jira reports are:

*{{jira|BUG-3323}}
*{{jira|SH-4375}}
*{{jira|BUG-3770}}
*{{jira|BUG-3882}}
*{{jira|BUG-3879}}
*{{jira|BUG-3877}}

====Zlib====

Updating from 1.2.3/1.2.4/1.2.5/1.2.6 to 1.2.8.

Library changes can be found here: http://zlib.net/ChangeLog.txt

Contributed minizip library is now built on all platforms. This library is used for file manipulations in colladadom. Originally, that library supplied minizip via binary blob.

====Libpng====

Updating from 1.5.1 to 1.6.8

Library changes can be found here: http://www.libpng.org/pub/png/libpng.html. Changes aren’t in one place so expect to dig.

Numerous .png files in viewer build show warnings/errors with new library due to non-conforming color profiles, etc. These warnings appear in the viewer’s (or SLplugin’s) standard error stream and are one of the following:

iCCP: known incorrect sRGB profile
iCCP: profile 'ICC Profile': 1000000h: invalid rendering intent
iCCP: cHRM chunk does not match sRGB

These PNG files were cleaned up and made conforming in changeset 654ca4c10c91.

====OpenSSL====

Updating from 0.9.8q/1.0.0d to 1.0.1h. The new version includes fixes for the Heartbleed exploit.

Library changes can be found here: http://www.openssl.org/news/changelog.html

====C-Ares====

Updating from 1.7.1 to 1.10.0.

Changes can be found here: http://c-ares.haxx.se/download/

These changes should be mostly irrelevant as the curl package has been switched over to use the threaded resolver. But there is still a DNS lookup utility present in the viewer.

====Libxml2====

Updating from 2.6.24 to 2.9.1 and expanding platforms from Linux-only to all three.

Changes can be found here: http://xmlsoft.org/news.html

====PCRE====

Updating from 7.6 to 8.35.

Changes can be found here: http://www.pcre.org/changelog.txt

====DirectFB====

Updating from 1.4.9 to 1.7.1.

Changes can be found here: http://directfb.org/index.php?path=Main%2FDownloads

====SDL====

Updating SDL from 1.2.14 to 1.2.15.

Changes can be found here: http://www.libsdl.org/release/changes-1.2.html

====curl====

Updating from 7.24.0 to 7.37.0.

Changes can be found here: http://curl.haxx.se/changes.html

====Boost====

Updating from 1.52.0 to 1.55.0.

Changes can be found here: http://www.boost.org/users/history/version_1_55_0.html

====google-mock====

Updating from 1.1.0 to 1.7.0. (1.6.0 to 1.7.0 on Windows)

Changes can be found here (if you’re lucky and persistent): https://code.google.com/p/googlemock/w/list

====collada-dom====

Continuing with 2.3 (dom version 1.4). This is not a version change despite earlier viewers having advertised the library as a 2.2 release.

====fontconfig====

Updating from 2.8.0 to 2.11.0.

Changes can be found here: http://www.freedesktop.org/software/fontconfig/release/

====freetype====

Staying at 2.4.4 but built differently for the viewer.

History can be found here: http://www.freetype.org/index.html#news

====llqtwebkit/Qt4====

Functionally equivalent to the previous 4.7.1 version of the Qt4 library. This collection of libraries is being built in a different, more maintainable fashion which is why it is mentioned. This does not address the outstanding issues with Webkit services on various platforms (e.g. Media-on-a-Prim, streaming media viewing).}}{{GreenCheckbox|title=Resolved Issues|body=* {{jira|MAINT-3297}} "Input Window" open by keystroke.}}
{{RedInfobox|title=Known Issues|body=* {{jira|MAINT-4158}} Avatar distorted when changing outfits
* {{jira|MAINT-809}} [PUBLIC]Setting 16x antialiasing crashes Viewer in Ubuntu 11.10 with GeForce 6600
* {{jira|MAINT-3200}} WL Haze effects are inconsistent between solid and transparent objects under water.
* {{jira|MAINT-3197}} Rigged alpha attachments don't render for impostors.
* {{jira|MAINT-3198}} Legacy bumpiness renders funny on HUD faces with custom alpha mode
* {{jira|MAINT-3213}} Brightness and Darkness legacy bump maps render incorrectly on Intel GPUs.
* {{jira|WEB-4659}} Direct Delivery Outbox fails in Linux build
}}

File:Texture console v372.png

2014-02-25T00:21:03Z

Monty Linden:

Texture Console

2014-02-25T00:20:23Z

Monty Linden: Document 3.7.2 release with new mesh status line

{{OSWikiFeatureNav}}

==Definitions==
'''Decode''' - Uncompressing a downloaded texture, in SL's case a JPEG2000 texture, into memory. Once it is decoded it will be handed to OpenGL.

'''Discard Level''' - A discard level of 0 means the highest available detail version of the texture. Discard level 1 means the second highest detail version, which is 1/2 the size in each dimension (and thus 1/4 the memory footprint in memory)

== 3.7.2 ==
[[Image:Texture_console_v372.png|Texture Console]]

'''Note: Unless the scene is *very* simple, this display only shows a tiny fraction of the number of textures. The textures displayed are active textures (i.e. textures that need more data) ordered by priority.'''

# Amount of texture data handed to OpenGL / Maximum amount SecondLife will hand to OpenGL*
# Amount of texture data currently bound by OpenGL / Threshold at which we decrease texture detail*
# FBO (Needs Details)
# Raw Tot. (ND)
# Bias. Texture detail multiplier. > 1 indicates that texture detail is being decreased to fit into memory
# Cache.
# Net Tot Tex. Total size of textures (MB) downloaded over network in this session. Includes both UDP and HTTP transport. Value is updated internally on a 10-second timer and so lags other activity in the console.
# Tot Obj. (MB) (ND)
# Tot Htp. Total number of HTTP requests issued for texture downloads. Repeated downloads (say, for existing or different discard levels) are counted individually. Retries on connection or HTTP failures were counted in the past. They are not counted currently.
# Cread. Count of on-disk texture cache reads requested by texture fetch code.
# Cwrite. Count of on-disk texture cache writes requested by texture fetch code.
# Rwait. Count of texture fetch requests that went to resource wait state (HTW) because the HTTP library had enough work queued up.
# Textures. Number of textures known to the texture management system. These will be in various states of completeness.
# Fetch. Number of outstanding texture fetch requests / Number of completed fetch requests awaiting finalization (leading to deletion of the request).
# Pkts. Count of UDP packets received containing texture header or image data. / Count of UDP packets received that could not be processed due to some error such as corruption or invalid ordering or no valid request.
# Cache R/W. Count of outstanding cache read requests / Count of outstanding cache write requests
# LFS. Count of async file operation requests outstanding on the LFS worker thread. LFS shouldn’t be involved in texture operations anymore so probably not interesting.
# RAW. Count of instances of LLImageRaw objects currently in the system.
# HTP. Count of active HTTP requests issued or queued for texture fetching. Completion will contribute to ‘Tot Htp’ above. These are the requests made available to the lower-level HTTP transport and not the number of concurrent requests (which is limited to eight by default).
# DEC. Count of requests outstanding for decoding of texture data.
# CRE. (ND)
# BW. UDP + HTTP texture bandwidth as consumed / UDP bandwidth limit as configured. Text will change color to yellow or red as configured value is approached and exceeded.
# Tex UUID. Fragment of UUID identifying texture. UUIDs will be rendered with varying colors:
#* White = Normal priority image
#* Yellow = Selected image, prioritized
#* Orange = Image under mouse ("hover"), prioritized
#* Magenta = Boosted (prioritized) image
#* Green = UI image
#* Grey = Image not in state machine (hopefully because current discard <= desired discard)
# Area. Area on screen. Approximate # of pixels this texture covers on-screen.
# DDis(Req). Desired Discard Level (see Discard definition) which is a function of area on screen and importance / Requested Discard Level. This is the client's record of the last discard level requested to the server. This is usually the same as Desired Discard Level, but may be larger if we have stopped requesting the texture because it is out of view (no area) or we have all of its data.
# DecodePri(Fetch). Priority for decode of image / Priority as requested for fetching.
# Progress Bar. Fills up as the requested texture is downloaded. This is basically a download progress bar for the textures current Desired Discard Level (but will only fill up if the requested discard level is 0). Incremental progress is indicated for UDP requests, HTTP will jump to completion.
# pk/max. For UDP, number of packets received (reflected in progress bar) / Max number of packets
# State. The texture request's current state in the fetching/decoding state machine. States include:
#* "---" - The texture is not being fetched (hopefully because current discard <= desired discard). If red, invalid state.
#* "INI" - The texture is waiting to be processed by the state machine
#* "DSK" - Reading from local cache (cyan=header, blue=body)
#* "NET" - Indicates the texture is in the UDP request queue, but has not yet been requested from the servers
#* "SIM" - Waiting for UDP packet data from simulator
#* "HTW" - Resource waiting for HTTP resources prior to "HTP" state
#* "REQ" - Preparing to send HTTP request to grid
#* "HTP" - Waiting for HTTP response data
#* "DEC" - Decoding Image
#* "WRT" - Writing image to local cache
#* "END" - Waiting for a request for more data or deletion (after timeout)
#* "CRE" - Texture needs to be created
#* "FUL/BAD/MIS" - Debug, shouldn't happen (needs create, fully loaded, bad, missing)
# Pkt. Handling information for recently-received data (mostly UDP-oriented):
#* White = packet received from simulator
#* Green = data requested from simulator
#* Yellow = texture processed by state machine
# Bnd. Binding of fetched data to OpenGL:
#* Purple = Texture is currently bound (i.e. being rendered)
# W x H. Dimensions of image.
# (Dis). Actual Discarded level. This should eventually (after textures are downloaded and decoded) be the same as Desired Discard Level (DDis).
# Mem. Amount of memory consumed by the texture.
# Mesh Reqs(Tot/Htp/Big). Mesh status line starting with counts of mesh requests issued: total (pre-cache), 'normal' HTTP and 'Big' (over 2MB) HTTP. A mesh request will typically be for a part of a full mesh: a single level-of-detail or perhaps a header. A request may be satisfied by the mesh cache. If not in the cache, then an HTTP request is issued. That request will be either a 'normal' or a 'big' request.
# Rtr/Err. Retries issued and final errors received for HTTP mesh requests.
# Cread/Cwrite. Mesh cache read and write operations. 'Cwrite' will approximately follow 'Htp' + 'Big'. 'Cread' gives an indication of the effectiveness of the local mesh cache.
# Low/At/High. The mesh fetching code maintains a pool of requests. This code attempts to keep the pool filled between the 'Low' and 'High' water levels shown here. The current pool level is given by 'At' and the pool is refilled when it falls below 'Low'.

Some patterns to look for when searching for texture fetch bugs:

1. If Cread is growing quickly while Cwrite and 'Tot Htp' are
static or growing slowly then the texture cache is populated
and being used.

2. If Cwrite and 'Tot Htp' grow at about the same rate as
Cread, then either the texture cache is cold or it isn't working.

3. If 'Tot Htp' is growing faster than 'Cwrite', then we're
doing unnecessary fetches for assets for some reason.

== 3.4.3 ==
[[Image:Texture_console_v343.png|Texture Console]]

'''Note: Unless the scene is *very* simple, this display only shows a tiny fraction of the number of textures. The textures displayed are active textures (i.e. textures that need more data) ordered by priority.'''

# Amount of texture data handed to OpenGL / Maximum amount SecondLife will hand to OpenGL*
# Amount of texture data currently bound by OpenGL / Threshold at which we decrease texture detail*
# FBO (Needs Details)
# Raw Tot. (ND)
# Bias. Texture detail multiplier. > 1 indicates that texture detail is being decreased to fit into memory
# Cache.
# Net Tot Tex. Total size of textures (MB) downloaded over network in this session. Includes both UDP and HTTP transport. Value is updated internally on a 10-second timer and so lags other activity in the console.
# Tot Obj. (MB) (ND)
# Tot Htp. Total number of HTTP requests issued for texture downloads. Repeated downloads (say, for existing or different discard levels) are counted individually. Retries on connection or HTTP failures were counted in the past. They are not counted currently.
# Cread. Count of on-disk texture cache reads requested by texture fetch code.
# Cwrite. Count of on-disk texture cache writes requested by texture fetch code.
# Rwait. Count of texture fetch requests that went to resource wait state (HTW) because the HTTP library had enough work queued up.
# Textures. Number of textures known to the texture management system. These will be in various states of completeness.
# Fetch. Number of outstanding texture fetch requests / Number of completed fetch requests awaiting finalization (leading to deletion of the request).
# Pkts. Count of UDP packets received containing texture header or image data. / Count of UDP packets received that could not be processed due to some error such as corruption or invalid ordering or no valid request.
# Cache R/W. Count of outstanding cache read requests / Count of outstanding cache write requests
# LFS. Count of async file operation requests outstanding on the LFS worker thread. LFS shouldn’t be involved in texture operations anymore so probably not interesting.
# RAW. Count of instances of LLImageRaw objects currently in the system.
# HTP. Count of active HTTP requests issued or queued for texture fetching. Completion will contribute to ‘Tot Htp’ above. These are the requests made available to the lower-level HTTP transport and not the number of concurrent requests (which is limited to eight by default).
# DEC. Count of requests outstanding for decoding of texture data.
# CRE. (ND)
# BW. UDP bandwidth limit as negotiated / UDP bandwidth limit as configured. Text will change color to yellow or red as configured value is approached and exceeded.
# Tex UUID. Fragment of UUID identifying texture. UUIDs will be rendered with varying colors:
#* White = Normal priority image
#* Yellow = Selected image, prioritized
#* Orange = Image under mouse ("hover"), prioritized
#* Magenta = Boosted (prioritized) image
#* Green = UI image
#* Grey = Image not in state machine (hopefully because current discard <= desired discard)
# Area. Area on screen. Approximate # of pixels this texture covers on-screen.
# DDis(Req). Desired Discard Level (see Discard definition) which is a function of area on screen and importance / Requested Discard Level. This is the client's record of the last discard level requested to the server. This is usually the same as Desired Discard Level, but may be larger if we have stopped requesting the texture because it is out of view (no area) or we have all of its data.
# DecodePri(Fetch). Priority for decode of image / Priority as requested for fetching.
# Progress Bar. Fills up as the requested texture is downloaded. This is basically a download progress bar for the textures current Desired Discard Level (but will only fill up if the requested discard level is 0). Incremental progress is indicated for UDP requests, HTTP will jump to completion.
# pk/max. For UDP, number of packets received (reflected in progress bar) / Max number of packets
# State. The texture request's current state in the fetching/decoding state machine. States include:
#* "---" - The texture is not being fetched (hopefully because current discard <= desired discard). If red, invalid state.
#* "INI" - The texture is waiting to be processed by the state machine
#* "DSK" - Reading from local cache (cyan=header, blue=body)
#* "NET" - Indicates the texture is in the UDP request queue, but has not yet been requested from the servers
#* "SIM" - Waiting for UDP packet data from simulator
#* "HTW" - Resource waiting for HTTP resources prior to "HTP" state
#* "REQ" - Preparing to send HTTP request to grid
#* "HTP" - Waiting for HTTP response data
#* "DEC" - Decoding Image
#* "WRT" - Writing image to local cache
#* "END" - Waiting for a request for more data or deletion (after timeout)
#* "CRE" - Texture needs to be created
#* "FUL/BAD/MIS" - Debug, shouldn't happen (needs create, fully loaded, bad, missing)
# Pkt. Handling information for recently-received data (mostly UDP-oriented):
#* White = packet received from simulator
#* Green = data requested from simulator
#* Yellow = texture processed by state machine
# Bnd. Binding of fetched data to OpenGL:
#* Purple = Texture is currently bound (i.e. being rendered)
# W x H. Dimensions of image.
# (Dis). Actual Discarded level. This should eventually (after textures are downloaded and decoded) be the same as Desired Discard Level (DDis).
# Mem. Amount of memory consumed by the texture.

Some patterns to look for when searching for bugs:

1. If Cread is growing quickly while Cwrite and 'Tot Htp' are
static or growing slowly then the texture cache is populated
and being used.

2. If Cwrite and 'Tot Htp' grow at about the same rate as
Cread, then either the texture cache is cold or it isn't working.

3. If 'Tot Htp' is growing faster than 'Cwrite', then we're
doing unnecessary fetches for assets for some reason.

==1.14==
[[Image:Texture_console_1_14.png|Texture Console]]

* '''Important note: Unless the scene is *very* simple, this display only shows a tiny fraction of the number of textures. The textures displayed are active textures (i.e. textures that need more data) ordered by priority.'''

* 1: Amount of texture data handed to OpenGL / Maximum amount SecondLife will hand to OpenGL*
* 2: Amount of texture data currently bound by OpenGL / Threshold at which we decrease texture detail*
* 3: Texture detail multiplier. > 1 indicates that texture detail is being decreased to fit into memory
* 4: Graphical representation of 1. Red indicates that (3) will be increased
* 5: Total number of textures currently referenced (i.e. nearby)
* 6: Number of textures with data being actively fetched (number pending deletion)
* 7: Number of textures waiting to be Read/Written to the local cache
* 8: Graphical representation of 2
* 9: First chunk of texture ID
* 10: Area on screen. Approximate # of pixels this texture covers on-screen.
* 11: Desired Discard Level. (see Discard definition) Is a function of area on screen and importance.
* 12: Requested Discard Level. This is the clients record of the last discard level requested to the server. This is usually the same as Desired Discard Level, but may be larger if we have stopped requesting the texture because it is out of view (no area) or we have all of its data.
* 13: Priority.
* 14: Requested Priority.
* 15: Data received. This bar fills up as the requested texture is downloaded. This is basically a download progress bar for the textures current Desired Discard Level (but will only fill up if the requested discard level is 0).
* 16: Number of Packets received (numerical representation of 15)
* 17: Max number of packets
* 18: "---" see 27-33
* 19: State: What state the texture fetcher is in for this texture
* 20: Pkt:
** White = packet received from simulator
** Green = data requested from simulator
** Yellow = texture processed by state machine
* 21: Bnd:
** Purple = Texture is currently bound (i.e. being rendered)
* 22: Width x Height
* 23: Actual Discarded level. This should eventually (after textures are downloaded and decoded) be the same as (11)Desired Discard Level.
* 24: Amount of memory consumed by the texture
* 25/26: Text Color
** White = Normal priority image
** Yellow = Selected image, prioritized
** Orange = Image under mouse ("hover"), prioritized
** Magenta = Boosted (prioritized) image
** Green = UI image
** Grey = Image not in state machine (hopefully because current discard <= desired discard)
* 27-33
** "---" - The texture is not being fetched (hopefully because current discard <= desired discard)
** "INI" - The texture is waiting to be processed by the state machine
** "DSK" - Reading from local cache (cyan=header, blue=body)
** "NET" - Indicates the texture is in the network request queue, but has not yet been requested from the servers
** "SIM" - Waiting for packet data from simulator
** "URL" - Waiting for URL for HTTP request
** "HTP" - Waiting for HTTP data
** "DEC" - Decoding Image
** "WRT" - Writing image to local cache
** "END" - Waiting for a request for more data or deletion (after timeout)
** "CRE/FUL/BAD/MIS" - Debug, shouldn't happen (needs create, fully loaded, bad, missing)

(*) These are functions of the 'Graphics Card Memory' setting under Preferences > Adv. Graphics

==1.13==
[[Image:Texture console.png|Texture Console]]

* '''Important note: Unless the scene is *very* simple, this display only shows a tiny fraction of the number of textures. The textures displayed are active textures (i.e. textures that need more data) ordered by priority.'''

* 1: Amount of texture data handed to OpenGL / Maximum amount SecondLife will hand to OpenGL*
* 2: Amount of texture data currently bound by OpenGL / Threshold at which we decrease texture detail*
* 3: Texture detail multiplier. > 1 indicates that texture detail is being decreased to fit into memory
* 4: Graphical representation of 1. Red indicates that (3) will be increased
* 5:
* 6:
* 7:
* 8: Graphical representation of 2
* 9: First chunk of texture ID
* 10: Area on screen. Approximate # of pixels this texture covers on-screen.
* 11: Desired Discard Level. (see Discard definition) Is a function of area on screen and importance.
* 12: Requested Discard Level. This is the clients record of the last discard level requested to the server. This is usually the same as Desired Discard Level, but may be larger if we have stopped requesting the texture because it is out of view (no area) or we have all of its data.
* 13: Priority.
* 14: Requested Priority.
* 15: Data received. This bar fills up as the requested texture is downloaded. This is basically a download progress bar for the textures current Desired Discard Level (but will only fill up if the requested discard level is 0).
* 16: Number of Packets received (numerical representation of 15)
* 17: Max number of packets
* 18: A pip shows up here when a packet arrives
* 19: A pip shows up here while the texture is being decoded
* 20: A pip shows up here if the texture is being displayed (bound)
* 21:
* 22: Width x Height
* 23: Actual Discarded level. This should eventually (after textures are downloaded and decoded) be the same as (11)Desired Discard Level.
* 24: Amount of memory consumbed by the texture
* 25: grey text.
* 26: purple text.
* 27: green text.
* 28: *.
* 29: *r.

(*) These are functions of the 'Graphics Card Memory' setting under Preferences > Adv. Graphics

==Notes==
* 'Texture Memory' or 'OpenGL Memory' refers to data passed to the OpenGL drivers. Depending upon the graphics card and driver, this memory may be on the graphics card, in system memory, or (likely) both.

Linden Department of Public Works

2013-01-25T16:38:51Z

Monty Linden: /* What is it? */

{{Help|Glossary=*}}[[Image:Visit the Mainland2.jpg|behind|600px]]

== What is it? ==

The '''Linden Department of Public Works''' (LDPW) is a program focused on improvements related to the experience of living on, or visiting the Linden Mainland. The LDPW will organize teams of Resident builders, artists, and scripters (the Moles!) to create new content on Linden Lab's behalf and to the benefit of all. Rather than divert company resources from areas of development that contribute to important issues like stability and usability, Linden Lab is choosing to go to the experts...

It should be no surprise that when it comes to creating compelling SL content, it's the Resident population itself that serves as the best talent pool. In order to hit the ground running, the LDPW has approached a number of content creators whose credentials are well-established, but from the start, its intentions were to make application to the program open to all residents. So if you're a skilled content creator, please consider applying when the application process is open! If you'd rather not join the build crew, but would still like to participate, then please help to name the new city sims by adding your suggestions below!

=== Lindens in the LDPW ===

'''[[User:Michael Linden|Michael Linden]]''' is the Senior Content Specialist in LDPW.

=== Residents in the LDPW ===

Hard working city and country moles, these are the Residents that have made up the illustrious ranks of molekind. Note this list is not complete, and also includes veteran moles no longer with the LDPW.

{|
|--
|valign=top|
*Barnesworth Anubis
*Chance Abattoir
*Charlotte Bartlett
*Canolli Capalini
*Dee Firefly
*Goran Matzerath
*Leah Salome
*Lilli Field
*Betlog Hax
*Moundsa Mayo
|valign=top|
*Alisha Matova
*Neil Robinson
*Prad Prathivi
*Nephilaine Protagonist
*Stella Costello
*Treacly Brodsy
*Vittorio Beerbaum
*Yeti Bing
*Zyrra Falcone

|valign=top|
*Caliandris Pendragon
*Peter13 Peterman
*Ilse Mannonen
*Itazura Radio
*Lonewolf Switchblade
*Grandma Bates
*Ravenna Soothsayer
|valign=top|
*Kat Claxton
*Miriel Enfield
*Elfod Nemeth
*Talia Tokugawa
*Grace Loudon
*Nerolus Mosienko
*Atashi Yue
|}

=== Past and Present Moles of the LDPW ===

{|
|--
|valign=top|
*Abnor Mole
*Ani Mole
*Auspicious Mole
*Avogadro Mole
*Bloomin Mole
*Buhbuhcuh Mole
*Crafty Mole
*Crazy Mole
*Dark Mole
*Deep Mole

|valign=top|
*Delicious Mole
*Earthy Mole
*Freerange Mole
*Garden Mole
*Glamorous Mole
*Guaca Mole
*Holy Mole
*Hyper Mole
*Igneous Mole
*Inconspicuous Mole

|valign=top|
*La Mole
*Macho Mole
*Maladaptive Mole
*Mighty Mole
*Milk Mole
*Mini Mole
*Misty Mole
*Mouldy Mole
*Multi Mole
*Myopic Mole
*Mysterious Mole
|valign=top|

*Mythic Mole
*Naughty Mole
*Opti Mole
*Princess Mole
*Protean Mole
*Railway Mole
*Secret Mole
*Silent Mole
*Smokey Mole
*Sneaky Mole
|valign=top|

*Squishy Mole
*Stoic Mole
*Sunny Mole
*Sylvan Mole
*Undercover Mole
*Vanity Mole
*Whacka Mole
|}

== FAQ ==

Here are some common questions from the various blog postings and LDPW office hours, as answered by LDPW Lindens.

; Is this a volunteer position?

:The moles are paid an hourly rate.

;Do I have to be good at design, building, texturing, sculpting AND scripting to apply?

:Fully rounded content creators are certainly encouraged to apply, but we will be asking you to indicate your core skill, assuming that most people are not Leonardo DaVinci and specialize in certain areas.

;What if I can't do any of those things, but still want to help somehow?

:Contribute your ideas here on the wiki! Suggest Region names and builds, or future LDPW projects, or even other ways for individuals to participate.

;Are builders going to using any 'megaprims'? I love/hate those things

:No, megaprims will not be used in any Linden or LDPW builds.

;Do the contractors keep the rights to their content?

:In order to maintain the rights to reproduce the content and to make some of it available via the Library, Linden Lab is purchasing full rights to content created by the mole builders.

;Aren't you supposed to be fixing lag and stuff?

:The LDPW project has no impact whatsoever on engineering or development efforts to improve Second Life. You REALLY don't want the the LDPW folks mucking about in the code. Trust me.

; So this LDPW thing is all about making new city sims?

:Not exclusively, no, although a new city area (Bay City) was the first LDPW project -- it entails numerous elements for future projects which will help us to define best practices and implement the structures needed to expand.

;So there will be road building then?

:Yes, LDPW creates roads and bridges on mainland sims, and considering a number of other infrastructure projects from planting trees, to new Infohubs to region-wide builds. We'll be taking all suggestions into account, so please stay tuned and join the continued discussion.

;What's all this about moles?

:The contractors use accounts with the last name Mole, which references a bit of graffiti that appeared in the original city sims long ago ... Beware the Mole People! Of course, those moles who wish to make their primary account names known are certainly free to do so.

==LDPW Projects==
[[LDPW_Projects|LDPW Projects]]

Texture Console

2013-01-02T21:53:57Z

Monty Linden: Update with the 3.4.3 layout of the texture console

File:Texture console v343.png

2013-01-02T21:11:14Z

Monty Linden: Annotated capture of texture console as rendered in V3.4.3.

Annotated capture of texture console as rendered in V3.4.3.

TPVD/Developers Group Agenda

2012-06-29T19:00:53Z

Monty Linden: /* Open Items: */

'''Add agenda requests at the end, and please put your SL Name in the request so Oz's know who to contact for any clarification'''
'''Use <nowiki>--~~~~</nowiki> to insert your signature'''
Next meeting: '''Noon SLT, June 29'''

====New:====

# Plans for the llphysicsextension stub, and the corresponding licensed library
# New community driven user group for content creation improvements --[[User:Geenz Spad|Geenz Spad]]



====Open Items:====

# In-world Viewer Test resources ([[User:Alexa Linden|Alexa Linden]])
# Communications reliability issues
## Monty needs consumer router information
# People API (we can still hope)

[[Category:Third Party Viewers]]

TPVD/Developers Group Agenda

2011-09-02T19:17:19Z

Monty Linden: /* Open Items: */

'''Add agenda requests at the end, and please put your SL Name in the request so Oz's know who to contact for any clarification'''
'''Use <nowiki>--~~~~</nowiki> to insert your signature'''

====Current:====

# Does LL have any plans to use Calling Cards/Friends soon? --[[User:Kadah Coba|Kadah Coba]] 11:58, 2 September 2011 (PDT)


====Open Items:====

# '''Fixed''' {{JiraIssue|SVC-7104|Granting/revoking perms broken for non-web-profile viewers}} --[[User:Kadah Coba|Kadah Coba]] 10:32, 21 July 2011 (PDT)
# Any updates on:
#*{{JiraIssue|VWR-25940|HTTP communication with grid capabilities router is unreliable at times affecting HTTP Textures}}
#*{{JiraIssue|SVC-6917|Apache2-worker/caps router on sim hosts is relaying 499 HTTP status codes back to clients - not a valid wire status code}}
#*{{JiraIssue|SVC-6760|Apache2-worker/caps router on sim hosts is experiencing a high failure rate leading to service interruptions}}
#*{{JiraIssue|VWR-25145|asset/texture download scenarios that work badly}}
#*{{JiraIssue|VWR-26218|Windows viewer is experiencing DNS issues while attempting to fetch textures}}
#: and the 499/caps failures? Can someone find out why do a few users see these issues so much? --[[User:Kadah Coba|Kadah Coba]] 12:38, 31 May 2011 (PDT)
#* Seeking feedback on good/bad experiences and networking hardware here:
#** {{JiraIssue|VWR-25426|Friendlist displays users as Unknown or (loading), teleports fail, assets will not save}}
# '''Profile API'''
# Minimap coarse location messages, any possibility on getting that updated to support avatars over 1000m --[[User:Kadah Coba|Kadah Coba]] 13:13, 21 May 2011 (PDT)
## {{JiraIssue|VWR-9326|Incorrect chevron directions on minimap when agents are above 768m}}
## {{JiraIssue|SVC-6152|Sky height limit issues}}
# Search not working without cookies enabled - options for fixing this -- [[User:Nya Linden|Nya Linden]] 14:17, 1 August 2011 (PDT)
# 2.8/3.0 tip OS compiles broken, due to mesh stub library breakage. -- [[User:Arrehn Oberlander]]
# New search returns wrong output when users's local time falls on a different day than SLT -- [[User:Arrehn Oberlander]]

[[Category:Third Party Viewers]]