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

From Second Life Wiki
Jump to navigation Jump to search
moved comments to talk page
 
redirect
 
(25 intermediate revisions by 9 users not shown)
Line 1: Line 1:
== Alternate Rendering Engines ==
#REDIRECT [[:Category:Feature Requests]]
* 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)
 
 
== DirectX3D Hardware Acceleration ==
 
 
== 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)

Latest revision as of 07:17, 18 February 2007

Redirect to:

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