User:SignpostMarv Martin/Archive/Implementing new features

From Second Life Wiki
Jump to navigation Jump to search

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

Just some Ideas that came up on the #opensl irc channel:

Alternate Rendering Engines

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

Removing Texture Loading

  • so SL can run on less powerful Systems (say the N800/N770)

Potential Barriers to Implementation

Comments

  • Seconded -- Disabling texture download/display would be a great asset to people interested in communication more than shopping/etc. Kamilion Schnook
  • Comment: As far as I was aware, libSL clients don't load textures, due to the lack of JPEG 2000 support :-P SignpostMarv Martin 07:51, 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, http://'''agentkey''':apassword@icecast.somehost.com:8000 as a parcel URL
  • To provide an external website with a SL User Name, http://www.somesite.com/somephp.php?query=stuff&slname=''agentname''&action=buy&deliveryto=''agentkey''

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. ubrowser:http://example.com, which will result in the dialog box indicating that the url will open inside the client.

Comments

  • Seconded 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. llParcelMediaCommandList([PARCEL_MEDIA_COMMAND_URL,'http://' + (string)llGetOwner() + ':' + stringVar__password + '@icecast.example.com:8000'); SignpostMarv Martin 07:51, 9 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. SignpostMarv Martin 07:51, 9 January 2007 (PST)

CTCP protocol layered on IM system

Potential Barriers to Implementation

Comments

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. SignpostMarv Martin 07:51, 9 January 2007 (PST)

See Also

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