Second Life Wiki - User contributions [en]

Server Beta User Group

2012-07-08T05:06:28Z

Buckaroo Mu:

This is the meeting tracking and progress page for the weekly Server BETA QA Meeting, moderated by Oskar Linden. Please contact him on AGNI for more information. You can join the '''Second Life Beta''' group for updates.

'''The next meeting is Thursday, July 5, 2012, 3PM PDT at {{SLurl|region=Morris|x=210|y=250|z=35|title=Morris}} on the preview grid, [[Preview_Grid | ADITI]].'''

* Join the email list - sign up here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta

== Agenda ==

=== Updates ===

* Rough week.
* No Tuesday roll because of the 4th of July
* No Wednesday roll because of the 4th of July
* We planned a Thursday roll...
** But then network outages
** It is postponed until next Tuesday.

* '''Second Life Server Channel'''
* Nothing new here.
** https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12#12.06.18.259948

* '''BlueSteel RC Channel'''
* Nothing new here.
* This channel has server changes to process prebaked avatar textures for library outfits again.
** https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/12#12.06.20.260188

* '''LeTigre RC Channel'''
* Nothing new here.
* This channel has server changes to process prebaked avatar textures for library outfits again.
** https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/12#12.06.20.260188

* '''Magnum RC Channel'''
* Nothing new here.
* This channel has server changes to process prebaked avatar textures for library outfits as well.
** https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/12#12.06.20.260188

* PathFinding User Group right after this meeting.

=== Upcoming Stuff ===

* Busy week next week
* prebaked av textures to main channel
* pathfinding part deux
* creative tools part deux
* a maint-server
** {{jira|SVC-7792}} - HUD Attachments Receive Infrequent Updates when Camera is Zoomed Out

=== Interesting Stuff ===
* '''Pathfinding Beta Regions Live on AGNI'''
** https://wiki.secondlife.com/wiki/Pathfinding_Public_Beta

=== Any Other Items ===
* {{jira|SCR-6}} - ''llGetSubString can produce results that crash Mono scripts''. Agni code now breaks llDeleteSubstring()

# [https://jira.secondlife.com/browse/SVC-7727 SVC-7727] - Aditi grid problem. After changing my password to cause my inventory on Aditi to update, my inventory no longer saves changes made to it from session to session. [[User:Nalates Urriah|Nalates Urriah]] This problem includes seveal moe issues and is still a horribly annoying problem for those of trying to test pathfinding and mesh items.

==== Don't know if I can make the meeting, but this is important to me: ====
* {{jira|SCR-82}} - ''Behavior of moving_start() and moving_end() is inconsistent''. This is a four-year-old problem I've just run into. When using llSetRegionPos, I'm relying on moving_end to let me know when the linkset is in place - and it's failing intermittently. No rhyme or reason I can detect. [[User:Buckaroo Mu|Buckaroo Mu]] 22:06, 7 July 2012 (PDT)

== Open Items ==
* {{jira|SVC-4632}} - People getting past Estate and Land bans | Critical & 325 (402 as of 8/11/10) votes!
** Dante has commented on this issue and reopened it.
* {{jira|SVC-5925}} - Erratic behavior on script rezzed prims set physical
* {{jira|SVC-3044}} - [[DEBUG_CHANNEL|Debug channel]] and script error reporting needs a major rethink
** related to {{jira|vwr-199}} and {{jira|vwr-7062}}
** [15:17] Roberto Salubrius: can we get that standarized pleaaaaaaaaaaaseeeeeeeeee so we can listen to the debug channel whenever there's a problem PLEAAAAAAAAAASEEEEEEE
** [15:17] Roberto Salubrius: preeeeeeeetty pleaaseeeeee
* {{jira|svc-4196}} - "Avatar entering sim or rezzing object causes sim to freeze for up to 30 seconds - everything stops for everybody there"
* wassup with {{jira|SVC-3895}}
* status on {{jira|SVC-3618}} - estate managers unable to freeze / eject
* status on {{jira|SVC-1253}} - users sitting on prims, which are set to phantom are not affected by damage. | 108 votes!
* status on {{jira|SVC-5404}} - Vehicles can no longer enter a region if no-object-entry flag is set
* What is going on with {{jira|SVC-421}} - Cannot delete contents from no-modify objects
* status on {{jira|SVC-5880}} - Vehicles "Jumping" when crossing prims
* {{jira|SVC-5922}} -Physics unset on vehicles when seated avatars goes beyond the physical 'prim' limit where agents are counted towards prims
* {{jira|SVC-6104}} script sim crossing bug
* {{jira|SVC-6123}} cant catch sphere type exact shape with lsl functions
* What is the story on the bug that allows the Meeroos food vending scam? Nalates U
* At what point do you want me document functions that appear here or in the RC release notes? (I won't be attending the meeting but I'll review the transcript) -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 12:29, 11 January 2012 (PST)
* Pathfinding characters got no proper character animation toolkit. Capabilities are limited to sliding bricks, or R2-D2 from "Star Wars" on it's best. If anybody is going to make a decent animation parser from well known animation formats like BVH - its not going to be open sourced, because it requires quite a bit of work on LSL (I'm already half way there). I know that some time people will just get fed up with it and beg Lindens for official tools with proper prim hierarchical rigged character animation capabilites done by SL's animation assets only on viewer side. Whats the loose ETA (year or half precision) on those tools considering that lots of stuff still broken and needs debugging? Come on guys, just say a number on your mind without any promises c: ([[User:FadeOut Razorfen|FadeOut Razorfen]])

