Second Life Wiki - User contributions [en]

HTTP Texture

2009-05-21T02:17:38Z

Sheet Spotter: Added simplified class diagrams for "Texture Threads" and "Texture Workers"

== Introduction ==
Questions this document will answer:
* What is the "http-texture" project?
* Where are the files involved with this project? (modified compared to trunk)
* How is this supposed to work?
* What about all those threads and their use?
* What about CURL use?

== Objective of the http-texture Project ==
The initial idea of the project is to allow the viewer to point to any image file of any format anywhere on the internet, pull it using the http protocol and use it as a regular texture anywhere textures are used.

This involves a bunch of moving (and new) parts:
* Using any file format as textures (instead of just j2c)
* Pulling image files using HTTP (instead of UDP)
* Getting resources from any host (instead of just the LL asset server)

This is a rather ambitious and wide ranging change. As of today (March 24th, 2009), the main plumbing has been implemented with the following caveats:
* Only jpeg images are supported as another file format
* Such images must be loaded at once (no progressive rendering yet)
* Except for jpegs specified with an "http://" URLs, all other images are still using the old fashion protocol
* There are still quite a bit of crashes here and there... Don't use such a build for your regular SL activities (search for bugs logged against ''http-texture branch'' in PJIRA for more info)

== Files Involved ==
Here are the files involved in the implementation of this feature:

<pre>
/indra/llcommon/llqueuedthread.cpp // Modifications to the virtual method LLQueuedThread::threadedUpdate()
/indra/llcommon/llqueuedthread.h // (does nothing in the root class, see derived class)

/indra/llimage/llimage.cpp // Initializes the image worker thread LLImageWorker::initImageWorker()
/indra/llimage/llimagedxt.cpp
/indra/llimage/llimageworker.cpp // Main implementation of the threading for llimage objects (completely redone)
/indra/llimage/llimageworker.h

/indra/llmessage/llcurl.cpp // Threaded CUrl implementation
/indra/llmessage/llcurl.h // (all of this has already been merged in trunk)
/indra/llmessage/llhttpclient.cpp //
/indra/llmessage/llhttpclient.h //
/indra/llmessage/llhttpassetstorage.cpp //
/indra/llmessage/llurlrequest.cpp //
/indra/llmessage/llurlrequest.h //

/indra/newview/llappviewer.cpp // Calls the init of the image decoding threads
/indra/newview/llconsole.cpp // Changed to use mutexes and different line coloring
/indra/newview/llconsole.h //
/indra/newview/lltexturecache.cpp // Changes with locked mutex, cache but without offset writing and other limitations
/indra/newview/lltexturecache.h // Adds open file book keeping mOpenFiles
/indra/newview/lltexturefetch.cpp // Adds most of the changes related to http texture fetching and threading
/indra/newview/lltexturefetch.h //
/indra/newview/lltextureview.cpp // Lots of fonts and text changes. Similar to llconsole in scope.
/indra/newview/llviewerimage.cpp // Creates the texture request from the passed URL
/indra/newview/llviewerimage.h // Holds the URL for the texture in mURL
/indra/newview/llviewerimagelist.cpp // Manages the list of textures
/indra/newview/llviewerimagelist.h // Defines getImageFromUrl()
</pre>

== Implementation ==
=== Fetching ===
==== Common Mechanism ====
The fetching mechanism uses threads to get data while the main rendering loop goes on. All threads used here inherit from LLThread so a good understanding of this class (and of LLMutex, defined in the same llthread file) is important to understand the texture fetching mechanism.

4 threads are used when requesting a tile/image/texture:
* the LLTextureCache thread: used to retrieve all textures from the local cache. This one is actually not used for http fetched textures.
* the LLTextureFetch thread: used to request textures (all types: j2c, jpg, etc...) from servers, support a variety of protocols (UDP, HTTP). That's the "front" thread of sort, the one that we hit first when posting a texture fetch request and that handles the delegation of tasks to other threads.
* the LLImageDecodeThread thread: used to convert the raw data loaded from the image file (or gathered in chunks by the network thread) into pixel data. In http texture, this is used at the end to decode the whole jpeg image in one single chunk of work.
* curl thread

Synchronization between threads is done using LLMutex, a wrap around Apache mutex to lock/unlock critical sections.

Threaded code is really hairy to track with work orders being created, checked, yielding, running, aborted, ending but not quite done, etc... It's hard to find ones way through the maze. So it's a good idea to keep in mind a little narrative, a story of what is supposed to happen. It's also a good handle to compare the code with the intent of the designer and, hopefully, fix problems.

So, how is an http texture supposed to be fetched and find its way in the viewer's data structure?

The general idea of texture fetching is the following:
* code asks for an image using LLViewerImageList::getImageFromUrl(): ideally, this is all the high level code needs to know. Textures retrieved through http are simply passed to the LLViewerImageList which handles all the fetch, load, etc... of the texture and returns an LLViewerImage pointer to the caller. The whole thing is supposed to be handled completely transparently underneath.
* this getImageFromUrl() call instantiates an LLViewerImage creation, passing the url to the constructor and adds it to the list of managed images
* the list updateImagesFetchTextures() is regularly called on the main thread
* this causes updateFetch() to be called on each image on the list
* the updateFetch() eventually calls createRequest() on the LLTextureFetch thread using the image url
* the LLTextureFetch thread adds a worker to its list to handle the request
* depending on the url and image id, the LLTextureFetchWorker calls the LLTextureCached thread or not. Note that, as of today:
** all files starting with "file://" are treated as local files and use the local cache worker to load. This is the case of all textures used in the UI and skins.
** all textures known by their UUID use the remote cache worker which tests if there is a local cached texture (stored from a previous session) and, if not, makes a network request. This is the code path used for all j2c scene textures.
** all other textures are "http://" jpeg images and will trigger an http request (see below)
* if the cache has the image, it loads it and passes the resulting raw and decoded image to the fetch worker
* if not, a network request is started, if the http flag is on, this will be an HTTP request. Note that, as of today:
** all j2c textures are using the old UDP request scheme
** only jpeg images are using the HTTP request scheme. This code path is exercised only in the map panel which fetches its image data from the Amazon S3 repository.
* the image file is fetched
* when done, the raw image is decoded using the LLImageDecodeThread thread
* when decoded, the request is deleted and the LLViewerImage updated with the decoded image

==== HTTP Fetch ====
For the HTTP fetch mechanism, here's a zoomed in trace of what happens starting with the texture fetch request creation:
* LLTextureFetch::createRequest() is called when an http url is detected
** LLTextureFetchWorker::LLTextureFetchWorker(): a worker is added to the queue
** LLTextureFetchWorker::startWork() starts by initializing a bunch of things on the worker
*** LLTextureFetchWorker::setDesiredDiscard(): the code currently requests the entire image to be loaded by the worker before going back to the main thread
** LLTextureFetchWorker::doWork() is called on the thread and allocate some time to each workers in sequence. The state of the work is updated depending of what's achieved:
*** mState = INIT
*** mState = LOAD_FROM_TEXTURE_CACHE : which actually does nothing currently for http fetched textures (no cached)
*** mState = SEND_HTTP_REQ
**** LLTextureFetch::addToHTTPQueue() and HTTPGetResponder::HTTPGetResponder() : creates a request on the http thread
*** mState = WAIT_HTTP_REQ: waits for the http thread to come back
*** during that time, the other threads might request the status of the worker using LLTextureFetch::getRequestFinished and LLTextureFetch::getFetchState
**** HTTPGetResponder::completedRaw(): eventually, the http thread completes
**** LLTextureFetch::removeFromHTTPQueue(): the fetch order is taken off the http queue
**** LLTextureFetchWorker::callbackHttpGet(): the callback is executed and the http worker deleted
*** mState = DECODE_IMAGE: is the new state of the fetch worker
**** It instantiates a DecodeResponder() on the LLImageDecodeThread and the LLTextureFetchWorker will check for it to complete
*** When completed, the file is written to cache (not implemented yet for http textures!)
*** LLTextureFetchWorker::finishWork and LLTextureFetchWorker::endWork are called
*** The request is then deleted, first it's removed from the queue, then the worker is deleted:
**** LLTextureFetch::deleteRequest()
**** LLTextureFetch::removeRequest()
**** LLTextureFetch::removeFromNetworkQueue()
**** LLTextureFetchWorker::deleteOK
**** LLTextureFetchWorker::clearPackets is eventually called

