Re: [opensource-dev] STORM-34 Test Binaries

[Celierra Darling]

It seems a little unclear to try to communicate "this can have privacy
implications" by putting the setting on the privacy tab.  It might be better
to write the setting label so it's more explicit (i.e. something like "Show
my favorites to anyone under 'Start At' before logging in" or "Show my
favorites under 'Start At' on login (before authenticating)" or etc.).

Celi


On Mon, Dec 27, 2010 at 11:59 AM, Carlo Wood  wrote:

> > I kinda have to agree with hitomi.
>
> I agree with Andrew; it's a privacy sensitive thing
> and users shouldn't accidently flip it without thinking
> because it's on the normal 'General' page.
> If they need or want it, then I'm sure they'll find it,
> like they find everything else. Also, it will take a
> while before a user needs links to favourite places
> on their login page: those are not newbies. It's sufficient
> to put the option in a place that requires more knowledge
> (and exploration) of the viewer interface.
>
> --
> Carlo Wood 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Help prevent DOS line endings...

[Celierra Darling]

For those that have already followed the instructions there - the coding
standard says to prefer tabs, not spaces, which is the opposite of what the
page was instructing until just now.

Celi


On Tue, Feb 1, 2011 at 7:35 AM, Oz Linden (Scott Lawrence)  wrote:

> Other than a few files that appear to be completely Windows specific,
> and I did not know for sure did not require them, I've converted all the
> DOS line endings in viewer-development back to plain linefeeds.  I'll be
> checking regularly for any that get added (hopefully before they get
> into the main repo) and advising the perpetrators of the error of their
> ways...
>
> So that I have a resource to direct them to, and to help prevent any new
> developers from committing this minor sin, we need a set of clear
> instructions on what Windows tools do this correctly and how to
> configure them to do so.   Please help by adding to:
>
>
> https://wiki.secondlife.com/wiki/How_to_avoid_DOS_line_endings_in_Windows_tools
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

[Celierra Darling]

I'm still seeing both of these, for FMOD and for KDU, in viewer-development
rev 15768 (8b6c61efed4c), the latest revision at the moment.  I can get past
the FMOD step by explicitly specifying  -- -DFMOD:BOOL=FALSE on the
configure command line (suggested by Ima on #opensl), but KDU doesn't seem
to have an option that's so simple.  (I'd rather not edit the URL to
download gray-area files if I can help it.)

Celi


On Thu, Apr 7, 2011 at 7:45 AM, WolfPup Lowenhar wrote:

> Ok I see two things here Glimmering Sands:
>
> 1.  You are using an old repository the current one is actually viewer
> development as autobuild has been merged in.
>
> 2.  FMOD and KDU are actually somewhere in
> http://s3-proxy.lindenlab.com of which we as Open Source Developers have
> NO access to and are NOT allowed to have access to.
>
>
>
> Ima Mecanique,
>
> The FMOD and KDU libs are not distributed externally if you look at a
> current copy of the autobuild.xml you will find that the address is a
> private one for them and a few others LL cannot freely distribute. Now LL
> has ‘provided’ a way for those that have FMOD already to ‘re-pacakage’ this
> one for use in the autobuild. LL dose not actually modify any of the FMOD
> files but actually creates a ‘wraper’ in the form of llaudio to interface
> with fmod.dll so that those that are on Windows will have working sound.
>
>
>
> *From:* opensource-dev-boun...@lists.secondlife.com [mailto:
> opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Ima Mechanique
> *Sent:* Thursday, April 07, 2011 7:03 AM
> *To:* opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] s3-proxy.lindenlab.com points to a private
> IP address?
>
>
>
> > Linden Lab should not be distributing either of these libraries, as
> > they do not have a license that permits them to do so(from what I have
> > heard from them in other dialogs). So this violates and possibly voids
> > their license for Kakadu, as well as all of their careful planning to
> > keep it out of every developers hands except for their own.
> >
> > I hope that they will take these down, and it is not an error that you
> > should NOT be able to download them. The error here is that they are
> > trying to be downloaded at all.
>
> This is something of a grey area.
> For KDU, this is not distributing per se, as it is only the headers and
> lib file to link against, not the final library being made available.
> I'm not privy to the license details so have no idea if this would be a
> breach of terms..
>
> For FMOD, things are clearer.
>
> "The contents of the FMOD distribution archive may not be redistributed,
> reproduced, modified, transmitted, broadcast, published or adapted in any
> way, shape or form, without the prior written consent of the owner,
> Firelight Technologies, be it by tangible or non tangible media.
>
> The fmod.dll file may be redistributed without the authors prior
> permission,
> and must remain unmodified."
>
> LL have both modified the archive (by creating a new one) and are
> redistributing that modified version, so I hope they have obtained
> written permission from Firelight Technologies  I'd hope that FT would
> be happy to grant permission, as it relieves their servers of the
> download bandwidth required.
>
>
> > On Wed, Apr 6, 2011 at 23:34, Glimmering Sands
> >  wrote:
> > > Well, I have discovered, through the wonders of Mr. Google, that there
> > > is an older copy autobuild.xml out there at:
> > >
> > >
> https://bitbucket.org/merov_linden/viewer-autobuild2010/src/44f214103cff/autobuild.xml
> > >
> > > and I was able to simply use the
> > >
> > > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/...
> > >
> > > lines for both fmod and kdu (would it be considered a bug that Linden
> > > Labs is distributing an autobuild.xml that uses internal only paths
> > > rather than using the external paths (that I guessed the used to
> > > have?)
> > >
> > > One can also wonder why you would let internal DNS records be allowed
> > > to external sites as well...
> > >
> > > Sometime later I will discover if this solves my grey goo box problem
> or not :-)
> > >
> > > Hugs,
> > >
> > > Glimmering
>
>
> --
> Ima Mechanique
> ima.mechanique(at)blueyonder.co.uk
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
> --
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1209 / Virus Database: 1500/3556 - Release Date: 04/06/11
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information 

Re: [opensource-dev] Intra-sim teleports and Local Chat History

[Celierra Darling]

I think it does serve as a good deliminator between distinct sections of the
chat record, and as a nice bit of context in chat logs.  And logging only
with inter-sim teleports happens to be a good rough indicator for what sort
of context shift could be 'big enough' to log.  For those uses, one might
consider changing it to list both the origin and destination of the teleport
(or perhaps revamp it entirely for that usage specifically).

Celi


On Sat, Apr 9, 2011 at 4:40 PM, Opensource Obscure <
opensourceobsc...@gmail.com> wrote:

> On Sat, Apr 9, 2011 at 21:29, Oz Linden (Scott Lawrence)
>  wrote:
>
> > Does anyone think that there's some important reason to change the
> > current behavior?  Is the notice in chat any more useful?  Indeed, given
> > that we have the teleport history, is the notice in chat really needed?
>
> I'm used to the notice in chat and I find it useful. But I think
> it was created as a workaround looking for a better implementation,
> which the current teleport history in sidebar is supposed to be.
>
> From a design/usability point of view, I'd say that removing the
> notice in chat would be the correct solution. That would move
> this functionality from a non-related place in the interface
> (the chat history) where it's only partially implemented,
> to its dedicated place where it works completely.
>
> Opensource Obscure
> --
> http://twitter.com/oobscure - http://opensourceobscure.com/lol
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

[Celierra Darling]

Ah, for some reason USE_KDU was already true, which caused cmake to keep
hallucinating that it needed KDU (regardless of whether the KDU package
existed in autobuild).  With -DUSE_KDU=FALSE on the command line, I ended up
not needing to touch the autobuild xml files:

autobuild configure -- -DFMOD:BOOL=FALSE -DINSTALL_PROPRIETARY:BOOL=FALSE
-DUSE_KDU:BOOL=FALSE

(Since cmake/LLKDU.cmake sets USE_KDU to true when INSTALL_PROPRIETARY is
true, maybe it should also explicitly falsify USE_KDU when
INSTALL_PROPRIETARY is set to be false?)

With Visual Studio 2010, you also apparently have to run the IDE at least
once prior to configuring, or else the background Visual Studio instance
that it spawns ends up crashing out.

Celi

On Sun, Apr 10, 2011 at 7:11 AM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

