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

[Jesse Barnett]

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 get back to the important stuff, like the
viewer itself.
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[Miro Collas]

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 forums (SLU especially) and in group chat. So, be very 
wary of whose word you believe.

For my part, the interview on treet.tv was enough to convince me to 
remain an Emerald user. That combined with knowing Jessica enough to 
trust her word.

On 08/23/2010 04:24 AM, Jesse Barnett wrote:
> 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 get back to the important stuff, like the
> viewer itself.
> ___
> 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

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

[Boroondas Gupte]

 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 (firstname, lastname) tuple
>> was used as all three. "Display Names" separates (2) and (3), but (1)
>> and (2) are still the same.
>>
>> I'm not sure if the work to do so is on anyone's backlog - I'm
>> betting there's a PJIRA on it, though.
You'd win :-)
SVC-6212  (which also
includes the 1:many relationship between (1) and (2) Argent suggests below)

>> Technically, it's much less code to touch than "Display Names" (since
>> a login-only private credential would be used in far fewer places in
>> the code than username or display names), but it would be mostly
>> server-side so the community can't help much.
We could write user stories :-P

On 08/23/2010 06:15 AM, Argent Stonecutter wrote:
> The other thing SL needs is a 1:many relationship between (1) and (2), so 
> that Argent David and Argent Stonecutter are both avatars associated with the 
> same account... like they are in Avatars United.
Which would allow for interesting permission schemes, like allowing
transfer of products only between avatars of the same account. (This
would probably have to be a new permission. Allowing transfer of all
"no-transfer" items between Alts, as SVC-4319
 suggests, would probably
upset quite some people.)

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.

cheers
Boroondas
___
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] Draw Distance

[Robin Cornelius]

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
>> offline, and to what.
>
> Wouldn't it be possible to have an argument "default" like this for
> example :
>
> /set debugvar default
>
> which would put back the debugvar to its default value ?

Yes,

settings.xml already contains all the default settings and is
essentaly readonly, changed settings are written to the user
settings.xml in the user data area, so it is easy to revert any
setting to its default installed value.

Robin
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[malachi]

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  
leave. While mr user data leakage remains on the team. Personally it  
appears to me that this is nothing more than a set up to shadow or sweep  
away the dirt that has been being flung around about the viewer. Fractured  
is asked to step down and walk away. But Fractured is the dev that  
purchased the license to build emkdu. Phox built the emkdu with user data  
leakage. And now they will be using a "clean" emkdu. Who is building the  
emkdu now? Fractured? Phox? of did one of the other devs run out and  
purchase a license to do so? Changing the server which hosts the client  
does nothing for saving face. And as long as Phox is a part of the  
team,(considering the fact that Phox and Jaycool are closer than twins)  
Fractured will still have access to changing code. If LL allows this to  
continue the TPVP is a joke. Hopefully the rest of you that use emerald  
will be more cautious about the client when you run it. After what we have  
seen thus far.god only knows whats next.
On Mon, 23 Aug 2010 05:21:35 -0400, Miro Collas   
wrote:

> 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 forums (SLU especially) and in group chat. So, be very
> wary of whose word you believe.
>
> For my part, the interview on treet.tv was enough to convince me to
> remain an Emerald user. That combined with knowing Jessica enough to
> trust her word.
>
> On 08/23/2010 04:24 AM, Jesse Barnett wrote:
>> 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 get back to the important stuff, like the
>> viewer itself.
>> ___
>> 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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
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] Draw Distance

[Thickbrick Sleaford]

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 for a
> SavedSettings.getBOOL() and the others?
> 

Please, no #defines...

You can cache the value of a settings and rely on callback magic to change the 
cached var when the setting has changed:

#include "llcontrol.h" (or llviewercontrol.h in 1.x, with a slightly different 
constructor)

static LLCachedControl cached_foo(gSavedSettings, "SettingFoo");

This way you can use cached_foo to get the value of the setting in methods 
that get called often, without doing a lookup in a big std::map.

> 
> bye,
> LC
> 

-- 
Thickbrick
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[David M Chess]

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 before posting to keep unmoderated posting privileges

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