==== Notes ====
* For the moment, the file (jpg) is downloaded at once (no partial download implemented yet)
* http downloaded files are not cached yet. In most cases though, it's not very relevant since the LLViewerImageList maintains live instances of all loaded images so the cache would be useful only between sessions
* The viewer uses only non nested mutex (APR_THREAD_MUTEX_UNNESTED).
* Threads manage work units as lists (maps actually) of LLWorkerClass objects.

=== Caching ===

See also the public wiki [http://wiki.secondlife.com/wiki/Texture_Cache Texture Cache] documentation for a general overview. The writing here under covers things that are specific to the http-texture branch and questions recently asked on the sldev mailing list.

The texture caching system implemented in lltexturecache.cpp is rather simple in its concept although it's not a simple store of raw files. The main elements of this system are:
* the header cache
* the "body" files
* the LRU and time stamping mechanism

LLTextureCache operations are implemented in a worker thread (inheriting from LLWorkerThread) so all the operations on the cache system are done by worker objects (inheriting from LLWorkerClass) in parallel to the rest of the viewer's operations.

==== Header Cache ====

The idea of the Header Cache is to allow fast retrieval of basic texture information (file size, image size, color model, other metadata...) without having to open and close each cached file. Instead, a single cache file containing all of these information for all cached textures is used.

===== cache/texture.cache =====

This file simply stores the first 600 byte chunk of raw data from the original stream into a single stream of texture "headers" (note that this is a conventional name and might store more than just metadata). This system is effective in SL because the viewer retrieves textures from the network in small packets of raw data and is able to decode a partially downloaded texture. So there's no penalty in storing the first retrieved packet in a special unique "header" file when they are first streamed down. The rest of the texture file is stored as a separate "body" file.

Each record in that file is exactly TEXTURE_CACHE_ENTRY_SIZE (600 bytes) in size per texture.

===== cache/texture.entries =====

To retrieve a texture header knowing its UUID, the viewer uses a map giving for each UUID an index in the texture.cache file. This (UUID,index) table is saved in the cache/texture.entries file, alongside cache/texture.cache.

In addition to the UUID (mID), each entry also contains:
* mImageSize : the original raw file size
* mBodySize : the size of the body file only (i.e. mBodySize = mImageSize - TEXTURE_CACHE_ENTRY_SIZE in the current case where the offset is null or zero if the file is smaller than TEXTURE_CACHE_ENTRY_SIZE)
* mTime : a time stamp stating when last the texture was used.

To optimize the position of frequently used textures and purge old ones, the cache is organized using an LRU (Least Recently Used) algorithm.

==== Body Files ====

Once the first packets are received and stored in the header cache file, the rest of the file (nicknamed "BODY") is stored in a texture specific file. Note that, because of this design:
* the header part is not being duplicated in the body file so, in effect, those cached texture files are not usable as is
* if the total file size is smaller than the size of a header cache entry (TEXTURE_CACHE_ENTRY_SIZE), the whole file is actually in the header cache and no body texture cached file is created

The body file is stored in the cache/textures folder hierarchy using a name built from the UUID of the texture asset as:
/[0-F]/UUID.texture

[0-F] being the first digit (in hexadecimal) of the UUID. This split between folders is to avoid running into file count limits in a folder on some platforms.

==== Reading and Writing the Cache ====

Because of this (somewhat) arbitrary split between header cache and body cache, there is a little bit of copy bits acrobatic to do to recreate a seamless stream when reading the cache back. This code is implemented in LLTextureCacheRemoteWorker and can be traced between the (mState == HEADER) and (mState == BODY) sections in LLTextureCacheRemoteWorker::doRead().

One puzzling data member of LLTextureCacheRemoteWorker to consider is mOffset. This covers data that are reserved for extra information in the formatted image buffer at creation *before* the readFromCache() is invoked (see LLTextureFetchWorker::doWork() in lltexturefetch.cpp). This quantity is fixed, file format specific and never changed. Those data are also *not* part of the raw stream of image data and should be taken out of the stream when reading the cache back.

This is the idea behind the various offset and skipping of data made between the (mState == HEADER) and (mState == BODY) sections in doRead().

In truth, we haven't found any instance of that code being exercised with anything else but (mOffset == 0). So it's possible that this code is somewhat buggy (there's no unit test for it).

In the http-texture branch, the cache now supports jpeg cached files in addition to j2c files. However, it does not support offset writing so, again, there's no chance for the code to be ever exercised with anything else but (mOffset == 0).

For this reason, we believe we should consider suppressing support for this mOffset reading/writing as it makes the code more complex and is likely to crash anyway since writing cache in http-texture does not support it.

=== Threads ===
[[Image:TextureThreads20090520.png|200px|thumb|right|Texture Threads]]
[[Image:TextureWorkers20090520.png|200px|thumb|right|Texture Workers]]
The relationship between the threads and workers described in this section is shown in the "Texture Threads" and "Texture Workers" simplified class diagrams (found on the right hand side). You can view larger versions of the diagrams by clicking on them, or you can open the larger versions in another browser window. (Some of the variable names from the source code have been renamed in the diagrams to simplify the explanation.)

All threads in the viewer derives from LLThread which is a wrapper around the APR thread mechanism. This package implements threads (LLThread), mutexes (LLMutex) and mutex conditions (LLCondition).

All threads involved with texture handling are of the LLQueuedThread class (derived from LLThread), meaning that they essentially run all the time and handle work bundle.

Most of those (actually all of them except LLImageDecodeThread) are "worker threads" of the LLWorkerThread class (derived from LLQueuedThread) and handle specialized work orders (derived from LLWorkerClass) in a worker queue. This allows lengthy operations (like fetching textures...) to be delegated to the thread and, asynchronously, checked for completion while the application continues to render.

The list of "workers" are organized as maps, usually indexed by images UUIDs.

While debugging or tracing threads, a good advice is to "follow the mutex". You need to identify which section of memory each mutex or condition is protecting and make sure lock/unlock are done at the right moment when writing or reading those sections of memory.

==== LLTextureFetch ====
This is the most complete thread of the list. The complexity comes from the fact that the work order on that thread do instantiate other work orders on other threads to get the work done. An additional complexity is that there are several queues and, therefore, several mutexes handled on that thread making the deciphering of the state of the work orders on the thread a tad difficult.

Basically though, the thread follows for each work order the narrative described above. Here's a complete trace of how the LLTextureFetch thread handles an http texture retrieval from the request creation to the image decoding passed to the image list:
<pre>
LLTextureFetch::createRequest
LLTextureFetchWorker::LLTextureFetchWorker
LLTextureFetchWorker::calcWorkPriority, priority = 136633646
LLTextureFetchWorker::startWork
LLTextureFetchWorker::setDesiredDiscard, discard = 5, size = 33554432
LLTextureFetch::getFetchState: Fetch state = 1
LLTextureFetchWorker::doWork: Handle mState INIT
LLTextureFetchWorker::clearPackets
LLTextureFetchWorker::doWork: Handle mState LOAD_FROM_TEXTURE_CACHE
LLTextureFetchWorker::doWork: Handle mState SEND_HTTP_REQ
LLTextureFetch::getHTTPQueueSize
LLTextureFetch::getTextureBandwidth
LLTextureFetch::removeFromNetworkQueue
LLTextureFetch::addToHTTPQueue
HTTPGetResponder::HTTPGetResponder
LLTextureFetchWorker::doWork: Handle mState WAIT_HTTP_REQ
LLTextureFetch::getFetchState: Fetch state = 7
LLTextureFetchWorker::setImagePriority, priority = 1.018e+006
LLTextureFetch::getRequestFinished: Request finished = 0
HTTPGetResponder::completedRaw
LLTextureFetch::removeFromHTTPQueue
LLTextureFetchWorker::callbackHttpGet
HTTPGetResponder::~HTTPGetResponder
LLTextureFetch::getFetchState: Fetch state = 8
LLTextureFetchWorker::doWork: Handle mState DECODE_IMAGE
Push a DecodeResponder() on the LLImageDecodeThread
LLTextureFetchWorker::doWork: Handle mState DECODE_IMAGE_UPDATE
LLTextureFetchWorker::doWork: Handle mState DONE
LLTextureFetchWorker::finishWork, param = 0, completed = 1
LLTextureFetchWorker::endWork, param = 0, aborted = 0
LLTextureFetch::deleteRequest()
LLTextureFetch::removeRequest()
LLTextureFetch::removeFromNetworkQueue()
LLTextureFetchWorker::deleteOK
LLTextureFetchWorker::~LLTextureFetchWorker
LLTextureFetchWorker::clearPackets
</pre>

==== LLTextureCache ====
The LLTextureCache thread takes care of saving and loading image files on the local file system, aka "cached" files as those files are supposed to be downloaded from SL servers or other web resources (e.g. Amazon S3). Note that in fact, some of those "cached" files are downloaded at install time with the application bundle so they are not truly "cached" but, heck... This thread allows the rest of the viewer application to request image files using file names, URLs or UUIDs transparently and rely on the LLTextureCache thread to load the cached version if it has already been downloaded.

Note: in the current implementation, images that are fetched using an HTTP URL are never cached on the local system. For this to work, we would need a convention to convert URLs to local file name (using a parsing convention) and there's no such system in place yet. Besides, the system would have to handle obsolete files, modified files, etc... There is however a system to convert UUIDs into local file name through LLTextureCache::getLocalFileName(). For the moment though, we do not create a UUID for each HTTP fetched texture so this caching system is not usable in that case.

The LLTextureCache thread is a worker thread (like almost all other threads in the viewer) meaning that it is started at launch and keeps running for the whole life time of the application. It handles "work orders" through a pooled list of objects types LLTextureCacheWorkers. There are actually 2 flavors of this worker:
* LLTextureCacheRemoteWorker
* LLTextureCacheLocalFileWorker: used to load local files (which file names start in "file://"), all UI textures are loaded using that worker.

One or the other flavor is created when the cache is queried through a readFromCache() call on the LLTextureCache thread. This call is done by an LLTextureFetchWorker object in the LLTextureFetch thread. For the moment, such calls are done only for local files (file name starting with "file://") and for files known only by their UUID. Files known by an "http://" URL are not hitting that call at all.

To load a local file (UI texture for instance), the sequence of calls is as follow:
<pre>
LLTextureFetchWorker::CacheReadResponder::CacheReadResponder:()
LLTextureCache::readFromCache()
LLTextureCacheLocalFileWorker::LLTextureCacheLocalFileWorker()
LLTextureCacheWorker::read()
LLTextureCacheWorker::startWork()
LLTextureCacheLocalFileWorker::doRead() // loads the entire file using LLAPRFile::readEx()
LLTextureCacheWorker::finishWork()
LLTextureCache::ReadResponder::setData: setData: imagesize = 1068, imagelocal = 1
LLTextureCache::addCompleted()
LLTextureFetchWorker::CacheReadResponder::completed: CacheReadResponder::completed() // will lock the fetch queue and transfer the image
LLTextureFetch::lockQueue()
LLTextureFetch::unlockQueue()
LTextureCacheWorker::endWork()
LLTextureCacheWorker::~LLTextureCacheWorker()
LLTextureFetchWorker::DecodeResponder::DecodeResponder:()
LLTextureFetchWorker::DecodeResponder::completed:()
LLTextureFetch::lockQueue()
LLTextureFetch::unlockQueue()
LLTextureCache::readComplete()
</pre>

==== LLImageDecodeThread ====
This thread is used in http texture to decompress the image texture once the raw image has been downloaded. If you're trying to get familiar with threads in the viewer, it's interesting to read that code in detail as it is short and gives a good overview of how the various objects involved in thread signaling work in the viewer. You'll see thread, requests, mutex and responders in action in 150 or so lines of code.

There's only one mutex (mCreationMutex) and one list (mCreationList) in the class. All access (read or write) to the mCreationList are guarded by mutex locking/unlocking. The list is a temporary buffer of data used to instantiate requests on the queued thread. Requests are then processed in order and the responder called when done.

Computations performed on the requests themselves are not guarded by mutexes as no one access the request data but the decoding thread. Once a work order is done, its result is made accessible to the calling thread by calling a responder.

Here's a detailed narrative of how things work:
* LLTextureFetchWorker::doWork(): when the worker reaches the (mState == DECODE_IMAGE) state, a call to decodeImage() on the LLImageDecodeThread is made.
* As part of the call, a pointer to a newly created DecodeResponder object is passed. This responder will be called once the decoding is complete.
* That call to decodeImage() pushes a new record on the mCreationList in the LLImageDecodeThread. The mCreationMutex is locked/unlocked for this call.
* At that point, no decoding code proper is really done or even started, there's just a record for a decoding request on the list. The request itself is not created either.
* The decodeImage() call returns to the LLTextureFetch thread and the state of the worker is changed to (mState == DECODE_IMAGE_UPDATE)
* For all subsequent LLTextureFetchWorker::doWork() calls, the worker will check the mDecoded flag which will be switched to true only when the responder's completed() method will be called by the LLImageDecodeThread thread.
* During that time, the LLImageDecodeThread continues processing:
** The way LLQueuedThread are implemented, they run an infinite loop and wait on condition. The main thread calls update() over and over updating the condition and making sure the processing thread gets some action (unless the thread is paused or idle but, let's not make things too complicated in this story, let's just assume the thread is running).
** LLImageDecodeThread::update() is called, locks the list again and iterates through it.
** For each record in that list, a new ImageRequest object is instantiated and is added to the queue using addRequest().
** The generic LLQueuedThread code then calls LLImageDecodeThread::processRequest() and LLImageDecodeThread::finishRequest().
** LLImageDecodeThread::processRequest() performs the actually decompression and decoding of the image data.
** LLImageDecodeThread::finishRequest() does some basic clean up and calls the responder's completed() method that will flip the mDecoded flag in the fetch worker.

For another view of that thread, you can take a look at its unit test in indra/llimage/tests/llimageworker_test.cpp. This unit test exercises the thread class in both a threaded and non threaded way.

==== LLLFSThread ====
The LLLFSThread (LFS stands for "Local File System") is used to queue file access on the client machine. It can be used to both load and save data on the local file system.

In the case of texture loading, it's used to read images from the cache if the USE_LFS_READ compilation option is set (which is not set by default).

By default (USE_LFS_READ not defined), the image files are loaded using LLAPRFile which is a wrapper class around the Apache file access facility.

== Links ==
Intro to threads and mutexes:
* [http://www.ibm.com/developerworks/library/l-posix1.html Threads]
* [http://www.ibm.com/developerworks/library/l-posix2/ Mutex]
* [http://www.ibm.com/developerworks/library/l-posix3/ Condition Variables]

== Jira Issues ==

New Jira Issues
{|
|}

Pre-existing Jira Issues
{|
{{Issue|VWR-8473|type=fs|Add a menu choice to force re-download of ruthed avs, missing textures or shapes}}
{{Issue|SVC-3446|type=fs|Ability to load textures on prim faces via http/https, as well as, for sculpt maps}}
{{Issue|VWR-217|type=fs|New Feature -> LSL -> Dynamic Web Textures}}
|}

== Development of this feature ==

As of this writing (2009-03-30), development on this branch is being done in the [http://svn.secondlife.com/trac/linden/browser/projects/2009/http-texture http-texture branch on svn.secondlife.com]. See [[HTTP Texture Development]] for more information about contributing

[[Category:Open Source Portal]]
[[Category:Linden Lab Projects]]

File:TextureWorkers20090520.png

2009-05-21T01:47:03Z

Sheet Spotter: Simplified class diagram for the worker classes used by the texture threads in the HTTP-Texture branch. Some variable names from the source code have been renamed in the diagram to simplify the explanation.

Simplified class diagram for the worker classes used by the texture threads in the HTTP-Texture branch. Some variable names from the source code have been renamed in the diagram to simplify the explanation.

File:TextureThreads20090520.png

2009-05-21T01:45:14Z

Sheet Spotter: Simplified class diagram for the thread classes used in the HTTP-Texture branch. Some variable names from the source code have been renamed in the diagram to simplify the explanation.

Simplified class diagram for the thread classes used in the HTTP-Texture branch. Some variable names from the source code have been renamed in the diagram to simplify the explanation.

Limits

2008-08-31T19:35:39Z

Sheet Spotter: Added 'Max. length of avatar name'

{{Help
|BugFixes=
|Avatar=
|Object=
|Land=
|Community=
|Viewer=
|Communication=
|Multimedia=
|Navigation=
|Misc=*
|Description=
|Wiki=
|Glossary=*
}}

This page is an easy reference to common queries about '''Second Life limits'''. Some of these will almost definitely change over time, so if you spot something incorrect/outdated, please take a moment to update it. Also see the [http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=5480 Knowledge Base counterpart of this article].

== Building ==
* '''Max. prim dimensions (non-megaprim)''' - 10x10x10 m
* '''Min. prim dimensions''' - 0.01x0.01x0.01 m
* '''Max. # of prims in a linkset''' - 255
* '''Max. link distance''' - See [[Linkability Rules]].
* '''Max. # of prims in a physical object''' - 32
** If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
** Note that this limit includes the driver and passengers of physics-enabled vehicles, e.g. if you are making a car to sit 4 people, 28 prims are available for the car itself.
* '''Max. build height''' - 4,096 m (SL 1.20.x or later required)
** This is 768 m for viewers prior to SL 1.20.x

== Avatar ==
* '''Max. # of attachment points''' - 30 for avatar, 8 for HUD.
** They can be viewed in Edit menu > Detach Object.
* '''Max. unassisted fly height''' - Stable hover almost 150 m above the ground (terrain mesh).
** While an improvement over the previous limit of 50 m, Torley thinks this limit is ridiculous because Second Life is 3D. You can easily acquire a flight attachment to fly up to seemingly infinite heights.
* '''Common shoe sizes''' - Most women's shoes are designed for a size 0 (zero) foot. Men's generally scale up to 14. You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.
* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 for total (including the space).

== Chat (text) ==
* '''Whisper distance (done via scripting objects)''' - 10 m
* '''Chat distance''' - 20 m
* '''Shout distance''' - 100 m
** Rule of thumb: when you're at default zoom (View menu > Reset View), if you can see another other person's nametag, they can see your chat. If they're far enough away that you don't see a nametag, they won't "hear" you unless you shout.
* '''Max. length of a chat message''' - 1023 bytes/single-byte characters
** The same holds true for an IM<->email replies.

== Groups ==
* '''Max. # of groups you can belong to''' - 25
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Min. # of members in a group''' - 2
** A group with only 1 person for 48 hours will be disbanded (cancelled).
* '''Max. # of roles allowed in a group''' - 10 (including "Owners" and "Everyone", which can't be deleted)

== Inventory ==
* '''Max. # of inventory items that can be sent in a folder''' - 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references. ;)

== Land ==
* '''Max. parcel size''' - 65,536 m2
** Covering a whole region, or square on the World Map.
* '''Min. parcel size''' - 16 m2
* '''Max. "NO ENTRY" ban line height''' - 768 m above the terrain mesh.
** This is if you're explicitly banned from a parcel. If the parcel is simply not public access or restricted to certain Residents/a group, then the access lines go up to 50 m above the terrain mesh.
* '''Max. prims in a region''' - 15,000 (3,750 prims for an [http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=4235 Openspace] region) <== (July 6, 2008) This limit for openspace sims is an intended limit, however due to a bug in the object bonus option the limit is currently unlimited. Using more than 3750prim on an openspace is still unadvisable because the sim performance decreases rapidly with the extra prims. Some openspace sims have been reported to hold 18000+ prims momentarily before crashing.
* '''Max. Autoreturn value''' - besides "0" (which means: ''never''), 999,999 minutes is the biggest autoreturn value.
* '''Terraforming limits''' - Almost all mainland can be raised/lowered by +/-4 m. Estate (private island) terraformability is settable to a max of +/-100 m by the estate owner or managers. Bay City regions cannot be terraformed, and there may be others.--[[User:Shadoe Landman|Shadoe Landman]] 13:07, 6 July 2008 (PDT)
** A few, very old regions like Da Boom have a terraform range of +/-40 m.
* '''Max. water height''' - 100 m
** Region water height is usually 20 m, and adjacent regions should have the same water height, or else they'll look discontinuous.
* '''Misc. estate limits''' - You can have a max. of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Mainland max. # of agents''' - 40 avatars/region
* '''Island max. # of agents''' - 100 avatars/region

== Performance ==
* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via Help menu > Lag Meter, or for more advanced usage, see View menu > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [http://blog.secondlife.com/2008/05/01/who-me-yes-you-couldnt-be-then-who-introducing-avatar-rendering-cost/ Learn all about it!]

== Scripting ==
For specific scripting limits, lookup calls in the [[LSL Portal]].

== Textures ==
* '''Aspect ratios''' of profile, place, etc. pictures — all of these were measured at UI size = 1.000:
** '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256x192 pixels)
** '''Search > Places and Classified tabs''' - ~7:5 (398x282 pixels)
** '''Search > Land tab''' - ~7:5 (358x252 pixels)
** '''Profile > 2nd Life tab''' - ~4:3 (178x133 pixels)
** '''Profile > Picks tab''' - ~16:9 (288x162 pixels)
** '''Profile > 1st Life tab''' - 1:1 (133x133 pixels)
** '''Profile > Classifieds tab''' - ~3:2 (206x137 pixels)
** '''Profile > Web tab''' - 1:1 (400x400 pixels) Note Scrollbars will eat 15 pixels
** '''About Land > Options tab''' - ~3:2 (178x117 pixels)
** '''Group Information > General tab's "Group Insignia"''' - 1:1 (126x126 pixels)
''Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you will want to pick a happy medium ratio and use enough pixels to fill the larger panels without too much blur.''

* '''Maximum texture size''' - 1024x1024 pixels
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.

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

Open Source Meeting/2008-08-21

2008-08-22T00:00:46Z

Sheet Spotter: Corrected formatting problem at [14:40]

* [14:01] [[User:Squirrel Wood|Squirrel Wood]]: quick question.... the SL client gets stuck at the region handshake when I try to log in from work... what can I do about it?
* [14:01] [[User:Rob Linden|Rob Linden]]: thanks Michelle2 for the agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
* [14:02] [[User:Carjay McGinnis|Carjay McGinnis]]: where's the soft one?
* [14:02] [[User:Rob Linden|Rob Linden]]: Squirrel....not sure, probably a firewall issue
* [14:02] [[User:Q Linden|Q Linden]]: squirrel, guessing it's a port problem?
* [14:02] [[User:Squirrel Wood|Squirrel Wood]]: It gets past the login. just the handshake fails
* [14:03] [[User:Rob Linden|Rob Linden]]: I'll (eventually) be posting the transcript from this meeting on the wiki, so bear that in mind while you type
* [14:03] [[User:Carjay McGinnis|Carjay McGinnis]]: so the xmlrpc part works?
* [14:03] [[User:Squirrel Wood|Squirrel Wood]]: I would assume it does
* [14:04] [[User:Rob Linden|Rob Linden]]: pinged Soft, but we can probably get started
* [14:04] [[User:Rob Linden|Rob Linden]]: 1. Discussion of Trunk branch, build issues, updates on 1.21's QA progress etc Michelle2 Zenovka 08:58, 21 August 2008 (PDT)
* [14:04] [[User:Rob Linden|Rob Linden]]: (this is a Soft-centric issue, though)
* [14:04] [[User:Liana Linden|Liana Linden]]: Hey, folks. Can the rest of you see the agenda up on the big screen?
* [14:04] [[User:Carjay McGinnis|Carjay McGinnis]]: thus the question for the soft one
* [14:05] [[User:Siddhartha Fonda|Siddhartha Fonda]]: where is it
* [14:05] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: not yet, not showing web media on parcel
* [14:05] [[User:Harleen Gretzky|Harleen Gretzky]]: yes, the hand
* [14:05] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: can see it.
* [14:05] [[User:Siddhartha Fonda|Siddhartha Fonda]]: oh
* [14:05] [[User:McCabe Maxsted|McCabe Maxsted]]: I can, but the text's pretty tiny
* [14:05] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: ther eit goes
* [14:05] [[User:Liana Linden|Liana Linden]]: Click "play" on your media control panel.
* [14:05] [[User:Siddhartha Fonda|Siddhartha Fonda]]: gotcha
* [14:05] [[User:Siddhartha Fonda|Siddhartha Fonda]]: yeah see it now
* [14:05] [[User:Carjay McGinnis|Carjay McGinnis]]: only a big hand
* [14:05] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: if you zoom it its fine
* [14:05] [[User:Carjay McGinnis|Carjay McGinnis]]: oh, it turns black
* [14:06] [[User:Carjay McGinnis|Carjay McGinnis]]: ah, now, cool
* [14:06] [[User:Liana Linden|Liana Linden]]: Great. Sorry to interrupt, Rob.
* [14:06] [[User:Rob Linden|Rob Linden]]: can't see it acutally...but that's ok
* [14:07] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: 3 points.. 2 defaults
* [14:07] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: I rasied this issue to see if anyone else was still having any general issues with cmake and to get an inside update on progress of the branch
* [14:07] [[User:Thomas Shikami|Thomas Shikami]]: Greetings
* [14:07] [[User:Carjay McGinnis|Carjay McGinnis]]: inside update sounds nice
* [14:08] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: We had the little struct issue with gcc 4.3.1 which i fogot to tell anyone about, and cmake 2.6.2 but i think things from outside are basicly working
* [14:08] [[User:Carjay McGinnis|Carjay McGinnis]]: that was fixed already if I saw correctly
* [14:08] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: can't remember if fmod mess got resolved
* [14:08] [[User:Rob Linden|Rob Linden]]: Soft is on his way. I don't think there's any big updates, though
* [14:08] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yes soft pushed an immediate fix then is going to clean it up again later
* [14:09] [[User:Thomas Shikami|Thomas Shikami]]: isn't cmake 2.4.x used?
* [14:09] [[User:Carjay McGinnis|Carjay McGinnis]]: it's always intriguing how many weird things are accepted by the microsoft compiler
* [14:09] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: thats the offical supported version
* [14:09] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: 2.6.0 and 2.6.1 don't work correctly but there is a 2.6.2-RC on cmake.org/files that does work
* [14:09] [[User:Rob Linden|Rob Linden]]: Soft: we're on 1. Discussion of Trunk branch, build issues, updates on 1.21's QA progress etc Michelle2 Zenovka 08:58, 21 August 2008 (PDT)
* [14:09] [[User:Carjay McGinnis|Carjay McGinnis]]: greetings Soft
* [14:09] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Hey soft
* [14:09] [[User:Soft Linden|Soft Linden]]: Hey hey
* [14:10] [[User:Thomas Shikami|Thomas Shikami]]: and sorry if I'm asking the obvious, sometimes people just forget about the trivial stuff and then wonder, why something doesn't work
* [14:10] [[User:Aimee Trescothick|Aimee Trescothick]]: (Would putting the prim on fullbright make the agenda clearer to read?)
* [14:10] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Thomas: you mean the cmake versions?
* [14:10] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: shakes his head.. "It's light enough in daylight.. Fontype is just too small.
* [14:11] [[User:Thomas Shikami|Thomas Shikami]]: yes, that's an example
* [14:11] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yea cmake 2.6.2-rc is not widely enough known about
* [14:11] [[User:McCabe Maxsted|McCabe Maxsted]]: is the build page on the wiki updated?
* [14:11] [[User:Rob Linden|Rob Linden]]: I'm still puttering along on this spec: https://wiki.secondlife.com/wiki/User:Rob_Linden/Build_Tool_Improvement_Spec_-_2008. I've got some feedback that I still need to incorporate
* [14:12] [[User:Rob Linden|Rob Linden]]: ..but that's going to be a while to go from spec to code
* [14:12] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: I don't think anyone has that cmake issue up anywhere yet, i can add it to my page which is also referenced alot
* [14:12] [[User:Carjay McGinnis|Carjay McGinnis]]: we need a agenda HUD
* [14:14] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: would be handy yes..
* [14:14] [[User:Rob Linden|Rob Linden]]: Soft, is there any short term stuff that's going to be useful for folks to know about here vis a vis build improvements?
* [14:15] [[User:Rob Linden|Rob Linden]]: can't think of anything
* [14:15] [[User:Soft Linden|Soft Linden]]: Michelle's page is actually the best. I'd be happy if we base our official 1.21 build instructions off of hers
* [14:15] [[User:Rob Linden|Rob Linden]]: ah, yes, instructions=good
* [14:15] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: I though Rob's was a rewrite of mine
* [14:15] [[User:Soft Linden|Soft Linden]]: I believe we're running out of surprises now, though.
* [14:15] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Timescales?
* [14:15] [[User:Soft Linden|Soft Linden]]: I'm sorry - I think I misunderstood the question. The existing build improvements I'm talking about, not the proposed stuff.
* [14:16] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i'm kind of talking about 1.21 hitting RC
* [14:16] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: in conjunction with the build improvments that will be live
* [14:17] [[User:Rob Linden|Rob Linden]]: 1.21 RC should be real soon now. the 1.24 server deploy was the main blocker for that I believe
* [14:17] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: 1.21 has mono compile too?
* [14:17] [[User:McCabe Maxsted|McCabe Maxsted]]: I've been having a lot of crashes with 1.21; I assume that's due to the extra debug stuff, yeah?
* [14:17] [[User:Carjay McGinnis|Carjay McGinnis]]: ok, was already wondering why things got so quiet recently
* [14:17] [[User:Soft Linden|Soft Linden]]: 1.21 will be very close to what you see in release right now. Yes, mono compile should be there.
* [14:17] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: cool
* [14:17] [[User:Soft Linden|Soft Linden]]: release/ - now trunk/
* [14:18] [[User:Aimee Trescothick|Aimee Trescothick]]: mono tick box is there in trunk now
* [14:18] [[User:Aimee Trescothick|Aimee Trescothick]]: :)
* [14:18] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i've not actualy been running trunk only building it, lol
* [14:18] [[User:Aimee Trescothick|Aimee Trescothick]]: lol
* [14:18] [[User:Carjay McGinnis|Carjay McGinnis]]: still waiting for the python tick box
* [14:18] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: ha
* [14:18] [[User:McCabe Maxsted|McCabe Maxsted]]: hehe
* [14:18] [[User:Rob Linden|Rob Linden]]: you'll have to forgive future confused Lindens....internally, "trunk" is still the "release" branch
* [14:19] [[User:Thomas Shikami|Thomas Shikami]]: still looking for a mono tick box for agent inventory compile
* [14:19] [[User:Soft Linden|Soft Linden]]: Hopefully we remedy that. Release as three different things in concept, name and target is just silly.
* [14:19] [[User:Rob Linden|Rob Linden]]: ....though those of us who have suggested renaming the internal "release" branch have gotten many +1s
* [14:20] [[User:Carjay McGinnis|Carjay McGinnis]]: do it on a quiet lonely night
* [14:20] [[User:Carjay McGinnis|Carjay McGinnis]]: and then take a long vacation
* [14:20] [[User:Soft Linden|Soft Linden]]: Ha :>
* [14:20] [[User:Carjay McGinnis|Carjay McGinnis]]: when you return everything will have worked itself out
* [14:20] [[User:Soft Linden|Soft Linden]]: The blocking thing is that it will complicate a lot of existing branches merging back into trunk.
* [14:21] [[User:Soft Linden|Soft Linden]]: We're pushing to move off of subversion, so it's been proposed that if we do that in the near future, we do the rename then as well.
* [14:21] [[User:Carjay McGinnis|Carjay McGinnis]]: well, we had so many weird issues due to renaming things in svn
* [14:21] [[User:Soft Linden|Soft Linden]]: Exactly.
* [14:21] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yea i can't believe sub version is holding up with the amout of branching and sub development you do, it must be a merge nightmare
* [14:21] [[User:Rob Linden|Rob Linden]]: k....anything else we need to discuss on item #1, or can we move on?
* [14:21] [[User:Q Linden|Q Linden]]: startles awake, screaming
* [14:22] [[User:Rob Linden|Rob Linden]]: :)
* [14:22] [[User:Rob Linden|Rob Linden]]: next up: 2. Any directly related to secondlife, opensource projects anyone wants yo update on (i have one hence my item) Michelle2 Zenovka 11:01, 21 August 2008 (PDT)
* [14:22] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: well firsly i wanted to bring up the debian package of the viewer..
* [14:23] [[User:Rob Linden|Rob Linden]]: do tell
* [14:23] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Mozilla has finally bitten and hard, one of the critical libs has vanished from debianb testing and unstable and now i have massive ABI breakage on xulrunner
* [14:23] [[User:Carjay McGinnis|Carjay McGinnis]]: oh, you were unable to find it?
* [14:24] [[User:Rob Linden|Rob Linden]]: I had heard from Callum that the 1.8 to 1.9 transition was practically a rewrite for these purposes
* [14:24] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: even if i do i now have to fork debian and ubuntu
* [14:24] [[User:Carjay McGinnis|Carjay McGinnis]]: yikes :-/
* [14:24] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: ubuntu froze months ago and has the lib, testing is freezing now and does not
* [14:24] [[User:Rob Linden|Rob Linden]]: (Mozilla 1.8 to 1.9)
* [14:24] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yea its a laugh and a half
* [14:24] [[User:Carjay McGinnis|Carjay McGinnis]]: that's silly
* [14:24] [[User:Rob Linden|Rob Linden]]: (which is the engine for Firefox 2 and Firefox 3 respectively)
* [14:25] [[User:Soft Linden|Soft Linden]]: So ubuntu has it, but likely won't have it in the next release. Debian loses it sooner.
* [14:25] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: its going to come down to me hosting a version of the package
* [14:25] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: and if i do that i might just as well fall back to the "linden" way of packaging mozilla
* [14:26] [[User:Rob Linden|Rob Linden]]: we've had some hiccups with our webkit evaluation, but we're still coming around to the idea that that's the way forward
* [14:26] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i think we were hoping that something may have appeared even as development code
* [14:26] [[User:Carjay McGinnis|Carjay McGinnis]]: huccups?
* [14:26] [[User:Carjay McGinnis|Carjay McGinnis]]: -u+i
* [14:27] [[User:Rob Linden|Rob Linden]]: I can't really go into details. at any rate, we do have some code that I think we should be able to publish
* [14:27] [[User:Rob Linden|Rob Linden]]: ...but it still needs A LOT of work
* [14:27] [[User:Aimee Trescothick|Aimee Trescothick]]: (hiccips?)
* [14:27] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: well if its published you can start to get patches ;-)
* [14:28] [[User:Carjay McGinnis|Carjay McGinnis]]: still, that does not sound good
* [14:29] [[User:Rob Linden|Rob Linden]]: I think there's reasons to be optimistic still
* [14:29] [[User:Rob Linden|Rob Linden]]: at any rate....were there other updates you had Michelle2?
* [14:29] [[User:Carjay McGinnis|Carjay McGinnis]]: ok, taking your word on it
* [14:29] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Yea my other side project
* [14:29] [[User:Carjay McGinnis|Carjay McGinnis]]: ;)
* [14:30] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i've been working on my own text client
* [14:30] [[User:Rob Linden|Rob Linden]]: oh, cool
* [14:30] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: just though i would announce, its pretty functional, based on Gtk# and mono
* [14:30] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: mainly because everone else uses dam winforms and latest version is not mono compatible yet
* [14:31] [[User:Rob Linden|Rob Linden]]: libsecondlife for the protocol handling, then?
* [14:31] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yes
* [14:32] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: [http://www.byteme.org.uk/secondlife/omvviewer-light.html] for details
* [14:33] [[User:Rob Linden|Rob Linden]]: nice
* [14:33] [[User:Carjay McGinnis|Carjay McGinnis]]: yeah, looks promising
* [14:33] [[User:Rob Linden|Rob Linden]]: presumably will run on windows, as well, I take it
* [14:34] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: yes, but you need to e mono Gtk# package
* [14:34] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: * the mono...
* [14:34] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: its quite cool i develop in VC# at work and monodevelop at home
* [14:34] [[User:Scotts Winkler|Scotts Winkler]]: hey rob, everyone
* [14:34] [[User:Scotts Winkler|Scotts Winkler]]: late :)
* [14:35] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: I heard a rumor about the lindens own text client with voice support
* [14:36] [[User:Rob Linden|Rob Linden]]: LIES LIES!
* [14:36] [[User:Rob Linden|Rob Linden]]: shrugs
* [14:36] [[User:Carjay McGinnis|Carjay McGinnis]]: greetings Scotts
* [14:36] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: not in braille writing either ? :|
* [14:36] [[User:Siglor Nootan|Siglor Nootan]]: yay i found lindens!
* [14:37] [[User:Rob Linden|Rob Linden]]: Michelle2 (or anyone else) updates on other open source packages?
* [14:38] [[User:Rob Linden|Rob Linden]]: (wind blowing)
* [14:39] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: It was just that from me
* [14:39] [[User:A group|A group]]: member named Bridie Linden gave you don't be a d*ck.
* [14:39] [[User:Rob Linden|Rob Linden]]: okee dokee, next item:
* [14:40] [[User:Soft Linden|Soft Linden]]: Joe announced a bit on that - you can probably google for articles about it to see what's there. I haven't followed that project myself.
* [14:40] [[User:Rob Linden|Rob Linden]]: urgh....not sure if it's appropriate, though: [[User:Bau Ur|Bau Ur]] Discussion of http://jira.secondlife.com/browse/VWR-4094 Ability of persons banned from parcel to build and script at elevation of 800 M over the parcel; also persons banned from a parcel may overhang their objects from an adjoining parcel. This is of considerable concern to sandbox users and sandbox admins trying to provide a good environment for new creators in SL. Lindens involved in governance, community development and resident retention may be interested.
* [14:40] [[User:Carjay McGinnis|Carjay McGinnis]]: was wondering about that one
* [14:40] [[User:Thomas Shikami|Thomas Shikami]]: should be 4096m
* [14:40] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: what is open source about that one ?
* [14:40] [[User:Liana Linden|Liana Linden]]: Bau pinged me earlier with an agenda item, and I directed him to post to the wiki. Didn't know what it was about. Is there a better venue for this question?
* [14:40] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: its not really open source
* [14:41] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: should be handled by G Team, i find *shrug*
* [14:41] [[User:Rob Linden|Rob Linden]]: it's a governace thing
* [14:41] [[User:Rob Linden|Rob Linden]]: Governance, even
* [14:41] [[User:Soft Linden|Soft Linden]]: That's a good topic for the Monday triage. It's already imported, but if it deserves additional weight, that would be a good place to make the argument.
* [14:42] [[User:Thomas Shikami|Thomas Shikami]]: physics team and server programmers
* [14:42] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i think we have been around the loops with this type of discussion of over hanging prims etc more than once and as you said there is nothign we can do here, we can't patrch the viewer etc
* [14:42] [[User:Liana Linden|Liana Linden]]: I'll reply to Bau and direct him to the Monday triage and/or a governance Linden. Thanks.
* [14:42] [[User:Rob Linden|Rob Linden]]: ah, I see, yeah. that issue should probably also be moved to SVC.
* [14:42] [[User:Rob Linden|Rob Linden]]: anyhoo
* [14:42] [[User:Carjay McGinnis|Carjay McGinnis]]: redirects to SVC-2900 which is assigned to thekellz
* [14:42] [[User:Carjay McGinnis|Carjay McGinnis]]: that redirect is nice
* [14:42] [[User:Carjay McGinnis|Carjay McGinnis]]: it never shows the VWR-page
* [14:43] [[User:Rob Linden|Rob Linden]]: oh, would you look at that
* [14:43] [[User:Soft Linden|Soft Linden]]: Yeah. I moved that earlier.
* [14:43] [[User:Soft Linden|Soft Linden]]: - ninja.
* [14:43] [[User:Rob Linden|Rob Linden]]: yeah, I didn't even notice. ok. anything else we should talk about here
* [14:43] [[User:Rob Linden|Rob Linden]]: ?
* [14:44] [[User:Rob Linden|Rob Linden]]: Hippo awards coming soon
* [14:44] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: wooot
* [14:44] [[User:Liana Linden|Liana Linden]]: Yep. Will be announced on Sat 9/6.
* [14:44] [[User:Liana Linden|Liana Linden]]: At SLCC and right here inworld.
* [14:44] [[User:Rob Linden|Rob Linden]]: thinks through other things to discuss....
* [14:44] [[User:Liana Linden|Liana Linden]]: Email about that comming soon to sldev.
* [14:44] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: sighs and thinks thats the 6/9 to all Europeans , lol
* [14:45] [[User:Liana Linden|Liana Linden]]: Sorry, I usually spell out the month just for that reason. Sept 6 at noon Pacific Time.
* [14:45] [[User:Thomas Shikami|Thomas Shikami]]: Set. Sep. 6?
* [14:45] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: it's sep 6th to us all .
* [14:45] [[User:Rob Linden|Rob Linden]]: careful or I'll go all ISO on your *** ;-)
* [14:45] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: laughs, only being difficult
* [14:45] [[User:Carjay McGinnis|Carjay McGinnis]]: 6.9.
* [14:45] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: lol
* [14:45] [[User:Rob Linden|Rob Linden]]: 2008-09-06 .... there
* [14:45] [[User:Nyx Linden|Nyx Linden]]: 2008-09-06
* [14:46] [[User:Aimee Trescothick|Aimee Trescothick]]: prefers 20080906
* [14:46] [[User:Liana Linden|Liana Linden]]: In any case, if you're not at SLCC, please join me here at that time and date to hear the announcement of winners.
* [14:46] [[User:Soft Linden|Soft Linden]]: 2008-09-06
* [14:46] [[User:Soft Linden|Soft Linden]]: Yis
* [14:46] [[User:Carjay McGinnis|Carjay McGinnis]]: what do you do in the year 20080?
* [14:46] [[User:Soft Linden|Soft Linden]]: 20080-09-06
* [14:46] [[User:Aimee Trescothick|Aimee Trescothick]]: 200800906
* [14:46] [[User:Carjay McGinnis|Carjay McGinnis]]: yes, meant Aimee
* [14:47] [[User:Rob Linden|Rob Linden]]: in other news....
* [14:47] [[User:Rob Linden|Rob Linden]]: (I got nuthin)
* [14:47] [[User:Carjay McGinnis|Carjay McGinnis]]: that's a tooosday BTW
* [14:47] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: whot?
* [14:47] [[User:Soft Linden|Soft Linden]]: By then I'll be using full names, as my petition for January Softuary March will have passed.
* [14:47] [[User:Aimee Trescothick|Aimee Trescothick]]: rofl
* [14:47] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: no plans to open source more of the LL code ?
* [14:47] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: no roadmap .. no progress .. nada ?
* [14:47] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: you guys all been on vacation or what ? :|
* [14:48] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: smirks.
* [14:48] [[User:Squirrel Wood|Squirrel Wood]]: open can, eat sauce.
* [14:48] [[User:Soft Linden|Soft Linden]]: There's still quite a bit of new stuff appearing, but it's more related to OGP, not the everyday viewer work.
* [14:48] [[User:Rob Linden|Rob Linden]]: well, Q started last week in his lead role in Sustaining Engineering, and we've all been going over the patch list much more carefully
* [14:49] [[User:Rob Linden|Rob Linden]]: our efforts right now are mainly around detail work rather than splashy new stuff, but that's the theme in general
* [14:49] [[User:Rob Linden|Rob Linden]]: Mono is about as splashy as it gets
* [14:49] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Hmm just seen one of my JIRA patches is taged as fix pending VWR-4981
* [14:49] [[User:Squirrel Wood|Squirrel Wood]]: Mono has been in testing for quite some time though
* [14:50] [[User:Rob Linden|Rob Linden]]: we're mulling over some ways of working with regular contributors more efficiently
* [14:50] [[User:Rob Linden|Rob Linden]]: how many of you have three or more patches pending?
* [14:50] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: just curios .. since nothing has been published much on SLDEV since oct 2007 either..
* [14:51] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: pending as in "fix pending" or just out there on JIRA?
* [14:51] [[User:Rob Linden|Rob Linden]]: (as in, unresolved, not just "fix pending")
* [14:51] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i've got a handful
* [14:51] [[User:Rob Linden|Rob Linden]]: I know Aimee does as well. Carjay, I'm assuming you do too
* [14:51] [[User:Carjay McGinnis|Carjay McGinnis]]: looking, lost track a bit
* [14:52] [[User:Aimee Trescothick|Aimee Trescothick]]: waves
* [14:52] [[User:Aimee Trescothick|Aimee Trescothick]]: :)
* [14:52] [[User:Carjay McGinnis|Carjay McGinnis]]: ok, 3 unresolved, but fix pending
* [14:52] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i've got one i need to look at again, its acceped in principle, but needs another round of tidying
* [14:52] [[User:Carjay McGinnis|Carjay McGinnis]]: rest resolved or fixed
* [14:52] [[User:Rob Linden|Rob Linden]]: that's reassuring
* [14:53] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: a few of mine are things like crazy mozzila stuff which there is no real resolution
* [14:53] [[User:Rob Linden|Rob Linden]]: I think we've gotten a lot better in general, but haven't done a good job of really tracking that in a deep way
* [14:53] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: i've got one or two which are clear bug fixes that have not been applied
* [14:53] [[User:Squirrel Wood|Squirrel Wood]]: Things have improved so you are moving in the right direction ^^
* [14:53] [[User:Carjay McGinnis|Carjay McGinnis]]: aha!
* [14:53] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: nods.
* [14:54] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: Things have improved... much.. admitted..
* [14:54] [[User:Carjay McGinnis|Carjay McGinnis]]: indeed
* [14:54] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: ok .. q ?
* [14:54] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: the voice implementation .. i 'm not sure it's .. done yet
* [14:55] [[User:Rob Linden|Rob Linden]]: Michelle2: which ones are those?
* [14:55] [[User:Q Linden|Q Linden]]: Will -- what do you mean?
* [14:55] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: VWR-8194 but the fix may have bypassed JIRA as i pinged sldev on that as well (thats carjays effort too on this one)
* [14:56] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: and someone i forget who was excited about it
* [14:56] [[User:Liana Linden|Liana Linden]]: Running off to another meeting. Thanks all.
* [14:56] [[User:Soft Linden|Soft Linden]]: It's been a few weeks on that one - I can add a note pinging the Linden who owns that internally.
* [14:57] [[User:Soft Linden|Soft Linden]]: It's assigned to the right guy, he's just a very busy one.
* [14:57] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Yea its a clear buffer overrun and easy to fix
* [14:57] [[User:Carjay McGinnis|Carjay McGinnis]]: hm, actually not that easy if you want to do it properly
* [14:57] [[User:Carjay McGinnis|Carjay McGinnis]]: you'd have to write some tests for it afterwards
* [14:58] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: the proper way is to not use an artifical buffer for GL calls
* [14:58] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: may be thats the blocker? its going to be done properly with a render pipe rewrite of that section
* [14:59] [[User:Carjay McGinnis|Carjay McGinnis]]: well, the proper way is not to use immediate mode at all
* [14:59] [[User:Rob Linden|Rob Linden]]: yeah, there's definitely some rework planned in that general area
* [14:59] [[User:Rob Linden|Rob Linden]]: well, we're out of time. anything else we should cover here?
* [15:00] [[User:Rob Linden|Rob Linden]]: alright, thanks everyone!
* [15:00] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: nah, call it a night!
* [15:00] [[User:Carjay McGinnis|Carjay McGinnis]]: thanks, Rob
* [15:00] [[User:Q Linden|Q Linden]]: thanks, all
* [15:00] [[User:Michelle2 Zenovka|Michelle2 Zenovka]]: Thanks
* [15:00] [[User:Harleen Gretzky|Harleen Gretzky]]: ttfn
* [15:00] [[User:Aimee Trescothick|Aimee Trescothick]]: thank q :D
* [15:00] [[User:WiLLuMPJuH Footman|WiLLuMPJuH Footman]]: nods goodbye and retreats.
*

Open Source Meeting/Agenda

2008-06-12T20:48:54Z

Sheet Spotter:

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring items up on [[SLDev]] before or concurrently with adding them as agenda items here.

== Agenda ==

* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Texture caching, follow up from SLDEV, can we store some kind of uncompressed data etc [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:02, 5 June 2008 (PDT)
* {{jira|VWR-7531}} - Dynamic grid loading to the login panel [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:02, 5 June 2008 (PDT)
** including establishing a standard format for grid (region domain) and agent domain identifiers (see my comment in VWR-7531) [[User:Cenji Neutra|Cenji Neutra]] 09:42, 5 June 2008 (PDT)
* Puppettering - Jake gave us the source code to discuss and play.. so Discuss! (seriously, not sure if there is much if better items turn up last minute then please replace) [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:04, 5 June 2008 (PDT)
* cmake - Hows everyone finding it, build issues, other issues etc [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:06, 5 June 2008 (PDT)
*{{jira|VWR-6994}} - "Avatar Rendering Cost" blanks current hover text. [[User:Sheet Spotter|Sheet Spotter]] 13:48, 12 June 2008 (PDT)
**I would like to understand the process for assisting LL to identify and correct JIRA issues.
**For example, I added a comment to VWR-6994 to describe the cause of this problem.
***Is this the correct procedure?
***Do I need to inform someone when the cause of a problem has been identified?
**Pointing me at any existing process that a developer should follow would be appreciated.
* Next item? Your name? (sign with "<nowiki>~~~~</nowiki>" which will be converted to your name + timestamp)

Default agenda is issue triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

Open Source Meeting/Agenda

2008-06-12T20:47:59Z

Sheet Spotter:

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring items up on [[SLDev]] before or concurrently with adding them as agenda items here.

== Agenda ==

* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Texture caching, follow up from SLDEV, can we store some kind of uncompressed data etc [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:02, 5 June 2008 (PDT)
* {{jira|VWR-7531}} - Dynamic grid loading to the login panel [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:02, 5 June 2008 (PDT)
** including establishing a standard format for grid (region domain) and agent domain identifiers (see my comment in VWR-7531) [[User:Cenji Neutra|Cenji Neutra]] 09:42, 5 June 2008 (PDT)
* Puppettering - Jake gave us the source code to discuss and play.. so Discuss! (seriously, not sure if there is much if better items turn up last minute then please replace) [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:04, 5 June 2008 (PDT)
* cmake - Hows everyone finding it, build issues, other issues etc [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 08:06, 5 June 2008 (PDT)
*{{jira|VWR-6994}} - "Avatar Rendering Cost" blanks current hover text. <nowiki>~~~~</nowiki>
**I would like to understand the process for assisting LL to identify and correct JIRA issues.
**For example, I added a comment to VWR-6994 to describe the cause of this problem.
***Is this the correct procedure?
***Do I need to inform someone when the cause of a problem has been identified?
**Pointing me at any existing process that a developer should follow would be appreciated.
* Next item? Your name? (sign with "<nowiki>~~~~</nowiki>" which will be converted to your name + timestamp)

Default agenda is issue triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

LlRezObject

2007-09-22T17:37:14Z

Sheet Spotter: Added statement "Silently fails when trying to rez objects more than 10 meters away' to Caveats

{{LSL_Function/inventory|inventory|uuid=false|type=object}}
{{LSL_Function
|func_id=104|func_sleep=0.1|func_energy=200.0
|func=llRezObject|sort=RezObject
|p1_type=string|p1_name=inventory
|p2_type=vector|p2_name=pos|p2_desc=position (in region coordinates)
|p3_type=vector|p3_name=vel|p3_desc=velocity
|p4_type=rotation|p4_name=rot|p4_desc=rotation
|p5_type=integer|p5_name=param|p5_desc=[[on_rez]] event parameter and value returned by [[llGetStartParameter]] in the rezzed object.
|func_footnote=Causes a hard delay based on the mass of the object rezzed. The root of '''inventory''' is not at '''pos''' but the center of '''inventory''' is.<br/>To have the root prim at '''pos''' use [[llRezAtRoot]] instead.
|func_desc=Instantiate '''inventory''' object at '''pos''' with velocity '''vel''' and rotation '''rot''' with start parameter '''param'''
|return_text
|spec
|caveats=
*Silently fails when trying to rez objects more than 10 meters away
|constants
|examples
|helpers
|also_functions=
{{LSL DefineRow||[[llRezAtRoot]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llGetStartParameter]]|}}
{{LSL DefineRow||[[llGodLikeRezObject]]|}}
|also_tests
|also_events=
{{LSL DefineRow||[[object_rez]]|triggered when this object rezzes an object from inventory}}
|also_articles
|notes
|permission
|inventory
|negative_index
|cat1=Rez
|cat2=Object
|cat3
|cat4
}}

LlRezObject

2007-09-22T17:03:43Z

Sheet Spotter: Added explicit statement that position argument is in region coordinates

{{LSL_Function/inventory|inventory|uuid=false|type=object}}
{{LSL_Function
|func_id=104|func_sleep=0.1|func_energy=200.0
|func=llRezObject|sort=RezObject
|p1_type=string|p1_name=inventory
|p2_type=vector|p2_name=pos|p2_desc=position (in region coordinates)
|p3_type=vector|p3_name=vel|p3_desc=velocity
|p4_type=rotation|p4_name=rot|p4_desc=rotation
|p5_type=integer|p5_name=param|p5_desc=[[on_rez]] event parameter and value returned by [[llGetStartParameter]] in the rezzed object.
|func_footnote=Causes a hard delay based on the mass of the object rezzed. The root of '''inventory''' is not at '''pos''' but the center of '''inventory''' is.<br/>To have the root prim at '''pos''' use [[llRezAtRoot]] instead.
|func_desc=Instantiate '''inventory''' object at '''pos''' with velocity '''vel''' and rotation '''rot''' with start parameter '''param'''
|return_text
|spec
|caveats
|constants
|examples
|helpers
|also_functions=
{{LSL DefineRow||[[llRezAtRoot]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llGetStartParameter]]|}}
{{LSL DefineRow||[[llGodLikeRezObject]]|}}
|also_tests
|also_events=
{{LSL DefineRow||[[object_rez]]|triggered when this object rezzes an object from inventory}}
|also_articles
|notes
|permission
|inventory
|negative_index
|cat1=Rez
|cat2=Object
|cat3
|cat4
}}

LlSetTimerEvent

2007-09-09T22:09:39Z

Sheet Spotter: Adding missing comment "Passing in 0.0 stops further timer events." to the function description.

{{LSL_Function
|func_id=107|func_sleep=0.0|func_energy=10.0
|func=llSetTimerEvent|p1_type=float|p1_name=sec
|func_footnote
|func_desc=Cause the {{LSLG|timer}} event to be triggered every '''sec''' seconds. Passing in 0.0 stops further timer events.
|return_text
|spec
|caveats=*The timer event is adversely effected by [[llGetRegionTimeDilation|time dilation]] (lag).
|constants
|examples=<pre>
float gap = 2.0;
float counter = 0.0;

default
{
state_entry()
{
// Activate the timer listener every 2 seconds
llSetTimerEvent(gap);
}

touch_start(integer total_number)
{
llSay(0, "The timer stops.");
llSetTimerEvent(0);

}

timer()
{
counter = counter + gap;
llSay(0, (string)counter+" seconds have passed");
}
}
</pre>
|helpers
|also_functions={{LSL DefineRow||[[llSensorRepeat]]|}}
|also_events={{LSL DefineRow||[[timer]]|}}
|also_tests
|also_articles
|notes
|permission
|negative_index
|sort=SetTimerEvent
|cat1=Script
|cat2=Time
|cat3
|cat4
}}