>  On 2011-04-09 22:57, Celierra Darling wrote:
>
> Hmm, this didn't work for me; autobuild still attempts to download kdu even
> if I specify DINSTALL_PROPRIETARY.  (If it helps, the same thing happens if
> I use autobuild configure -c OpenSourceRelWithDebInfo , though I don't
> have to specify DFMOD there.)
>
>
> Sorry - I wasn't clear.
>
> To prevent the attempt to download, you have to take the installable out of
> the autobuild configuration.  The cmake variable only prevents trying to use
> it.
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Windows compiling problem

[Celierra Darling]

I'm getting the same problem (either with 7.1 or 7.0a in the message,
depending on which order of includes I'm trying at the moment).  I've tried
fiddling with include paths, updating DirectX and UNSIS, building without
the 7.1 SDK update so far, without success.  But I can't find where to
download the 7.0a version of the SDK, only 7.0 and 7.1. :(  I did notice
that VS 2010 installed a 32-bit-host version of the 7.0a SDK instead of the
64-bit-host versions that the SDK installers picked for me, though I don't
know if that's causing this particular problem.

I haven't tried building from command consoles yet, just the GUI IDE.

From
http://social.msdn.microsoft.com/Forums/en/Vsexpressinstall/thread/9ec96544-0b7d-4b0b-8eca-dffb30a385be#d79e6ab7-6976-430b-98c7-976f035263fdthere's
some instructions regarding a Platform Toolset setting that's
supposed to be for an entire solution. I don't see that, but I do see one
such setting on each individual project, and it's set to "v100" (7.0a, I
would guess?) instead of "Windows7.1SDK".  That seems a bit suspicious; I
presume we want it to be using 7.1 if it's installed?

Celi

On Fri, Apr 8, 2011 at 2:34 PM, Jonathan Welch  wrote:

> I've tried all the suggestions that people have suggested, but to no
> avail.  I still get messages like the one below.
>
> Anyone with more ideas?
>
> -- Build started: Project: llwindow, Configuration: Release Win32
> --
>  llwindowwin32.cpp
>  lldxhardware.cpp
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
> syntax error : identifier '__RPC__out_xcount_part'
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
> syntax error : ')'
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
> C1903: unable to recover from previous error(s); stopping compilation
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Windows compiling problem

[Celierra Darling]

Had the bad luck to run into a sketchy update among the ones released this
past Patch Tuesday, so in case anyone else is seeing the same thing:
If Windows Update can't seem to install KB2455033, there's a workaround [1]
going around saying to install KB2519277 first - but *don't* do that.  If
you do, then you indeed can install KB2455033 afterwards, but then
compilation will fail with this error:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\intrin.h(26):
fatal error C1083: Cannot open include file: 'ammintrin.h': No such file or
directory

If you happen to have hit this problem already, someone has a
workaround-around [2] involving reinstalling VS2010 and the 7.1 SDK before
installing VS2010 SP1, but I haven't gotten to trying that yet.

Celi

[1] https://connect.microsoft.com/VisualStudio/feedback/details/660653/
[2] https://connect.microsoft.com/VisualStudio/feedback/details/660584/



On Tue, Apr 12, 2011 at 6:53 PM, Nicky Perian  wrote:

> Dont' want to come across as self-promoting and am hesitant to advise LL
> devs but, this might help out.
>
>
> https://wiki.secondlife.com/wiki/User:Nicky_Perian/Visual_Studio_10_Autobuild
>
> --
> *From:* Joshua Bell 
> *To:* Jenn Leech 
> *Cc:* opensource-dev@lists.secondlife.com
> *Sent:* Tue, April 12, 2011 5:07:35 PM
>
> *Subject:* Re: [opensource-dev] Windows compiling problem
>
> I was running into that exact objidl.h issue until I updated my DirectX
> SDK. I had a 2008 SDK, I needed to uninstall and reinstall the June 2010 SDK
> linked from
> http://wiki.secondlife.com/wiki/Viewer_2_Microsoft_Windows_Builds
>
> (IMHO
> it was probably less about the SDK version than the install order.)
>
> On Tue, Apr 12, 2011 at 11:10 AM, Jenn Leech  wrote:
>
>> On my development machine I uninstalled the Windows SDK entirely, relying
>> on the one that ships with VS2010, to resolve a similar conflict. If a
>> similar tactic works for you, let us know!
>>
>> Thx,
>> - Jenn
>>
>> On Fri, Apr 8, 2011 at 11:34 AM, Jonathan Welch wrote:
>>
>>> I've tried all the suggestions that people have suggested, but to no
>>> avail.  I still get messages like the one below.
>>>
>>> Anyone with more ideas?
>>>
>>> -- Build started: Project: llwindow, Configuration: Release Win32
>>> --
>>>  llwindowwin32.cpp
>>>  lldxhardware.cpp
>>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
>>> syntax error : identifier '__RPC__out_xcount_part'
>>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
>>> syntax error : ')'
>>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
>>> C1903: unable to recover from previous error(s); stopping compilation
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Windows compiling problem

[Celierra Darling]

Okay, my problem was that I'd forgotten to uninstall the December 2006
version of the DirectX SDK prior to installing the June 2010 one, and the
2006 version ended up leaving behind many vestigial traces.  Had to
reinstall the 2006 version, then uninstall it.  (I also had to manually tell
the installer to uninstall, i.e. msiexec /X
%temp%/Microsoft_DirectX_SDK.msi, but I'm not sure if that's normal.)

Celi


On Tue, Apr 12, 2011 at 5:59 PM, Celierra Darling wrote:

> I'm getting the same problem (either with 7.1 or 7.0a in the message,
> depending on which order of includes I'm trying at the moment).  I've tried
> fiddling with include paths, updating DirectX and UNSIS, building without
> the 7.1 SDK update so far, without success.  But I can't find where to
> download the 7.0a version of the SDK, only 7.0 and 7.1. :(  I did notice
> that VS 2010 installed a 32-bit-host version of the 7.0a SDK instead of the
> 64-bit-host versions that the SDK installers picked for me, though I don't
> know if that's causing this particular problem.
>
> I haven't tried building from command consoles yet, just the GUI IDE.
>
> From
> http://social.msdn.microsoft.com/Forums/en/Vsexpressinstall/thread/9ec96544-0b7d-4b0b-8eca-dffb30a385be#d79e6ab7-6976-430b-98c7-976f035263fdthere's
>  some instructions regarding a Platform Toolset setting that's
> supposed to be for an entire solution. I don't see that, but I do see one
> such setting on each individual project, and it's set to "v100" (7.0a, I
> would guess?) instead of "Windows7.1SDK".  That seems a bit suspicious; I
> presume we want it to be using 7.1 if it's installed?
>
> Celi
>
>
> On Fri, Apr 8, 2011 at 2:34 PM, Jonathan Welch  wrote:
>
>> I've tried all the suggestions that people have suggested, but to no
>> avail.  I still get messages like the one below.
>>
>> Anyone with more ideas?
>>
>> -- Build started: Project: llwindow, Configuration: Release Win32
>> --
>>  llwindowwin32.cpp
>>  lldxhardware.cpp
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
>> syntax error : identifier '__RPC__out_xcount_part'
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
>> syntax error : ')'
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
>> C1903: unable to recover from previous error(s); stopping compilation
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 3D soound

[Celierra Darling]

Hmm, SL would first need to synthesize stereo sound, as should be heard
through headphones, very well, it seems. From what I can tell, the technique
ends up simulating wearing headphones when you're actually listening through
speakers.  According to the site, the idea is that the stereo sounds with
all the right audio cues (time and volume differences) were recorded, but if
you play it back using speakers, the illusion ends up destroyed by the
interfering crosstalk. [1]

But I'm pretty sure that some SL sounds (at least, voice - I vaguely recall
SL inworld audio stuff being more nuanced?) aren't synthesized with the
correct-for-headphones effects.  I remember feeling very disoriented in
voice meetings because people to my left or right ended up having their
voice playing pretty much exclusively in my left or right ear, which isn't
correct.  I could imagine that, in such situations, real-world crosstalk
from loudspeakers actually helps recreate the illusion during playback -
perhaps it was a bit of a hack based on having the volume difference be
interpreted as attenuation.
It does look like implementation is a lot more complicated than it, er,
sounds... There's something involving something called a BACCH filter, with
"some aspects not published for propriety reasons". [2]