= Minutes from Previous Meetings =
*2012
** May
*** [[Beta_Server_Office_Hours/Minutes/2012-06-28 | 2012-06-28]]
*** [[Beta_Server_Office_Hours/Minutes/2012-06-21 | 2012-06-21]]
*** [[Beta_Server_Office_Hours/Minutes/2012-06-14 | 2012-06-14]]
*** [[Beta_Server_Office_Hours/Minutes/2012-06-07 | 2012-06-07]]
** May
*** [[Beta_Server_Office_Hours/Minutes/2012-05-31 | 2012-05-31]]
*** [[Beta_Server_Office_Hours/Minutes/2012-05-24 | 2012-05-24]]
*** [[Beta_Server_Office_Hours/Minutes/2012-05-17 | 2012-05-17]]
*** [[Beta_Server_Office_Hours/Minutes/2012-05-10 | 2012-05-10]]
*** [[Beta_Server_Office_Hours/Minutes/2012-05-03 | 2012-05-03]]
** April
*** [[Beta_Server_Office_Hours/Minutes/2012-04-26 | 2012-04-26]]
*** [[Beta_Server_Office_Hours/Minutes/2012-04-19 | 2012-04-19]]
*** [[Beta_Server_Office_Hours/Minutes/2012-04-12 | 2012-04-12]]
*** [[Beta_Server_Office_Hours/Minutes/2012-04-05 | 2012-04-05]]
** March
*** [[Beta_Server_Office_Hours/Minutes/2012-03-29 | 2012-03-29]]
*** [[Beta_Server_Office_Hours/Minutes/2012-03-22 | 2012-03-22]]
*** [[Beta_Server_Office_Hours/Minutes/2012-03-15 | 2012-03-15]]
*** [[Beta_Server_Office_Hours/Minutes/2012-03-08 | 2012-03-08]]
*** [[Beta_Server_Office_Hours/Minutes/2012-03-01 | 2012-03-01]]
** February
*** [[Beta_Server_Office_Hours/Minutes/2012-02-23 | 2012-02-23]]
*** [[Beta_Server_Office_Hours/Minutes/2012-02-16 | 2012-02-16]]
*** [[Beta_Server_Office_Hours/Minutes/2012-02-09 | 2012-02-09]]
*** [[Beta_Server_Office_Hours/Minutes/2012-02-02 | 2012-02-02]]
** January
*** [[Beta_Server_Office_Hours/Minutes/2012-01-26 | 2012-01-26]]
*** [[Beta_Server_Office_Hours/Minutes/2012-01-19 | 2012-01-19]]
*** [[Beta_Server_Office_Hours/Minutes/2012-01-12 | 2012-01-12]]
*** [[Beta_Server_Office_Hours/Minutes/2012-01-05 | 2012-01-05]]
*2011
** December
*** [[Beta_Server_Office_Hours/Minutes/2011-12-15 | 2011-12-15]]
*** [[Beta_Server_Office_Hours/Minutes/2011-12-08 | 2011-12-08]]
*** [[Beta_Server_Office_Hours/Minutes/2011-12-01 | 2011-12-01]]
** November
*** 2010-11-24 *NO MEETING* Happy Thanksgiving!
*** [[Beta_Server_Office_Hours/Minutes/2011-11-17 | 2011-11-17]]
*** [[Beta_Server_Office_Hours/Minutes/2011-11-10 | 2011-11-10]]
*** [[Beta_Server_Office_Hours/Minutes/2011-11-03 | 2011-11-03]]
** October
*** [[Beta_Server_Office_Hours/Minutes/2011-10-27 | 2011-10-27]]
*** [[Beta_Server_Office_Hours/Minutes/2011-10-20 | 2011-10-20]]
*** [[Beta_Server_Office_Hours/Minutes/2011-10-13 | 2011-10-13]]
*** [[Beta_Server_Office_Hours/Minutes/2011-10-06 | 2011-10-06]]
** September
*** [[Beta_Server_Office_Hours/Minutes/2011-09-29 | 2011-09-29]]
*** [[Beta_Server_Office_Hours/Minutes/2011-09-22 | 2011-09-22]]
*** [[Beta_Server_Office_Hours/Minutes/2011-09-15 | 2011-09-15]]
*** [[Beta_Server_Office_Hours/Minutes/2011-09-08 | 2011-09-08]]
*** [[Beta_Server_Office_Hours/Minutes/2011-09-01 | 2011-09-01]]
** August
*** [[Beta_Server_Office_Hours/Minutes/2011-08-25 | 2011-08-25]]
*** 2011-08-18 *No meeting. Oskar was on vacation*
*** [[Beta_Server_Office_Hours/Minutes/2011-08-11 | 2011-08-11]]
*** [[Beta_Server_Office_Hours/Minutes/2011-08-04 | 2011-08-04]]
** July
*** [[Beta_Server_Office_Hours/Minutes/2011-07-28 | 2011-07-28]]
*** [[Beta_Server_Office_Hours/Minutes/2011-07-21 | 2011-07-21]]
*** [[Beta_Server_Office_Hours/Minutes/2011-07-14 | 2011-07-14]]
*** [[Beta_Server_Office_Hours/Minutes/2011-07-07 | 2011-07-07]]
** June
*** [[Beta_Server_Office_Hours/Minutes/2011-06-30 | 2011-06-30]]
*** [[Beta_Server_Office_Hours/Minutes/2011-06-23 | 2011-06-23]]
*** [[Beta_Server_Office_Hours/Minutes/2011-06-16 | 2011-06-16]]
*** [[Beta_Server_Office_Hours/Minutes/2011-06-09 | 2011-06-09]]
*** [[Beta_Server_Office_Hours/Minutes/2011-06-02 | 2011-06-02]]
** May
*** [[Beta_Server_Office_Hours/Minutes/2011-05-26 | 2011-05-26]]
*** [[Beta_Server_Office_Hours/Minutes/2011-05-19 | 2011-05-19]]
*** [[Beta_Server_Office_Hours/Minutes/2011-05-12 | 2011-05-12]]
*** [[Beta_Server_Office_Hours/Minutes/2011-05-05 | 2011-05-05]]
** April
*** [[Beta_Server_Office_Hours/Minutes/2011-04-28 | 2011-04-28]]
*** [[Beta_Server_Office_Hours/Minutes/2011-04-21 | 2011-04-21]]
*** [[Beta_Server_Office_Hours/Minutes/2011-04-14 | 2011-04-14]]
*** [[Beta_Server_Office_Hours/Minutes/2011-04-07 | 2011-04-07]]
** March
*** [[Beta_Server_Office_Hours/Minutes/2011-03-31 | 2011-03-31]]
*** [[Beta_Server_Office_Hours/Minutes/2011-03-24 | 2011-03-24]]
*** [[Beta_Server_Office_Hours/Minutes/2011-03-17 | 2011-03-17]]
*** [[Beta_Server_Office_Hours/Minutes/2011-03-10 | 2011-03-10]]
*** [[Beta_Server_Office_Hours/Minutes/2011-03-03 | 2011-03-03]]
** February
*** [[Beta_Server_Office_Hours/Minutes/2011-02-24 | 2011-02-24]]
*** [[Beta_Server_Office_Hours/Minutes/2011-02-17 | 2011-02-17]]
*** [[Beta_Server_Office_Hours/Minutes/2011-02-10 | 2011-02-10]]
*** [[Beta_Server_Office_Hours/Minutes/2011-02-03 | 2011-02-03]]
** January
*** [[Beta_Server_Office_Hours/Minutes/2011-01-27 | 2011-01-27]]
*** [[Beta_Server_Office_Hours/Minutes/2011-01-20 | 2011-01-20]]
*** [[Beta_Server_Office_Hours/Minutes/2011-01-13 | 2011-01-13]]
*** [[Beta_Server_Office_Hours/Minutes/2011-01-06 | 2011-01-06]]
* 2010
** December
*** 2010-12-30 *NO MEETING*
*** 2010-12-23 *NO MEETING*
*** [[Beta_Server_Office_Hours/Minutes/2010-12-16 | 2010-12-16]]
*** [[Beta_Server_Office_Hours/Minutes/2010-12-09 | 2010-12-09]]
*** [[Beta_Server_Office_Hours/Minutes/2010-12-02 | 2010-12-02]]
** November
*** 2010-11-25 *NO MEETING* Happy Thanksgiving!
*** [[Beta_Server_Office_Hours/Minutes/2010-11-18 | 2010-11-18]]
*** [[Beta_Server_Office_Hours/Minutes/2010-11-11 | 2010-11-11]]
*** [[Beta_Server_Office_Hours/Minutes/2010-11-04 | 2010-11-04]]
** October
*** [[Beta_Server_Office_Hours/Minutes/2010-10-28 | 2010-10-28]]
*** [[Beta_Server_Office_Hours/Minutes/2010-10-21 | 2010-10-21]]
*** [[Beta_Server_Office_Hours/Minutes/2010-10-14 | 2010-10-14]]
*** [[Beta_Server_Office_Hours/Minutes/2010-10-07 | 2010-10-07]]
** September
*** [[Beta_Server_Office_Hours/Minutes/2010-09-30 | 2010-09-30]]
*** [[Beta_Server_Office_Hours/Minutes/2010-09-23 | 2010-09-23]]
*** [[Beta_Server_Office_Hours/Minutes/2010-09-16 | 2010-09-16]]
*** [[Beta_Server_Office_Hours/Minutes/2010-09-09 | 2010-09-09]]
*** [[Beta_Server_Office_Hours/Minutes/2010-09-02 | 2010-09-02]]
** August
*** [[Beta_Server_Office_Hours/Minutes/2010-08-26 | 2010-08-26]]
*** [[Beta_Server_Office_Hours/Minutes/2010-08-19 | 2010-08-19]]
*** [[Beta_Server_Office_Hours/Minutes/2010-08-12 | 2010-08-12]]
*** [[Beta_Server_Office_Hours/Minutes/2010-08-05 | 2010-08-05]]
** July
*** [[Beta_Server_Office_Hours/Minutes/2010-07-29 | 2010-07-29]]
*** [[Beta_Server_Office_Hours/Minutes/2010-07-22 | 2010-07-22]]
*** [[Beta_Server_Office_Hours/Minutes/2010-07-15 | 2010-07-15]]
*** [[Beta_Server_Office_Hours/Minutes/2010-07-08 | 2010-07-08]]
*** [[Beta_Server_Office_Hours/Minutes/2010-07-01 | 2010-07-01]]
** June
*** [[Beta_Server_Office_Hours/Minutes/2010-06-24 | 2010-06-24]]
*** [[Beta_Server_Office_Hours/Minutes/2010-06-10 | 2010-06-10]]
*** [[Beta_Server_Office_Hours/Minutes/2010-06-03 | 2010-06-03]]
** May
*** [[Beta_Server_Office_Hours/Minutes/2010-05-27 | 2010-05-27]]
*** [[Beta_Server_Office_Hours/Minutes/2010-05-20 | 2010-05-20]]
*** [[Beta_Server_Office_Hours/Minutes/2010-05-13 | 2010-05-13]]
*** [[Beta_Server_Office_Hours/Minutes/2010-05-06 | 2010-05-06]]
** April
*** [[Beta_Server_Office_Hours/Minutes/2010-04-29 | 2010-04-29]]
*** [[Beta_Server_Office_Hours/Minutes/2010-04-22 | 2010-04-22]]
*** [[Beta_Server_Office_Hours/Minutes/2010-04-15 | 2010-04-15]]
*** [[Beta_Server_Office_Hours/Minutes/2010-04-08 | 2010-04-08]]
*** [[Beta_Server_Office_Hours/Minutes/2010-04-01 | 2010-04-01]]
** March
*** [[Beta_Server_Office_Hours/Minutes/2010-03-25 | 2010-03-25]]
*** [[Beta_Server_Office_Hours/Minutes/2010-03-18 | 2010-03-18]]
*** [[Beta_Server_Office_Hours/Minutes/2010-03-11 | 2010-03-11]]
*** [[Beta_Server_Office_Hours/Minutes/2010-03-04 | 2010-03-04]]
** February
*** [[Beta_Server_Office_Hours/Minutes/2010-02-25 | 2010-02-25]]
*** [[Beta_Server_Office_Hours/Minutes/2010-02-18 | 2010-02-18]]
*** [[Beta_Server_Office_Hours/Minutes/2010-02-11 | 2010-02-11]]
*** [[Beta_Server_Office_Hours/Minutes/2010-02-04 | 2010-02-04]]
** January
*** [[Beta_Server_Office_Hours/Minutes/2010-01-21 | 2010-01-21]]
*** [[Beta_Server_Office_Hours/Minutes/2010-01-14 | 2010-01-14]]
*** [[Beta_Server_Office_Hours/Minutes/2010-01-07 | 2010-01-07]]
* 2009
** December
*** [[Beta_Server_Office_Hours/Minutes/2009-12-17 | 2009-12-17]]
*** [[Beta_Server_Office_Hours/Minutes/2009-12-10 | 2009-12-10]]
*** [[Beta_Server_Office_Hours/Minutes/2009-12-04 | 2009-12-04]]
** November
*** [[Beta_Server_Office_Hours/Minutes/2009-11-26 | 2009-11-26]]
*** [[Beta_Server_Office_Hours/Minutes/2009-11-19 | 2009-11-19]]
*** [[Beta_Server_Office_Hours/Minutes/2009-11-12 | 2009-11-12]]
*** [[Beta_Server_Office_Hours/Minutes/2009-11-05 | 2009-11-05]]
** October
*** [[Beta_Server_Office_Hours/Minutes/2009-10-29 | 2009-10-29]]
*** [[Beta_Server_Office_Hours/Minutes/2009-10-22 | 2009-10-22]]
*** [[Beta_Server_Office_Hours/Minutes/2009-10-15 | 2009-10-15]]
*** [[Beta_Server_Office_Hours/Minutes/2009-10-08 | 2009-10-08]]
*** [[Beta_Server_Office_Hours/Minutes/2009-10-01 | 2009-10-01]]

