Second Life Wiki - User contributions [en]

Talk:Extensible Prim Attributes from LSL

2007-02-26T04:55:58Z

Carnildo Greenacre:

This would be useful. In the interim, is the object description usable for holding meta data? This may still be sent to the client even if it's not normally visible on objects you don't own. This is the case with object names, at least. It's worth investigation. --[[User:Soft Noel|Soft Noel]] 13:30, 24 February 2007 (PST)

This would be quite useful for my raytracer work. Right now, I'm thinking of re-using the lighting parameters to carry advanced material properties: light radius can also store index of refraction, light intensity can be used for specular highlight intensity, and light falloff can store specular highlight size. --[[User:Carnildo Greenacre|Carnildo Greenacre]] 20:55, 25 February 2007 (PST)

User talk:SignpostMarv Martin/Archive/Implementing new features

2007-02-13T03:19:14Z

Carnildo Greenacre: /* Alternate Rendering Engines */

== Alternate Rendering Engines ==
* Heh, isn't SL already running on an open source 3D engine? :-) [[User:Eddy Stryker|Eddy Stryker]] 19:55, 9 January 2007
** Nope. Just saying we-do-this-and-that does not make things happen :) [[User:Andy Tir|Andy Tir]] 23:31, 11 February 2007 (PST)
*I'm probably insane to try this, but I'm working on a raytracing engine for SecondLife. If I'm lucky, it'll be able to run on current quad-core CPUs. If I'm not, it won't be usable until summer, when dual-quad systems are available. --[[User:Carnildo Greenacre|Carnildo Greenacre]] 19:19, 12 February 2007 (PST)

== Better Sound Support ==
* '''Seconded'''. [[Community Bounties#VLC instead of QuickTime]] might help. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Removing Texture Loading ==
* '''Comment''' How complete do you want this to be? I made a very quick and easy patch that prevents the client from requesting any image downloads, but in my experience it still rendered a few textures like the grass terrain and avatar hair. It sped up the framerate a lot, but didn't change the GPU requirements to run SL. If the latter is your goal you'd probably have better luck by removing shaders and disabling OpenGL extensions. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

* '''Seconded''' -- Disabling texture download/display would be a great asset to people interested in communication more than shopping/etc. [[User:Kamilion Schnook|Kamilion Schnook]]
** As long as you like the color grey :-) --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)
* '''Comment:''' As far as I was aware, libSL clients don't load textures, due to the lack of JPEG 2000 support :-P [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
** This is somewhat incorrect. libsecondlife has had JPEG2000 support for quite some time through our jasper shim called libjaspernet, and some projects use it. Most don't however, as there are few interactive GUI clients using libsecondlife. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