So to apply this to SL, there'd need to be:
1) accurate synthesizing of sounds as would be heard next to the ears (i.e.
what headphones should play) for both inworld clips and voice, using both
time delay and attenuation
 2) knowledge of whether the listener is using headphones or speakers
3) implementation of this crosstalk cancellation thing if they're using
speakers
3b) permission/licensing to use it from Princeton

Celi

[1]
http://www.princeton.edu/3D3A/PureStereo/Pure_Stereose10.html#x21-110
[2] http://www.princeton.edu/3D3A/Papers.html

On Tue, May 24, 2011 at 1:42 PM, Lee ponzu  wrote:

> I saw this cool demo of 3D sound.  This is totally different from the SL
> Voice technology, and I think it would compliment it perfectly.
>
> Take a look...
>
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=princeton+3D+sound
>
> The basic idea is that stereo gives a weak illusion of 3D.  You have the
> left signal, ls, and the right signal, rs.  A filter computes
>
> rs_new = rs - ls
> ls_new = ls - rs
>
> and then play rs_new and ls_new.  (Details left as an exercise...)
>
> In English---when you record in stereo, you record cross talk between the
> mics which is recreated when you play back.  This idea removes the cross
> talk, and dramatically increases the 3D illusion.  It is a simple filter and
> works totally at playback time on all sound sources and any stereo
> recording.  It would be easy to add it to the viewer...
>
> Just an idea.
> ponzu
>
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Autobuild errors

[Celierra Darling]

I don't have any familiarity with Xcode, so forwarding this thread back onto
the list...
Celi

-- Forwarded message --
From: Lee ponzu 
Date: Fri, Jul 8, 2011 at 3:24 PM
Subject: Re: [opensource-dev] Autobuild errors
To: Celierra Darling 


No issues with KDU.

The next problem is that I have Xcode 4 installed, so autobuild spit up on
not finding the 10.5 SDK.  I tried copying it over from Xcode 3, but that
leads to new problems.

Check dependencies
Invalid value '4.0' for GCC_VERSION
[WARN]Unable to determine concrete GCC compiler for file
/Users/lee/Documents/viewer/viewer-beta/indra/cmake/cmake_dummy.cpp of type
sourcecode.cpp.cpp.