[Hitomi Tiponi]

> 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 anybody using better than that can go to 2.0 at a bare minimum.

The default for 'class 0' on Viewer 2.1 is 0 (yes 'zero').  This has the effect 
of making the 50% of new users that enter Second life with class 0 machines 
(according to Linden Labs statistics) see a very odd world where a lot of the 
sculpties are a complete mess and all circular objects are hexagonal (no more 
curves in SL for them) and have no idea that it is not supposed to be that way. 
 
Experienced users will either know how to change it or add this to their list 
of 
reasons for not using Viewer 2.  I believe this was an unwise move to try and 
make the performance of the viewer look better on 'low' settings that it is and 
needs reversing.

I raised it as a JIRA 6 weeks ago - http://jira.secondlife.com/browse/VWR-20183 
- but I see it is not important enough to be in the product backlog.  For those 
who want to see what sl looks like for a lot of new users just set your 
settings 
to 'Low' in the new viewer and ask if you would use a world that looks like 
this 
rather than the one they used to see using Viewer 1.xx.

And here's the compulsory user story: "As a user with a machine that meets the 
minimum specificartions I would like to be able to see circular objects and see 
those nice sculpted objects like cars and trees that I used to be able to see.  
I am fed up of my friends telling me how wonderful a place is when it looks 
like 
it has just sufferred a terrorist attack to me."



  ___
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] Display names, again.

[David M Chess]

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 question was "will there be 
procedures in place", and since the current Lab plan is that there won't 
be procedures in place, "No" is the right answer.

You can argue that the current plan should be changed, but "wrong answer" 
just makes you sound faux-macho and confrontational.

> I think the Lindens are underestimating the legal fallout that will 
ensue when names are abused.  

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 someone 
else's?  How many times has Plurk been sued because you can make your 
display name be anything you like?  How many times has *any* online 
service been sued because it made it too easy for one person to masquerade 
as someone else?  What makes you think you have a better notion of the 
legal danger than the Lab's legal staff does?

> People are stating loud and clear what they want.  

Careful inspection will reveal that not everyone is saying the same thing.

> Are you guys deaf?

No, they aren't.  And this kind of insulting tagline just makes you look 
like a posturing child.

fwiw...

___
___
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] Display names, again.

[Moriz Gupte]

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 someone else's?
 How many times has Plurk been sued because you can make your display name
be anything you like?  How many times has *any* online service been sued
because it made it too easy for one person to masquerade as someone else?
 What makes you think you have a better notion of the legal danger than the
Lab's legal staff does? "
Even my homeland prime minister (Mauritius) had his FB created by some geek,
he sued and lost... he just got the page removed. In Idaho, where I
currently stay, many republicans started using Twitter only because folks
created accounts in their name, and they joined the bandwagon later..., even
the Dalai Lama's FB and twitter accounts got created... yes there are
problems, but they got fixed once the genuine people raised the alarm. From
where I stand, this functionality will go a long way to improve the first
hour experience, because new so called 'serious/fed agency/corporate' users
getting pushed into SL, come with the expectation that its registration
process will be like any web 2.0 application they are already familiar with.
Then beyond this issue, once they are logged in, comes the problem of
identifying each other...real names is the only cue that will allow them to
connect (in that first hour). And I have used pretty much all the tricks of
the trade to make their rl names appear above their avatar but the process
is crazy at best. They can learn about whether to trust or not these names
etc... later on and learn how to use exercise caution and address the name
spoofing issues pretty much like what happens in rl and at similar
frequencies. There are no perfect systems,I recognize that display names
feels like a band aid solution, so be it. SL is a mega bandaid...no turning
back. Some decisions were made in the past which lead to the naming problems
we see today, every bad initial decision which has been integrated into
useful functionalities will take a very long time to die (fact of life).
@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 take the noise as part of business,
that would be my advice to you. And I stop my noise here.
R

On Mon, Aug 23, 2010 at 9:24 AM, David M Chess  wrote:

>
> 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 question was "will there be procedures
> in place", and since the current Lab plan is that there won't be procedures
> in place, "No" is the right answer.
>
> You can argue that the current plan should be changed, but "wrong answer"
> just makes you sound faux-macho and confrontational.
>
> > I think the Lindens are underestimating the legal fallout that will ensue
> when names are abused.
>
> 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 someone else's?
>  How many times has Plurk been sued because you can make your display name
> be anything you like?  How many times has *any* online service been sued
> because it made it too easy for one person to masquerade as someone else?
>  What makes you think you have a better notion of the legal danger than the
> Lab's legal staff does?
>
> > People are stating loud and clear what they want.
>
> Careful inspection will reveal that not everyone is saying the same thing.
>
> > Are you guys deaf?
>
> No, they aren't.  And this kind of insulting tagline just makes you look
> like a posturing child.
>
> fwiw...
>
> ___
>
> ___
> 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
>



-- 
'Consider how the lilies grow. They do not labor or spin.'
*Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State
University, Pocatello, ID 83209 Tel: 208-282-5333
Blog ,
LinkedIn
, Play2Train 
___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Joshua Bell]

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: this broad class of identity-related
functionality was discussed when "Display Names" was being designed, and
while not tackled as part of that project, we made sure it was not precluded
and could still be undertaken later. We very much wanted to avoid embarking
on a "everything you always wanted to do with identity" project.

Joshua
___
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] Display names, again.

[Oz Linden (Scott Lawrence)]

 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 take the noise as part 
of business, that would be my advice to you.


I'm listening... and filtering out all amateur lawyers (and will be 
really really surprised if any of what I've seen is coming from anyone 
who's actually passed the Bar anywhere).


I'd much rather have to listen to noise than to silence.


___
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] separation between login id and publicly visible id(s)

[Oz Linden (Scott Lawrence)]

 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 linked agents centrally etc.


No argument from me!

But as with the other suggestion: this broad class of identity-related 
functionality was discussed when "Display Names" was being designed, 
and while not tackled as part of that project, we made sure it was not 
precluded and could still be undertaken later. We very much wanted to 
avoid embarking on a "everything you always wanted to do with 
identity" project.


... and people should appreciate that.  One of the easiest ways to fail 
to make progress is to insist on taking only giant leaps forward.  Small 
steps are not only quicker and easier, they're also less harmful if they 
turn out to be mistakes.



___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Yoz Grahame]

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 have. In fact, we did some technical design on a master account
system as part of a project which unfortunately had to be significantly
scaled back. The idea definitely isn't dead, though.

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. Using the email address as a
unique master account ID (and then choosing avatar on login) would probably
be the way to go - once we've managed to move email address out of the
avatar record, which is significant work in itself and not currently on the
roadmap. (However, there are also advantages to making email
unique-per-avatar; the horrible hackiness of the IM<->Email system is a
demonstration of that)


> Which would allow for interesting permission schemes, like allowing
> transfer of products only between avatars of the same account. (This would
> probably have to be a new permission. Allowing transfer of all "no-transfer"
> items between Alts, as 
> SVC-4319suggests, would probably 
> upset quite some people.)
>
> 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.
>

Yep. But obviously, as well as looking at this as a whole pile of useful
functionality, one has to look at this as a possibly-bigger pile of work.
Especially since most of the value comes from a load of new or overhauled
interfaces and logic rather than merely creating the underlying structure.
(Also, we consider any proposed changes to the permissions system with all
due reluctance, not to mention outright terror.)

In short: it's not a question of if but when and how, especially in relation
to all our other priorities.

-- Yoz
___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Joel Foner]

>
> 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... email addresses change fairly regularly. Basing the
permanent unique account identifier on a transient token seems bound to
create problems in the longer term due to user movements from one email
address to another, and old addresses become invalid and even forgotten by
users.

Joel
___
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] Display names, again.

[Will]

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] 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 take the noise as part of business, that would be my advice to 
you. 

I'm listening... and filtering out all amateur lawyers (and will be really 
really surprised if any of what I've seen is coming from anyone who's actually 
passed the Bar anywhere).

I'd much rather have to listen to noise than to silence.








