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

From Second Life Wiki
Jump to navigation Jump to search
(moved several)
(blanking, moving out completed)
Line 1: Line 1:
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.


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:{{PAGENAME}}|Talk page]]
== 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 [[User:SignpostMarv Martin|SignpostMarv Martin]] 11:11, 11 January 2007 (PST)
<hr />
== 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)
<hr />
== 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)
=== Barriers to Implementation ===
* Developer incentive/motivation
<hr />
== 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)
<hr />
== 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
<hr />
== Implement GUI in Native Widgets ==
I also would like to see multiple monitor support, but I'd prefer this to happen by implementing the inventory system and other parts using native palettes, toolbars, and windows (dockable to the SL window).
<hr />
== Embedded scripting language for client-side plugins ==
[[User:Heather Goodliffe|Heather Goodliffe]], [[User:Yumi Murakami|Yumi Murakami]]
:''See [[Plugin architecture]]''
* 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.
* Let me second that: I'd like to see client-side scripting as well.  It should be easy to add that (in particular, using Lua), and it would let users fix so many usability problems.  At a minimum, the scripting language should be able to access the functionality available through the menus, it should permit key bindings and grab keys, access preference settings, and it should be able to listen to chat and IM, so that commands can be triggered from there. [[User:Jherek Cerminara|Jherek Cerminara]]
<hr />
== Nude patch ==
[[User:Carnildo Greenacre|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' ====
# 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 to prevent ''''Attack&nbsp;of&nbsp;the&nbsp;''(nude)''&nbsp;Clones''''
:[[User:SignpostMarv Martin|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
* [http://somegeekstuff.wordpress.com/2007/01/26/second-life-nude-patch/ here] is a quick and dirty solution ;)
<hr />
== Two Tier Search ==
[[User:Yumi Murakami|Yumi Murakami]]
* Server performs a possibly less-effective search which is database efficient, such as the current fulltext search.  The client then performs its own search, refining the results.  Should allow extra flexibility and take some load off LL's database.
<hr />
=== User Interface Improvements ===
[[User:Yumi Murakami|Yumi Murakami]]
* General improvements to the user interface.  Maybe move to a seperate article: [[User Interface Improvements]]
<hr />
== More Text for Abuse and Bug Reports ==
[[User:Anders Nordberg|Anders Nordberg]]
* Bug Reports as well as Abuse Reports are currently very limited in the amount to text you can enter. Very difficult sometimes to describe a bug in just 2 or 3 sentences...
'''NOTE: A lengthy bug report that would benefit from additional material such as videos or photos could possibly be submitted to [https://jira.secondlife.com Jira] --[[User:SignpostMarv Martin|SignpostMarv Martin]]'''
<hr />
== Attachments registering as additional limbs for animation ==
[[User:Alderic LeShelle|Alderic LeShelle]]
* Attachments with distinct object names (like wings, tails, extra limbs...) may register themselves in the skeletal structure of the avatar, so that a BVH animation might animate them as well.
<hr />
== Much Longer Land Draw Distance ==
[[User:Huns Valen]]
* The idea is to have a separate slider for land draw distance. It must be greater than or equal to the "master" draw distance. As drawing land is much less resource-intensive than drawing objects and avatars, it should be possible to have a land draw distance measured in kilometers, not meters.
* Could possibly use colored map textures (from the world map, not from the viewer-generated local map) as terrain patch, rather than the supplied patch, although this might not look great for closer-in terrain.
** Perhaps all terrain within 512 meters could be drawn using the sim-supplied textures, and anything further could be drawn using the world map textures.
==== Barriers to Implementation ====
* Would require child connections to more simulators to render "sorta near" terrain (that is, beyond the draw distance for objects and avatars, but within the usual "far clip.") The simulators would have to JUST send land, not objects/avs/etc. as that would defeat the purpose of having a lower draw distance. (Terrain beyond the usual far clip would all be done as world map textures.)
* Colored map textures may not be available in suitable resolution for it to look really good. However, it should be acceptable to many residents in lieu of the "version 2" graphics engine we were shown previews of in 2005 (and which subsequently was cancelled.)
* If this works well as a proof of concept, LL might be persuaded to make higher-resolution world map textures available, and work on some server-side optimizations.
<hr />
== 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 07:12, 18 February 2007

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