So, I suppose I wil have to figure out how to get autobuild to use Xcode 3.2
instead.  Or just not build a viewer  8-(

ponzu



On Fri, Jul 8, 2011 at 1:49 PM, Celierra Darling  wrote:

> Cached in CMake.  I'm guessing perhaps there's code in there where
> -DINSTALL_PROPRIETARY=TRUE will cause DFMOD to be set to TRUE (like the
> first time you ran it when you tried the Release configuration)?
>
> If the next error you're getting is about KDU, you want to add
> -DUSE_KDU:BOOL=FALSE to the end of that.
>
> Celi
>
>
>
> On Fri, Jul 8, 2011 at 1:40 PM, Lee ponzu  wrote:
>
>> Cached where?  This is a fresh clone of viewer-beta, and the first time I
>> ever tried autobuild...
>>
>> however, the advice is good.  It didn't fail right away  8-)
>>
>> ponzu
>>
>>
>> On Fri, Jul 8, 2011 at 1:33 PM, Celierra Darling wrote:
>>
>>> You might have some variables cached, maybe?  Try explicitly setting --
>>> -DFMOD:BOOL=FALSE , like:
>>>
>>> autobuild build --verbose -c ReleaseOS -- -DFMOD:BOOL=FALSE
>>>
>>> (Feel free to Reply All to the list if this works. :p )
>>>
>>> Celi
>>>
>>
>>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Unjust Banning of residents?

[Celierra Darling]

It might be that the explanation message is mistaken, and it's supposed to
reference the TPVP instead of the TPVD (or even a different policy
altogether, if, say, someone clicked the wrong message).  Are you sure that,
whatever viewer(s) was being used, it conformed to the TPVP, and there
wasn't anything else going on that could be shady?

Celi


On Tue, Aug 16, 2011 at 2:23 PM,  wrote:

> I thought it was a phishing attempt as well. But the account has been
> removed from second life. POOF. so unless some phisher has the ability
> to terminate accounts this is as real as it gets.
>
>
> On Tue, 16 Aug 2011 20:21:48 +0200, Marine Kelley wrote:
> > Careful, it could be a phishing attempt. Do NOT click on any of the
> > links inside this email (unless you're certain it comes from Linden
> > Lab, but then again emails can be spoofed).
> >
> > On 16/08/2011, mala...@tamzap.com  wrote:
> >> exactly which is why this message is so disturbing. accounts have
> >> been
> >> terminated from second life for using a viewer not listed in the
> >> directory.
> >>
> >>
> >> "This email is notification that Linden Lab has terminated
> >> your access to the Second Life virtual world due to severe
> >> or repeated violations of the Second Life Terms of Service
> >> or Community Standards. Your (account name 'xx') and
> >> alternate Second Life accounts have been
> >> made permanently inaccessible."
> >>
> >>
> >> On Tue, 16 Aug 2011 13:33:39 -0400, Erin Mallory wrote:
> >>> Last I checked there is no requirement to use an approved tvp. even
> >>> on the tvp listing page. Looking at the policy and the directory
> >>> pages, no where does it say that the viewer must be listed in the
> >>> tvp...
> >>> http://secondlife.com/corporate/tpv.php
> >>> http://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory
> >>>
> >>> "You may connect to Second Life using software released by a
> >>> third-party developer. Linden Lab provides a Policy on Third-Party
> >>> Viewers [1] to promote a positive and predictable experience for
> >>> all
> >>> Second Life Residents."
> >>>
>  Date: Tue, 16 Aug 2011 10:23:21 -0700
>  From: mala...@tamzap.com
>  To: opensource-dev@lists.secondlife.com
>  Subject: [opensource-dev] Unjust Banning of residents?
> 
>  Violation: Third Party Viewer Usage
>  You are connecting to the grid with a viewer that is not in the
> >>> third
>  party viewer directory.
> 
> 
>  However...
> 
>  A viewer does not need to be on the Third Party Viewer Directory
>  in
>  order for development or usage of it to be compliant with the
>  Third
> >>>
>  Party Viewer Policy (see Policy on Third-Party Viewers | Second
> >>> Life)
>  and the Terms of Service. While I am sure you are well aware of
> >>> this, it
>  can also be deduced through common sense that the open source
> >>> program
>  (Snowstorm, Snowglobe, etc) would not be able to exist in an
> >>> environment
>  where every personal compile had to be listed on the TPVD before
>  it
> >>>
>  could even begin to undergo any form of live quality assurance
>  processes.
> 
>  Long story short, unless there have been recent changes to the
> >>> Terms of
>  Service that I am unaware of, or if there are relevant sections
> >>> that I
>  have missed that indicate that a viewer that complies with the
> >>> Third
>  Party Viewer Policy still must be in the Directory to be
> >>> legitimately
>  used, I would request that you provide me with them.
> 
>  What this means is every single BETA tester for every client on
>  the
> >>>
>  TPVD is at risk of losing their accounts because that compiled
> >>> version
>  of that client is not listed on the TPVD. Each and every Developer
> >>> who
>  has worked so hard to help Linden Lab build their Client into what
> >>> it is
>  is at risk of losing their accounts because each time they
> >>> recompile the
>  source it isn't listed in the TPVD and is now considered a
> >>> Violation of
>  some hidden TOS clause.
> 
> 
>  I am posting this to this forum because I wanted to get feed back
> >>> from
>  the community. As I myself and a developer who has contributed
> >>> patches
>  to various TPVD Clients and am now finding myself cautious to even
> >>> use
>  these clients source codes to help them. I would like
>  clarification
> >>> from
>  Linden Lab as well as other Developers on this new banning policy
> >>> that
>  is requiring every compiled client that connects to second life to
> >>> be
>  listed in the TPVD.
>  ___
>  Policies and (un)subscribe information available here:
>  http://wiki.secondlife.com/wiki/OpenSource-Dev
>  Please read the policies before posting to keep unmoderated
>  posting
> >>> privileges
> >>>
> >>>
> >>> Links:
> >>> --
> >>> [1] http://

Re: [opensource-dev] Viewer Policy Changes

[Celierra Darling]

(I am not a lawyer, but...)

>From the text in the blog post, it looks like it's intended to be an
anti-fragmentation measure.  I don't think it's literally a desire to make
the TPV devs wait until the official viewer catches up (and definitely not
to make TPV people "develop [features] for the LL viewer").

To help allay the concern, though, I think there could be some sort of
"with specifications released by LL" exception - once an API has been
hashed out and released, I can't think of any benefit to making the TPV
wait.  That'd make the rule a little more tightly focused on getting TPVs
to make specs that LL's willing to endorse and use.

Celi


On Fri, Feb 24, 2012 at 7:18 PM, Jessica Lyon <
jessica.l...@phoenixviewer.com> wrote:

> Actually, under 2.k, features like breast physics, secondary attachments,
> shared parcel WL etc, would have never been permitted to exist. And this
> means that any feature in the future to which a TPV may conjur up, which
> effects the shared experience (Ie. something one user could see but another
> couldn't) will need to be developed for the LL viewer by TPV devs, accepted
> by LL, released by LL before a TPV may release it themselves. Another
> example would be the Mesh deformer from Qarl, if LL were not interested in
> it.. none of us would be allowed to release it in our viewers.
>
> Jessica Lyon
> Project Manager
> The Phoenix Viewer Project, Inc.
>
> On Fri, Feb 24, 2012 at 7:00 PM, Cinder Roxley wrote:
>
>>  Yes, you're mistaken. The key phrase there is "alters the shared
>> experience of the virtual world".  A tpv can alter individual user's
>> experiences, (UI, build tools, controls, graphics enhancements) but not the
>> shared experience of the world.  IE, exposing information such as the
>> friend online visibility of *other users*.
>>
>> Kind regards,
>> -Cinder
>>
>>
>> On 2/24/2012 4:44 PM, Nalates Urriah wrote:
>>
>> Does this new policy essentially eliminate the reason for the existence
>> of 3rd party viewers:
>>
>> 2.k : You must not provide any feature that alters the shared experience
>> of the virtual world in any way not provided by or accessible to users of
>> the latest released Linden Lab viewer.
>>
>>
>> http://community.secondlife.com/t5/Second-Life-Viewer/Third-Party-Viewer-Policy-Changes/m-p/1399141
>>
>> This seems to say all changes can be submitted to LL but not implemented
>> until and unless LL approves them and adds them to the SL viewer. Am I
>> mistaken?
>>
>> --
>> Nalates Urriah (SL AV)
>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
> Jessica Lyon
> Phoenix Viewer Project Inc
> http://phoenixviewer.com
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] tired of the bad testting

[Celierra Darling]

On a more serious note, this is one way JIRA is useful - it helps walk
users through reporting a problem clearly, so that we all can know what
being referred to and its context, and we can start looking for possible
causes.

(Well, JIRA's more thorough, at least; the interface could still be
improved so non-devs don't get lost)
Celi


On Mon, Mar 26, 2012 at 11:05 PM, Carlo Wood  wrote:

> On Mon, 26 Mar 2012 12:15:20 -0400
> "Oz Linden (Scott Lawrence)"  wrote:
>
> > On 2012-03-25 23:56 , Flats Fixed wrote:
> >  the latest stable came out. it broke the teleporters at 2100 meters.
> > you know guys this is not a jira this is simple testing.  love the
> > new policy but the fact is the team is running people out of SL. test
> > it befor it goes stable.
> >
> > Perhaps you could provide a clear problem report?
> >
> > What software were you using?
>
> The latest stable.
>
> > What did you do?
>
> Try to teleport back after teleporting to 2100 meter.
>
> > What did you expect to happen?
>
> The same as with the older viewers.
>
> > What actually happened?
>
> It didn't work.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] GTX680 Compatibility

[Celierra Darling]

That might refer to the fact that the new nvidia cards don't have a
separate shader *clock*.  That is, they still have shader hardware, but you
can't speed up or slow down the shaders separately from the rest of the gpu
anymore.  That shouldn't do much in terms of compatibility.
Celi
On Apr 6, 2012 2:23 PM, "Ann Otoole"  wrote:

> I know there are some interesting changes in respect to shaders. Also some
> possible disinformation going around about no shaders but that looks to be
> bogus. Maybe we will have to wait and see what happens to the first lucky
> person into the pool with a 680.
>
>   --
> *From:* Geenz 
> *To:* Ann Otoole 
> *Cc:* Viewer 
> *Sent:* Friday, April 6, 2012 2:12 PM
> *Subject:* Re: [opensource-dev] GTX680 Compatibility
>
>  It *should* run, provided Nvidia hasn't done anything funky with their
> drivers.
>
> --
> Geenz
> Sent with Sparrow 
>
> On Friday, April 6, 2012 at 1:43 PM, Ann Otoole wrote:
>
> Will SL run on the new nVidia GTX680? If not are there any plans to
> advance Secondlife with the way Video card technology is moving?
>
>  ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
>
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Celierra Darling]

On Mon, Jul 30, 2012 at 1:08 PM, Oz Linden (Scott Lawrence)
 wrote:
>
> On 2012-07-29 04:07 , Henri Beauchamp wrote:
>
> With just a few tweakings to the texture fetcher (and in particular
> a setting that permits up to 32 concurrent HTTP fetches),
>
>
> Caution... once we begin supporting persistent connections and pipelined
requests on the server side (we're working on it), opening that many
connections will very likely be considered abuse of the service.  Allowing
a single server to have that many potentially long-lived connections to the
same server would starve the file descriptor pool very quickly at the
server end, adversely affecting other users.
>
> HTTP itself recommends that clients not maintain more than 2 connections
to the same service [1].  I don't know exactly what limit we will decide is
reasonable (I expect that 2 will be ok, but don't know whether or not some
larger number will be also).
>
> Please bear this in mind as you think about your designs.  I will keep
you all informed as things develop.
>
>
> [1] RFC 2616, section 8.1.4


FYI, the Firefox folks had a conversation in 2008 and decided to bump up
from 2 to 6 by default at that time (partly because everyone else was
raising it).[1]  (And for what it's worth, I found a mention from '06 that
"anything above 10 is excessive".[2])  That doesn't necessarily mean SL
viewers should use the same values, but I think it probably demonstrates
where people might try to push that setting, at least at first.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4
[2]
http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-server&diff=28784&oldid=28783

Celi
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

[Celierra Darling]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/612/#review1288
---


Hey Tofu! :3



indra/newview/app_settings/settings.xml
<http://codereview.secondlife.com/r/612/#comment1179>

I still think it might be valuable to attenuate (HSV) saturation, but since 
it'd been stuck at 1.0 since forever and it doesn't look like it'll be exposed 
in Environment Settings anytime soon... *shrug*

Used like this, RenderSSAOEffect might be entirely redundant with 
RenderSSAOFactor, if I remember correctly?



indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl
<http://codereview.secondlife.com/r/612/#comment1180>

Where's the code where ssao_effect_mat had been constructed? (If it's not 
being used, it should probably be taken out too.)



indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl
<http://codereview.secondlife.com/r/612/#comment1181>

This line can probably go too. (It got removed in class2 but not class1; 
maybe check for more?)



indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl
<http://codereview.secondlife.com/r/612/#comment1177>

The 'if' here might be problematic.. I remember some cards were choking on 
branches, thus the convoluted lines that looked like new = old + 
int(conditional)*value.  (same for class1)

Also, I could have sworn that there used to be comments here specifying 
what the non-mangled math originally was (a la the old 
softenLightF.glsl:206-214)



indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl
<http://codereview.secondlife.com/r/612/#comment1178>

Won't using norm.xyz*diff raw like this cause false positives (from 
self-occlusion)?  IIRC, that was why the old code used dot(samp-0.05*norm-pos, 
norm).  (todo for self: render this for one sample to check...)  (same for 
class1)



indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl
<http://codereview.secondlife.com/r/612/#comment1182>

Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 
0.0" ?  Seems odd in cases of 0 < angrel < distrel.  (No longer using the 
sphere assumption?)