___
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] Display names, again.

[Oz Linden (Scott Lawrence)]

 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 decline to 
predict its timing or content.


___
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] separation between login id and publicly visible id(s)

[Tateru Nino]

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 that it really should be


Just a quick note... email addresses change fairly regularly. Basing 
the permanent unique account identifier on a transient token seems 
bound to create problems in the longer term due to user movements from 
one email address to another, and old addresses become invalid and 
even forgotten by users.


Actually, I remember that the RegAPI (for a long time - don't know if it 
still does) wouldn't accept an email address that had /ever/ been used 
for registration of an account previously. Ran into that one during some 
client work.


--
Tateru Nino
http://dwellonit.taterunino.net/

___
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] Display names, again.

[Tateru Nino]

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 believe that one will be coming out in due time, but decline to 
predict its timing or content.
I'm already waiting on an official response from the Lab spokespersons 
(since last week). I'll blog it when it comes through.


--
Tateru Nino
http://dwellonit.taterunino.net/

___
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] Draw Distance

[Erik Anderson]

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 of indexes in order to improve
performance.  Two major versions later and the engine was suddenly smart
enough to figure it out on its own and the hash size override was
deprecated.

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?

On Sat, Aug 21, 2010 at 9:36 PM, Miro Collas  wrote:

> How about bbeing able to just type it in?  Why a slider, or mouse wheel,
> which is inaccurate? How about being able to type it in chat?
>
> On 08/22/2010 12:19 AM, a...@skyhighway.com wrote:
> > !! YES !!  If all i had to do was mouse up over the camera widget and
> roll
> > the scroll button i would be *soo* happy!  Serious.  i mean, Henri's
> > Cool VL innovation is great!  And i think that even if it were a mouse
> > wheel scrollable widget it should still have some kinda additional text
> > box to it where numbers can be typed in.  But to be able to look around
> > like that would be MEGA-AWESOME!!  (Just like opening your eyes *really*
> > wide...!!)
> >
> > - AK
> >
> >I probably use the draw-distance slider more often than any other UI
> > widget. I'd probably map it to my mouse's scroll-wheel, if I could.
> >
> > On 22/08/2010 10:31 AM, Suz Dollar wrote:
> >>> This is one concept that I have wanted for at least four years in SL. I
> >>> change draw distance multiple times a day depending on where I"m
> >>> visiting. Many of my own estate regions I can use a full powered 512
> >>> draw distance. Going to my public sandbox, however, requires an instant
> >>> drop to 128 or lower. Visiting my old 'hometown' of Caledon, mandates
> >>> the same. And I have to be honest, the places I can still use 512 draw
> >>> distance with viewer 2.x has dropped dramatically. I now usually can't
> >>> use higher than 256 yet have been assured since the first beta release
> >>> that there should be no performance difference between 1.23 and 2.x
> with
> >>> regard to graphics. An easily accessible way to change draw distance
> >>> would be awesome. I'm also frustrated that its so much harder with the
> >>> slider to hit the magic numbers: 64, 96, 128,  256 you get the
> idea.
> >>> But if the slider were at least out on the main UI somewhere, my own
> >>> preference being up in the navigation area, but anywhere directly
> >>> accessible, would be AWESOME.
> >>>
> >>> Char
> >>>
> >>>
> >>> a...@skyhighway.com wrote:
> > There was some talk lately about draw distance.  i mentioned that
> > from my
> > place if i have my draw distance turned up over about 150 i can
> almost
> > count on crashing when i tp.  i'm really sorry i can't describe the
> > problem any better than that.  If someone wants to tell me how i
> could
> > understand it better, i'd love to listen?
> >
> > Anyway, i mentioned in mail to this list that it would be really
> > cool if
> > there were an onscreen widget like the movement&   camera controls
> that
> > made draw distance a lot easier to change.  Please forgive me for not
> > having already figured out how to do that myself.  Just sayin' tho,
> it
> > would be really nice if, like for instance, Snowglobe had either a
> > mouse
> > gesture, keyboard short cut, or onscreen widget (all three?) for
> > rapidly,
> > easily changing draw distance,  i think it's a function that lots of
> > people would use heavily.  i know there's performance concerns, but
> if,
> > for instance, the onscreen widget included a simple performance bar
> > indicator that went down as the draw distance was turned up, that
> would
> > communicate pretty well to all the people who didn't know better for
> > whatever reason.
> >
> > The tp crash i get is just one more reason to make the setting easy
> to
> > deal with.  Besides, to me it seems like such a natural part of
> camera
> > controls that i don't know why it's not there already?  If it was me
> > adding the feature i'd put it in the camera controls widget.  i'd
> been
> > using SL for several months before i even realized that draw
> > distance was
> > configurable.
> >
> > Thanks for listening!
> >
> > ___
> > 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/wik