== Patching it so that llLoadURL opens the F1 Help Browser ==
* '''Seconded''' [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* Streaming media urls can be implemented in this manner by making use of string concatenation, e.g. <nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki> [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* The problem with this, is that doing this via serverside script is that there's only one media URL, and you'd be connecting to it with the owner's key -- What is wanted is each individual client responds with it's own key. For instance, integrating a "Who is listening in SL" to an icecast server. Each connected client supplies it's own key/name via rewriting, and a name2key/key2name DB displays each individually connected user's SL information. [[User:Kamilion Schnook|Kamilion Schnook]] 20:35 Jan 8, 2007 PST
**Using the PARCEL_MEDIA_COMMAND_AGENT, I'm told you can give each agent their own stream to listen to. So you could do the user method, or more likely, append a query string, e.g:<div style="font-size:140%;"><code class="lsl"><nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki></code></div>
**[[User:SignpostMarv Martin|SignpostMarv Martin]] 03:31, 10 January 2007 (PST)

== Adding a Avatar Local Stream Channel ==

== Peer to Peer Voice over IP using above idea, improved ==

== More efficient local cache ==
* '''Comment:''' Seronis has some good ideas on how this should be implemented. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* '''Comment:''' Definitely. One cache per region, to a configurable cap total, would be an immense load off the asset servers, and off of our poor bandwidth. [[User:Buckaroo Mu|Buckaroo Mu]] 11:30, 9 January 2007 (PST)

== [http://en.wikipedia.org/wiki/Client-To-Client_Protocol CTCP] protocol layered on IM system ==
* Bleh ? [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Command Line Interface Improvements ==

== More sophisticated IM features ==
* '''Seconded''' with a big hell yes. In a large group, it's difficult to keep track of a conversation when there is a mass exodus from the session. It's annoying having the system spam the window. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Shortcut/Link/Alias function in Inventory ==
A pure viewer based solution can "only" be a hack at best. A possible implementation could be:

#) Change the viewer, so that when a drag and drop operation is performed on a 'no-copy' item, the error is trapped
#) for each error, register the UUID of the object in a special notecard
#) When presenting the contents of a folder in the viewer, preset a mixture of the real contents and the contents of the note card
#) Hide the special notecard
#) Handle folder drops onto the avatar
#) Handle moving of the special links
#) Handle deletion of the special links
#) Handle deletion of the original 'no-copy' item

This will only a partial solution, as an scrips running on the servers will still see the real contents of the folder.

:Yea, I realized that this would really have to include a new Inventory Type ID - but do the servers do checking for type IDs? This may be something that can be done client-side with either no server-side change or only one very minor one - the assignment of a Type ID. For instance: Assume the new Inventory Type of Link, which simply stores the UUID of the original object. The simplest thing to do with them regarding copying would be to make them either no-transfer, or "delete on transfer" - they simply go away if you try to transfer them. In every other way, it behaves as a normal inventory item. [[User:Buckaroo Mu|Buckaroo Mu]] 09:15, 11 January 2007 (PST)

::This definitely could be fudged by using a series of specially named notecards (for configuration data), allowing the feature to be implemented without requiring modifications to the server
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 10:03, 11 January 2007 (PST)

:::It ''could be'' fudged with notecards - but how many hacks do you want in SL? The assignment of an additional inventory type at the server end, as far I as can tell from the viewer source, would require probably two lines of code. We need to work with LL to see if they would support this inclusion, rather than make kludges that work but are far less elegant, and may break scripts. [[User:Buckaroo Mu|Buckaroo Mu]] 16:16, 12 January 2007 (PST)

::::You're forgetting something: the servers aren't built for dynamic assets. 'Fudging' it would allow the community to decide on features and interfaces while Linden Lab make the significant changes to the server required for this to work.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 21:12, 12 January 2007 (PST)

:::::If you ''fudge'' this via notecards, serverside scrips working on inventories will see the inventory as it really is. In effect making life complicated for LSL scripts, because now they have to parse a notecard as well.
:::::[[User:Duffy Langdon|Duffy Langdon]]

== DirectX3D Hardware Acceleration ==

The OpenGL code is scattered all over the entire codebase. You'd have to abstract out all the 3D code first, it wouldn't be an improvement it would be a complete rewrite.

== GPGPU Support ==

== Multiple Monitor Support ==
* '''Seconded''' I've been wanting this since I only had one monitor :-D [[User:SignpostMarv Martin|SignpostMarv Martin]] 11:13, 10 January 2007 (PST)

== Embedded scripting language for client-side plugins ==
One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.

The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).

This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.

[[User:Duffy Langdon|Duffy Langdon]] 12:34, 10 January 2007

== Nude patch ==
It's inevitable. Any bets on how long it will be?
# Ages ago. Around about the time alpha textures for clothes were allowed. [[User:SignpostMarv Martin|SignpostMarv Martin]] 00:53, 11 January 2007 (PST)
# Do bear in mind that my mention of a possible implementation for the 'nude patch' would be akin to hallucinating, due to the also mentioned ability to run extra-stringent checks on the server side for submitted content in PG regions. [[User:SignpostMarv Martin|SignpostMarv Martin]] 01:08, 11 January 2007 (PST)

I don't think a nude patch could work anyway - the skin and clothing textures are combined on the wearer's client, then the combined texture is uploaded to the server as the single texture that appears on the avatar. That's why "rebaking" your textures on your client affects how other people see you. You could possibly just apply the same skin to everyone but you might just as well leave everyone unrezzed then ;) - Yumi Murakami

: and chase all your payig customers away ? In order for us to build our business out in SL and represent our RL business inside SL such things should never be possible therefor as this is a technical wiki and forum how to further create a better client i suggest to build as much security in the client as possible ro prevent such 'attacks' on our avatars. [[User:River Senyurt|River Senyurt]] 11:34, 12 January 2007

:: As I described in the Barriers to implementation section for this "feature", security such as this would have to be built into the server. Since the Viewer is now GPL, all it would take is for someone to remove this 'security' layer, and you're right back where you started, thus Linden Lab are highly unlikely to spend time implementing such a mechanism in the client. The method I described has benefits for both the main and teen grids anyway.

:: Aside from the odd oversight over the years (e.g. texture uploads, megaprims), all security and validation operations are executed on the server side. It fits into LL's behaviour to implement such checks on the server, and while they could, and most likely will do something alone these lines, there is unfortunately nothing you can do to stop somebody else making their client get nervous imagine you in your underwear. Or less.
:: [[User:SignpostMarv Martin|SignpostMarv Martin]] 04:18, 12 January 2007 (PST)

== Out of sight., out of mind ==

# The client has an option to prevent certain types of objects from being rendered
# Objects are addressed server-side by UUID

The client would have be made aware of the UUID of an object, categorising it as a new type of object, and a hotkey could be used to toggle the visibility.

Similarly, if a photographer or machinimaker is working in-world, the following options would be useful:

* Do not render anything other than the land owner's objects
* Do not render objects not owned by people on your friends list
* Do not render avatars on your friends list

This would enable people to deal with certain types of griefer attacks more easily, much in the same way that toggling particles on and off can be useful when particle poofers have been dropped.

[[User:SignpostMarv Martin|SignpostMarv Martin]] 15:32, 12 January 2007 (PST)

=== Visual mute ===
Maybe add Visual Mute, that makes agent's avatar and objects not rendered?
[[User:Tharkang Varayez|Tharkang Varayez]] 04:59, 13 January 2007 (PST)

== Night skies ==

I'm working on customizing the night sky. Since the sky, and especially the starfield, are strictly client-side effects, this would involve storing the data in a local file. Where would be the best place to store this, and what would be the best way to access it?

Are there any plans for things like sim-wide data storage? Such a thing would make it possible to assign per-sim or per-area skies. I figure a decent starfield would require between 8k and 16k of storage; objects like comets, planets, and the like would be much smaller. --[[User:Carnildo Greenacre|Carnildo Greenacre]] 00:48, 13 January 2007 (PST)

=== Marv's crazy thoughts ===
Rename feature to "Celestial Effects"
:''Since the effects you refer to- comets, planets, starfiled, and one assumes Aurora Borealis, as well as celestial bodies such as nebulae, pulsars, supernovas, asteroid fields etc etc, are '''effects seen in the sky''' or space''' (which is the basic definition of 'celestial'), it would make sense to make allowance for the code to be extended to provide this wider scope.''

I would suggest implementing bitTorrent (or other P2P protocol) client, putting an option in the Network tab, and adding the necessary UI elements that say "Customised Celestial Effects Server XYZ has '''n''' celestial packs available for this parcel/simulator, please select download", as well as options for saving/deleting/editing said celestial effects.

Separate bandwidth control options would be advised, although the gzipped/7zipped celestial effects packages are likely to be rather small.

Since it would be cool to have the ability to edit the celestial effects, it might make sense to implement a version control system, so once people have played around with the effects package, they could submit their take on the pack/their improvements back to the server.
* It would be useful to alert people who are using another version of the effects pack that another version has been made available

I'm going to hazard a guess that doing a mashup of CVS/SVN + bitTorrent might be a pain in the ass, but with 20k+ concurrent Resis, and filesizes of less than 16kb (adding support for procedural generation of content to help lower things further would be advised), this would make things rather efficient if it was pulled off.

Individual items of content should be made available for distribution individually- one person's comet effect might be better than another's for example.

Since these creations will involve intellectual property, I would advise enforcing a Creative Commons licensing policy from the get-go.

==== Summary ====
* Rename feature to "Celestial Effects"
* use bitTorrent or other P2P technology to distribute content
* use Version Control systems for server-side storage
* enforce Creative Commons licensing ( CC BY-NC-ND for example would mean refusing submissions back to the central storage server.
** Since multiple servers are likely to be made available, it would make sense for the following two features to be added to the servers
**# Checking to make sure someone hasn't resubmitted someone else's content as a fresh asset.
**# Allowing communication between servers to check results.
* Allow individual assets of the effects package to be modified or replaced
** An option for:
*** Always use asset X for asset type Y
*** Never use asset type Y
*** Never use assets under a specific CC license
** This would mean a single data format could be designed for things such as constellations, which could be combined with any number of celestial effects for the numerous '''Star''' asset types, rendering effects for specific subsets of the '''Star''' asset type.

=== Celestial Asset Types ===
* Stars
* Nebulae
* Comets
* Asteroids
* See [http://en.wikipedia.org/wiki/Celestial_body the Wikipedia article on celestial bodies for full list]

I'm going to stop myself short on this, as I feel this feature alone would eat up a rather large amount of the talk page and is complex enough that it should be given it's own sub-section of the wiki, [[Project:Celestial Effects]], since I have all kinds of crazy ideas in mind for this :-D

[[User:SignpostMarv Martin|SignpostMarv Martin]] 08:52, 13 January 2007 (PST)

== Implement other languages options - Dutch ==

At this moment I'm already changing my english GUI from SL client into a Dutch (nederlands) language version. So my question is if somebody is interested in this and maybe in the future, to add this in the official beta release.
Although there is still a lot of work to do.

--[[User:Crash Crabe|Crash Crabe]] 01:09, 25 January 2007 (PST)

:Although it's in an "in development" stage, I'm guessing the best place to discuss other language options would be [[User talk:SignpostMarv Martin/Sandbox/Project:Internationalisation|Project:Internationalisation]]
:[[User:SignpostMarv Martin|SignpostMarv Martin]] 03:24, 12 February 2007 (PST)

Third Party Libraries

2007-01-23T09:23:29Z

Carnildo Greenacre: Sorting out the JPEG and JPEG-2000 libraries

{{OSWikiLearnBox}}
{| border="1" cellpadding="3"
|- style="background:#ffdead;"
!Library !! Version !! Description


|-valign="top"
![http://apr.apache.org/ Apache Portable Runtime ] || 1.1.2
|A set of C functions which provide a portable and consistent interface into operating system - or simply widely useful - functionality. We primarily use it for threading and socket i/o. This is actually three packages, apr, apr-util and apr-iconv.


|-valign="top"
![http://www.boost.org/ Boost] || 1.32.0
|A set of portable C++ libraries which provide a wide set of functionality. Used primarily for tokenization.


|-valign="top"
![http://tut-framework.sourceforge.net/ TUT] || 2006-06-22
|Unit test framework based on the use of c++ meta template programming. Used to test LL libraries.


|-valign="top"
![http://developer.apple.com/quicktime/ Quicktime] || 7.13
|Used to play in-world video clips on a prim.


|-valign="top"
![http://curl.haxx.se/libcurl/ libcurl] || 7.15.1
|Handles moving data across the net in many different protocols. Used to GET/POST/PUT/DELETE web resources.


|-valign="top"
!openssl || 0.9.7c
|Provides encryption for sensitive actions such as user login


|-valign="top"
![http://www.zlib.net/ zlib] || 1.2.1
|zlib is a lossless data-compression library which is used for a variety of network i/o and file compression.


|-valign="top"
![http://www.mozilla.org/developer/ Mozilla] || 1.8.0.9
|The mozilla library handles rendering HTML in the viewer.


|-valign="top"
![http://developer.nvidia.com/page/cg_main.html CG] || ??
|cg controls some visual effects.


|-valign="top"
![http://www.opengl.org/ OpenGL] || ??
| 3D Graphics rendering engine.


|-valign="top"
![http://expat.sourceforge.net/ Expat] || 1.95.8
|XML parser.


|-valign="top"
![http://www.freetype.org/ FreeType] || 2.1.5
|Font engine.


|-valign="top"
![http://www.ijg.org/ jpeglib] || 6b
|JPEG decoder library.


|-valign="top"
![http://www.kakadusoftware.com/ KDU] || 5.2.1
|Kakadu (KDU) JPEG-2000 decoder library.


|-valign="top"
![http://xiph.org/ogg/ OGG] || 1.0.3
|Audio control.


|-valign="top"
![http://xiph.org/vorbis/ Vorbis] || 1.1.2
|Audio control.


|-valign="top"
![http://www.libsdl.org/index.php SDL] || 1.2.7
|The Simple DirectMedia Layer libraries are used for handling input and basic window/GL setup on the Linux client.


|-valign="top"
![http://www.microquill.com/smartheap/index.html Smartheap] || ??
|Memory allocation.


|-valign="top"
![http://www.speedtree.com/ Speedtree] || ??
|Controls rendering of trees that are not yet implemented.


|-valign="top"
![http://xmlrpc-epi.sourceforge.net/ xmlrpc-eip] || 0.51
|Controls the XML-RPC protocol.


|-valign="top"
!OpenJPEG || 1.0
|An open-source JPEG-2000 library; a slower alternative to Kadaku


|-valign="top"
!Glib || 2.0.0
|??


|-valign="top"
![http://www.gtk.org/ GTK+] || ??
|'Native' UI components on the Linux client.


|-valign="top"
![http://sourceforge.net/projects/elfio/ ELFIO] || ??
|Enhanced stacktrace information on the Linux client.


|-valign="top"
!Mesa || 6.2.1
|??

|}

Third Party Libraries

2007-01-23T09:21:58Z

Carnildo Greenacre: Purpose of OpenSSL

{{OSWikiLearnBox}}
{| border="1" cellpadding="3"
|- style="background:#ffdead;"
!Library !! Version !! Description


|-valign="top"
![http://apr.apache.org/ Apache Portable Runtime ] || 1.1.2
|A set of C functions which provide a portable and consistent interface into operating system - or simply widely useful - functionality. We primarily use it for threading and socket i/o. This is actually three packages, apr, apr-util and apr-iconv.


|-valign="top"
![http://www.boost.org/ Boost] || 1.32.0
|A set of portable C++ libraries which provide a wide set of functionality. Used primarily for tokenization.


|-valign="top"
![http://tut-framework.sourceforge.net/ TUT] || 2006-06-22
|Unit test framework based on the use of c++ meta template programming. Used to test LL libraries.


|-valign="top"
![http://developer.apple.com/quicktime/ Quicktime] || 7.13
|Used to play in-world video clips on a prim.


|-valign="top"
![http://curl.haxx.se/libcurl/ libcurl] || 7.15.1
|Handles moving data across the net in many different protocols. Used to GET/POST/PUT/DELETE web resources.


|-valign="top"
!openssl || 0.9.7c
|Provides encryption for sensitive actions such as user login


|-valign="top"
![http://www.zlib.net/ zlib] || 1.2.1
|zlib is a lossless data-compression library which is used for a variety of network i/o and file compression.


|-valign="top"
![http://www.mozilla.org/developer/ Mozilla] || 1.8.0.9
|The mozilla library handles rendering HTML in the viewer.


|-valign="top"
![http://developer.nvidia.com/page/cg_main.html CG] || ??
|cg controls some visual effects.


|-valign="top"
![http://www.opengl.org/ OpenGL] || ??
| 3D Graphics rendering engine.


|-valign="top"
![http://expat.sourceforge.net/ Expat] || 1.95.8
|XML parser.


|-valign="top"
![http://www.freetype.org/ FreeType] || 2.1.5
|Font engine.


|-valign="top"
![http://www.ijg.org/ jpeglib] || 6b
|JPEG decoder library. It is an open alternative to KDU.


|-valign="top"
![http://www.kakadusoftware.com/ KDU] || 5.2.1
|Kakadu (KDU) iJPEG decoder library.


|-valign="top"
![http://xiph.org/ogg/ OGG] || 1.0.3
|Audio control.


|-valign="top"
![http://xiph.org/vorbis/ Vorbis] || 1.1.2
|Audio control.


|-valign="top"
![http://www.libsdl.org/index.php SDL] || 1.2.7
|The Simple DirectMedia Layer libraries are used for handling input and basic window/GL setup on the Linux client.


|-valign="top"
![http://www.microquill.com/smartheap/index.html Smartheap] || ??
|Memory allocation.


|-valign="top"
![http://www.speedtree.com/ Speedtree] || ??
|Controls rendering of trees that are not yet implemented.


|-valign="top"
![http://xmlrpc-epi.sourceforge.net/ xmlrpc-eip] || 0.51
|Controls the XML-RPC protocol.


|-valign="top"
!OpenJPEG || 1.0
|??


|-valign="top"
!Glib || 2.0.0
|??


|-valign="top"
![http://www.gtk.org/ GTK+] || ??
|'Native' UI components on the Linux client.


|-valign="top"
![http://sourceforge.net/projects/elfio/ ELFIO] || ??
|Enhanced stacktrace information on the Linux client.


|-valign="top"
!Mesa || 6.2.1
|??

|}

Viewer Architecture

2007-01-14T04:00:34Z

Carnildo Greenacre: /* Program Flow */

{{OSWikiLearnBox}}

The Second Life client (also known as the "viewer") is a complex piece of software. It can be visualized as a streaming media client like RealPlayer, a game engine like Quake 3, or a web browser.

First you'll need to learn some terminology like "agent", "sim", and "region" in the [[glossary]].

== Learn by Example ==
* [[Adding a menu item]]
* [[Adding a dialog]]
* [[How movement works]]
* [[How the camera works]]
* [[How login works]]
* [[How keyboard processing works]]
* [[How scripts work]]
* [[The lifetime of a session]]
* [[Adding a preference]]

== Major Systems ==
* [[Message System]] - reliable and unreliable transport over UDP
* [[Image System]] - prioritizes and decodes JPEG2000 images into OpenGL textures
* [[Viewer Object System]] - objects in scene for rendering and editing
* [[Rendering System]] - from viewer object to drawable to face to vertices to graphics card
* [[Culling]] - octree and occlusion based culling to speed rendering
* [[UI Widgets]] - cross platform buttons, scroll bars, etc.
* [[UI Floaters]] - dialogs and windows built from XML files
* [[Asset System]] - transport for animations, sounds, notecards, scripts, etc.
* [[Inventory]] - server-side storage of assets for each user
* [[Sound System]] - cross platform audio based on FMOD
* [[Movie System]] - QuickTime-based video on object surfaces
* [[VFS]] - cached data is held in two "virtual file systems" in large files on the client
* [[Selection Manager]] - holds extended information for selected objects and allows editing
* [[Avatar Appearance]] - appearance is constructed from a mesh, parameters to deform the mesh, and textures to describe clothing
* [[Web Browser]] - the integration of the viewer with the web.
* [[Avatar Profiles]]
* [[Groups]]
* [[L$ System]]
* [[Tools]] - anything that takes effect when you click your mouse on the world view.

== Threads ==
The viewer is a single process with a few threads:
* Main thread -- The input/output main program function (including rendering).
* VFS thread -- Thread responsible for reading/writing to the local virtual file system.
* LFS thread -- Thread responsible for some reading/writing to the local native file system.
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Image thread -- Thread responsible for requesting and decoding image data
** Used by the {{OSWiki|Threaded_Image_Pipeline}} project
* Worker Threads -- Threads designed to do cpu intensive background tasks
** These threads may be paused during rendering so as not to reduce performance (design in-progress)

== Program Flow ==
# Initialize - newview/viewer.cpp :: main()
# Loop - newview/viewer.cpp :: main_loop()
#* Gathers keyboard and mouse input
#* Pumps the TCP i/o
#* idle()
#* Render the frame
#* let filesystem and worker threads process
# Shutdown

== Sources of Input ==
* The [[Message System]].
** Assets through the [[Asset System]], transmitted using the [[Transfer Manager]], and extracted from the [[VFS]].
** Files through [[Xfer Manager]].
* Files copied out of a [[VFS]] into local file store and read through c/c++/ll file API.
* XMLRPC calls such as [[Authentication Flow|login]] and [[Buying Land and Currency]].
* HTTP GET/POST to the [[Backbone]]. This is not yet in use.
* Streaming music and videos.
** Quicktime.
** FMOD.
* The web browser.

== User Guides ==
Known [[Client_parameters]]

Known Client Parameters on [http://lslwiki.com/lslwiki/wakka.php?wakka=newview&show_comments=1 LSLwiki.com]

Known [[defines]]

[[Godmode]] - what Lindens can do

User talk:SignpostMarv Martin/Archive/Implementing new features

2007-01-13T08:48:17Z

Carnildo Greenacre: Night skies

== Alternate Rendering Engines ==
* Heh, isn't SL already running on an open source 3D engine? :-) [[User:Eddy Stryker|Eddy Stryker]] 19:55, 9 January 2007

== Better Sound Support ==
* '''Seconded'''. [[Community Bounties#VLC instead of QuickTime]] might help. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Removing Texture Loading ==
* '''Comment''' How complete do you want this to be? I made a very quick and easy patch that prevents the client from requesting any image downloads, but in my experience it still rendered a few textures like the grass terrain and avatar hair. It sped up the framerate a lot, but didn't change the GPU requirements to run SL. If the latter is your goal you'd probably have better luck by removing shaders and disabling OpenGL extensions. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

* '''Seconded''' -- Disabling texture download/display would be a great asset to people interested in communication more than shopping/etc. [[User:Kamilion Schnook|Kamilion Schnook]]
** As long as you like the color grey :-) --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)
* '''Comment:''' As far as I was aware, libSL clients don't load textures, due to the lack of JPEG 2000 support :-P [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
** This is somewhat incorrect. libsecondlife has had JPEG2000 support for quite some time through our jasper shim called libjaspernet, and some projects use it. Most don't however, as there are few interactive GUI clients using libsecondlife. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

== Patching it so that llLoadURL opens the F1 Help Browser ==
* '''Seconded''' [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* Streaming media urls can be implemented in this manner by making use of string concatenation, e.g. <nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki> [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* The problem with this, is that doing this via serverside script is that there's only one media URL, and you'd be connecting to it with the owner's key -- What is wanted is each individual client responds with it's own key. For instance, integrating a "Who is listening in SL" to an icecast server. Each connected client supplies it's own key/name via rewriting, and a name2key/key2name DB displays each individually connected user's SL information. [[User:Kamilion Schnook|Kamilion Schnook]] 20:35 Jan 8, 2007 PST
**Using the PARCEL_MEDIA_COMMAND_AGENT, I'm told you can give each agent their own stream to listen to. So you could do the user method, or more likely, append a query string, e.g:<div style="font-size:140%;"><code class="lsl"><nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki></code></div>
**[[User:SignpostMarv Martin|SignpostMarv Martin]] 03:31, 10 January 2007 (PST)

== Adding a Avatar Local Stream Channel ==

== Peer to Peer Voice over IP using above idea, improved ==

== More efficient local cache ==
* '''Comment:''' Seronis has some good ideas on how this should be implemented. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* '''Comment:''' Definitely. One cache per region, to a configurable cap total, would be an immense load off the asset servers, and off of our poor bandwidth. [[User:Buckaroo Mu|Buckaroo Mu]] 11:30, 9 January 2007 (PST)

== [http://en.wikipedia.org/wiki/Client-To-Client_Protocol CTCP] protocol layered on IM system ==
* Bleh ? [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Command Line Interface Improvements ==

== More sophisticated IM features ==
* '''Seconded''' with a big hell yes. In a large group, it's difficult to keep track of a conversation when there is a mass exodus from the session. It's annoying having the system spam the window. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

== Shortcut/Link/Alias function in Inventory ==
A pure viewer based solution can "only" be a hack at best. A possible implementation could be:

#) Change the viewer, so that when a drag and drop operation is performed on a 'no-copy' item, the error is trapped
#) for each error, register the UUID of the object in a special notecard
#) When presenting the contents of a folder in the viewer, preset a mixture of the real contents and the contents of the note card
#) Hide the special notecard
#) Handle folder drops onto the avatar
#) Handle moving of the special links
#) Handle deletion of the special links
#) Handle deletion of the original 'no-copy' item

This will only a partial solution, as an scrips running on the servers will still see the real contents of the folder.

:Yea, I realized that this would really have to include a new Inventory Type ID - but do the servers do checking for type IDs? This may be something that can be done client-side with either no server-side change or only one very minor one - the assignment of a Type ID. For instance: Assume the new Inventory Type of Link, which simply stores the UUID of the original object. The simplest thing to do with them regarding copying would be to make them either no-transfer, or "delete on transfer" - they simply go away if you try to transfer them. In every other way, it behaves as a normal inventory item. [[User:Buckaroo Mu|Buckaroo Mu]] 09:15, 11 January 2007 (PST)

::This definitely could be fudged by using a series of specially named notecards (for configuration data), allowing the feature to be implemented without requiring modifications to the server
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 10:03, 11 January 2007 (PST)

:::It ''could be'' fudged with notecards - but how many hacks do you want in SL? The assignment of an additional inventory type at the server end, as far I as can tell from the viewer source, would require probably two lines of code. We need to work with LL to see if they would support this inclusion, rather than make kludges that work but are far less elegant, and may break scripts. [[User:Buckaroo Mu|Buckaroo Mu]] 16:16, 12 January 2007 (PST)

::::You're forgetting something: the servers aren't built for dynamic assets. 'Fudging' it would allow the community to decide on features and interfaces while Linden Lab make the significant changes to the server required for this to work.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 21:12, 12 January 2007 (PST)

== DirectX3D Hardware Acceleration ==

The OpenGL code is scattered all over the entire codebase. You'd have to abstract out all the 3D code first, it wouldn't be an improvement it would be a complete rewrite.

== GPGPU Support ==

== Multiple Monitor Support ==
* '''Seconded''' I've been wanting this since I only had one monitor :-D [[User:SignpostMarv Martin|SignpostMarv Martin]] 11:13, 10 January 2007 (PST)

== Embedded scripting language for client-side plugins ==
One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.

The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).

This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.

[[User:Duffy Langdon|Duffy Langdon]] 12:34, 10 January 2007

== Nude patch ==
It's inevitable. Any bets on how long it will be?
# Ages ago. Around about the time alpha textures for clothes were allowed. [[User:SignpostMarv Martin|SignpostMarv Martin]] 00:53, 11 January 2007 (PST)
# Do bear in mind that my mention of a possible implementation for the 'nude patch' would be akin to hallucinating, due to the also mentioned ability to run extra-stringent checks on the server side for submitted content in PG regions. [[User:SignpostMarv Martin|SignpostMarv Martin]] 01:08, 11 January 2007 (PST)

I don't think a nude patch could work anyway - the skin and clothing textures are combined on the wearer's client, then the combined texture is uploaded to the server as the single texture that appears on the avatar. That's why "rebaking" your textures on your client affects how other people see you. You could possibly just apply the same skin to everyone but you might just as well leave everyone unrezzed then ;) - Yumi Murakami

: and chase all your payig customers away ? In order for us to build our business out in SL and represent our RL business inside SL such things should never be possible therefor as this is a technical wiki and forum how to further create a better client i suggest to build as much security in the client as possible ro prevent such 'attacks' on our avatars. [[User:River Senyurt|River Senyurt]] 11:34, 12 January 2007

:: As I described in the Barriers to implementation section for this "feature", security such as this would have to be built into the server. Since the Viewer is now GPL, all it would take is for someone to remove this 'security' layer, and you're right back where you started, thus Linden Lab are highly unlikely to spend time implementing such a mechanism in the client. The method I described has benefits for both the main and teen grids anyway.

:: Aside from the odd oversight over the years (e.g. texture uploads, megaprims), all security and validation operations are executed on the server side. It fits into LL's behaviour to implement such checks on the server, and while they could, and most likely will do something alone these lines, there is unfortunately nothing you can do to stop somebody else making their client get nervous imagine you in your underwear. Or less.
:: [[User:SignpostMarv Martin|SignpostMarv Martin]] 04:18, 12 January 2007 (PST)

== Out of sight., out of mind ==

# The client has an option to prevent certain types of objects from being rendered
# Objects are addressed server-side by UUID

The client would have be made aware of the UUID of an object, categorising it as a new type of object, and a hotkey could be used to toggle the visibility.

Similarly, if a photographer or machinimaker is working in-world, the following options would be useful:

* Do not render anything other than the land owner's objects
* Do not render objects not owned by people on your friends list
* Do not render avatars on your friends list

This would enable people to deal with certain types of griefer attacks more easily, much in the same way that toggling particles on and off can be useful when particle poofers have been dropped.

[[User:SignpostMarv Martin|SignpostMarv Martin]] 15:32, 12 January 2007 (PST)

== Night skies ==

I'm working on customizing the night sky. Since the sky, and especially the starfield, are strictly client-side effects, this would involve storing the data in a local file. Where would be the best place to store this, and what would be the best way to access it?

Are there any plans for things like sim-wide data storage? Such a thing would make it possible to assign per-sim or per-area skies. I figure a decent starfield would require between 8k and 16k of storage; objects like comets, planets, and the like would be much smaller. --[[User:Carnildo Greenacre|Carnildo Greenacre]] 00:48, 13 January 2007 (PST)

Build the Viewer on Linux

2007-01-12T18:40:57Z

Carnildo Greenacre: /* Augh!! The client seems REALLY slow!! */ Better wording

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has only been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu]. For other platforms, see [[Get source and compile]].

== Installing the required dependencies ==

The Second Life Viewer has a number of compile/link dependencies on external libraries which need to be put in place first - to help you, the source download page contains a link to a slviewer-linux-libs package which you unpack over the source tree to fill most of the dependancies (and thus avoid most of the fiddly work described on this page). The Second Life Viewer is not a trivial build, and experience with building large software packages will help you greatly - but don't be daunted, it should be simple once the dependencies are in the right place the first time.

Paths and package names given here are based on Ubuntu 6.06 and may vary according to your Linux distribution.

=== Prerequisites ===

* You will need the SCons build tool [package: scons]
* You should use the GCC 3.4 C/C++ compiler [package: g++-3.4]; other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without some code adjustments.

* fetch and unpack FMOD 3.75 <http://www.fmod.org/>
** FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
*** Remove the reference to 'fmod-3.75' in indra/SConstruct
*** Replace '-DLL_SDL=1' with '-DLL_SDL=1 -DLL_FMOD=0' in indra/SConstruct
*** Comment-out the libfmod line in indra/newview/linux_tools/client-manifest-i686

* You will need the Curl library [package: libcurl-dev]

* You will need some development headers for OpenGL and X11: gl.h, glext.h, glu.h, Xlib.h, and Xutil.h [packages: mesa-common-dev, libglu1-mesa-dev, libx11-dev]

* You will need GTK 2.x development headers [libgtk2.0-dev]

* You will need yacc and lex [suggest packages: bison, flex]

* You may either use our easy slviewer-linux-libs bundle of pre-built libraries and headers unpacked into the Second Life Viewer source tree, or (for example if you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries) you will have to install the following additional dependencies:
** boost [libboost-dev]
** boost-regex [libboost-regex-dev]
** apr-1 [libapr1.0-dev]
** aprutil-1 [libaprutil1.0-dev]
** xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
*** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
*** Build with ./configure --prefix=/usr --includedir=/usr/include/xmlrpc-epi --[[User:Caelum Lewellen|Caelum Lewellen]] 15:47, 11 January 2007 (PST)
** jpeglib [libjpeg62-dev]
** SDL [libsdl1.2-dev]
** Vorbis [libvorbis-dev]
** build ELFIO <http://sourceforge.net/projects/elfio/>
** build OpenJPEG <http://www.openjpeg.org/>
** expat [libexpat1-dev]

=== Copy headers and libraries into the source tree ===

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.
* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${FMOD} refers to the top-level directory into which you unpacked FMOD 3.
<code>
cp ${FMOD}/api/inc/* ${SLSRC}/libraries/i686-linux/include/
cp ${FMOD}/api/libfmod-3.75.so ${SLSRC}/libraries/i686-linux/lib_release_client/

cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/

</code>

If you are using our easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.
<code>
cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

mkdir ${SLSRC}/libraries/i686-linux/include/expat
cp -a /usr/include/expat*.h ${SLSRC}/libraries/i686-linux/include/expat/

mkdir ${SLSRC}/libraries/i686-linux/include/zlib
cp -a /usr/include/zlib*.h ${SLSRC}/libraries/i686-linux/include/zlib/

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/
</code>

== Compiling ==

<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.

== Testing and packaging the client ==

=== Testing the result from inside the tree ===

You may find it simpler to follow the instructions in the 'Packaging the client' section below to run the client under the same conditions as an end-user would. Otherwise:

* Preparing to run 'in-tree'
** ensure that you have indra/newview/app_settings/static_*.db2 - if not, you'll find it in the 'slviewer-linux-libs' download.
** now, from the indra directory:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
</code>

* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

==== Augh!! The client seems REALLY slow!! ====

By default, the open-source Second Life Viewer uses the open-source OpenJPEG library to decode the (many) JPEG-2000 texture images it receives from the servers. Unfortunately this isn't quite of comparable speed to the proprietary third-party library which the Linden Lab viewer builds have traditionally used, for which we are not permitted to redistribute the source.

However, the slviewer-linux-libs package includes two pre-built libraries which facilitate the use of this smoother image decoding method: libkdu_v42R.so and libllkdu.so. These are provided for your testing; again, we are not permitted to grant you the right to re-distribute these libraries to downstream users, but the viewer will still work (albeit slower) without them.

To use these faster image-decoding libraries, they simply need to be put into the right places relative to the viewer runtime directory - nothing needs to be reconfigured or recompiled. If you're running the client from the source tree, the following will make the KDU libraries available:
<code>
cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
mkdir "$SLSRC/indra/lib"
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
</code>

The file indra/newview/linux_tools/client-manifest-i686 contains some commented-out entries describing where these libraries belong; if you uncomment the two lines corresponding to libllkdu and libkdu then they will be automatically copied into the right place in the runtime directory when you follow the 'Packaging the client' instructions below.

==== "Unable to initialize communications" ====

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

=== Packaging the client ===

If you substitute 'BUILD=release' with 'BUILD=releasefordownload' in the 'Compiling' section above, then packaging the resulting code, libraries, data and documentation into a tarball for the end-user will be done automatically as the final stage of the build process; the pristine end-user client distribution has been assembled into the directory indra/newview/SecondLife_i686_1_X_Y_Z/ and has also been tarred into indra/newview/SecondLife_i686_1_X_Y_Z.tar.bz2

The file which controls what (and where) files go into the end-user runtime viewer directory is indra/newview/linux_tools/client-manifest-i686

==== Packaging errors ====

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

Talk:Coding standard

2007-01-11T05:33:24Z

Carnildo Greenacre:

== Indentation ==

What does it mean ''Use 4 character tabs for indentation and ensure that your editor is not converting tabs to spaces.''?

If my editor doesn't change tabs to spaces, what's the difference whether they are shown in my editor as 4, 8 or 13 spaces?

[[User:Tharkang Varayez|Tharkang Varayez]] 09:18, 8 January 2007 (PST)

:Non-code-structure spacing. Consider:
func_call(one_param, two_param, three_param,
four_param, five_param, six_param);
:The indent under func_call could be either ten spaces, or two tabs and two spaces. --[[User:Carnildo Greenacre|Carnildo Greenacre]] 21:33, 10 January 2007 (PST)

User:SignpostMarv Martin/Archive/Implementing new features

2007-01-11T04:30:53Z

Carnildo Greenacre: It's inevitable

{{OSWikiContribBox}}

Of course, a really valuable way to contribute is to add a new feature. Try to work with the community and with Linden Lab in planning the feature before running off and implementing new things. Though we appreciate your hard work, we can't accept every new feature, since maintaining new features comes with a cost. Try thinking of ways to use APIs to make plugins, or perhaps propose new APIs to make the viewer more extensible, before adding new things to the core viewer.

== Ideas for new Features ==

=== Alternate Rendering Engines ===
* older hardware support, etc...
* [http://www.google.ca/search?q=Open+Source+3D+Engine (''Open Source 3D Engine'')]
** Heh, isn't SL already running on an open source 3D engine? :-)

==== Potential Barriers to Implementation ====

==== Comments ====

=== Better Sound Support ===
* Preload status
* playback control, etc...
** Quote: ''llKelly: eightltr: yes, that idea has been suggested in the past. ('''L$1 per 1sec audio''') I think we would rather improve the methods of linking to externally hosted sounds.''
* MIDI Support - maybe with some nice clientside Wavetables
* MOD, XM, ect. Support

==== Potential Barriers to Implementation ====

==== Comments ====
* '''Seconded'''. [[Community Bounties#VLC instead of QuickTime]] might help. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

=== Removing Texture Loading ===
* so SL can run on less powerful Systems (say the N800/N770)
** How complete do you want this to be? I made a very quick and easy patch that prevents the client from requesting any image downloads, but in my experience it still rendered a few textures like the grass terrain and avatar hair. It sped up the framerate a lot, but didn't change the GPU requirements to run SL. If the latter is your goal you'd probably have better luck by removing shaders and disabling OpenGL extensions. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

==== Potential Barriers to Implementation ====

==== Comments ====
* '''Seconded''' -- Disabling texture download/display would be a great asset to people interested in communication more than shopping/etc. [[User:Kamilion Schnook|Kamilion Schnook]]
** As long as you like the color grey :-) --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)
* '''Comment:''' As far as I was aware, libSL clients don't load textures, due to the lack of JPEG 2000 support :-P [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
** This is somewhat incorrect. libsecondlife has had JPEG2000 support for quite some time through our jasper shim called libjaspernet, and some projects use it. Most don't however, as there are few interactive GUI clients using libsecondlife. --[[User:Eddy Stryker|Eddy Stryker]] 12:01, 9 January 2007 (PST)

=== Patching it so that llLoadURL opens the F1 Help Browser ===
* Adding keyword replacement in llLoadURL, Streaming media support, and other external links
** For instance, to provide an icecast stream with a agent UUID, <nowiki>http://'''agentkey''':apassword@icecast.somehost.com:8000</nowiki> as a parcel URL
* To provide an external website with a SL User Name, <nowiki> http://www.somesite.com/somephp.php?query=stuff&slname=''agentname''&action=buy&deliveryto=''agentkey''</nowiki>

==== Potential Barriers to Implementation ====
* Unless the LSL2 VM starts supporting optional parameters, you risk breaking thousands of scripts
** '''Workaround:''' Prefix urls with ubrowser:, e.g. '''<nowiki>ubrowser:http://example.com</nowiki>''', which will result in the dialog box indicating that the url will open inside the client.
** '''Alternative Workaround:''' Clientside rewriting only, for connecting to media URLs
==== Comments ====
* '''Seconded''' [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* Streaming media urls can be implemented in this manner by making use of string concatenation, e.g. <nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki> [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* The problem with this, is that doing this via serverside script is that there's only one media URL, and you'd be connecting to it with the owner's key -- What is wanted is each individual client responds with it's own key. For instance, integrating a "Who is listening in SL" to an icecast server. Each connected client supplies it's own key/name via rewriting, and a name2key/key2name DB displays each individually connected user's SL information. [[User:Kamilion Schnook|Kamilion Schnook]] 20:35 Jan 8, 2007 PST
**Using the PARCEL_MEDIA_COMMAND_AGENT, I'm told you can give each agent their own stream to listen to. So you could do the user method, or more likely, append a query string, e.g:<div style="font-size:140%;"><code class="lsl"><nowiki>llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000',PARCEL_MEDIA_COMMAND_AGENT,llGetOwner()]);</nowiki></code></div>
**[[User:SignpostMarv Martin|SignpostMarv Martin]] 03:31, 10 January 2007 (PST)

=== Adding a Avatar Local Stream Channel ===
* that has a Range of X Meters around an Avatar
* This would be used for Local Audio Streaming
** Or Local VoIP chat
** Teamspeak...

==== Potential Barriers to Implementation ====

==== Comments ====

=== Peer to Peer Voice over IP using above idea, improved ===
** Capible clients advertise themselves via below CTCP-style protocol
** Clients use multicast packets to broadcast to a list of addresses the server manages of clients in range.
** In effect, this would give each avatar two unidirectional shoutcast-style stream impliments, or one bidirectional impliment.

==== Potential Barriers to Implementation ====

==== Comments ====

=== More efficient local cache ===

==== Potential Barriers to Implementation ====

==== Comments ====
* '''Comment:''' Seronis has some good ideas on how this should be implemented. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)
* '''Comment:''' Definitely. One cache per region, to a configurable cap total, would be an immense load off the asset servers, and off of our poor bandwidth. [[User:Buckaroo Mu|Buckaroo Mu]] 11:30, 9 January 2007 (PST)

=== [http://en.wikipedia.org/wiki/Client-To-Client_Protocol CTCP] protocol layered on IM system ===

==== Potential Barriers to Implementation ====
Establishing a circuit between two clients will probably require server side assistance, since circuits are UDP based, and most clients will be behind NAT's and firewalls. CTCP will require a clientside listening socket either implemented via [http://www.faqs.org/rfcs/rfc3489.html RFC 3489] or some sort of UPnP code using a TCP direct connection.

==== Comments ====
* Bleh ? [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

=== Command Line Interface Improvements ===
* for changing preferences sending an IM, teleporting, etc
** for example: "/set drawdist 96", "/set sound off", "/tp ahern", or "/im kex godel hello"
** would need an escape system which doesn't conflict with script command gestures (or a reserved words like how /me is)
** Or better yet, the Ctrl-G Gesture management window could be improved to allow this, and even allow rebinding /commands

==== Potential Barriers to Implementation ====
* Implementing an escape system which doesn't conflict with script command gestures (or a reserved words like how /me is)

==== Comments ====

=== More sophisticated IM features ===
* muting/filtering/autoresponse options
** mute or do not alert on IMs by started by a group, agent, or group-agent
** Autoreply to IMs received while (Away)
** Sidebar Userlist of Active Users who are currently participating in a Group IM Session.
*** When a user says something, they're added. When a user leaves the session, they're removed from the list.
* More control over filtering specific objects/textures/sounds/agents/etc

==== Potential Barriers to Implementation ====

==== Comments ====
* '''Seconded''' with a big hell yes. In a large group, it's difficult to keep track of a conversation when there is a mass exodus from the session. It's annoying having the system spam the window. [[User:SignpostMarv Martin|SignpostMarv Martin]] 07:51, 9 January 2007 (PST)

=== Shortcut/Link/Alias function in Inventory ===
*Add a "link" ("alias", "shortcut") facility to the inventory, that would not break Permissions. For instance, I have one nice set of prim dress shoes that are no-copy, and four tuxedos. I cannot make complete separate outfits, because I have only one copy of the shoes. However, using a "link", I could create an outfit folder with the tux and a link to the no-copy shoes. Still means I would only have the one set, but it would make changing clothes much much easier. [[User:Buckaroo Mu|Buckaroo Mu]] 09:23, 9 January 2007 (PST)

==== Potential Barriers to Implementation ====

==== Comments ====
A pure viewer based solution can "only" be a hack at best. A possible implementation could be:

#) Change the viewer, so that when a drag and drop operation is performed on a 'no-copy' item, the error is trapped
#) for each error, register the UUID of the object in a special notecard
#) When presenting the contents of a folder in the viewer, preset a mixture of the real contents and the contents of the note card
#) Hide the special notecard
#) Handle folder drops onto the avatar
#) Handle moving of the special links
#) Handle deletion of the special links
#) Handle deletion of the original 'no-copy' item

This will only a partial solution, as an scrips running on the servers will still see the real contents of the folder.

=== DirectX3D Hardware Acceleration ===
*A DirectX3D-driven version of the viewer, allowing those with ATi or Intel hardware accelerated cards to take advantage of the processing power. The system could allow selection as a preference of OpenGL or DirectX3D, as many Windows-only games currently do. Conditional build statements would keep the option from appearing in the non-DirectX3D capable builds. [[User:Buckaroo Mu|Buckaroo Mu]] 09:28, 9 January 2007 (PST)

==== Potential Barriers to Implementation ====

==== Comments ====

=== GPGPU Support ===
*A method of offloading some of the [http://www.gpgpu.org/ graphics processing to the GPU] might help increase framerate. [[User:Buckaroo Mu|Buckaroo Mu]] 09:37, 9 January 2007 (PST)

==== Potential Barriers to Implementation ====

==== Comments ====

=== Multiple Monitor Support ===
*Support for detachable sub-windows, allowing the inventory, chat history, IM, etc. windows to be moved to a second monitor (if available). This is a very highly-desired feature (by those that have dual-monitor systems). [[User:Buckaroo Mu|Buckaroo Mu]] 09:37, 9 January 2007 (PST)
* This could potentially be done using an external program, if SL had some way of exposing this data in a crossplatform way. (Does NT support named pipes?) Some libsecondlife projects such as SLeek are already exposing this. [[User:Kamilion Schnook|Kamilion Schnook]] 20:39 Jan 9 2007
==== Potential Barriers to Implementation ====

==== Comments ====
* '''Seconded''' I've been wanting this since I only had one monitor :-D [[User:SignpostMarv Martin|SignpostMarv Martin]] 11:13, 10 January 2007 (PST)

=== Client Side Scripting ===
* Make the client more powerful and plugable

==== Known Barriers to Implementation ====

==== Comments ====
One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.

The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).

This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.

=== Nude patch ===
*Modify the client to not render any avatar clothes or attachments.

==== Known Barriers to Implementation ====

==== Comments ====
It's inevitable. Any bets on how long it will be?

== See Also ==
Linden Lab is considering offering bounties for especially desirable features in the viewer.

* [[Linden Lab Bounties]]
* [[Community Bounties]]
* [[:Category:Bounties]]