[[Category:Bug Tracker]]
[[Category:Quality Assurance]]
[[Category:QA_Portal]]
[[Category:User Groups]]

Talk:Agni Pilot Regions

2010-09-14T14:15:00Z

Buckaroo Mu: /* Addition and Removal Requests */

== Discussions ==
* Hope you don't mind Dante, added some formatting to allow for more use if needed and to hopefully keep things easy to read. [[User:Gordon_Wendt|<font color="green">''GW''</font>]] <sup><small>([[User talk:Gordon_Wendt|<Font color="red">T</font>]]|[[Special:Contributions/Gordon Wendt|<font color="blue">C</font>]])</small></sup> -- 06:05, 22 August 2009 (UTC)
* any possibility of adding some of the new Linden Home sims? we could probably use one of each type to test the moles code on new rollouts... I'd like to graciously nominate Fujiwara sim for the japanese theme sim (I have a plot there while I check out what can be done to spruce up such plots) <br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 16:37, 30 March 2010 (UTC)

== Addition and Removal Requests ==
Place requests for region addition/removal below. The wiki edit must be made by the '''land owner''' to validate the request.
----

*Honeoye (I'm ''an'' owner, but not the only one) [[User:Buckaroo Mu|Buckaroo Mu]] 14:15, 14 September 2010 (UTC)

Linden Lab Official talk:What are Second Life's subnets?

2009-12-05T04:56:30Z

Buckaroo Mu:

This page needs to be updated. Torley's last edit removed required blocks. Anyone who follows the instructions on the blog post to open only the listed subnets will still be unable to connect.
Complete list is:
63.210.156.0/22
64.34.14.0/24
64.154.220.0/22
70.42.62.0/24
8.2.32.0/22
74.201.98.0/23
8.4.128.0/22
64.127.104.64/30
8.10.144.0/21
64.127.112.104/29
216.82.0.0/18
64.127.121.88/29
64.127.123.192/26
64.147.162.0/26
64.147.180.128/27
69.80.215.224/30 [[User:Buckaroo Mu|Buckaroo Mu]] 04:54, 5 December 2009 (UTC)

Linden Lab Official talk:What are Second Life's subnets?

2009-12-05T04:54:39Z

Buckaroo Mu: NEEDS REVISION! Badly!

User:Buckaroo Mu

2008-06-19T20:01:10Z

Buckaroo Mu: /* Buckaroo Mu: First Life */

== Buckaroo Mu: Second Life ==
DJ, Dragon, Scripter - and a little of everything else. I sell scripted gadgets in my store in Wildmutt, DJ here & there, and help to lead the Dragons of Pern RP group headquartered on the Gianfar Estate. I'm married to the lovely Wendy Foxchase, talented clothing, shoe, hat, and jewelry designer, and an all-around wonderful person to be around.

== Buckaroo Mu: First Life ==
OK, it's not my real name, but it's close enough. I am a life-long Geek of All Trades, currently serving as the Systems & Network Administrator for a large non-profit in the Mid-West USA (UTC-6/5). In the past, I have been: all ranks from Captain to ballast of a sailing vessel; Kinko's copy-boy; Arc-welder repairman, US Army Radio Repairman (ret); VAX, Novell, and Windows System Admin; Novell Server, Windows, PHP, and AVR Systems Programmer; and telephone Tech Support, to name a few.

I am an advocate of F/OSS, and use FreeBSD whenever possible rather than Windows (Although I do use XP on all of my desktops). I have converted my employer from Novell to FreeBSD/Samba/LDAP (much to their delight), and incorporate as much F/OSS as I can. I cannot say I'm good with C++ - I'm a Guru-level programmer with plain C, never learned much about the ++ part - but I do hope to be useful in the development of Second Life as an Open-Source System.

I'm also married to the Real Life woman behind Wendy Foxchase, and have been for the last glorious 17+ years.

{{Jira Reporter}}

User:Buckaroo Mu

2008-06-19T20:00:10Z

Buckaroo Mu: /* Buckaroo Mu: Second Life */

Open Source Meeting/Agenda

2008-06-19T19:10:57Z

Buckaroo Mu: Added discussion of the uncompressed texture cache and related issues.

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring items up on [[SLDev]] before or concurrently with adding them as agenda items here.

== Agenda ==

* Next item? Your name? (sign with "<nowiki>~~~~</nowiki>" which will be converted to your name + timestamp)

Default agenda (barring agenda above):
* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Threaded Local File System (LLFSThread class) - what are LLs plans for it? [[User:Carjay McGinnis|Carjay McGinnis]] 10:51, 17 June 2008 (PDT)
* Triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240
* Meta Agenda:
{| border=2 cellpadding=5
|-
| How do you feel about relative C++ noobs (*waves!*) jumping headfirst into the client source to explore it? Do you prefer that only people with years of prior C++ experience try to be involved with the open source project? ("Come back when you've actually used a multimap in a program!")

I am wondering if showing up at the open source meeting and asking what may seem as "stupid beginner's questions" would be perceived as annoying and a waste of your professional time. (For example, why is ll_apr_file used for open/read/write/etc rather than just apr_file? Is llapr.cpp a shim library, to make transitioning from the LLLFS easier? And IS the LLLFS being replaced by the APR? I can't find any official coding policy or notes pointing in that direction. Is it okay to discuss this in SL-Dev or not?)

My interest and involvement in the source is mostly because I want the VFS expunged, and the overall caching performance improved... but since this coding task is apparently not on anyone else's agenda, I guess there's room for a QBASIC/LSL2/Apple II 6502-assembly programmer to explore the issue. (Note, the only thing I've ever threaded is a needle.) [[User:Scalar Tardis|Scalar Tardis]] 10:23, 19 June 2008 (PDT)
|}
* Discuss the changes to llTextureFetch and llTextureCache recently discussed on SLDEV, any issues that may arise from moving the decode and network fetch operations to llTextureCache (or possibly more or less combining the two classes into one), and other "uncompressed cache" issues. [[User:Buckaroo Mu|Buckaroo Mu]] 12:10, 19 June 2008 (PDT)

SLDEV Discussion - Texture Cache Plan of Attack

2008-06-14T23:13:21Z

Buckaroo Mu: OK, done. Discuss amonst yourselves

{{ViewerArchNav|parent=Image System}}

Discussion is underway in the SLDev Mailing List regarding options to overhaul the texture cache. Mostly the plan involves storing decompressed textures, rather than the JPG2000 compressed versions, which allows the Texture Fetch operations to skip the decode, which is currently the major bottleneck in the cache system. This article is for summarizing, planning, and status of this project. Please discuss via the SLDev mailing list.

== Overview ==
=== Current Implementation ===
Currently, the client will download uncached JPG2000 textures from the region/asset servers, progressively decode and apply them to the faces rendered in whatever quality level is currently available. As more data is downloaded, it is further decoded, and the quality rendered goes up. Textures are cached in a three-part system sharing space with the [[VFS]], described in the [[Texture Cache]] article.

=== New Plan ===
The discussion on the SLDev list has been very helpful in nailing down ways to improve the cache. The biggest change will be caching of textures in an un-compressed format - TGA or Raw - while preserving the existing obfuscation technique to prevent direct ripping of the cached images. In addition, the cache settings will be split into two separate caches - the VFS for objects that use it currently, and a completely new layer of cache exclusively for textures.

== Steps ==
=== Rework Cache to store multiple formats ===
Currently, the texture cache can read TGA and JPG2000 files from the cache. However, it has no way to ''write'' TGA to the cache. The interface between llTextureFetch and llTextureCache will need to be refactored to support storing and retrieving in a format-agnostic way, allowing JPG2000, TGA, and Raw to to exist simultaneously in the cache, with the possibility of adding others down the line if needed relatively easily.

In short, the calls from llTextureFetch to llTextureCache, and the return data, should include a Format Identifier, a block of data for the image itself (in whatever format is indicated by the Format Identifier), and any other details that may be required such as data size, image dimensions, and (if necessary) color depth. llTexureCache should be able to store and retrieve this data in a format-agnostic way, ideally returning decoded data to llTextureFetch as a llRawImage object. Metadata would be stored in the cache index, discussed below, with the bulk of the data stored in the manner it is done now - subfolders with filenames equivalent to the UUID of the texture.

=== Rework Cache Index for Greater Storage ===
Currently, the Texture Cache shares space with the VFS, and is limited to 800MB - 80% of the maximum total "cache size", the other 20% of which is reserved for the VFS. With the cache capable of storing uncompressed files, it could grow much faster; and with the cost of disk space these days, limiting the cache to 1GB is ludicrously inadequate. A separate slider in the "Network" preferences tab should allow the individual specification of max VFS ("Object Cache") and max Texture caches. In discussion, many commenters stated that they would allocate as much as 100GB to a texture cache. Aside from the speed benefit garnered from a larger cache, it also will dramatically reduce the amount of textures that would need to be re-downloaded due to a lower cache discard rate.

The Cache Index would store Metadata about the texture - the Format ID, the dimensions, file size, and color depth (if necessary), and, like the current cache index, would also have the first (arbitrary number of) bytes of the actual data - primarily for obfuscation purposes, to prevent the casual ripping of textures from the cache. Multiple copies of the same texture could be stored in the cache, in different formats - for example, stored as JPG2000 while progressively downloading, then stored in uncompressed format once complete. The Texture Fetcher would simply request a texture, and the cache would respond with the cached version available with the lowest CPU-overhead - Raw first, then TGA, then JPG2000, with the network fetch as the fail-through option. Ideally, once a texture has been downloaded completely and decoded, it would be stored as a Raw image, and the JPG2000 version would be marked as "expired" or otherwise scheduled for purging from the cache. The bulk of the texture data, stored in the UUID-named file in the subfolders of the cache, will need to have an extension added to it that signifies the Format ID to allow co-existence of multiple encodings of the same texture.

Some discussion was brought up about XORing the raw texture data with a hard-coded key, or perhaps one based on the Hardware Hash of each individual machine - in effect a fast but low-quality encryption. This has been largely disregarded in the interest of attaining the best speed - although it remains an option if the community demands more obfuscation than currently exists in the texture cache.

=== Cache Discard Optimization ===
There is discussion on the [[Texture Cache]] page regarding further optimization or replacement of the Cache Discard algorithms, which should probably be moved here - however, this portion is not a part of the current ongoing discussion in SLDev. I will leave it to someone else to take the initiative on this.

[[Category:Design Discussions]]

SLDEV Discussion - Texture Cache Plan of Attack

2008-06-14T23:05:35Z

Buckaroo Mu: Save early, save often. Still in progress.

{{ViewerArchNav|parent=Image System}}
''' DO NOT EDIT - CREATION IN PROGRESS '''

Discussion is underway in the SLDev Mailing List regarding options to overhaul the texture cache. Mostly the plan involves storing decompressed textures, rather than the JPG2000 compressed versions, which allows the Texture Fetch operations to skip the decode, which is currently the major bottleneck in the cache system. This article is for summarizing, planning, and status of this project. Please discuss via the SLDev mailing list.

== Overview ==
=== Current Implementation ===
Currently, the client will download uncached JPG2000 textures from the region/asset servers, progressively decode and apply them to the faces rendered in whatever quality level is currently available. As more data is downloaded, it is further decoded, and the quality rendered goes up. Textures are cached in a three-part system sharing space with the [[VFS]], described in the [[Texture Cache]] article.

=== New Plan ===
The discussion on the SLDev list has been very helpful in nailing down ways to improve the cache. The biggest change will be caching of textures in an un-compressed format - TGA or Raw - while preserving the existing obfuscation technique to prevent direct ripping of the cached images. In addition, the cache settings will be split into two separate caches - the VFS for objects that use it currently, and a completely new layer of cache exclusively for textures.

== Steps ==
=== Rework Cache to store multiple formats ===
Currently, the texture cache can read TGA and JPG2000 files from the cache. However, it has no way to ''write'' TGA to the cache. The interface between llTextureFetch and llTextureCache will need to be refactored to support storing and retrieving in a format-agnostic way, allowing JPG2000, TGA, and Raw to to exist simultaneously in the cache, with the possibility of adding others down the line if needed relatively easily.

In short, the calls from llTextureFetch to llTextureCache, and the return data, should include a Format Identifier, a block of data for the image itself (in whatever format is indicated by the Format Identifier), and any other details that may be required such as data size, image dimensions, and (if necessary) color depth. llTexureCache should be able to store and retrieve this data in a format-agnostic way, ideally returning decoded data to llTextureFetch as a llRawImage object. Metadata would be stored in the cache index, discussed below, with the bulk of the data stored in the manner it is done now - subfolders with filenames equivalent to the UUID of the texture.

=== Rework Cache Index for Greater Storage ===
Currently, the Texture Cache is part of the VFS, and is limited to 800MB - 80% of the maximum total "cache size", the other 20% of which is reserved for the VFS. With the cache capable of storing uncompressed files, it could grow much faster; and with the cost of disk space these days, limiting the cache to 1GB is ludicrously inadequate. A separate slider in the "Network" preferences tab should allow the individual specification of max VFS and max Texture caches. In discussion, many commenters stated that they would allocate as much as 100GB to a texture cache. Aside from the speed benefit garnered from a larger cache, it also will dramatically reduce the amount of textures that would need to be re-downloaded after being purged from the cache.

The Cache Index would store Metadata about the texture - the Format ID, the dimensions, file size, and color depth (if necessary), and, like the current cache index, would also have the first (arbitrary number of) bytes of the actual data - primarily for obfuscation purposes, to prevent the casual ripping of textures from the cache. Multiple copies of the same texture could be stored in the cache, in different formats - for example, stored as JPG2000 while progressively downloading, then stored in uncompressed format once complete. The Texture Fetcher would simply request a texture, and the cache would respond with the version available with the lowest CPU-overhead - Raw first, then TGA, then JPG2000, with the network fetch as the fail-through option. Ideally, once a texture has been downloaded completely and decoded, it would be stored as a Raw image, and the JPG2000 version would be marked as "expired" or otherwise scheduled for purging from the cache. The bulk of the texture data, stored in the UUID-named file in the subfolders of the cache, may need to have an extension added to it that signifies the Format ID to allow co-existence of multiple encodings of the same texture.

Some discussion was brought up about XORing the raw texture data with a hard-coded key, or perhaps one based on the Hardware Hash of each individual machine - in effect a fast but low-quality encryption. This has been largely disregarded in the interest of attaining the best speed - although it remains an option if the community demands more obfuscation than currently exists in the texture cache.

=== Cache Discard Optimization ===
There is discussion on the [[Texture Cache]] page regarding further optimization or replacement of the Cache Discard algorithms, which should probably be moved here - however, this portion is not a part of the current ongoing discussion in SLDev. I will leave it to someone else to take the initiative on this.

[[Category:Design Discussions]]

SLDEV Discussion - Texture Cache Plan of Attack

2008-06-14T22:38:59Z

Buckaroo Mu: Base article - creating in progress, saving with a "Don't work on me yet" flag.

Texture Cache

2008-06-14T22:11:28Z

Buckaroo Mu: Added link to current plan as discussed on SLDev, separate page.

{{ViewerArchNav|parent=Image System}}

'''LLTextureCache''' is a worker thread interface class used for reading and writing texture data to the local disk cache (part of the [[Image System]])

== Current design ==
* There are two different disk caches used by the Second Life Viewer:
** The static texture cache
*** Located in the Second Life/skins/textures directory
*** This is a read-only cache which contains common textures shipped with the Viewer
** The general texture cache
*** Stored in a 'textures' subdirectory in the cache directory, specified in the preferences
*** This is a two tiered read/write cache
**** A list of all files in the cache is stored in texture.entries
**** The header for each image (enough to identify the size and load the first mip level) is stored in texture.cache
**** The body (minus the header) for a limited (by the cache size) number of entries is stored in textures/[0-9a-f]/textureid
* Requests to read or write to the cache are processed in the priority given
* The results are given through a [[Responder]] class when they are ready

== Disk storage format ==
* Currently all textures in Second Life are stored in the JPEG2000 compressed format
=== The header consists of two files ===
* cache/texture.entries
''8 byte header:''
<pre>
struct EntriesInfo
{
F32 mVersion;
U32 mEntries;
};
</pre>
''Array of 24 byte entries''
<pre>
struct EntriesInfo
{
LLUUID mID; // 128 bits
S32 mSize; // total size of image if known (NOT size cached)
U32 mTime; // seconds since 1/1/1970
};
</pre>
* cache/texture.cache
''Array of 600 byte entries (first 600 bytes of .j2c file)''
=== The main "body" cache consists of an entries file and 16 subdirectories ===
* cache/textures/texture.entries
** This file consists of a an array of EntriesInfo, except mSize is the body size, not the total image size
** When a texture is written to the cache, a new EntriesInfo struct is appended to the file ''regardless of whether or not an entry already exists''.
*** This prevents the disk cache from having to explicitly keep track of which entries have bodies stored in the main cache
** On startup and when the disk cache becomes full, textures.cache is parsed
*** Only the latest entry for each texture is retained.
*** Old entries are purged until 10% of the disk cache is available
''Array of 24 byte entries''
<pre>
struct EntriesInfo
{
LLUUID mID; // 128 bits
S32 mSize; // size of texture body stored on disk
U32 mTime; // unused TODO: create separate structure without this entry
};
</pre>
* cache/textures/[0-f]/uuid
''Body of the texture, i.e. all of the texture minus the header''

== Analysis ==

(so far:)

In the discussion of the texture cache has, it is apparent that there are two separate issues involved. Beyond the view of the texture cache, there is the method to which to determine how long a texture is stored in the cache and there is medium format of the textures being stored. At this time, the format of the medium is still under discussion. However, there is significant data to move to a new system for the method to determine the storage time.

* [http://www.vldb.org/dblp/db/conf/vldb/vldb94-439.html 2Q cache system]. Benefits include that the 2Q method has already been studied by other groups and that it is possible to fit this method into the current design. Only drawback noticed so far is that it appears to carry a specific implementation, but this drawback will need to be confirmed. The 2Q's intended implementation may not easily allow for extra values in the cache system to determine factors of pixel coverage. The drawback is of low impact to the the current design since the significant pixel coverage data is stored in memory. However, in order to further implement the ideas being suggested in the discussion about the medium format and pixel coverage, we could adapt the 2Q system.

* [http://www.almaden.ibm.com/StorageSystems/projects/arc/ ARC] Algorithm designed by IBM Research as an improvement over LRU. Patent encumbered, however IBM will grant license for open source use only.

== Discussion about improvements ==

Main Article: [[SLDEV Discussion - Texture Cache Plan of Attack]]

The texture cache is a hot topic for optimization. Current ideas/subjects discussed from the mailing list include:
*Multi-level cache for uncompressed and compressed textures

*Example Cache Levels:
** Memory
** Uncompressed Disk
** Compressed Disk
** Low Rez Compressed
** Network
**A flexible policy architecture would be able to discard, cache, retrieve, and migrate texture data from one level to the next as is appropiate with an external XML file to facilitate fine tuning of policy parameters.

*Fixed block size cache to store images of any size that is a power of 2
*Reformatted textures, being changed from jpeg2000 to TGA (with or without RLE), BMP, GIF, or downsampled
*Storage:
**Filesystem
**Database
**Network
**Memory mapped
*Quality of cached images
*System Requirements
**Minimal
**Optimal
**Surveys
**Core(s)

Please use the [[Talk:Texture cache|Talk page]] to continue discussion.

Related articles: [[Image System]], [[VFS]]

[[Category:Design Discussions]]

User:Buckaroo Mu

2007-06-05T05:11:22Z

Buckaroo Mu: Jira Reporter update

== Buckaroo Mu: Second Life ==
I am a successful DJ, spending my nights at ~Mons Venus~, the hottest Rock & Blues Club around. I also enjoy building and scripting, and am looking to get into more complicated designs as time allows. I am Chief Moderator of the History & Moral Philosophy discussion group, which has open enrollment and meets on a regular basis to discuss the gray areas of existence. I'm married to the lovely Wendy Foxchase, talented clothing, shoe, hat, and jewelry designer, and an all-around wonderful person to be around.

== Buckaroo Mu: First Life ==
OK, it's not my real name, but it's close enough. I am a life-long Geek of All Trades, currently serving as the Systems & Network Administrator for a large non-profit in the Mid-West USA (UTC-6/5). In the past, I have been: all ranks from Captain to ballast of a sailing vessel; Kinko's copy-boy; Arc-welder repairman, US Army Radio Repairman (ret); VAX, Novell, and Windows System Admin; Novell Server, Windows, PHP, and AVR Systems Programmer; and telephone Tech Support, to name a few.

I am an advocate of F/OSS, and use FreeBSD whenever possible rather than Windows (Although I do use XP on all of my desktops). I have converted my employer from Novell to FreeBSD/Samba/LDAP (much to their delight), and incorporate as much F/OSS as I can. I cannot say I'm good with C++ - I'm a Guru-level programmer with plain C, never learned much about the ++ part - but I do hope to be useful in the development of Second Life as an Open-Source System.

I'm also married to the Real Life woman behind Wendy Foxchase, and have been for the last glorious 16 years.

{{Jira Reporter}}

Web Textures

2007-01-27T02:31:54Z

Buckaroo Mu: /* Do nothing, just implement it */

=Summary=
This page is about dynamic web textures, a feature to allow an LSL script to assign an image URL to a face and cause it to dynamically update from the script. This is not HTML-on-a-prim, though it shares some of the same complications regarding anonymity.

This raises a potential issue regarding [[Expected Privacy]]. The only practical way to accomplish dynamic web textures is to let the client download the image directly. This will expose user's IP addresses. This issue is also there for HTML on a prim, though the limitations several Lindens have mentioned to reduce the processing overhead of HTML on a prim - similar to the current limitations for media textures - make it less likely to be easily abused.

<blockquote>We are looking toward making it possible for prims to reference external websites for texture information, which is where PNG textures would start to come into play. -Phoenix Linden</blockquote>

=Benefits of this feature=

#Negates the need for scripts like XyText that are very laggy when dynamic displays are large.
#Allows for things like streaming news service HUDs.
#Interactive games can present large amounts of off-world data.
#Corporations that already have many dynamic web assets can reuse them in-world.
#Live porn.
#Web Cams.

=Potential LSL implementation=
<pre>
llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);
</pre>

Example with text generation script:

<pre>
llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llRefreshTextureURL(integer face);
</pre>

=Suggested Privacy Protections=
Because this feature would expose the IP address of an agent in a way that could identify the agent, especially on a HUD, several suggestion were made to enhance privacy protections. They are listed in order of least effort to implement to most effort.

==Do nothing, just implement it==
*Pro: Feature itself is somewhat easy to implement, if images are powers of 2
*Pro: Sets precedent for other features that may expose IP association information.
*Con: Sets precedent for other features that may expose IP association information.
**I hate to be the bearer of bad news, but the IP is already exposed if the avatar is listening to streamed music. I check my stream host, and see a list of IP addresses of all who are listening, how long they've been listening. Not that I ''do'' anything with this info, but it's there for the gathering. [[User:Buckaroo Mu|Buckaroo Mu]] 18:31, 26 January 2007 (PST)
*Con: Unannounced loss of privacy.
**Mitigation: Announce it first.
*Con: Could become a public relations nightmare if users react badly.

==Global on/off, with one time dialog opt-in==
The client could prompt the first time you encounter a web texture, and ask you if you want to enable it, warning you that it will expose your IP address to third parties. This would be similar to the way parcel streaming media prompts the first time you encounter a parcel with it set.
*Con: The user is asked to make technical decisions they might not understand.
*Con: The user must sacrifice all dynamic web content to get privacy for their IP.
*Pro: No annoyance for those who don't care about exposing IP associations.

==Proxy Options==
The client would provide a place to enter a HTTP proxy address for web textures. This would allow the user to enter an anonymizing proxy service if they want to.
*Pro: Easy to implement
*Pro: Proxy support will be needed anyway for the general move to HTTP texture transfers for regular asset textures.
*Con: Configuring proxy settings for anonymizing proxies can be extremely difficult even for professionals.
** Mitigation: this work can be hidden by the browser or browser extensions, so SL or a plugin for SL could do the work.
*** But there isn't such a plugin mechanism yet.
*Con: Anonymizing proxies are slow and unreliable.
*Con: Proxy support is not even implemented yet for the help browser
*Con: Default settings (no proxy) expose users to privacy violations.
** Which means this is likely to be a PR disaster.

==Attachments==
Using web textures in an attachment (particularly a HUD) provides an attacker the greatest oppportunity to ensure that they have a correct match to an IP address, so while this is not that useful for bulk data gathering it's particularly problematic for targeted attacks. It would probably be best not to make web textures on attachments an exception to any wider restrictions. Web textures on HUDs, though, are particularly useful, so there should be some mechanism to allow a user to grant their own attachments the right to load web textures even if they are otherwise disabled.

*Pro: Allows cautious users to use web-enabled HUDs.
*Pro: Promotes effective low-lag tools.

'''Dialog Boxes'''

The client could pop up some sort of dialog when attaching a HUD with web textures, asking if you want to allow the HUD to use them.

*Pro: Easy on the scripter.
*Pro: Implemented entirely in the client.
*Con: The user is asked to make technical decisions they might not understand.
*Con: It's a unique mechanism.
*Con: Dialog boxes are annoying.
*Pro: Establishes precedent for other useful client-side security and privacy tools
**Or is that a con? :)

'''The Permissions system'''

Alternatively, this could be done through the normal LSL permission system with a permission request, and something like PERMISSION_TEXTURE_URL.

*Pro: Already well-understood interface.
*Con: Dialog boxes are annoying.
*Con: The user is asked to make technical decisions they might not understand.

'''Whitelists'''

This could simply be handled the same way as third-party textures in the proposal below. The same pros and cons apply.

==White/Black List==
Similar to Firefox/IE popup blocking, the client could manage white/black lists.
*Pro: Flexible and complete control
*Pro: users not concerned about privacy could select "Accept everything"
*Con: If poorly implementd, this would cause a lot of user input: (for example, thousands of prompts per second for someone flying over the mainland).
*Con: The user is asked to make technical decisions they might not understand (the user might be tricked, they might not know who to trust).
*Con: Very complex to implement, UI elements hard to design effectively.
**Mitigation: Using existing controls (texture cues, pie menu) would simplify the implementation and make the interface more familiar.
*Con: Reinstalling could lose settings.
**Mitigation: Selecting a "safe default" would protect naive users. If it's easy to update the whitelist or disable the protections again this shouldn't cause any major inconvenience for anyone.

===Suggested implementation:===

'''Safe but convenient default behaviour.'''
*Textures on prims set to the land group are automatically loaded by default.
*Optionally - Textures set by scripts created by you, or owned by and readable by you are automatically loaded by default.
*All other textures are left unloaded.

'''No popups.'''
*Unloaded HTML textures have a distinct appearance.
*Optionally - Left-clicking on the object will load the unloaded texture(s).
*Right-clicking on an unloaded HTML texture will bring up the pie menu, and a pie menu option will allow you to load the textures on the object or whitelist it.
**Load the textures on this object.
**Always load textures on this object
**Always load textures from objects owned by this person
**Always load textures from objects in this group
*You can also remove these permissions if they are set.

'''Simple preferences'''
* Privacy setting: only three levels of privacy:
** Low - load all HTTP textures and HTML-on-a-prim automatically.
** Normal - default behaviour described above.
** High - No HTTP textures are loaded.
* Button to clear textures.

'''What is required of the Sim'''

When an HTTP texture is sent to the client, it's bundled with some UUIDs:
*The owner of the object.
*Optionally - The creator of the script that set the texture.
*Optionally - A flag indicating the user has granted permission to display this texture through the permission system as suggested under '''Attachments''', above.
*The group of the object.

==Change Users Privacy Expectation==
Make it clear to the users that their IP address association with their avatar name is not private information and can't be protected while still providing dynamic and seamless integration with the rest of the Internet.
*Pro: No technical implementation necessary.
*Con: Not easy.

==Trusted hosting partners==
Have one or more trusted hosting partners that would provide scriptable webspace on standard Linux servers. The key difference is that the partners could not allow the IP address of clients to pass through to the scripting language.
*Pro: Fully fixes privacy problem, with no effort required from the end user.
*Con: Hard to monitor trusted partners for compliance if more than one.
*Con: If only one, then developers have no choice.
*Con: Business risk from close external relationship with other company if only one provider.
*Con: Not in the spirit of SL.

==Linden Lab Webhosting==
Linden Lab would could offer their own webhosting that withholds end user IP similar to above.
*Pro: Fully fixes the privacy problem
*Pro: Could also be used as a super low latency way to do HTTPRequest calls to a web server. HTTPRequest limits could be raised for requests to these servers.
*Con: LL is not a web hosting company.
**But they sort of are... it's just a "3d web".

[[Category:Feature Requests]]

User talk:SignpostMarv Martin/Archive/Implementing new features

2007-01-13T00:16:50Z

Buckaroo Mu: /* Shortcut/Link/Alias function in Inventory */

== Alternate Rendering Engines ==
* 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)

:::It ''could be'' fudged with notecards - but how many hacks do you want in SL? The assignment of an additional inventory type at the server end, as far I as can tell from the viewer source, would require probably two lines of code. We need to work with LL to see if they would support this inclusion, rather than make kludges that work but are far less elegant, and may break scripts. [[User:Buckaroo Mu|Buckaroo Mu]] 16:16, 12 January 2007 (PST)

== DirectX3D Hardware Acceleration ==

The OpenGL code is scattered all over the entire codebase. You'd have to abstract out all the 3D code first, it wouldn't be an improvement it would be a complete rewrite.

== 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)

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. [[User:River Senyurt|River Senyurt]] 11:34, 12 January 2007

:: As I described in the Barriers to implementation section for this "feature", security such as this would have to be built into the server. Since the Viewer is now GPL, all it would take is for someone to remove this 'security' layer, and you're right back where you started, thus Linden Lab are highly unlikely to spend time implementing such a mechanism in the client. The method I described has benefits for both the main and teen grids anyway.

:: Aside from the odd oversight over the years (e.g. texture uploads, megaprims), all security and validation operations are executed on the server side. It fits into LL's behaviour to implement such checks on the server, and while they could, and most likely will do something alone these lines, there is unfortunately nothing you can do to stop somebody else making their client get nervous imagine you in your underwear. Or less.
:: [[User:SignpostMarv Martin|SignpostMarv Martin]] 04:18, 12 January 2007 (PST)

== Out of sight., out of mind ==

# The client has an option to prevent certain types of objects from being rendered
# Objects are addressed server-side by UUID

The client would have be made aware of the UUID of an object, categorising it as a new type of object, and a hotkey could be used to toggle the visibility.

Similarly, if a photographer or machinimaker is working in-world, the following options would be useful:

* Do not render anything other than the land owner's objects
* Do not render objects not owned by people on your friends list
* Do not render avatars on your friends list

This would enable people to deal with certain types of griefer attacks more easily, much in the same way that toggling particles on and off can be useful when particle poofers have been dropped.

[[User:SignpostMarv Martin|SignpostMarv Martin]] 15:32, 12 January 2007 (PST)

User:SignpostMarv Martin/Archive/Implementing new features

2007-01-11T17:15:18Z

Buckaroo Mu: /* Comments */

{{OSWikiContribBox}}

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.

: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)

