Difference between revisions of "User:SignpostMarv Martin/Archive/Implementing new features"

From Second Life Wiki
Jump to navigation Jump to search
m (redirect)
 
(46 intermediate revisions by 12 users not shown)
Line 1: Line 1:
{{OSWikiContribBox}}
#REDIRECT [[:Category:Feature Requests]]
 
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 ====
 
===== Steps to how Linden Lab could 'disable' a 'nude patch' =====
 
# Run a check on clothing textures including alpha information
#* Check for alpha information around the genitalia, refuse upload if check returns positive
# Composite clothing textures server-side when avatars are:
#* In PG regions
#* Viewable from PG regions
 
A 'nude patch' would function by:
* somehow submitting full alpha textures on all clothes no matter what was worn (prevented by LL as described above)
* ignoring what the server says regarding skins
** Could use procedurally generated textures based on avatar shape, and primitar type so prevent ''''Attack of the (nude) Clones''''
:[[User:SignpostMarv Martin|SignpostMarv Martin]] 01:02, 11 January 2007 (PST)
 
==== Comments ====
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)
 
== See Also ==
Linden Lab is considering offering bounties for especially desirable features in the viewer.
 
* [[Linden Lab Bounties]]
* [[Community Bounties]]
* [[:Category:Bounties]]

Latest revision as of 07:16, 18 February 2007

Redirect to:

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:SignpostMarv_Martin/Archive/Implementing_new_features&oldid=10847"