Re: [opensource-dev] Draw Distance

[Arrehn Oberlander]

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 a number of use cases that call
for different draw distances.

If you're playing with some kinds of vehicles, you may have the best
experience with a medium-low draw distance to keep framerates high but
still let you see where you're going.
If you're in the audience of a high-traffic event, you may have the
best experience with an extremely low draw distance.
If you're taking photographs, particularly of scenery, you will turn
draw distance up very high and not be so concerned with framerates.
If you're trying to keep an eye on a particular spot on a sim X
distance from you, you'll want to use a draw distance of at least X.
If you're in an indoor area with confined spaces, a very small draw
distance may be optimal.
If you're trying to get 'the lay of the land' for how a region is
spread out, a higher draw distance may be necessary so you can see
buildings and landscaping together.

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).  I find myself frequently adjusting draw
distance in practice, mainly for photographcs, music events, and some
types of vehicle use. Viewers that have some quick UI for for this are
far more handy than the clicks involved in navigating to custom
graphics preferences.
___
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] Draw Distance

[Martin Spernau]

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 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 fps' and 'optimize for view distance'  
would be the viewer equivalöents

-Martin


___
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] Draw Distance

[Bunny Halberd]

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 fps' and 'optimize for view distance'
> would be the viewer equivalöents

That's exactly what I was thinking.

Most cameras have several settings:

 - Auto (this is the default and most people just leave it here)
 - Portrait (short depth of field, center weight the exposure)
 - Landscape (very long depth of field, balance the exposure)
 - Fully Manual (that's what SL has today)

I've often wondered why there isn't an "auto" setting on SL where it
can manage the draw distance for you, if you want it to. Just like the
fully automatic mode on a camera.

- Bunny
___
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] Draw Distance

[aklo]

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 is that draw distance is a candidate for a (maybe optional)
onscreen widget that makes it as easy to adjust as the camera controls.

All the ideas for chat line access and defaults management of draw
distance and other settings are really awesome, too!  My opinion says they
should be implemented in parallel with something super simple and obvious
to use for draw distance, including maybe even a way to enable a mouse
gesture the same way it works for the maps.

If you think about it for a sec, isn't a quick and easy type of "draw
distance" adjustment part of the way our eyes work?  It seems very natural
to make SL work in its world the same way.

- AK (Aklo Modan)

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 a number of use cases that call
for different draw distances.

If you're playing with some kinds of vehicles, you may have the best
experience with a medium-low draw distance to keep framerates high but
still let you see where you're going.
If you're in the audience of a high-traffic event, you may have the
best experience with an extremely low draw distance.
If you're taking photographs, particularly of scenery, you will turn
draw distance up very high and not be so concerned with framerates.
If you're trying to keep an eye on a particular spot on a sim X
distance from you, you'll want to use a draw distance of at least X.
If you're in an indoor area with confined spaces, a very small draw
distance may be optimal.
If you're trying to get 'the lay of the land' for how a region is
spread out, a higher draw distance may be necessary so you can see
buildings and landscaping together.

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).  I find myself frequently adjusting draw
distance in practice, mainly for photographcs, music events, and some
types of vehicle use. Viewers that have some quick UI for for this are
far more handy than the clicks involved in navigating to custom
graphics preferences.
___
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] Draw Distance

[aklo]

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 there at the time.