=== 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 to 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)
# 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)

=== Embedded scripting language for client-side plugins ===

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 ====

==== Comments ====

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

* [[Linden Lab Bounties]]
* [[Community Bounties]]
* [[:Category:Bounties]]

Talk:Feature requests

2007-01-10T18:48:10Z

Buckaroo Mu:

What's missing: '''WHERE''' to file the requests...

Looks like most of them are ending up in [[Implementing_new_features|this]] page... [[User:Buckaroo Mu|Buckaroo Mu]] 10:48, 10 January 2007 (PST)

User:SignpostMarv Martin/Archive/Implementing new features

2007-01-09T19:30:01Z

Buckaroo Mu: /* Comments */

User:SignpostMarv Martin/Archive/Implementing new features

2007-01-09T19:28:32Z

Buckaroo Mu: /* More efficient local cache */

User:SignpostMarv Martin/Archive/Implementing new features

2007-01-09T19:26:45Z

Buckaroo Mu: Additional feature suggestions

Feature requests

2007-01-09T19:21:41Z

Buckaroo Mu: Moved specific feature requests to a different page.

User:Buckaroo Mu

2007-01-09T17:55:02Z

Buckaroo Mu: Introduction.

Feature requests

2007-01-09T17:37:29Z

Buckaroo Mu: Feature Request: Multiple Monitor Support

{{OSWikiContribBox}}

== Filing Feature Requests==
We're always looking for new ideas. Please let us know what you would like to see done.

== Refining Feature Requests ==

Features are more likely to get implemented if the description of the feature is clear. For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea.

== Minor Feature Requests ==
*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)

== Major Feature Requests ==
*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)

*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)

*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)

Feature requests

2007-01-09T17:28:52Z

Buckaroo Mu: Feature Request: DirectX3D or GPGPU Support

{{OSWikiContribBox}}

== Filing Feature Requests==
We're always looking for new ideas. Please let us know what you would like to see done.

== Refining Feature Requests ==

Features are more likely to get implemented if the description of the feature is clear. For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea.

== Minor Feature Requests ==
*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)

== Major Feature Requests ==
*A DirectX3D-driven version of the viewer, allowing those with ATi or Intel hardware accelerated cards to take advantage of the processing power. Alternatively, 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:28, 9 January 2007 (PST)

Feature requests

2007-01-09T17:23:52Z

Buckaroo Mu: Feature Request: Shortcut Inventory Type