- Celierra Darling


On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/612/
> ---
> 
> (Updated Dec. 2, 2012, 3:49 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Use a different scheme for weighting SSAO samples, apply SSAO before fog is 
> applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 
> 'checkerboard' stipple had been refactored incorrectly, change some default 
> settings in line with the resulting visual changes.  Also, improve comments a 
> bit. :3
> 
> 
> This addresses bug VWR-29083.
> http://jira.secondlife.com/browse/VWR-29083
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt UNKNOWN 
>   indra/llrender/llshadermgr.h UNKNOWN 
>   indra/llrender/llshadermgr.cpp UNKNOWN 
>   indra/newview/app_settings/settings.xml UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl 
> UNKNOWN 
>   indra/newview/pipeline.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/612/diff/
> 
> 
> Testing
> ---
> 
> Been running with this for months on an assortment of nvidia hardware, linux 
> only.
> 
> 
> Thanks,
> 
> Tofu Buzzard
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

[Celierra Darling]

> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/settings.xml, line 7823
> > <http://codereview.secondlife.com/r/612/diff/1/?file=8132#file8132line7823>
> >
> > I still think it might be valuable to attenuate (HSV) saturation, but 
> > since it'd been stuck at 1.0 since forever and it doesn't look like it'll 
> > be exposed in Environment Settings anytime soon... *shrug*
> > 
> > Used like this, RenderSSAOEffect might be entirely redundant with 
> > RenderSSAOFactor, if I remember correctly?
> 
> Tofu Buzzard wrote:
> I don't think HSV-modulating according to SSAO is valuable (either 
> aesthetically or physically) - some sort of colour-grading function would be 
> grand but it shouldn't be tied to SSAO.  Only the 'V' part has ever been 
> enabled (as released) as you say...
> RenderSSAOEffect and RenderSSAOFactor are unrelated.

Hmm, there is some effect where saturation (seems to) decrease on AO'd areas, 
but that can be more illusion than physical.  Tweaking it here would be either 
cancelling it or exaggerating it, and I can see the argument for avoiding it.  
Though there are real cases of artificial narrow-spectrum direct lighting + 
fuller-spectrum ambient light, like gas-discharge streetlamps at dusk or the 
such - thus my selfish lust for it getting exposed in environment settings... :p

Looking at your comment, I think -Factor might be being used for something 
different from when I was using it, so never mind that.


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl, line 
> > 214
> > <http://codereview.secondlife.com/r/612/diff/1/?file=8134#file8134line214>
> >
> > Where's the code where ssao_effect_mat had been constructed? (If it's 
> > not being used, it should probably be taken out too.)
> 
> Tofu Buzzard wrote:
> It was being constructed in pipeline.cpp, and the patch includes removal 
> of that part.

Whoops, thanks; not sure how I missed it.


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 130
> > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line130>
> >
> > Won't using norm.xyz*diff raw like this cause false positives (from 
> > self-occlusion)?  IIRC, that was why the old code used 
> > dot(samp-0.05*norm-pos, norm).  (todo for self: render this for one sample 
> > to check...)  (same for class1)
> 
> Tofu Buzzard wrote:
> I'm not sure I follow - but a sample candidate co-incident with the 
> sample origin is disregarded.

'angrel' and the larger sampling radius seem to have taken care of it.  This 
was referring to the case where, for example, a sample pixel is picked that's 
0.01 m away from the origin on the same triangle, and with a little rounding 
error, the sample ends up looking like a huge occluder.  The old code has 
nothing analogous to 'angrel': there's an assumption that incoming ambient 
light is falling onto the sample origin equally from all directions. 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 127
> > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line127>
> >
> > The 'if' here might be problematic.. I remember some cards were choking 
> > on branches, thus the convoluted lines that looked like new = old + 
> > int(conditional)*value.  (same for class1)
> > 
> > Also, I could have sworn that there used to be comments here specifying 
> > what the non-mangled math originally was (a la the old 
> > softenLightF.glsl:206-214)
> 
> Tofu Buzzard wrote:
> Our shaders are really branchy, that's really not a problem (on the 
> target class).  I don't strictly remember removing comments on the original 
> maths, but the weighting (the only mathy part of this affair really) has 
> changed radically at least twice since the original inline explanation, and 
> should be simple enough to follow procedurally lately. :)
> 
> Geenz Spad wrote:
> However, a general rule of thumb is if you can save a branch in a shader, 
> then you should do so.  My personal preference is to try and keep it to 
> branches that have defined ARB instructions that a vendor's GLSL compiler 
> will likely optimize to (which is limited to less than and greater than 
> unfortunately).  Though you're right, it's not much of a problem on class 2 
> hardware that ca

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

[Celierra Darling]

> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 132
> > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line132>
> >
> > Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : 
> > 0.0" ?  Seems odd in cases of 0 < angrel < distrel.  (No longer using the 
> > sphere assumption?)
> 
> Tofu Buzzard wrote:
> The reasoning was that as a sample candidate draws nearer to the sample 
> origin, the relevancy of its relative angle becomes overshadowed (so to speak 
> :)), given that it's not really a point but a sampling of something (i.e. the 
> sphere) with size whose extents are also increasingly blocking off the local 
> area.  Conversely, all distances being equal, the occlusion of the sample 
> origin is proportional to the directness with which the sample candidate 
> blocks its normal (the direction from which it *would* otherwise be drawing 
> the most light).
> So the two relevancies modulate either other, the 'correct' mixing of the 
> two in my head would be sqrt(angrel*distrel) but max(angrel,distrel) seemed a 
> touch more pleasing and probably quicker.
> 
> Celierra Darling wrote:
> Thanks!  You may want to put in that you're not presuming uniform 
> incoming ambient light like the old code was.  (Also, you forgot the sqrt in 
> your comment if you were intending it to say the same thing as you said here?)

Er, to be clearer, the old presumption was that ambient light would be falling 
onto the sample origin equally from all directions if not for the occluders 
that were sampled - thus no use of angrel.  In hindsight, that seems a little 
dumb - to me, the way you're doing it is like using a better prior in the 
Bayesian sense.


- Celierra


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/612/#review1288
---