i think one of the important ideas in Arrehn's mail and some of the earlier
messages is that draw distance is a candidate for a (maybe optional)
onscreen widget that makes it as easy to adjust as the camera controls.

All the ideas for chat line access and defaults management of draw
distance and other settings are really awesome, too!  My opinion says they
should be implemented in parallel with something super simple and obvious
to use for draw distance, including maybe even a way to enable a mouse
gesture the same way it works for the maps.

If you think about it for a sec, isn't a quick and easy type of "draw
distance" adjustment part of the way our eyes work?  It seems very natural
to make SL work in its world the same way.

- AK (Aklo Modan)

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 a number of use cases that call
for different draw distances.

If you're playing with some kinds of vehicles, you may have the best
experience with a medium-low draw distance to keep framerates high but
still let you see where you're going.
If you're in the audience of a high-traffic event, you may have the
best experience with an extremely low draw distance.
If you're taking photographs, particularly of scenery, you will turn
draw distance up very high and not be so concerned with framerates.
If you're trying to keep an eye on a particular spot on a sim X
distance from you, you'll want to use a draw distance of at least X.
If you're in an indoor area with confined spaces, a very small draw
distance may be optimal.
If you're trying to get 'the lay of the land' for how a region is
spread out, a higher draw distance may be necessary so you can see
buildings and landscaping together.

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).  I find myself frequently adjusting draw
distance in practice, mainly for photographcs, music events, and some
types of vehicle use. Viewers that have some quick UI for for this are
far more handy than the clicks involved in navigating to custom
graphics preferences.
___
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] Draw Distance

[Tateru Nino]

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 (although there
>> are hints, I will grant).
>
> 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 fps' and 'optimize for view distance'
> would be the viewer equivalöents
Something very much like that, yes. I've only got about six common 
settings, but I might use all of them in the space of five minutes.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[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, and that's not unique, though we're
>> starting to think that it really should be
>>
>
> Just a quick note... email addresses change fairly regularly. Basing the
> permanent unique account identifier on a transient token seems bound to
> create problems in the longer term due to user movements from one email
> address to another, and old addresses become invalid and even forgotten by
> users.
>

Many other services seem to manage it just fine. But this is the kind of
devil in the details that makes it require some more thought. I'm sure we'd
have some kind of internal account ID (in a similar vein to agent ID) to
which everything's tied, so that email changes would have minimal
administrative update cost, and we'd keep a history of all such changes.
That's *if* this is the route we take, if and when we do this work.

-- Yoz
___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Lance Corrimal]

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, and
> >> that's not unique, though we're starting to think that it
> >> really should be
> > 
> > Just a quick note... email addresses change fairly regularly.
> > Basing the permanent unique account identifier on a transient
> > token seems bound to create problems in the longer term due to
> > user movements from one email address to another, and old
> > addresses become invalid and even forgotten by users.
> 
> Many other services seem to manage it just fine. But this is the
> kind of devil in the details that makes it require some more
> thought. I'm sure we'd have some kind of internal account ID (in a
> similar vein to agent ID) to which everything's tied, so that
> email changes would have minimal administrative update cost, and
> we'd keep a history of all such changes. That's *if* this is the
> route we take, if and when we do this work.
> 
> -- Yoz


one additional field in the avatar's data... "parent UUID"... the main 
avi would have NULL_KEY in there, alts would have the UUID of the 
"master account".
users would always log in with the login account, and after you log in 
but before you actually connect to the grid you'd get a popup with a 
list of your avatars to select from, and a button for "create new 
avatar".

During rollout each avatar would be set up as a master avatar (parent 
avi = NULL_KEY), and on the website you could link your alts to your 
main account IF YOU SO DESIRE.

This relation would/should not be visible for anyone else but the 
avatars in question, of course.

each avatar could have a separate email address configured for IM to 
email, changeable in preferences and the website. newsletters and the 
likes would _only_ be delivered to "master accounts"... I believe that 
would cut the sheer volume of email traffic coming out of the lab down 
to 30% if not less (not counting IM to email).

This relation would/should not be visible for anyone else but the 
avatars in question, of course.

