Re: [opensource-dev] Draw Distance - TPV Solution Example - SLIDER Correction

On 24/08/2010 4:49 PM, Lance Corrimal wrote: > Am Tuesday 24 August 2010 schrieb Science Fiction Computer - SCi-Fi > PC: >> Apologies all, correction, the SLIDER is located, off-center, TOP >> RIGHT. > > you mean there is one in the original skin too? neat. > -- Tateru Nino http://dwellonit.tat

Re: [opensource-dev] Draw Distance - TPV Solution Example - SLIDER Correction

Am Tuesday 24 August 2010 schrieb Science Fiction Computer - SCi-Fi PC: > Apologies all, correction, the SLIDER is located, off-center, TOP > RIGHT. you mean there is one in the original skin too? neat. bye, LC ___ Policies and (un)subscribe informat

Re: [opensource-dev] Draw Distance - TPV Solution Example - SLIDER Correction

Apologies all, correction, the SLIDER is located, off-center, TOP RIGHT. SF. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Lance Corrimal Sent: Tuesday, August 24, 2010 4:25 PM To: opensource-dev@list

Re: [opensource-dev] Draw Distance - TPV Solution Example

Am Tuesday 24 August 2010 schrieb Science Fiction Computer - SCi-Fi PC: > If you find the time, download the latest "Kirsten's Viewer" > S20(33). > > There is a neat little Draw Distance slider located in the TOP-LEFT > of the Viewer UI, which conveniently provides an EASY TOOL for > adjusting de

Re: [opensource-dev] Draw Distance - TPV Solution Example

If you find the time, download the latest "Kirsten's Viewer" S20(33). There is a neat little Draw Distance slider located in the TOP-LEFT of the Viewer UI, which conveniently provides an EASY TOOL for adjusting detail vs performance. It's simple, elegant, and most importantly, "Functional on the

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

On 2010-08-23, at 13:18, Yoz Grahame wrote: > As Josh and others have said, one of the things we'd need is a unique secret > account identifier. Unfortunately the only existing account datum which might > work here is email address, and that's not unique, though we're starting to > think that it

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

And a further note: Be sure to handle the "+" (plus) character in emails. Gmail (and possibly other systems) allows you to concatenate a + and some character string to the account name portion of the email address. This would allow me to have myemail+a...@gmail.com, etc. allowing me to only need a

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

Am Monday 23 August 2010 schrieb Yoz Grahame: > On 23 August 2010 11:51, Joel Foner wrote: > > As Josh and others have said, one of the things we'd need is a > > unique > > > >> secret account identifier. Unfortunately the only existing > >> account datum which might work here is email address

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

On 23 August 2010 11:51, Joel Foner wrote: > As Josh and others have said, one of the things we'd need is a unique >> secret account identifier. Unfortunately the only existing account datum >> which might work here is email address, and that's not unique, though we're >> starting to think that

Re: [opensource-dev] Draw Distance

