[opensource-dev] llRegionSay() vs. HTTP-In
Slightly off topic, but I have a region performance question: >From an in-sim usage standpoint, and say 2-20 messages per second prospect What are the pro and cons of llRegionSay() vs. HTTP-In in terms of resources? (aside from the known pro and cons of the function itself as stated on the wiki) Are there any potential performance benefits from using one vs. the other? ___ 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] Hippotropolis Theater Design Competition
Oh! The grand prize is a lunch? Such a grandiose generosity from Linden Lab!!! The losers get to sell their models on the marketplace instead for more L$... PS: Don't forget to flush the toilet Oz. On 3/7/12 12:05 PM, "Oz Linden (Scott Lawrence)" wrote: >Hippotropolis is our region for promoting and supporting the open source >program, and I've been doing some updating there; as part of that, >Linden Lab is sponsoring a competition to design a new meeting space: > >https://wiki.secondlife.com/wiki/Hippotropolis_Theater_Design_Competition > > >___ >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] Third party viewer policy
A name suggestion for viewers: "A viewer that connect to a virtual world that can't be name for risks of being objected to by a company with aggressive lawyers who like to come up with unconscionable terms of services, or who make illegitimate attempts of one's right to forbid the usage of words they do not have trademark rights over" > "Unfortunately they maintain that we put our trademark at risk without consistent enforcement. They can't budge." Soft, they ought to consider that abusive overreach on their part could on the other end, put LL at risk of being liable once again of lawsuits being translated in court to unconscionable terms of services. Sounds familiar? As far I recall LL has the trademark over "SL" and "Second Life". So perhaps your lawyers could suck the "Life" out of their jurisdictions? I get the fact that they had to go an extra unusual mile with brand name protection due the nature of the company's name. But there was also an attempt to trademark the word "grid" alone, in the past. That speaks a lot! I don't see a need for concessions here, but for your lawyers to re-evaluate their legitimate rights to such claim to begin with. I just don't see it. If I was your marketing department. I would be equally concerned as to the repercussions of such restrictions for impeding the ability for Linden Research to promote its Second Life name and market itself as a grid. "Stop shooting yourself in the foot. It could impede your ability to walk." On 2/24/10 11:16 AM, "Soft Linden" wrote: > On Wed, Feb 24, 2010 at 1:50 AM, Marine Kelley wrote: >> You gotta be kiddin me !! I call that a stab in the back. You guys disgust >> me. >> >> Your Third-Party Viewer name must not be confusingly similar to or use any >> part of a Linden Lab trademark, including ³Second,² ³Life,² ³SL,² or >> ³Linden.² For example: >> >> You must not have a Third-Party Viewer name that is ³ Life² where >> ³² is a term or series of terms > > I talked to legal to ask if there were any concessions they could make > - I know there are hundreds of items that use your name, which makes > this really disruptive. Unfortunately they maintain that we put our > trademark at risk without consistent enforcement. They can't budge. > However, they were willing to offer some extra time for transitioning > to a new name, as well as help in making sure people can still find > your viewer based on the old name. > > First, you wouldn't need to change the name right away. They were okay > with giving three months to make a change, in hopes that that's enough > time to do so without a rush or an extra release. > > Second, if you're able to do that, you can still be listed in the > viewer registry right away. You'd need to select a new name for the > viewer, but "(formerly Restrained Life)" will be shown underneath the > name so there's no question as to which viewer people would download > if they came in search of your own. > > If there's anyone else with an established viewer name that conflicts > with the viewer policy, and who wants to be included in the registry, > the same offer is open to you as well. > ___ > 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] FAQ posted for Third Party Viewer Policy
Morgaine, I think your statement is a misunderstanding on your part. It¹s not ³just promotion². You don¹t have a choice but to be be listed AND comply if you want to legitimately connect to the grid with your viewer. As originally intended by LL. They are not exclusive as currently implemented and described, unless they change that: ³agree to our Policy on Third-Party Viewers and the Second Life Terms of Service. If you do not agree, you are ineligible for the Viewer Directory, and you do not have permission to access Second Life using a third-party viewer.³ i.e. You either comply AND feature in the "viewer registry". OR ignore it, as you said and you¹d be in breach of the TOS as such: ³5.6 You will indemnify Linden lab from claims arising from breach of this Agreement by you, from your use of Second Life, from loss of Content due to your actions, or from alleged infringement by you². And I don¹t think opting out of the "viewer registry" should or ever will be an option. On 2/28/10 4:44 PM, "Morgaine" wrote: > Joe, thanks for clarifying that what you are doing with the Directory is > "promotion" of Third Party Viewers. Since it's just promotion, TPV developers > are free to ignore it when they excel on features and don't need promotion, > and of course you will never make promotion mandatory. ___ 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] FAQ posted for Third Party Viewer Policy
Sorry Morgaine, I stand corrected by having read the FAQs afterwards. I thought registration was required to connect to the grid... Joe, I agree with others that it¹s not enough to guard against intellectual property infringement and protect residents. Is there a plan to allow inworld residents to detect unidentified/unregistered Viewer names or Identifiers as least? Without that, I don¹t see how the current policy would actually fulfill goals of the policy and program from actual rogue viewers. It¹s a good step but that leaves security loopholes without such enforcement abilities. An LSL function somewhere to identify viewers would help. Leave then to us the ability to make inworld tools to control who gets in or not. Bryon On 2/28/10 5:36 PM, "Joe Linden" wrote: > TPV developers may choose to list their viewers in the Directory for the value > of receiving a wider awareness than they may be able to create themselves, or > not. That's entirely up to the developer. All viewers that connect to the SL > grids will need to abide by the TPV Policy regardless of their choice to list > in the Directory. > > And, since we're only talking about conditions that apply when a TPV connects > to Linden Lab's grid(s), we reserve the right to add, subtract, or otherwise > modify those conditions at any point in the future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine > wrote: >> >> ... Since it's just promotion, TPV developers are free to ignore it when they >> excel on features and don't need promotion, and of course you will never make >> promotion mandatory. >> >> Morgaine. ___ 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] FAQ posted for Third Party Viewer Policy
Of course, I know that Tigro. But just like any web site can detect a user-agent and block it, I'd like to be able to detect the viewer agent, (perhaps via llGetAgentInfo) of the avatar getting on my land anyway. Such would be useful for various other reasons such a compatibility checks, analysis of traffic sources, who you visitors are etc... On 2/28/10 7:15 PM, "Tigro Spottystripes" wrote: > > Last i've heard, if you know what you're doing, it's quite easy to mask > your viewer as being another viewer; any detection system would only be > able to catch viewers made by unskilled people (and viewers that > intentionally tell the truth). > ___ 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] FAQ posted for Third Party Viewer Policy
Carlo, I talked about banning every unknown or unidentified viewer that is not in the registry should I have a way to detect the viewer agent. Just like I have the right to restrict an unidentified web agent or telling an Internet Explorer 6.0 user than I do not support their obsolete browsers from my site. There is no violation of your privacy. This is regulation and policy within my own land, for my user base and customers protection. If a developer wants to test his own viewer, he is free go to a developer sandbox reserved to that effect (where they allow it), or on its own land. The bottom line is that if a TPV developer is not taking measures to be in the registry, there is no reason for me to trust and allow that viewer to enter my land. Others can make their own assessments as they see fit. Initially, I thought LL was to restrict unidentified viewers all together. And I can see why that could a bit much. Although you know there is a beta grid for testing and if LL really wanted maximum security they could very well do that and only allow testing (unidentified viewers) on the beta grid. You are left with with those who can spoof other viewers but nevertheless it would be a solid measure. And when I mean viewer, I mean the viewer mainly. I agree that an Avatar shouldn't be necessarily banned everywhere for using such viewer in one location under the currently assumed policy. That's a legit concern to have as a developer. I personally wouldn't support such drastic measures and don't endorse or use the type of device you describe. The reason such imperfect measures exists though, is precisely because there are no alternatives at this time. All I am asking is the minimum standards which currently apply to browsers. Some kind of cookies down the road would be nice too. > DO NOT ADD YOUR VIEWER... at least not until > the great majority agrees with the literal wording of the final > published TPV policy, and we're far from that. nods On 3/1/10 5:04 AM, "Carlo Wood" wrote: > On Sun, Feb 28, 2010 at 07:55:57PM -0800, Bryon Ruxton wrote: >> Of course, I know that Tigro. But just like any web site can detect a >> user-agent and block it, I'd like to be able to detect the viewer agent, >> (perhaps via llGetAgentInfo) of the avatar getting on my land anyway. >> Such would be useful for various other reasons such a compatibility checks, >> analysis of traffic sources, who you visitors are etc... > > Actually, since you clearly WILL use this info to ban people from > your shops,... it's a violation of privacy. > > Look at that scam object that was released not long ago, being > sold for a monthly fee of L$ 700... It adds peoples names to > a central database once they are detected (hopefully without > any false-positives) to use a known-bad viewer (ie, neillife > or cryolife, listed by name in the blog threads). Result: > that account is from then on banned in EVERY sim that uses > this object. There is so much wrong with that that I won't > even begin. > > Add to that remarks in the said blog like "every possible > banned thief is a benefit", and the conclusion is easy: > If LL makes the agent ID's public, people will soon ban > *ALL* minor TPV's (being all of them, except maybe emerald, > because that has already a pretty large userbase) "just in case". > > The result: Total death to all TPV development; nobody will > be able to start with their own new viewer, because nobody > will use a viewer that is instantly banned JUST because it's > used by a minority and you "never know if won't be stealing > my stuff". > > Hence, privacy. ___ 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] FAQ posted for Third Party Viewer Policy
It's not a concern that apply in this environment. It would be an issue between the grid and the TPV developers to resolve. Land owners don't control the markup language structure of their 3d environment. On 3/1/10 2:25 PM, "Argent Stonecutter" wrote: > On 2010-03-01, at 16:13, Bryon Ruxton wrote: >> I talked about banning every unknown or unidentified viewer that is >> not in >> the registry should I have a way to detect the viewer agent. Just >> like I >> have the right to restrict an unidentified web agent or telling an >> Internet >> Explorer 6.0 user than I do not support their obsolete browsers from >> my >> site. > > There are several sites where I have to lie about my browser, because > their browser selection logic is screwed up. > > Like the ones that only work if I set the user agent to IE6 or IE5.5. > > Like the ones that insist I use Netscape Navigator 4 or better and > don't work on Firefox. > > > ___ 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] Open Development project: extending avatar wearables
Could you please stop putting everything into that sidebar as the only way to access stuff. You¹ve kept wanting to make this ³communicator window ³ before into a single un-detachable block. And despite many of use hating it and asking for you to make separate floaters, (or at least give us that option), you keep attaching everything all together again in that sidebar. This is an ill conceived approach for many of us, who are used to identify specific panels at a specific position of our choice on the screen just like . Blending it all together makes it harder in that sense. I recall LL hiring a guy who worked on the Tivo interface which is a great one for its purpose. But the viewer is a much more complex interface. I see too much of the Tivo formula into this ³drawer². The worse part is that the sidebar buttons are stuck on the left side and actual move with the sidebar panel itself. That seems wrong. Button should stay at the same place on the right in an Adobe fashion for distinction purpose. I wish you had studied and adopted the approach of the Adobe UIs with stackable and detachable panels and buttons on the right side (which always stay there). Their approach is a much better solution in my view that this drawer type, which is a huge waste of space right now and adding to the required amount of clicks to get somewhere. In short, please reserve an option for detachable floaters as much as possible, and please consider the Adobe approach for a more flexible and customizable sidebar(s) for Version 2.x.x Thank you On 3/22/10 8:06 PM, "Nyx Linden" wrote: > Good question! There is still a lot of detail left out of these descriptions, > but we are planning on moving the UI in the appearance editor into the > sidebar, along with creating a new outfit editor UI. You will still see the > results of the changes you are making on your avatar in-world in real time. > There will still be an "editing appearance" mode as you have now, it will just > be accompanied by a panel in the sidebar instead of a separate floater. > > - Nyx > > On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter > wrote: >> >> On 2010-03-22, at 12:45, Nyx Linden wrote: >>> 1) A new panel to edit what is stored in your saved outfit without >>> creating a new one. >>> This will include both an inventory view and a view of your outfit >>> itself, so you can drag items from your inventory to your outfit without >>> having an extra floater open >>> 2) Editing of wearable items (body parts and/or clothing objects) in the >>> sidebar, selectable from the outfit editor >>> 3) Removal of the appearance floater >> >> I have a concern about this, where it comes to editing outfits containing >> prim parts. You have to see them in world, you can't just edit them in a >> sidebar window, because you may need to edit them with reference to objects >> in world. >> >> If I'm mistaken about what "removal of the appearance floater" means, in the >> context of a UI designed to allow you to edit outfits without having to wear >> them, then I'll be happy to be corrected. >> > > > > ___ > 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] Thank you for updating the Viewer Directory requirements
Henri, > So, registering to the directory is clearly not a requirement to be considered as TPV-policy compliant, but on the other hand LL suggests that the viewers which are not in the directory are "dangerous" ones... This is both unfair and very close to pure diffamation. The viewer is required to comply, just make your viewer comply and don't register in the directory. If they are to prevent any viewer that does not comply with the TPV to connect to the grid I am glad for it. And I agree with you in substance with your privacy claims, but you have to live in the real world and you have to abide by California law here. You own interpretation of French law is irrelevant. Yes LL has a wishy-washy policy designed not to accept any responsibility for anything. Guess what! So does Google and every hosting company on the planet, I have the same type of clauses as a business and doing otherwise would stupid and putting my company and myself at risk. If you are not willing to trust anyone with your basic information, you may want to start building your own personal datacenter Henri. You ARE trusting free.fr and Paypal with even more sensitive data btw... What should I or anyone trust using your viewer if there is so much to hide and unwillingness to provide a real name and a simple physical address. If I applied your own standards of trust, I am afraid I see no way for me to even consider using your viewer for my own protection. Just think about it. On 4/28/10 2:57 PM, "Henri Beauchamp" wrote: > Sorry, but as far as I'm concerned, I won't take the risk and won't trust LL > (or any other company on Internet, even French ones) about being able to keep > my data safe from prying eyes... ___ 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] Banning by client
Is that thing really exploiting a quicktime hack? I.e. Trying to protect Computer Crimes Law by violating the very same laws. If so, isn't that against the LL TOS and shouldn't it be taken down by LL? The below reviews have me raising eyebrows... https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=2138 424&allReviews=1#reviews "Sandrina Koolhoven on 2010-03-22 27 of 71 members found this review helpful. "THIS system is indeed using a hack through Quicktime that gains access to a persons hard drive. This system has been torn down and looked at. Scanning yours or my HDD is a clear violation of USA Privacy laws and only LL has a right to know who your alts are, not the designer of this system."... Dekadance Mint on 2010-03-17 79 of 165 members found this review helpful. "Easiest method to avoid detection by this device requires no compiling or programming, just add "-noquicktime" into the short cut, and this device can't detect you untill Skills finds a new method of detection. I say this tidbit of info because the appeal process is atrocious and horrible from my experience." On 4/30/10 10:06 PM, "Tigro Spottystripes" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > there is Skill's CDS system > > On 1/5/2010 01:45, Andromeda Quonset wrote: >> I went there. I saw a "GC Continental" was on the ban list for both >> of the sims. That was the closest I could find to you. >> >> I am not aware of there being any autobanners that ban by client that >> any landowner or sim owner can use. I don't know of any way to >> detect via script or estate or land controls what client someone is even >> using. >> >> I do know there is maintenance going on, and regions being >> restarted. Perhaps you were simply caught in a sim restart. >> >> At 09:49 PM 4/30/2010, Glen Canaday wrote: >>> There are autobanners that ban by client, no? Full-sim, estate ban? >>> >>> I'm on Snowglobe 2 and just got banned from both The Loft and The Loft >>> II; both are furniture store sims. Can someone TP there and test if they >>> get banned? If someone is banning by presence on the TPV list, then snow >>> needs to be on it rather than listed separately... (tho I could have >>> sworn it WAS on it)... >>> >>> --GC ___ 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] [POLICY] Configurable HTTP user-agent string
Can't we just get an additional AGENT_VIEWER flag via llGetAgentInfo? Even if not foolproof, it's useful as a factor for legitimate security or warning tools, as well as for stats gathering for 99% of residents. It seems like a logical solution to me, instead of having to go the http agent route or other hackish solutions. If I don't get any feasibility objections here, I'll open a Jira issue. I haven't' seen any such proposal on there yet... On 5/5/10 4:18 AM, "Robin Cornelius" wrote: > On Wed, May 5, 2010 at 11:02 AM, Tigro Spottystripes > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> can the the client loading HTML on a prim be considered the same as the >> internal web browser or the rules change in that case? > > Techinaly there is no "internal" webbrowser, all html pages are > generated from a seperate process to the viewer using the webkit > rendering engine and passed to the viewer as a texture via a shared > memory buffer. Using seperate processes is enough to isolate from GPL > issues and other licence issues in other cases so i can't see what the > html engine user agent string has to do with the TVP and the unique > identifier which is used by LL on the xmlrpc login processin this case > either. > > I often have to change user agent on my browser to fix broken > websites, I can't see how this is any different. > > Plus if this "really" is an issue LL can request that you unfix your > code, i believe that was part of the TVP conditions for connecting to > SL but again the webbrowser is not specificly connecting to secondlife > and its the age old story of anyone who wants to do bad things can and > will fake idents regardless, its only leigit viewers that need to fake > idents to avoid "broken content" in this case and not allowing a > viewer to fake this only hurts and would make a mocery of the entire > 3rd party viewer system. > > 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 > > ___ 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] Open Viewer Development Announcement
Oz, Henri does not seem to suggest going back to 1.23 code as much as the UI behavior ought to go back to the way 1.23 functioned. And rightfully so when it comes to ³That moronic side bar is its modal tools which impair productivity and user-friendliness...² As bluntly put as it is. This is a problem description. I¹ve seen that harsh criticism a dozen times in blogs and forums as well. If that requires us to do a wire frame for you to get that idea, please tell us so, but frankly we are talking about a global oop behavior for all panels as far I am concerned, and it shouldn¹t require you a complete description for that... Kirsten Lee Cinquetti is one who completely gets is when it comes to such modification of the v2 U, back to a more fluid 1.23 way. And there is a lot more to do, but she¹s headed in the right direction. I understand blunt comments rubs you the wrong way, but the sidebar rubs us the wrong way in equal measures. It¹s the 1st major problem preventing me from even beginning to use viewer 2... as much as I¹d like to. I think addressing the hurdles that prevents people still on 1.23 to move to 2.0 before you get into ³Rapid, effective deployment of new features and functionality.² is the most urgent priority in my opinion. PS: Henri, Q acknowledged and explained what happened with V2 here http://www.ustream.tv/recorded/8948405. That failure has little to do with developers as much a LL leaders who had a poor understanding when it comes to the SL interface as week as misdirected or flawed overall goals. Don¹t expect a: ³We fucked up² from them it¹s not going to happen. Some of those probably left LL anyway... But Q. Oz and Philip acknowledged it multiple times in their own measured comments. So let¹s put that criticism to rest, it only add to the fire. On 8/16/10 11:56 AM, "Oz Linden (Scott Lawrence)" wrote: >On 2010-08-16 14:23, Henri Beauchamp wrote: >> >> Well, the first improvement to do is to actually revert 80% of the UI >> to the way v1.23's one was working, especially getting rid of that >> moronic side bar is its modal tools which impair productivity and >> user-friendliness... The question is: will LL finally admit that the >> viewer 2 UI is a failure and widely rejected by 80% of its regular user >> base, and accept a move in the way of "going back" (actually repairing) >> UI-wise ?... > > I've said this before, and I'll repeat it again here: > > Don't waste everyones time suggesting that we throw away Viewer 2, or that we > revert the UI to Viewer 1. It is absolutely not going to happen, and any > suggestion to that effect will be ignored. > > That does not mean that we don't recognize that some choices in V2 were not > optimal, and that some probably need to be revisited, and we're open to doing > that. But we will do it in the context of calm discussions of what problems > exist and creative ideas for how to solve them. We are not moving backwards, > we are moving forwards. > > Think about it for a minute - there are an infinite number of possible > solutions for how to build a UI for a virtual world viewer - what are the odds > that the first or second attempt produced the best possible UI? We need new > and creative ideas focused on specific problem descriptions. ___ 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] Open Viewer Development Announcement
Mike, First of all, I said ³us² in the context of those, like Henri, who hate the sidebar. As for ³we² in general, it is the majority who says they hate or dislike viewer 2.0 as indicated by multiple polls or articles like the following, justifying the word ³we² (i.e. the overall majority of Residents who gave their opinion): http://www.questionpro.com/akira/ShowResults?id=1604314&mode=data (75% disliking or hating the sidebar here.) http://blogs.secondlife.com/poll.jspa?poll=1017 http://blogs.secondlife.com/poll.jspa?poll=1018 http://polldaddy.com/poll/3048677/?view=results http://nwn.blogs.com/nwn/2010/03/20-not-increasing-growth.html Thus it¹s not my personal feelings. I check my facts before I say something. When there is that much ³hate²(and not just dislike) for a product by such significant measure, deploying a task force to find out why, and how to fix it in emergency mode is required. That also includes listening to people like you who like the interface, and see exactly what they like, to assess the changes necessary, and what ought to be kept in consideration for the 10-20% who like it. On 8/16/10 4:50 PM, "Dickson, Mike (ISS Software)" wrote: > As another poster has already pointed out, there is no *us* in a argument like > this. Stop trying to attribute your personal feelings as the will of everyone > else. I'm sure there are people that don't like the current viewer. > Personally *I DO*. There is room for improvement (I host at clubs for > instance and sending notices in viewer2 is many more mouse clicks) but overall > I like the new interface and features. So if you *don't* then please find a > constructive way to suggest improvements or work on a 3rd party viewer with > the old interface. But don't attribute your opinions to some global "us" as > that doesn't exist. > > Mike > ___ 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 = the end of 1.x viewers?
As you are implementing this, you may to consider forcing capitalization via JavaScript or else on the first name (from the official actual username) e.g. "first Linden" look bad as if there is a typo in there and such proper nouns are normally capitalized. I have always found it annoying to see lowercase first names. It is probably mostly a result of omissions, but also tends to happen more frequently with younger users. And as we "officially" will get 16 and 17 years old it is much more likely to happen. It happens a lot in shopping carts or any web user database if you don't automatically capitalize first and last names or addresses by code, which I now tend to do to prevent such inconsistence in postage labels, etc... It would make for a more consistent database too. On 8/17/10 2:41 PM, "Brian McGroarty" wrote: > On Tue, Aug 17, 2010 at 2:34 PM, Lance Corrimal > wrote: >> ... >> http://blogs.secondlife.com/community/features/blog/2010/08/17/display- >> names-bringing-greater-self-expression-to-second-life >> >> ... I guess that means the end for logging in with 1.x based viewers, >> does it? > > Old viewers will continue to work. Old accounts would continue to log > in as they do today. New accounts log in with their username as their > first name and "Resident" as the last name. (For the difference > between username and Display Name, see the FAQ linked at the end of > the blog post). > > Under the hood, for all legacy viewers and scripts, the only real > change is that new accounts created after some point will only ever > have "Resident" as a last name. The new Display Names won't replace > usernames in any location within an old viewer. ___ 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 = the end of 1.x viewers?
Sorry if lacked clarification, I was referring to the "current" residents names (as capitalized), NOT the new display name which will become the person's username as I understand it. Because of the added flexibility with Display Names, I see it a good opportunity to enforce the official First and Last name both capitalized when shown and possibly clean up the legacy database of "First & Last" names. i.e. Someone named currently named "iama Linden" would be changed automatically to Iama Linden as his display name which he can change to lower case via his display name box he chooses so, like dahlia here does. Even if that was to apply to future usernames "when first chosen". You could very well enforce a first capital and still allow for lowercase display names after that, or even have a checkbox to prevent the automatic JavaScript capitalization at registration. But it would fair to say that lack of fist name capitalization due to users omission is much more common than a deliberate intent coming from the user. So I view "initial capitalization" as a default setting for that reason. And 2. you should also prevent anyone to use a display name baring the name of an existing username in my opinion. As per the FAQs: >Will you limit the number of people who use a particular Display Name? >No, because you can use username to uniquely identify individual avatars. There can be many Residents using John Smith as their Display Name, but you can discover which is which by looking at their username for example, in their profile. That's prone to problems of deceptive impersonations of existing avatar names and misunderstandings. Any display name should check against the username db. On 8/17/10 3:20 PM, "Marc Adored" wrote: > The purpose of this is to give people more freedom to express > themselves in their name. Therefore enforcing capitalization would > hinder that idea. A lot of people have usernames that are not > capitalized for a reason either for expression or because its to mimic > the proper name of something they like. like someone using iMonster or > something is a spoof of apples uses of lowercase i in front of their > products and people use it to mimic or mock apple. > > hope you understand what im trying to get to > > On Tue, Aug 17, 2010 at 6:13 PM, Bryon Ruxton wrote: >> As you are implementing this, you may to consider forcing capitalization via >> JavaScript or else on the first name (from the official actual username) >> e.g. "first Linden" look bad as if there is a typo in there and such proper >> nouns are normally capitalized. >> >> I have always found it annoying to see lowercase first names. It is probably >> mostly a result of omissions, but also tends to happen more frequently with >> younger users. And as we "officially" will get 16 and 17 years old it is >> much more likely to happen. >> >> It happens a lot in shopping carts or any web user database if you don't >> automatically capitalize first and last names or addresses by code, which I >> now tend to do to prevent such inconsistence in postage labels, etc... >> It would make for a more consistent database too. >> >> On 8/17/10 2:41 PM, "Brian McGroarty" wrote: >> >>> On Tue, Aug 17, 2010 at 2:34 PM, Lance Corrimal >>> wrote: >>>> ... >>>> http://blogs.secondlife.com/community/features/blog/2010/08/17/display- >>>> names-bringing-greater-self-expression-to-second-life >>>> >>>> ... I guess that means the end for logging in with 1.x based viewers, >>>> does it? >>> >>> Old viewers will continue to work. Old accounts would continue to log >>> in as they do today. New accounts log in with their username as their >>> first name and "Resident" as the last name. (For the difference >>> between username and Display Name, see the FAQ linked at the end of >>> the blog post). >>> >>> Under the hood, for all legacy viewers and scripts, the only real >>> change is that new accounts created after some point will only ever >>> have "Resident" as a last name. The new Display Names won't replace >>> usernames in any location within an old viewer. >> >> >> ___ >> 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 = the end of 1.x viewers?
On 8/17/10 4:47 PM, "Michael Schlenker" wrote:
> Am 18.08.2010 um 01:16 schrieb Bryon Ruxton:
>
>> Sorry if lacked clarification,
>> I was referring to the "current" residents names (as capitalized), NOT the
>> new display name which will become the person's username as I understand it.
>>
>> Because of the added flexibility with Display Names, I see it a good
>> opportunity to enforce the official First and Last name both capitalized
>> when shown and possibly clean up the legacy database of "First & Last"
>> names.
>
> This will break content if it hits the scripting layer. E.g. i have some
> scripts
> that derive things from the current username (including upper/lowercase
> distinction),
> and if you simply capitalized names it would break. Same with the
> aformentioned scripted access control lists.
First and Last being unique I'd advise you lowercase them anyway before
processing as a general practice. It allows for partial names, typos, better
search etc...
>>
>> i.e. Someone named currently named "iama Linden" would be changed
>> automatically to Iama Linden as his display name which he can change to
>> lower case via his display name box he chooses so, like dahlia here does.
>>
>> Even if that was to apply to future usernames "when first chosen".
>> You could very well enforce a first capital and still allow for lowercase
>> display names after that, or even have a checkbox to prevent the automatic
>> JavaScript capitalization at registration. But it would fair to say that
>> lack of fist name capitalization due to users omission is much more common
>> than a deliberate intent coming from the user. So I view "initial
>> capitalization" as a default setting for that reason.
>>
>> And 2. you should also prevent anyone to use a display name baring the name
>> of an existing username in my opinion.
>
> NO. That would limit the usefulness for some kind of RP for sure. Might be
> okay if it was
> not allowed for IM or if IM always showed the old style name too.
It surely needs to be clearly identified if there are no restrictions at
all.
E.g. I don't mind if you use: "Philip Linden's Baby", "Philip Linden 1",
"Philip Linden©" or "«Philip Linden»" etc.. but not "Philip Linden". A 100%
match of the name (case insensitive) and even perhaps groups name should be
prevented for the best. As I interpret it you cannot use "Georges Clooney"
as display name unless perhaps you real name is indeed Georges Clooney, that
would be in breach of the rules. So is "Coca Cola" ("Cola Cola Fan" being
acceptable)
Rules being: When selecting a name, do not choose one that:
* violates a celebrity¹s right in their name, a trademarked brand name, or
any copyright or intellectual property right.
* deceives others regarding your identity or affiliation; or
* is vulgar, offensive, hateful or harassing.
I already see a lot of abuse reports claiming breach of the Display Name
rules should there be no preemptive enforcement. I think the one I am
suggesting is a minimum prevention and fits along those principles.
At LL's discretion to assess its merits against the projected caveats and
name confusions issues they'll have to deal with.
> And maybe you noticed that lowercase/uppercase transformation is not a
> lossless operation
> (okay, might be due to the restrictions on SL firstnames, but in general its a
> lossy operation).
> Michael
>
___
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] Open Viewer Development Announcement
I am not sure if that's what you meant as "not opening a submenu centered on the mouse click". or whether my suggestion would resolves it but I think the pie menu repetition on sub level is prone to confusion indeed. I would envision a pie menu on the first root level. And more normal submenus on subsequent levels, or something like this can be evaluated and perhaps improved: http://usabilitynews.usernomics.com/2008/05/circular-menus-and-usability.htm l But I prefer the pie menu as well personally. It fits better in the context of a 3d interaction. Flat pull down menus kind of break that immersive charm of the pie menu to me. On 8/18/10 9:53 AM, "Oz Linden (Scott Lawrence)" wrote: > I'm going to channel comments I've heard Q make here because he's not > able to do it himself at the moment. > > While there were some good things about the v1 implementation of pie > menus, they also had some flaws - such as not opening a submenu centered > on the mouse click. > > I think that if someone were to step up and do the work to create a > better pie menu implementation that we could do good comparisons with > (and especially if it allowed menu style to be a preference setting), > then it would be a much more interesting discussion. > > Note: that in no way should be interpreted as "we would take it if it > happened" - I can't make any such commitment on my own at this time. If > someone wants to sign up for the work, I'm willing to sponsor the > discussion. ___ 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 = the end of 1.x viewers?
On 8/19/10 12:09 PM, "Michael Schlenker" wrote: > Am 19.08.2010 um 11:51 schrieb Argent Stonecutter: > >> >> On 2010-08-18, at 13:19, Michael Schlenker wrote: Can you elaborate on what kind of RP would require you to be able to set your display name to "Argent Stonecutter" >> >>> Sure. Anywhere you wanna have uniform appearance, like having a bunch of >>> 'Agent Smith' AVs in black suits to give the >>> impression of identical twins or clones. >> >> That wouldn't be "having the same display name as a user name". >> >> That would be "having the same display name as another display name". I'm not >> talking about that. Is anyone talking about that? No one should be talking about that. Display Names checked against other Display Names would be compromising the reasons behind the feature itself. It should of course be allowed to choose existing Display Names. > Its a special case of the general case, i didn't check but I'm pretty sure > 'Agent Smith' is taken by someone. If it is and you > had your way it would not be possible to use that name. You have a point, although I would assume all current Last names were carefully chosen not to imitate that of a superhero, a brand or a famous movie character like "Agent Smith". In the context of CURRENT usernames that is, it shouldn't be an issue or only have a very few exceptions. Futures usernames being more open for such conflicts, with future usernames that would want to be chosen for Role Playing as Display Names. But not doing anything about it other that rely on Abuse Report remedies is not ideal either. The RESI Team is there to handle such issues appropriately. But that does not minimize the occurrence of such issue happening in the first place, making it unpleasant for everyone and possibly causing fraud etc.. and require additional work on our part to file the report... which is not really fast easy and fun. ;P As I conveyed in the blog, it could be just a warning rather than a complete restriction. Such as: "Please be aware that this is a resident's username. Any deceptive attempt using this resident's name is prohibited..." etc in the case of a match. Or simply a text warning always displayed below the Display Name box. While it maybe only an ounce of prevention, it's worth considering as a method of reminding people what the rules are, and that they should think twice about abusing someone's name for deceptive tricks, as well as ease that concern for everyone and minimize incidents (throw-away alt accounts excluded of course, not much to do about those). e.g. We have similar preemptive messages for detected weapon usage in PSG sandboxes which helps educate naïve newbies about the rules before they get ejected and/or banned, and it is helpful in minimizing griefing cases... Or maybe just start with a log count as to how many times someone tried or used someone else's name, against the number of abuse reports to evaluate whether such concern is validated and supported by data or not. And then assess the need for such warning or restriction using meaningful data, instead of flat out accepting our early assumptions made that it will plague us with issues... CUSTOMER SERVICE TIPS to Lindens when you communicate: It would have been as simple as responding in the blog, that LL will take such concerns into consideration for further reassessment and study possible solutions for it welcoming ideas (as I am giving here), rather than saying that it's already been thought of with the arguments, yet giving the sentiment that it's a final decision, which is what has been perceived. Not by me necessarily, but by many others, which doesn't surprise me. Carefully customer service oriented responses can save you a lot of flaming posts... Just my 2 cents. Cheers Bryon > But lets have another take at this, you want to ban people from using 'Argent > Stonecutter' as a display name, fine. > How about any homographs of your current SL name, should they also be banned? > http://en.wikipedia.org/wiki/IDN_homograph_attack > > It opens a can of worms. > > How about a display option in the viewer that can 'highlight' the fact that > your display name is the same as your username > (different colour, font or an other UI hint). > That would prevent many of the imposter issues, as it would be pretty obvious. > > Maybe an opt-out to deny the use of current usernames as display names would > be appropriate, but a general ban to reuse a current username > as a display name sounds a bit excessive. > > Michael ___ 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 = the end of 1.x viewers?
On 8/19/10 7:20 PM, "Argent Stonecutter" wrote: > On 2010-08-19, at 14:09, Michael Schlenker wrote: >> Its a special case of the general case, i didn't check but I'm pretty sure >> 'Agent Smith' is taken by someone. If it is and you >> had your way it would not be possible to use that name. > > Yes. So? Argent, Keep in mind once the feature is implemented: One will be able to choose "Captain America" with captain.america becoming his unique username. And it wouldn't be fair to prevent anyone else to RP "Captain America" as his display name. So if there is a restriction it can only be on current/old "First.Last" usernames, which are unlikely to create such conflicts. ___ 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 = the end of 1.x viewers? Correction
On 8/19/10 7:20 PM, "Argent Stonecutter" wrote: > On 2010-08-19, at 14:09, Michael Schlenker wrote: >> Its a special case of the general case, i didn't check but I'm pretty sure >> 'Agent Smith' is taken by someone. If it is and you >> had your way it would not be possible to use that name. > > Yes. So? Argent, Keep in mind once the feature is implemented: One will be able to choose "Captain America" with captain.america becoming his unique username. And it wouldn't be fair to prevent anyone else to RP "Captain America" as his display name. So if there is a restriction it can only be on current/old "First.Last" usernames, which are unlikely to create such conflicts. CORRECTION: Actually the username will be "captainamerica" not captain.america, my bad. Which makes it impossible to even know where the space was past the first Display Name change, since it won't be saved. You can't choose to restrict "Capt Ainamerica" or "Captaina Merica" on the basis of that username. It becomes completely impractical at that stage... That said it'd be nice if earlier residents get the benefit of having their "nromal" legacy name protected as a plus for the inconvenience caused... ___ 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 = the end of 1.x viewers?
On 8/19/10 9:53 PM, "Baloo Uriza" wrote: > On Thu, 19 Aug 2010 19:42:37 -0700, Bryon Ruxton wrote: > >> On 8/19/10 7:20 PM, "Argent Stonecutter" >> wrote: >> >>> On 2010-08-19, at 14:09, Michael Schlenker wrote: >>>> Its a special case of the general case, i didn't check but I'm pretty >>>> sure 'Agent Smith' is taken by someone. If it is and you had your way >>>> it would not be possible to use that name. >>> >>> Yes. So? >> Argent, Keep in mind once the feature is implemented: One will be able >> to choose "Captain America" with captain.america becoming his unique >> username. > > Actually, not quite, based on what I saw in Torley's video. I could > change my display name to "Captain America," but my unique username would > still be baloo.uriza. Of course it will. Please read my second email (the correction). Your username won't change, I said new users, sigh. ___ 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] 2.0 Absolute Dealbreaker - script count feature request
Sounds good to begin with! The caveats you mentioned are not really problems to be concerned too much about. I would just suggest llGetObjectMemory(key id) for the function name. Perhaps a list params with SCRIPT_COUNT and SCRIPT_MEMORY then SCRIPT_USAGE with the lower results for mono scripts later on... On 9/29/10 2:00 PM, "Kelly Linden" wrote: > So I was playing with the following LSL function in a sandbox yesterday and I > like it, but I'm gonna guess not everyone will. > integer llGetScriptMemoryTotal(key id) returns the total script memory used by > all scripts in the object or for agents the total script memory used by all > attachments combined. Only works for objects and avatars in the same region. > > Potential problems with it: > * Dyslexic naming weird it is. > * No permissions checks, anyone can view the sum for anyone / any object. > Since this is the case for the viewer feature it seems like adding any > restrictions will just leave people still wanting the viewer hack version. > * No detail information. I think this is best when used on anyone not yourself > for privacy reasons. And we do have the UI for finding per-attachment details > on yourself. So maybe not an issue. > * Reports 'reserved' script memory. A mono-script will report 64k while an LSL > script will report 16k, when really the mono script may be using less (mono > scripts average 8-10k last I checked, in actual usage). Being able to report > lower results for mono scripts is gated on other development work not > currently in progress. > * It doesn't seem like a very complete API. > > On Wed, Sep 29, 2010 at 12:47 PM, miss c wrote: >> Still need a script counter *hides* >> >> What I am probably going to do is get my husband to build me a personal >> version of 2.2 with mesh and the script counter. That doesn't help everyone >> else though. >> > > > ___ > 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] 2.0 Absolute Dealbreaker - script count feature request
It is useful enough to me. You can¹t have it all now (Kelly explained why) and while it¹s not ideal, it¹s valuable information as far as I am concerned to identify problems, should they arise. And Zee I don¹t care about what stupid people do on their land... It the least of my worries Whether is it true memory usage or not, people can ban. It¹s a fact. The legitimacy in doing so is another question... And stupid people will remain stupid... Ask yourselves the question: Do you want an incomplete yet helpful solution doable now, to be improved/completed later on, or do you prefer to wait another 6-12+ month with nothing at all? On 9/29/10 2:51 PM, "miss c" wrote: > This again isn't that useful because you cant accurately guess how many > scripts the person is wearing because of the memory difference. Secondly the > laggiest script with every lsl call in the world would still only register at > 16k. I think that what would make my body melt into a pool of happiness is a > script usage per avatar, the calls coming from an avatar that put strain on > the server because some LSL functions are more evil than others. I don't know > how complex something like this would be to do. At least with the script > counter I know accurately that Mr. Cybernetic has 1534 scripts in his suit and > each script takes up .02 ms of memory if there isnt strain on the sim. Did > you know there are some resizing scripts that have chat listeners, OMG, > someone go shoot those designers. :p > > But I want to thank you so much with everything in my soul that your > attempting to find a solution to this problem, just for your attempt I > completely adore you, please don't stop! > > :p > > Miss > > > From: Bryon Ruxton > To: Kelly Linden ; miss c > Cc: opensource-dev@lists.secondlife.com > Sent: Wed, September 29, 2010 4:33:30 PM > Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature > request > > Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request > Sounds good to begin with! The caveats you mentioned are not really problems > to be concerned too much about. > I would just suggest llGetObjectMemory(key id) for the function name. > Perhaps a list params with SCRIPT_COUNT and SCRIPT_MEMORY then SCRIPT_USAGE > with the lower results for mono scripts later on... > > On 9/29/10 2:00 PM, "Kelly Linden" wrote: > >> So I was playing with the following LSL function in a sandbox yesterday and I >> like it, but I'm gonna guess not everyone will. >> integer llGetScriptMemoryTotal(key id) returns the total script memory used >> by all scripts in the object or for agents the total script memory used by >> all attachments combined. Only works for objects and avatars in the same >> region. >> >> Potential problems with it: >> * Dyslexic naming weird it is. >> * No permissions checks, anyone can view the sum for anyone / any object. >> Since this is the case for the viewer feature it seems like adding any >> restrictions will just leave people still wanting the viewer hack version. >> * No detail information. I think this is best when used on anyone not >> yourself for privacy reasons. And we do have the UI for finding >> per-attachment details on yourself. So maybe not an issue. >> * Reports 'reserved' script memory. A mono-script will report 64k while an >> LSL script will report 16k, when really the mono script may be using less >> (mono scripts average 8-10k last I checked, in actual usage). Being able to >> report lower results for mono scripts is gated on other development work not >> currently in progress. >> * It doesn't seem like a very complete API. >> >> On Wed, Sep 29, 2010 at 12:47 PM, miss c wrote: >>> Still need a script counter *hides* >>> >>> What I am probably going to do is get my husband to build me a personal >>> version of 2.2 with mesh and the script counter. That doesn't help everyone >>> else though. >>> >> >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
That was in part my justification behind the need of script counts in the function, to assess numbers of scripts vs memory count in a slightly more meaningful manner, for lack of true memory usage. e.g. 4 scripts with 64k memory usage can be evaluated as 64k accurately, while a 64k memory without a number of scripts attached, give you indeed nothing to assess. i.e. The number of LSL vs. Mono scripts can be easily figured out with quite simple math if we have the script count under the initial conditions of 16k and 64k caps. As you pointed out, true memory usage isn¹t a given... Memory fluctuates over time or conditions and even snapshots of it would not reflect true usage... As you suggest, if you allowed mono scripts to set their own memory cap, I guess you could report the memory cap based on that, perhaps rounded to chunks/multiples of 4k... So I¹ll stick to list llGetObjectMemory( key id, list params ) with SCRIPT_COUNT and SCRIPT_MEMORY flags as the most viable initial solution I¹d be happy with. Then once you add mono memory caps, either add a flag or change what is reported as SCRIPT_MEMORY... OR possibly add those flags in LlGetObjectDetails?? But I don¹t know the technicals there.. Anyway that was my suggestion of the day, Back to RL work! On 9/29/10 4:06 PM, "Kelly Linden" wrote: > * In my mind the biggest issue is that mono scripts will appear 4x worse than > LSL scripts. ___ 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] 2.0 Absolute Dealbreaker - script count feature request
> * We change something, and the thing that used to work no longer works > * People scream that we broke content > So if we create a call that returns approximate results now, it *always* has > to return the same results. Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will not technically break content, it would just requires to slightly alter the interpretation of it. Modifying the cap variables for event(s) to lower numbers, is the only things at stake here. If you put the information out on the wiki right away, as to what to expect of the function in the future. I would see no valid reason for anyone to whine about such a change later on if informed prior. The change can also be planned ahead in our code and work seamlessly with no issues along the way, if you are certain as to what the changes will be. (e.g. if the number is not longer a strict multiple of 16, then apply different rules...done!) As long as it is planned carefully and followed through to the end goal, that seems fine to me on the short to medium term. > This is one reason we are reluctant to add new measurements; people come to > depend on them even when they shouldn't. Understandable view on your side... but the facts that some people don't have the proper judgment or skills to rely or analyze statistics accurately, shouldn't be a reason to deprive those who can use it properly as well as ethically, with valid and useful reasons for doing so. On 10/1/10 10:07 AM, "Kent Quirk (Q Linden)" wrote: > I don't actually have an opinion about the right answer, but I will note that > if this is going to be used for things like banning people, then we can't ever > change it to be something accurate later. The pattern we see is: > > * We build something that has a numeric limit > * Someone builds something that pushes right to the limit > * We change something, and the thing that used to work no longer works > * People scream that we broke 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
[opensource-dev] Jira Issue Resolution Issue
As a user I would like to be able to reopen Jira issues wrongly closed by ignorant people who can't read, creating havok. Like this one there: Stone Tremont added a comment - 08/Oct/10 2:17 AM This is not a bug because you do not pay prims, avatars are payed via whole objects. This should be a feature request. I have a way to set different prices for variations in vendors, you just need to make a more advanced, intuitive script like mine. https://jira.secondlife.com/browse/VWR-3048 Please reopen this issue! As per Gigs Taggart's comment, its used to work.. It you are going to allow any kiddo to close issues, the same should true for reopening them, or it doesn't make any sense at all. ___ 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] Jira Issue Resolution Issue
Thanks Q >reopening because you don't like a decision is a waste of everyone's time, and will result in temporary or permanent loss of JIRA access. Sounds good to me. On 10/11/10 7:44 AM, "Kent Quirk (Q Linden)" wrote: > So we've modified the JIRA system again to allow residents to reopen issues in > VWR and STORM. > > But with power comes responsibility -- we aren't going to tolerate edit wars, > and we're not going to let JIRA be a place to vent your frustrations with us > or with each other. Please keep it polite. Reopening because of a mistake or a > misunderstanding is reasonable, especially when accompanied by a good > explanation. But reopening because you don't like a decision is a waste of > everyone's time, and will result in temporary or permanent loss of JIRA > access. > > I should note that on the Snowstorm team we're trying to aggressively prune > down JIRA to actionable issues. > > "FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it, > because it's too broad and unactionable. A summary JIRA with 3 separate > problems doesn't help us track it, especially when 2 of them have been fixed. > So we may close these, and we'll try to explain why. If the reason is that we > can't use the issue the way it's written, then please don't reopen it, write a > new and better one. > > Thanks for your help on this. > Q ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] O.O Display name code DROP!
Hi Leyla, Glad to keep the current text format if there are no real goals for changing it. For one that would have broken the integrity of current log files. On that point I would actually love to know if the filenames of IM logs is to eventually change, from say First Last.txt to first.last.txt (for legacy names). Please consider that one carefully, as that would require us to change all file names of existing logs to avoid new sets of files being created on top existing log files, when starting using that viewer's code, should it change. i.e. Being able to keep the IM history for each Agent or Group name in one unique file is important here. And Sythos¹s suggestion would be correct for separate IM logs specifically, for avoiding redundant repetition of the username unnecessarily for each line. On 10/15/10 4:23 PM, "Leyla Linden" wrote: > Hi All, > > The chat log format change wasinitially done so we could easily add > more information in the chat logs. Now that the display name can > change it's nice to have more data like an agent_id that can be hooked > up to inspectors. > > But seeing as how many people rely on easily readable text chat logs, > we're going to revert them back to text files. The only difference is that > they'll include both display names and usernames, much like Rob > Nelson suggested. > > - Leyla > > > ___ > 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
