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 tateru.n...@gmail.com 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?
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 Ninotateru.n...@gmail.com 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
Re: [opensource-dev] Draw Distance
On Mon, Aug 23, 2010 at 5:49 AM, Laurent Bechir laurent.bec...@madonie.org 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?
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 miro.col...@gmail.com 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 Ninotateru.n...@gmail.com 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
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 LLCachedControlbool 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?
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)
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.
This post could be a classroom lesson in how to alienate people and not be taken seriously. Daniel Smith javajo...@gmail.com: 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.
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 ch...@us.ibm.com wrote: This post could be a classroom lesson in how to alienate people and not be taken seriously. Daniel Smith javajo...@gmail.com: 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 http://deepsemaphore.posterous.com/, LinkedInhttp://www.linkedin.com/in/rameshramloll , Play2Train http://www.play2train.org ___ 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?)
On Mon, Aug 23, 2010 at 2:32 AM, Boroondas Gupte 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. 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.
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) (was: display names = the end of 1.x viewers?)
On 23 August 2010 02:32, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: You'd win :-) SVC-6212 http://jira.secondlife.com/browse/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-4319http://jira.secondlife.com/browse/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?)
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.
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] 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 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] 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 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
On Mon, Aug 23, 2010 at 3:06 PM, Martin Spernau mar...@traumwind.de 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
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 eri...@odysseus.anderson.name 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
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 eri...@odysseus.anderson.name 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
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?)
On 23 August 2010 11:51, Joel Foner joel.fo...@gmail.com 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?)
Am Monday 23 August 2010 schrieb Yoz Grahame: On 23 August 2010 11:51, Joel Foner joel.fo...@gmail.com 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?)
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 lance.corri...@eregion.de wrote: Am Monday 23 August 2010 schrieb Yoz Grahame: On 23 August 2010 11:51, Joel Foner joel.fo...@gmail.com 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?)
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