On Jan. 11, 2013, 1:34 p.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/612/
> ---
> 
> (Updated Jan. 11, 2013, 1:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Use a different scheme for weighting SSAO samples, apply SSAO before fog is 
> applied, fix a bug in the screen-space shadow/ssao smoothing offset where the 
> 'checkerboard' stipple had been refactored incorrectly, change some default 
> settings in line with the resulting visual changes.  Disregard samples which 
> are being taken from outside the screen extents - eliminates spurious SSAO 
> fringe at screen edges at some angles.  Micro-optimize the shadow co-ord 
> calculation.  Also, improve comments a bit. :3
> 
> 
> This addresses bug VWR-29083.
> http://jira.secondlife.com/browse/VWR-29083
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt UNKNOWN 
>   indra/llrender/llshadermgr.h UNKNOWN 
>   indra/llrender/llshadermgr.cpp UNKNOWN 
>   indra/newview/app_settings/settings.xml UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
> UNKNOWN 
>   indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl 
> UNKNOWN 
>   indra/newview/pipeline.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/612/diff/
> 
> 
> Testing
> ---
> 
> Been running with this for months on an assortment of nvidia hardware, linux 
> only.
> 
> 
> Thanks,
> 
> Tofu Buzzard
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side prediction

[Celierra Darling]

I'm not sure about this -- I tried this with a free-flight parabola and got
a nonsense value out. Calculations attached at the end.

What is the significance of the "anchor"?  It looks like you're trying to
estimate the center of the path's curvature?  If you were doing that, you
want to intersect using the lines through p and *perpendicular* to v (in
2D), not intersect the lines created by v.  In 3D, I think you'd want to
intersect 3 planes, the two planes through p perpendicular to their
respective v and also the plane that contains both points.

I'm not sure how to extend that to handle torques on the object

Have you tried estimating a = (v1 - v2)/t, and extrapolating using that
(p_next = p_cur + v_cur*dt + 1/2*a*dt^2)?  It would also extend to torques
and angular velocity using the analogous equation.  (I'm sure you could even
fit a line or spline to multiple previous values of v to get something even
higher-order, if you wanted, though with diminishing returns.)

Celi

The aforementioned calculation:

dt = 0.1
a = g = [0,-2]

initial position and velocity:
p1 = [0, 0]
v1 = [1, 0]

next position and velocity
p2 = [0.1, -0.01]
v2 = [1, -0.2]

perfect value: p3 = [0.2, -0.04]

lines are (p1 + s*v1) and (p2 + t*v2)
intersect at s = 0.05, t = -0.05, position = [0.05, 0]

angle change = clockwise 3pi/4 (radians)
current angle = -pi/4
angle after "twist" = pi/2 (upwards!?)

(it just gets worse from here - you estimate a distance upwards, and the
step forward using the current velocity doesn't get you back to y=0.)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side prediction

[Celierra Darling]

I made a small mistake at the "current angle" (it should be -0.2ish radians
instead of -pi/4), which makes the angle difference close to a semicircle.
 But still, if you add that, you end up with a vector pointing up and
backwards... (If you subtract, you end up just heading back left...)

Maybe I'm just not interpreting what you mean by the "twist" correctly?
 (Even when I 'visually' do it to your picture, I get the same result...)
 Am I supposed to be finding the angle between the velocity vectors, or the
angle between the (position - intersection point) vectors?

(We might want to work things out off-list, unless anyone would like to see
those details.)

Celi
.
On Fri, Feb 5, 2010 at 10:22 PM, Nexii Malthus wrote:

> Ah, thanks Celierra. 3 planes, yes that makes a lot more sense.
>
> Hmm, trying to step through your calculations. I think you have to subtract
> the angle difference rather than add it on.
> I just tried visually going through your calcs and it seems to hit right on
> your perfect value p3.
>
> http://i48.tinypic.com/15x2wz8.png
>
> - Nexii
>
>
>
> On Sat, Feb 6, 2010 at 1:28 AM, Celierra Darling 
> wrote:
> > I'm not sure about this -- I tried this with a free-flight parabola and
> got
> > a nonsense value out. Calculations attached at the end.
> > What is the significance of the "anchor"?  It looks like you're trying to
> > estimate the center of the path's curvature?  If you were doing that, you
> > want to intersect using the lines through p and *perpendicular* to v (in
> > 2D), not intersect the lines created by v.  In 3D, I think you'd want to
> > intersect 3 planes, the two planes through p perpendicular to their
> > respective v and also the plane that contains both points.
> > I'm not sure how to extend that to handle torques on the object
> > Have you tried estimating a = (v1 - v2)/t, and extrapolating using that
> > (p_next = p_cur + v_cur*dt + 1/2*a*dt^2)?  It would also extend to
> torques
> > and angular velocity using the analogous equation.  (I'm sure you could
> even
> > fit a line or spline to multiple previous values of v to get something
> even
> > higher-order, if you wanted, though with diminishing returns.)
> >
> > Celi
> > The aforementioned calculation:
> >
> > dt = 0.1
> > a = g = [0,-2]
> > initial position and velocity:
> > p1 = [0, 0]
> > v1 = [1, 0]
> > next position and velocity
> > p2 = [0.1, -0.01]
> > v2 = [1, -0.2]
> > perfect value: p3 = [0.2, -0.04]
> > lines are (p1 + s*v1) and (p2 + t*v2)
> > intersect at s = 0.05, t = -0.05, position = [0.05, 0]
> > angle change = clockwise 3pi/4 (radians)
> > current angle = -pi/4
> > angle after "twist" = pi/2 (upwards!?)
> > (it just gets worse from here - you estimate a distance upwards, and the
> > step forward using the current velocity doesn't get you back to y=0.)
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Snowglobe 2.0^H^H^H1.3 way forward?

[Celierra Darling]

I think this "no" refers to the ".0" iteration.  If 2.x stays around for as
long as 1.x, mesh might end up in some 2.x (but obviously not 2.0).

Celi


On Fri, Mar 12, 2010 at 6:19 PM, Armin Weatherwax <
armin.weather...@googlemail.com> wrote:

>
> e.g. that:
>
> SLDev Mailing List  "Kent Quirk (Q Linden)"
>  wrote On Jan 14, 2010, at 06:55:
>
> On Jan 13, 2010, at 11:42 PM, Dale Mahalko wrote:
>
> > There are other important questions to ask about SL 2.0.
> >
> > Will the mesh implementation... 
>
> NO.
>
> I don't know how the mesh rumor got started, but it's already been
> stated in this thread that 2.0 will NOT include mesh support. All the
> questions are interesting, but they don't apply yet.
>
>Q
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Viewers in the directory are being impersonated already

[Celierra Darling]

There's still other facets.  For example, the approved viewers get some
publicity and reputation by being on the approved viewers page, and it makes
people think that much harder about using sketchy viewers to do sketchy
things.  (And yeah, they have to do one extra sketchy thing, as Thomas
mentions.)

(As an aside, connecting from the same account and/or same IP with random
MACs seems pretty obviously strange and detectable.  There's a few more
hoops left to jump through there.)

Celi

On Mon, Apr 12, 2010 at 4:33 PM, Dale Glass  wrote:

>
> Of course maybe this will be ignored entirely, users who abuse things like
> these will be banned and the developers will continue as before, but then
> what
> was the point?
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Pie menu ideas (was: Re: Open Viewer Development Announcement)

[Celierra Darling]

Seems like this should be in a different thread

To get rid of creep, perhaps slide the pie instead of the mouse cursor while
moving the mouse.  As an example, if you move your mouse south to the
"More..." option, the actual cursor can remain in the same position on the
screen, but the pie can slide northward under the mouse cursor.

On the submenus-extending-out-from-the-wedge mockup that someone linked to
before [1], I think something like that is probably what users would expect.
 But I don't like the kludge that the article uses - it expands "View" at
the edge of the menu to avoid making the submenu's wedges annoyingly thin.
 That suddenly eats into a lot of the space for the neighboring wedges
(especially as SL's wedges expand infinitely out), so I can imagine a lot of
unintentional actions like, say, if you accidentally hover over "View" on
the way to "This Page" in the mockup.

There could be some zoom going on instead.  I am imagining the submenu's
wedges widening and filling a semicircle, with the backwards direction
indicating 'Back'.  The Dasher text input system does something like what I
mean, although Dasher's is linear (and it has way way too many options) [2].
 It might be a little weird to have buttons growing as you approach them;
Apple seems to like the visual effect (ex. the dock) but I can't think of
any other examples.

Celi

[1] http://techknack.net/circular-menus-and-usability/
[2] http://www.inference.phy.cam.ac.uk/dasher/, Java demo at
http://www.inference.phy.cam.ac.uk/dasher/TryJavaDasherNow.html

On Wed, Aug 18, 2010 at 3:04 PM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

>  On 2010-08-18 14:14, Aidan Thornton wrote:
>
> On 8/18/10, Oz Linden (Scott Lawrence)  
>  wrote:
>
>  While there were some good things about the v1 implementation of pie
> menus, they also had some flaws - such as not opening a submenu centered
> on the mouse click.
>
>  I actually puzzled over this a bit when I first realised that Second
> Life's pie menus worked this way. Originally, the pie menus worked
> well when you didn't click too close to the edge of the screen but
> didn't actually open under the mouse cursor if you did. Since the
> "More..." item is sensibly always the southmost one, opening new
> submenus centered on the mouse would cause the pie menu to drift down
> the screen until it hit the bottom and caused problems.
>
> Also, opening the submenu at the same location has the nice
> side-effect that the mouse remains over the "More..." option for the
> pie menus that are nested 3 or more levels deep.
>
> What I have been contemplating is how to make it possible to open the
> next layer of a pie menu without moving the mouse at all. Sadly, it'd
> probably break too much from normal UI conventions to be worth doing.
>
>
> If I understood him correctly, what Q seemed to think was the right
> behavior is:
>
>- The first mouse-down opens the pie centered on the mouse location, so
>no choice is under the mouse
>- If the choice is a submenu, each new menu is also centered on the
>mouse
>
> that way, you are never making a choice within the submenu if you
> accidentally double click, because the center is never a choice.  this does
> mean that the nested menus 'creep', but that has the effect that each nested
> choice is a 'gesture-like' unique series of clicks.
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Blocking viewers.

[Celierra Darling]

You can still use that software, but you'll just have to connect somewhere
else for service if you do so.  LL doesn't have to care only about direct
effects on their own servers, and LL has the right to no longer trust
viewers that identify themselves as "Emerald".

Sure, you can get around it if you really want, but keep in mind that
there's reasons why LL doesn't trust Emerald to connect to their servers.
 (Well, to be more precise, the original Emerald - there are Emerald forks
on the TPV directory, which aren't affected AFAIK.)

Celi


On Wed, Sep 8, 2010 at 5:39 PM, Tom Grimshaw  wrote:

>  Dear Linden Lab,
>
> It's absolutely none of your business what software I choose to run on
> my PC.
>
> Blocking emerald is a step of pure arrogance - and ignorance - on Linden
> Lab's behalf - it's not having an adverse effect on your servers, in
> fact THE ONLY WAY you can tell i'm runing Emerald is by the channel and
> version provided in login, and this has been proven by the number of
> clones that have popped up with their channel renamed (and the ID
> texture changed of course). You cannot censor Open Source software, and
> the fact that you're trying to makes you a despicable organisation.
>
> Stop policing my computer. I will decide what viewer I use, thank you.
>
> ~T
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Severe water flicker in recent development build

[Celierra Darling]

On Sun, Sep 12, 2010 at 12:01 PM, Ponzu  wrote:

> Several years ago, some Linden posted a table that showed the typical
> range of FPS for various graphics cards. At the time I thought that
> was a very interesting piece of data, and am sad to have never seen it
> again (maybe I missed it).
>

The chart is still up, but I don't think it's been updated very recently...
http://wiki.secondlife.com/wiki/Typical_Frame_Rate_Performance_by_Graphics_Card/GPU


Celi
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Possibility to revert UI changes on snowstorm?

[Celierra Darling]

>From the "see above", I'd gather that the reason is that LL dislikes parts
of the 1.x UI about as much as they now dislike parts the 2.x one.  Both UIs
have well-publicized strikes against them now; I think an attempt to make
changes *away* from that 1.x status quo has been well-justified for a long
time (even if that might not seem as true for all the changes *to* where
2.0.0 ended up at).  Thus I'd agree with Yoz's request to look for ideas
that are improvements on both 1.x and 2.x, instead of just going back to 1.x
blindly.

Celi

On Tue, Sep 21, 2010 at 1:39 PM, Gigs  wrote:

> On 09/20/2010 09:30 PM, Yoz Grahame wrote:
> > If you're asking about reverting the entire viewer UI to 1.x: in short,
> > no. In less short, we'd need an objective, well-reasoned argument
> > against each and every one of the several hundred UI changes between 1.x
> > and 2.x. See above.
>
>
> Why would the burden be that way?   Linden Lab changed the status quo,
> they should be the ones justifying their new design, not the other way
> around.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] crazy land idea

[Celierra Darling]

I'd think that those clipping / occlusion culling algorithms you cited only
work if one of the two pieces of geometry can be transformed (reversibly) so
that it ends up being rectilinear - like a cube, a camera frustum, etc.  You
can see how the examples in your link use rectangles.  Clipping in that
narrow context is *much* easier than the general case of creating geometry
that way, which would be more like Constructive Solid Geometry [1].  SL
already does the union operation in the trivial way (render all prims
whole), so you're looking to not only optimize that but also implement the
difference operation.  In particular, notice how you'd have to reason about
actively creating vertices at the edges where two or more prims meet - I'd
be tempted to just go to meshes and leave that problem to mesh editors to
solve, although then it's not trivial to test whether or not you're inside
the mesh

If we narrow this to just doing CSG in volumes of "weather" (or water or
space or etc.) specifically, rendering might not be necessary, and checking
whether the camera is inside the volume is pretty easy (just add booleans).
 If you need to visualize it, I think wireframes might be enough - it can
get messy, but I can't imagine the resulting volumes being so complicated
that it'd get too difficult to visualize that way.

What Carlo is talking about in terms of "looking out the window" can
probably be done with stencils [2] - something like, if you're not already
in the volume of rain, then
- render the scene without rain
- save the z-buffer from that render
- render the bounds of the volume of rain into a stencil while re-using that
z-buffer (so that iff something in the scene was "outside", the rain
boundary will be rendered on top of it)
- apply the rain to the applicable areas in the stencils (either re-render
or through some post-processing trick)

...but that seems really costly and it needs that render-the-volume step.  A
hack might end up better (like, just do "the easy way" from Carlo's message,
and then allow in-world objects like windows and such to query the weather
and change their textures).

Celi

[1] http://en.wikipedia.org/wiki/Constructive_solid_geometry
[2]
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=26

On Sun, Sep 26, 2010 at 3:06 PM, k\o\w  wrote:

>  I've been thinking about ways to implement subtractive objects for a
> while now:
> We would flag the object as subtractive and flip its normals.
> During the rendering phase, we would apply a simple clipping algorithm
> to each object to slice off the intersecting geometry.
> The subtractive object would be merged into the original object to
> create the hollowed section.
>
> The math involved is very similar to the math already used in SL's
> occlusion culling, and if used properly should reduce render time vs.
> trying the create the same effect with many more prims.
>
> A quick demo of an algorithm for openGL clipping can be found here:
> http://www.docstoc.com/docs/272548/Computer-Graphics-clipping-opengl
>
> Similar code would be required for the physics, lighting, and shadow
> implementations.
>
> Subtractive geometry has been a basic feature of many game engines for
> quite a while, and if used right improves performance.
>
>
> I like the idea of using prims to define area effects like the presence
> of rain or snow! This is exactly how these kinds of things are done in
> other game engines. Content creators already do this with volume
> detection but it could be supported better by the client and a new prim
> type.
>
> On 9/26/2010 12:10 PM, Carlo Wood wrote:
> > Hmmm, yes. There is more use to detecting "being inside a prim"
> > and toggling certain render types as a result it seems.
> >
> > Now, an easy way would be to detect if the CAM is inside a prim,
> > and then turn off -say- water fog, or whatever causes one to
> > appear being under water; or turn off rain/snow if that is turned
> > on.
> >
> > However, if then you look out the window, it stopped raining
> > outside too.. so that isn't good enough.
> >
> > On Sun, Sep 26, 2010 at 09:46:09AM -0400, Tammy Nowotny wrote:
> >> This is purely anecdotal (though maybe someone knows more than my
> anecdote): I
> >> have heard that the SL game engine is not good at determining which
> points are
> >> under/above/inside an enclosure such as a building.  Moreoever, legend
> has it
> >> that there is a whole weather system in the engine which was never
> activated
> >> because there was no way to stop rain, snow etc. from going through
> roofs,
> >> walls, etc.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.co

Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES)

[Celierra Darling]

More than whether 2.x can technically get Unity features in two years, a
question would be how to teach or incentivize creators to use those features
without creating a laggy Tragedy of the Commons situation on the machines
the viewers are running on.  If you consider how much work and discussion is
needed to develop metrics and limits (for example, in that script metrics
thread), two years (or more!) might be taken up in just planning and testing
those rules.  The social considerations need to be thought about just as
carefully as (if not more than) technical ones.

(Also, adding additional platforms won't be free either - they each need
extra work for their different quirks, user interfaces, and strengths and
weaknesses.  Trying to use a Windows PC viewer on the Wii or Android would
be a train wreck.  It's not like C# scripting was suddenly free after
getting mono.)

Celi

On Sun, Oct 3, 2010 at 2:57 PM, Daniel Smith  wrote:

>
> Where could a Unity-based viewer be in 2 years?
> ...
> Consider what it would take to have a Unity foundation, layered with the
> SL-specific experience on top.  Then think about it the other way (trying to
> get the existing standard of 2.x to that level of quality, and on all of
> those platforms).
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?

[Celierra Darling]

I don't see why mesh editing needs to be considered "basic"?  I would
consider building through prims to be the most basic, to learn how
objects/prims/links work and what features are available and what texturing
is and the such.  New users also have all the free tools and those existing
tutorials available to start working with meshes, so new users should
hopefully still feel like they have an advancement path.  Even if prim
objects became totally non-competitive on the market, people probably still
start out just experimenting for their own use, so prims should still be a
good stepping stone while learning for their quick results and feedback.
 What would a mesh editor in the viewer add?  (Well, one likely feature of
an in-world tool would be to enable people to work concurrently with others
and see others' changes as they are made, but I doubt you're referring to
that aspect.)

Ironically, what I would think of as the most basic conceptual transitions
going from prims to meshes are probably the most difficult to program.  To
ease the transition to meshes when the time comes for a new content creator,
what I could imagine is the introduction of some tools and concepts from a
mesh's content creation process - hierarchical links to allow stacking
transformations? a way to palletize the textures applied to an object? - but
while still working with prims in-world.  Maybe it can even go as far as a
full conversion tool if someone were ambitious enough to code such a thing
(to convert and tinker).  But I wouldn't go as far as controlling
subdivisions or twiddling edge normals or nudging vertices -- a list that is
in increasing order of usability difficulty, but decreasing order of
programming complexity, and thus the irony of a "basic" mesh editor.

Celi


On Tue, Oct 5, 2010 at 2:21 AM, Science Fiction Computer - SCi-Fi PC <
partn...@scifipc.com> wrote:

> LL Snowstorm/Opensource-Dev,
>
> To stimulate SL growth and accessibility to the mainstream, one or the
> collective SL Viewer developers and/or decision makers ought to think &
> design universally.
>
> If mesh becomes a standard in SL, a basic mesh editor ought to be included
> by default.
>
> The ability to plugin with existing professional tools such as Photoshop,
> Gimp, Blender, Max, etc. is essential for high-end content production and
> advanced SL users.
>
> However, to deny a new users who are discovering either 3D Second Life or
> the 3D Web for the first time a complete basic set of content creation
> tools
> for the 3D world they are introduced to (of which would include a mesh
> editor), may seriously discourage them; along with potential opportunity
> for
> regular influx of new & emerging content creators within our community from
> Low, Medium, and High End.
>
> SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there'
> and 'basic' to encourage new content creators to create and feel that they
> begin to learn and participate without significant barriers.
>
> We must try and avoid any situation where a New User in SL feels
> disadvantaged or unable to create before they start.
>
> Regards,
>
> DMC Zsigmond-Jurassic
> Science Fiction.
>
>
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Stickman
> Sent: Tuesday, October 05, 2010 2:48 PM
> To: Frans
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase
> plugin capable?
>
> On Mon, Oct 4, 2010 at 1:38 PM, Frans  wrote:
> > I really hope LL is not going to add a Mesh Editor in the client. That's
> > just going to be so bloated.
>
> I think it's a terrible idea for LL to try to recreate tools that
> teams of professionals have already been working on for years.
> Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out
> there, many of them free, that already do a much, much better job than
> LL ever could, simply because that is their only job and they have
> years of a head start.
>
> What I would like to see is a better connection with existing tools.
> Being able to have SL work with other programs easier, better
> conversion and import support, to cut steps out of the design
> workflow. For example, texture work often involves modifying a
> texture, test it out, modifying it again, and repeat forever. Having
> SL "watch" a texture, model, or other file for a change and
> automatically update it in SL so you can see exactly what it will look
> like would cut out a lot of steps. Even if it was only a local view.
> Heck, even if I had to pay for every single time I hit the save button
> in Photoshop or Blender. Though I'd prefer it be integrated in a way
> that all people could see what I was working on, then I hit "finalize"
> and it does the final upload.
>
> Having said that, very simple editors that are not designed to have
> fancy features but be as basic as possible would allow people to
> create 

Re: [opensource-dev] Request for feedback - Preferences Cleanup

[Celierra Darling]

That mute button sometimes does the opposite of what "mute" means in SL.  On
the telephones in my house and on my Android, mute turns off the
*microphone*, not the incoming sound.  (Ditto for some other apps I've seen,
such as GoToMeeting.  "Hold" is the closest analogue, which turns off both
directions.)  I'm guessing this is probably the source of some of the
confusion.

Celi


On Fri, Nov 5, 2010 at 5:43 PM, Andromeda Quonset <
andromedaquon...@gmail.com> wrote:

>  FWIW,
>
> I would also like to see the return to "Mute" instead of "Block".  With all
> due respect to your user testing, the telephone on my desk has a "Mute"
> button, not a "Block" button, and I consider it a very heavily used
> communications tool.  Perhaps there should be an option in preferences for
> setting the label for this function to either "Mute" or "Block",  as that
> would keep all of your users happy.
>
> Thank you
>
>
> At 09:10 AM 11/5/2010, Sarah (Esbee) Kuehnle wrote:
>
> Thanks for the feedback everyone. I'm working on some updates to the pdf
> right now and will send that out for further review later today!
>
> I can't promise all the suggested additions will go into the prefs, but
> I'll definitely look at each one as I'm making updates.
>
> A few responses to those who's provided feedback so far:
>
> @Marine - 1) The text chat logs have been fixed in 2.3 beta. 2) We changed
> the label from "Mute" to "Block" early on in V2 because our user testing
> indicated new users were confused about what "Mute" means and understood
> "Block" because it's used commonly in other communication tools.
>
> @GeneJ - That for the reminder on that typo. It was pointed out in my OH
> the other week and I needed a good kick to remember to fix it! :)
>
> @Wolfpup - We're just talking about skinning for now. In the meantime, I'm
> just gathering color options in one place. But you're right - future
> skinning preferences will likely require a restart before changes would take
> effect.
>
> @Erin - I've taken note of your request for the numerical debug settings
> for sculpties. I'm not sure they make sense in this preference cleanup I'm
> doing now, but will be useful when I can focus my team on a sprint focused
> on content creation as some point in the near future. As far as local lights
> go, they've actually been added back in on the Mesh Project Viewer 
> (SH-157)
> (which will eventually be added into the main Second Life Viewer). I'll take
> a look at the other tickets you referenced today.
>
> @Hitomi - Thanks for the additional settings. I'll review these this
> morning and see what makes sense to incorporate. That's a great list!
>
> More updates from me soon!
>
> --Esbee
>
>
> On Thu, Nov 4, 2010 at 6:50 PM, WolfPup Lowenhar  
> wrote:
>
> I keep seeing people talking about user readable chat logs and from what
> I’m seeing in the current dev builds the logs are already back to plain
> text. I’m currently working on a feature that is dealing with chat and
> group/personal IM logs.
>
>
>
> From: opensource-dev-boun...@lists.secondlife.com 
> [mailto:opensource-dev-boun...@lists.secondlife.com]
> On Behalf Of Hitomi Tiponi
> Sent: Thursday, November 04, 2010 4:37 PM
> To: Opensource_dev
>
> Subject: Re: [opensource-dev] Request for feedback - Preferences Cleanup
>
>
>
> Thanks for the Preferences mock-up (must say that I rather like the anime
> look of them :)) - some really sensible stuff there.
>
> Suggestions (all currently in Debug Settings): Chat - adjustable life and
> fade times for Startup, IM and Group popups - I find they are too short for
> me to spot sometimes Chat - Add in spinners to alter the number of times
> that IM tabs flash and the rate at which they flash at Advanced - Move 'UI
> Size' slider to Graphics as KL and myself have done - it fits more naturally
> there Graphics->Hardware - allow forcing on of Antialiasing (as the Viewer
> GPU presets often gets this wrong) or better still fix the presets :) Move
> & View - put in spinners for amount of head movement Move & View -
> Checkbox to allow double-click point-move in-world as an alternative to
> double-click teleport (which is welcome) Move & View - Checkbox for
> 'Number keys move avatar' Privacy - Check-box to select option to also
> create user-readable chat logs (as others have suggested) <- this is what
> I’m referring to. Advanced - Checkbox for 'Show Grid Selection at login' 
> Advanced
> - Checkbox for 'Disable Camera Constraints' Advanced - Checkbox for 'Limit
> the distance I can select objects at' and sliders/spinners for selection
> distance and amount you can drag in one step Advanced - Checkbox for 'Show
> UI in snapshots'
>
>
>  No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1153 / Virus Database: 424/3236 - Release Date: 11/03/10
>
> ___
> Policies and (un)subscribe information available here:
>  http://wiki.secondlife.com/wi