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

From Second Life Wiki
Jump to navigation Jump to search
(restored see also section)
Line 162: Line 162:
** 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
** 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.
== See Also ==
Linden Lab is considering offering bounties for especially desirable features in the viewer.
 
* [[Linden Lab Bounties]]
* [[Community Bounties]]
* [[:Category:Bounties]]

Revision as of 04:12, 12 January 2007

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

If you have an idea for a new feature you'd like to see in the client, consider adding it to this list.

Discussion on each topic can be found in this article's Talk page

Alternate Rendering Engines

Fox Diller

Barriers to Implementation

Better Sound Support

Falk Bergman (by way of #opensl on IRC)

  • 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

Barriers to Implementation

Removing Texture Loading

Falk Bergman (by way of #opensl on IRC)

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

Barriers to Implementation

Patching it so that llLoadURL opens the F1 Help Browser

Falk Bergman (by way of #opensl on IRC)

  • 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''

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.
    • Alternative Workaround: Clientside rewriting only, for connecting to media URLs


Adding a Avatar Local Stream Channel

Falk Bergman (by way of #opensl on IRC)

  • that has a Range of X Meters around an Avatar
  • This would be used for Local Audio Streaming
    • Or Local VoIP chat
    • Teamspeak...

Barriers to Implementation

Peer to Peer Voice over IP using above idea, improved

Kamilion Schnook

    • 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.

Barriers to Implementation

More efficient local cache

Barriers to Implementation

CTCP protocol layered on IM system

Kex Godel

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 RFC 3489 or some sort of UPnP code using a TCP direct connection.


Command Line Interface Improvements

Kex Godel

  • 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

Barriers to Implementation

  • Implementing an escape system which doesn't conflict with script command gestures (or a reserved words like how /me is)


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

Barriers to Implementation

  • Anything that requires server-side modification SignpostMarv Martin 11:11, 11 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. Buckaroo Mu 09:23, 9 January 2007 (PST)

Potential Barriers to Implementation

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. Buckaroo Mu 09:28, 9 January 2007 (PST)

Barriers to Implementation

GPGPU Support

Barriers to Implementation

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). 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. Kamilion Schnook 20:39 Jan 9 2007

Barriers to Implementation

Embedded scripting language for client-side plugins

Heather Goodliffe, Yumi Murakami

  • Make the client more powerful and plugable
  • Embed a scripting language, such as LUA or Python, within Second Life to enable client plug-ins to be written in a modular fashion. Client plugins would be distributed via Second Life itself; hopefully LL would eventually agree to create a new object type for these, but for testing purposes notecards would probably suffice.


Known Barriers to Implementation

Nude patch

Carnildo Greenacre

  • Modify the client to not render any avatar clothes or attachments.

Barriers to Implementation

Steps to how Linden Lab could 'disable' a 'nude patch'
  1. Run a check on clothing textures including alpha information
    • Check for alpha information around the genitalia, refuse upload if check returns positive
  2. 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 to prevent 'Attack of the (nude) Clones'
SignpostMarv Martin 01:02, 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

See Also

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