On 24/08/2010 6:06 AM, Martin Spernau wrote: > Am 23.08.2010 um 21:39 schrieb Arrehn Oberlander: >> This is just off the top of my head. Many of these depend on user's >> preference for framerate vs scene details at a moment in time, and >> can't be reliably guessed purely from inworld behavior (

Re: [opensource-dev] Draw Distance

Oop! Sorry, i meant "Arrehn's comments" and "Arrehn's mail," not "Erik's." No offense, Erik. - AK i really like Arrehn's comments! He gives lots of good examples. The best draw distance isn't always a function of the best performance. Sometimes it may not even make sense to someone who's not

Re: [opensource-dev] Draw Distance

i really like Erik's comments! He gives lots of good examples. The best draw distance isn't always a function of the best performance. Sometimes it may not even make sense to someone who's not there at the time. i think one of the important ideas in Erik's mail and some of the earlier messages

Re: [opensource-dev] Draw Distance

On Mon, Aug 23, 2010 at 3:06 PM, Martin Spernau wrote: > Isn't that much like in photography, where you have different kinds of > 'automatic' (shutter speed vc aperture auto) ... and depending on your > creatice needs the one is betzer than the other and vice versa > Maybe the 'optimize for high

Re: [opensource-dev] Draw Distance

Am 23.08.2010 um 21:39 schrieb Arrehn Oberlander: > This is just off the top of my head. Many of these depend on user's > preference for framerate vs scene details at a moment in time, and > can't be reliably guessed purely from inworld behavior (although there > are hints, I will grant). Isn't t

Re: [opensource-dev] Draw Distance

On Mon, Aug 23, 2010 at 3:22 PM, Erik Anderson wrote: > > Shouldn't the SL client be able to figure out what a good draw distance > would be? Maybe have it start autodetecting draw distance based on rolling > average number of polygons visible or something? > It's not that simple, there are are

Re: [opensource-dev] Draw Distance

Just a quick/late comment for a thread that seems to have left the subject line a couple days ago anyhow... Requiring the draw distance to be changed that easily smells like a bad paradigm that needs adjusting. It reminds me of a database engine I was using that required me to set the hash size o

Re: [opensource-dev] Display names, again.

On 24/08/2010 5:05 AM, Oz Linden (Scott Lawrence) wrote: On 2010-08-23 14:57, Will wrote: Oz, what is Linden Labs position on Emerald and will they be making a public announcement? (not a lawyer just a concerned resident, remember them?) This is not the place to make any such statement. I

Re: [opensource-dev] separation between login id and publicly visible id(s)

On 24/08/2010 4:51 AM, Joel Foner wrote: As Josh and others have said, one of the things we'd need is a unique secret account identifier. Unfortunately the only existing account datum which might work here is email address, and that's not unique, though we're starting to think

Re: [opensource-dev] Display names, again.

On 2010-08-23 14:57, Will wrote: Oz, what is Linden Labs position on Emerald and will they be making a public announcement? (not a lawyer just a concerned resident, remember them?) This is not the place to make any such statement. I believe that one will be coming out in due time, but declin

Re: [opensource-dev] Display names, again.

Oz, what is Linden Labs position on Emerald and will they be making a public announcement? (not a lawyer just a concerned resident, remember them?) From: Oz Linden (Scott Lawrence) Sent: Monday, August 23, 2010 1:28 PM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Disp

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

> > As Josh and others have said, one of the things we'd need is a unique > secret account identifier. Unfortunately the only existing account datum > which might work here is email address, and that's not unique, though we're > starting to think that it really should be > Just a quick note... ema

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

On 23 August 2010 02:32, Boroondas Gupte wrote: > You'd win :-) > SVC-6212 (which also includes > the 1:many relationship between (1) and (2) Argent suggests below) > > As I commented in that issue, this is something we at the Lab would dearly love to

Re: [opensource-dev] separation between login id and publicly visible id(s)

On 2010-08-23 12:35, Joshua Bell wrote: On Mon, Aug 23, 2010 at 2:32 AM, Boroondas Gupte mailto:slli...@boroon.dasgupta.ch>> wrote: But even without that, a 'master account' would make a lot of things easier, like one could account verify all Alts at once, see billings for all lin

Re: [opensource-dev] Display names, again.

On 2010-08-23 11:50, Moriz Gupte wrote: @Oz Linden, I feel your pain of being submerged with noise, but unfortunately this is the price you have to pay for listening. And you cannot afford not to listen because there are gems in that noise that will help your own work and LL in general. So tak

Re: [opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

On Mon, Aug 23, 2010 at 2:32 AM, Boroondas Gupte wrote: > > But even without that, a 'master account' would make a lot of things > easier, like one could account verify all Alts at once, see billings for all > linked agents centrally etc. > No argument from me! But as with the other suggestion:

Re: [opensource-dev] Display names, again.

Thanks David, share your sentiments and logic. Would not have overloaded the list, but guess this is one of the venues that is heard most. Totally agree with "Lame Internet lawyers are lame. How many lawsuits have their been over the fact that it's easy to have a name that's very similar to someon

Re: [opensource-dev] Display names, again.

This post could be a classroom lesson in "how to alienate people and not be taken seriously". Daniel Smith : >>> 1. Will there be procedures in place to prevent someone else to use my >>> true avatar name as their display name? >> >>No. > > Wrong answer. Actually it's the right answer! The qu

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

> Actually, it would be nice if RenderVolumeLODfactor could either > persist from one version to the next (instead of getting reset with everey > new version installation), or be set based on GPU detection. > I imagine the default of 1.125 is based on "class 0" (intel integrated >graphics) > but a

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Could we move all this stuff to a new "emeraldgate" list, or something? That I could then carefully not subscribe to? _ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies be

Re: [opensource-dev] Draw Distance

On Sunday 22 August 2010 18:22:56 Lance Corrimal wrote: > related line of thought: > > > how much faster could the viewer be if every single of these "do not > change this ever" settings was replaced with a #define in a central > include file? > or in other words, what is the cpu cycle penalty fo

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

I would love to see emerald continue and grow. I for one actually like emerald. however. I find it odd that 3 of the devs are known for creating copybot/griefer clients. And with emerald alone 2 of the devs have created malicious code inside of emerald. Yet only one of the devs was asked to

Re: [opensource-dev] Draw Distance

On Mon, Aug 23, 2010 at 5:49 AM, Laurent Bechir wrote: > > > Marine Kelley a écrit : >> Please be careful not to screw up debug settings that must NOT be >> changed. Some are capital for the viewer to function normally, and >> would completely shut out users who don't know how to change them back

[opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

On 08/23/2010 05:53 AM, Joshua Bell wrote: >> Ideally, IMHO, there would be at least three "names": >> >> (1) login identifier (used with password as login credential) >> (2) unique human readable identifier >> (3) casual conversational identifier >> >> Prior to "Display Names", the Second Life (f

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

I don't want to start a war of any kind, but let me suggest that you ask for evidence before believing what people say in chat or elsewhere. There are people who would love to see Emerald crumble, and have no problem deceiving, misleading or plain lying. I have seen this done on this list, in f

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Really wish that was true but you saw Katharine's comments in irc. Absolutely nothing has changed with Emerald except for the servers. Here is hoping that both Philip and legal are not deceived so easily. Jesse Barnett On Monday, August 23, 2010, Tateru Nino wrote: >  And now, perhaps, we can g