it would also open a way towards shared inventories (which might 
actually require an additional boolean in every asset... a permission 
bit that a creator could set, "allow to share with your alts" or 
such). it would also allow xstreet purchases to be delivered to your 
alt (making freebies pseudo-giftable).



bye,
LC


___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Ricky]

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 single email account, but have as many "unique"
addresses as I need for a given task.

I've had too much trouble with websites and programs accepting an
email address with a +, but choking on it after account creation...

Ricky
Cron Stardust

On Mon, Aug 23, 2010 at 1:51 PM, Lance Corrimal
 wrote:
> 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, and
>> >> that's not unique, though we're starting to think that it
>> >> really should be
>> >
>> > Just a quick note... email addresses change fairly regularly.
>> > Basing the permanent unique account identifier on a transient
>> > token seems bound to create problems in the longer term due to
>> > user movements from one email address to another, and old
>> > addresses become invalid and even forgotten by users.
>>
>> Many other services seem to manage it just fine. But this is the
>> kind of devil in the details that makes it require some more
>> thought. I'm sure we'd have some kind of internal account ID (in a
>> similar vein to agent ID) to which everything's tied, so that
>> email changes would have minimal administrative update cost, and
>> we'd keep a history of all such changes. That's *if* this is the
>> route we take, if and when we do this work.
>>
>> -- Yoz
>
>
> one additional field in the avatar's data... "parent UUID"... the main
> avi would have NULL_KEY in there, alts would have the UUID of the
> "master account".
> users would always log in with the login account, and after you log in
> but before you actually connect to the grid you'd get a popup with a
> list of your avatars to select from, and a button for "create new
> avatar".
>
> During rollout each avatar would be set up as a master avatar (parent
> avi = NULL_KEY), and on the website you could link your alts to your
> main account IF YOU SO DESIRE.
>
> This relation would/should not be visible for anyone else but the
> avatars in question, of course.
>
> each avatar could have a separate email address configured for IM to
> email, changeable in preferences and the website. newsletters and the
> likes would _only_ be delivered to "master accounts"... I believe that
> would cut the sheer volume of email traffic coming out of the lab down
> to 30% if not less (not counting IM to email).
>
> This relation would/should not be visible for anyone else but the
> avatars in question, of course.
>
> it would also open a way towards shared inventories (which might
> actually require an additional boolean in every asset... a permission
> bit that a creator could set, "allow to share with your alts" or
> such). it would also allow xstreet purchases to be delivered to your
> alt (making freebies pseudo-giftable).
>
>
>
> bye,
> LC
>
>
> ___
> 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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Argent Stonecutter]

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 really should be.

If email is an issue...

You could ask people to set up a unique account ID to merge their current 
accounts into. Or let them choose to keep on using (one of) their existing ID 
and create new avatars/identities/whatyoucallems under that.
___
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] Draw Distance - TPV Solution Example

[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 detail vs
performance.

It's simple, elegant, and most importantly, "Functional on the Fly" - ergo,
would be great to see this slider in Snowglobe or Main LL Viewer.

SF.

___
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] Draw Distance - TPV Solution Example

[Lance Corrimal]

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 detail vs performance.
> 
> It's simple, elegant, and most importantly, "Functional on the Fly"
> - ergo, would be great to see this slider in Snowglobe or Main LL
> Viewer.
> 

its in the starlight skin, so it can only be a pure xml thing.


bye,
LC
___
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] Draw Distance - TPV Solution Example - SLIDER Correction

[Science Fiction Computer - SCi-Fi PC]

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@lists.secondlife.com
Subject: 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 detail vs performance.
> 
> It's simple, elegant, and most importantly, "Functional on the Fly"
> - ergo, would be great to see this slider in Snowglobe or Main LL
> Viewer.
> 

its in the starlight skin, so it can only be a pure xml thing.


bye,
LC
___
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 incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3090 - Release Date: 08/24/10
04:34:00

___
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] Draw Distance - TPV Solution Example - SLIDER Correction

[Lance Corrimal]

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 information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Tateru Nino]

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.taterunino.net/

___
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