Re: [opensource-dev] SecondLife 2.0 beta download????

[Maya Remblai]

Tillie Ariantho wrote:
> On 17.02.2010 21:25, Maggie Leber (sl: Maggie Darwin) wrote:
>
>   
>> On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin  wrote:
>> 
>>>  ive noticed that there is a link on the secondlife.com dashboard to
>>>  download sl 2.0 (with a target of http://secondlife.com/beta-viewer/)
>>>  is this a case of released to soon or what??
>>>   
>> Your question cannot be answered unless you sign an NDA. :-)
>> 
>
> I'll sign an NDA happily if I get an answer for that and get a working 
> download link for the 2.0 beta. ;-D
>
> Tillie
>   
I think pretty much everybody on this group would. At any rate, if they 
released 2.0 today it wouldn't be "early," it would be "on time." Blog 
posts pointed to a February release.

Also, technically it would be the BSI group that would be more likely to 
know this kind of thing, being the designated alpha testing group. (They 
weren't used for 2.0's alpha though, and the group has been silent for 
months, so I don't blame you. ;) )

~Maya Remblai, still a bit pessimistic.
___
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] Viewer 2.0 JIRA - Classic UI option

[Maya Remblai]

http://jira.secondlife.com/browse/VWR-17176 -Make the classic UI optional

I know a lot of you don't like the new UI at all, or like some things 
and don't like others. I'd like to see LL make it possible to have the 
classic UI by ticking an option in Preferences. As I state in this JIRA, 
the new UI is for me unusable for content creation.

While I imagine that most third party developers will fix this, it would 
be in LL's favor to do it themselves.

Maya Remblai
___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

> Also most bald hair bases use an alpha texture.
>   
Not really relevant here, but true.
>>> On the bright side - anyone making tattoos and understanding the alpha
>>> mask isn't wearing system hair... 
Or system eyes in most cases. :P

>>> plain wrong, since you can't NOT wear system hair.
>>> you can wear system hair of length 0, otherwise known as a "bald hair base".
>>> the one you're wearing while creating an alpha layer in a viewer with this
>>> unfinished patch becomes broken, and turns you into a cloud.
>>>   
This is true, but easily dealt with, if I'm understanding things 
correctly (I haven't had time to try the patch myself): Just make a 
throwaway set of hair/eyes/skin/whatever's getting corrupted, and switch 
to something else when you're done editing. Of course that's assuming 
that the cloud-ruthing isn't permanent.

Regardless, I'm excited to see effort being put into this. I can't use 
2.0 in its current state, and even with all the tweaks in place its new, 
longer methods of doing things is detrimental to my work. So I'm glad 
someone's working on backporting, and I know many other content creators 
that will be similarly pleased. :)

Maya
___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

Henri Beauchamp wrote:
> I found what was wrong in my patch. The new code now works properly, but
> for a cosmetic glitch (avatar not being rebaked while in customize
> appearance mode when changing an Alpha wearable) which I'm trying to
> address.
>
> You can expect the next release of the Cool SL Viewer (http://sldev.free.fr/)
> to include full Tattoo and Alpha wearables support... ;-)
>
> Henri.
>   
Did you hear that? It was the sound of the dozen or so people using 2.0 
dropping it like a hot potato. ;)

Will you be making the patch available by itself? I imagine all the 
third party devs will want it. If I had it, I'd run it through an 
Emerald build myself just for fun, that being the viewer I'm currently 
comfortable working with. (Though I will be trying Cool Viewer since 
it's been brought to my attention again)

Maya
___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

Henri Beauchamp wrote:
> My guess is that very few old timers, power users and role-players will
> bother with 2.0 once third parties viewers implementing the v1 UI will
> have all the main features of v2.0 backported...
>   
I'd say that's a very accurate guess. Granted, the type of people I 
generally interact with in-world is limited to certain types of people. 
But, those people are content creators, a few role-players, and a lot of 
my own customers. Most of them dislike 2.0 in general, the rest dislike 
it but could tolerate it if some major changes were made. They'd rather 
stick with what they know and can use though. I only know *one* person 
who likes 2.0.
>   
> Yes. Unlike most other third parties viewers, I provide individual patches
> for each feature/fix/improvement implemented in the Cool SL Viewer, and
> this both for the v1.23 and v1.19 branches (yes, I also intend to try and
> backport Tattoo and Alpha support into v1.19, for the benefit of people with
> "old" computers).
>
> In fact, most third parties viewers already use part of the Cool SL Viewer
> patches... No wonder since it has been around for almost two years and a
> half now.
>
> Oh, and that's it: I fixed the last quirk... Patch ready for v1.23. Will
> try and backport it to v1.19 tomorrow...
>
> Henri.
>   
Thank you, thank you, THANK YOU. I knew you were behind many of the 
patches common to several third party viewers, but I haven't looked at 
your site in quite a while and didn't realize you keep a repository of 
patch files. That's a great idea, and very helpful to the community.

Also, I played around with Cool Viewer earlier, and it's my new 
animation uploader. :) I use different viewers for different aspect of 
content creation at times, but lacked one that was really handy with 
animation uploads. Emerald has the preview in-world function, but it 
tends to glitch and freeze the head and eye movements after closing the 
window. Cool Viewer doesn't do that, which I'm very glad of. Good job. 
:D I'll probably use it for other things too, once I get to use it some 
more.

Maya
___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

Andromeda Quonset wrote:
> I'd like to see the entire alpha wearables support and feature 
> removed in it's entirety.  Ever since it was introduced, AV's are 
> generally invisible unless I am within 5 meters of them.  I'm more 
> than a little tired of attending meetings that are nothing more than 
> me, and a bunch of floating nametags that never rez.
>   
That's a problem with your system, I'd imagine. I haven't heard that 
complaint from anyone, and it's highly unlikely that all those people 
were using 2.0 (and thus able to wear alpha masks) anyway. Though it IS 
possible, if they were indeed using 2.0, that they were intentionally 
wearing total alpha masks, which would make them invisible. But I'm 
betting on graphics card issues on your end. Open a JIRA with your exact 
specs, and hopefully someone can track it down. :)

And if you don't like the idea of alpha masks, you've probably never 
worn a non-human avatar, or shoes. ;)

Maya
___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

> Thanks for responding, Maya!
>
> I don't think that the AV's I wasn't seeing were running 2.0, or were 
> necessarily using an alpha mask.  I started seeing this with sim 
> 1.34.  I have tried several viewers, and it seems to be present in 
> the viewer I prefer using:  The Windows Cool Viewer from Boy Lane 
> that is based on the 1.22 viewer code.  I haven't seen the issue when 
> I use Emerald, or viewers which are based on 1.23, 1.21, or 1.19 
> code.  So, I am looking forward to the backporting of the 2.0 code to 
> see if resolves the problem.
>   
Very strange. I wouldn't expect a server update to affect rendering, but 
I've seen stranger things happen. All I can think of is to open a JIRA 
and see if anyone else is having the same problem. Sorry I can't be of 
more help.
> Otherwise, I don't really care one way or the other about alpha masks 
> / didn't care  until it started effecting me.  I have been known to 
> wear shoes, and I have never been known to wear a non-human avatar, 
> but it seems to me that alpha textures would be more of a hindrance 
> than a help with non-human avatars.
>
> Andro 
>
>   
It's the opposite, actually (about non-human avatars). When you want to be a 
horse, you want to be just a horse, not a horse with a human head sticking out 
of its neck. If you want to be extremely small, you want to have only your tiny 
creature body showing, not a mess of squished mesh. Being able to make part or 
all of the base mesh invisible is very important. That's why invisiprims have 
been in use for so long, and LL got in so much trouble when they tried to "fix" 
them without alpha masks available. I can show you how important it is in-world 
sometime. I have a couple of micro avatars (smaller than "tinies") that don't 
work at all unless the avatar mesh is hidden, such as with an alpha mask. They 
also don't work with invisiprims.

Maya


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

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

[Maya Remblai]

Martin Spernau wrote:
> My feeling is that it would make the most sense to add a 'old style  
> UI' as option to Snowglobe 2, along with the ability to turn off all  
> unwanted new features (media on prim etc)
> -Martin
>   
I agree with this. 2.0 DOES have some useful functions, and not just new 
features like the alpha mask and tattoo layers. It's just that the UI 
isn't one of them. I'm all for people using it if they like it better, 
but don't shove it down the throats of us oldbies who don't need our 
hands held while we access our inventory. Besides being a bad idea 
business wise by annoying current users, it's also dangerous, as has 
been pointed out over and over again. I'm not epileptic, but I still 
can't use the 2.0 UI for health reasons. The tweaks on the wiki aren't 
enough, though they do allow me to use the viewer for a few minutes.

I'm putting my support behind backporting, but I would also like to see 
the classic UI ported to a 2.0 base.

Maya
___
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] oh give me a break

[Maya Remblai]

New Hax wrote:
> but on the internet as a content maker you can make INFINITE products
> so you arent losing anything if i copy it and make no money off of it.
>   
Not true. See the following example that actually happened to me:

Person A rips a large number of products, including mine. He boxes them 
and gives them away, for free, claiming he has my permission (which he 
doesn't). Now, the total value of my products involved was $150 USD. If 
he only gave the box to 10 people (it was actually more than that) I'm 
now out $1500 USD. Person A has done a huge amount of monetary damage to 
me by taking away sales.

It's true that content theft happens, but it depends on the platform and 
what you do about it. Because all of SL, including its content, is under 
the direct control of LL, it is reasonable to expect LL to remove all 
stolen content from users' inventories. They CAN tell the difference 
between the original and ripped copies. The problem with content theft 
in SL comes, not from the initial theft, but from LL's lack of action. 
They systematically violate the DMCA by simply removing one instance of 
the stolen content, and sometimes they don't even do that. (The last 
time I filed a DMCA, they reported that they removed the individual 
products from the thief's inventory, but not the box containing more 
copies!) So the solution isn't really in preventing theft, it's in LL 
following DMCA law. And it IS a law, IP theft is still theft, and there 
are legal ramifications.

FYI, Person A was permabanned following DMCA orders.

Maya
___
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] oh give me a break

[Maya Remblai]

Soft Linden wrote:
> Who? There's a non-participant who showed up to troll, and Carlos who
> says he wishes things were different so he could learn and experiment
> more.
>
> But - even if the list were swarming with looters itching to violate
> others' rights, how would the app store solution you push be better
> for stopping copying? Closing the source wouldn't help for the reasons
> I gave in my first reply. How does closing source and adding yet
> another API and distribution model make copying harder?

Exactly. The people that say open source is the root of all theft are 
not only ignoring the fact that theft happens and has been happening 
regardless of open source availability, but they're also ignoring the 
importance of open source viewers. To those people, as an example, I say 
have a look at the JIRA, at the number of people who have had seizures 
or otherwise become ill from using Viewer 2.0. Those people MUST use a 
third party viewer once 2.0 goes standard, or leave SL forever. Even if 
you overlook the ethical and moral problems of taking that option away 
from them, doing so would mean a considerable loss of income for content 
creators and LL. And not just because those people wouldn't be there 
buying things anymore. They also wouldn't be creating, and the related 
schools, hospitals, and other non-profits the LL has been trying to 
attract will pull out.

Maya

___
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] oh give me a break

[Maya Remblai]

Hm, yes, I suppose that is true. My mind works mostly in absolutes, it's 
easier to just count all the stolen freebies as lost sales. You're 
right, however. My mistake. It was probably fueled by my general bad 
feelings about the incident, because I DO use my earnings in the real 
world, and I also have a strong sense of justice. It bothers me more 
than it should when someone can steal content and go virtually 
unpunished. Even the first thief who was permabanned was back with an 
alt right away.

Maya

Carlo Wood wrote:
> Not entirely true, first of all, he didn't steal any money from
> you, nor any goods; unless you suddenly saw a significant drop
> in revenue then nothing really happened, financially spoken.
>
> It certainly isn't true that if he did NOT give that box to
> those ten people that all ten would have come to you and spend
> L$ 40,000 in your shop.
>
> In fact, most people spend a fixed amount of money in SL. If
> they get anything for free on top of that, it doesn't cause
> them to spend less real money.
>
> So, surely, you didn't get any MORE money because of this..
> but you didn't *lose* $1500 either, not even a fraction of that.
>
>   

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

Re: [opensource-dev] Fixing the 2.0 chat bar focus problem?

[Maya Remblai]

Anders Arnholm wrote:
> Roleplayers rage form the combate users, thert need wasd, DCS/CCS 
> enviroemnt, to many others. WASD is the only you can use if you have the 
> mouse to the right, as most righthanded people have.
>
>   
Um, I'm right handed, my mouse is on the right, and I use the arrow keys 
to move. Just because you like it that way doesn't mean everyone does. 
The function in 2.0 should be optional, with an option to have the 
classic function. Plain and simple, and would make everyone happy.

Maya

___
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] Fixing the 2.0 chat bar focus problem?

[Maya Remblai]

Tigro Spottystripes wrote:
> like i said before, hitting a key to call the chatting functionality is
> quite common in games
>   
So? I've played a couple MMOs and to type in those you just start 
typing. No need to press a specific key. Of course, that's assuming 
you've set the control to controller rather than keyboard. In other 
words, it's an *option.* And even then, typing with control set to 
keyboard is initiated with the space bar, not enter/return.

Besides, SL isn't like any other program out there, game or no. Trying 
to force it to conform to any mold other than its own is a recipe for 
disaster.

Maya
___
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] Fixing the 2.0 chat bar focus problem?

[Maya Remblai]

Er, it's been there for quite a while.
http://jira.secondlife.com/browse/VWR-17011

Chatbar related meta:
http://jira.secondlife.com/browse/VWR-17172

Maya

Philippe (Merov) Bossut wrote:
> Hi,
>
> Seems like a good candidate for a JIRA. Someone?
>
> It would be nice indeed to be able to navigate with the arrows and 
> type chat text at the same time i.e. without having to do "Esc/Enter" 
> to switch between modes. At least as an option. I'd even venture that 
> casual res/newbie would find it easier to use (no data to back that 
> claim though).
>
> Cheers,
> - Merov
> ges

___
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] Fixing the 2.0 chat bar focus problem?

[Maya Remblai]

No problem. I have trouble finding things on the JIRA, in my own watch 
list! ;P I'm glad it's getting attention.

Maya

Philippe (Merov) Bossut wrote:
> That'd teach me querying SNOW bugs only...
>
> Thanks for the links :)
>
> - Merov

___
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

[Maya Remblai]

All interesting ideas, but it would be prudent to include a floater as 
an option. Not only will it make things easier on experienced users and 
those who don't like the sidebar, it will make things easier for the 
devs making versions of Viewer 2.0 for photo-sensitive people to use 
without issue.

Maya

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 
> mailto:secret.arg...@gmail.com>> 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] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[Maya Remblai]

Ok, I was trying to be diplomatic, but now I'm going to be frank.

It disturbs me that LL is ignoring how dangerous the shifting behavior 
of the sidebar and the blinking and winking of 2.0 is. Some people have 
already had or come close to having seizures because of it, and people 
without epilepsy are having motion sickness and vertigo. LL has been 
warned about it, especially on the JIRA, but the complaints haven't been 
acknowledged. If LL loves 2.0 so much, the very least they're going to 
have to do is include a video game style seizure warning on startup.

Read the comments on this JIRA entry.
http://jira.secondlife.com/browse/VWR-17249

Here's the meta for all sidebar issues. The comments on most of these 
point out the photosensitivity issue.
http://jira.secondlife.com/browse/VWR-17012

Maya

Maya Remblai wrote:
> All interesting ideas, but it would be prudent to include a floater as 
> an option. Not only will it make things easier on experienced users and 
> those who don't like the sidebar, it will make things easier for the 
> devs making versions of Viewer 2.0 for photo-sensitive people to use 
> without issue.
>
> Maya
>
> 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 
>> mailto:secret.arg...@gmail.com>> 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
>
>   

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

Re: [opensource-dev] Client 2.0 - sidebar

[Maya Remblai]

People on forums have said they know where such behavior can occur, and 
avoid those places. Clubs, mainland sandboxes, etc. But you'd have to 
ask them.

At any rate, that's not particularly relevant here. Up until now no one 
has had any reason to be wary of an LL viewer. But now, someone could 
install 2.0 without knowing about the problems. In your example, it's up 
to the individual to protect themselves. But with the new viewer, there 
are no warnings, so blame falls on LL.

Maya

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Btw, how do those people that have seizure issues deal with the
> possibility of people having quickly changing particle emitters,
> suddenly rezzed prims, fast moving big objects etc?
>
>   

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

Re: [opensource-dev] Client 2.0 - sidebar

[Maya Remblai]

I'm not going to bother trying to educate you about photosensitivity 
since you clearly don't have it. I'll just suggest you go read the SLU 
forums and elsewhere, where people with epilepsy and other 
photosensitvity problems are talking about this. And also suggest you 
take note of the epilepsy support groups in SL. Maybe even read 
Wikipedia's photosensitivity articles. Companies can and do get sued 
over stuff like this, because people with epilepsy and photosensitivity 
can and do watch TV, use computers, and play video games, whether you 
think they do or not.

And FYI, LL didn't pay attention to the alpha testers who said they 
didn't like 2.0. They didn't pay attention to the people who said they 
didn't like it in the beta. I suspect they'll pay attention to a 
lawsuit, but I'd rather it not come to that, therefore I and many other 
people are pointing out the ethical and legal problems. Don't attack me 
for someone else's mistake.

Maya

Jonathan Irvin wrote:
> Not to be rude, but if people are getting vertigo, epilepsy, etc. from 
> SL...viewer 2.0 isn't going to make a difference.  Viewer 1.23 would 
> have the same effect.  Maybe not in your coveted sidebar, but it SL in 
> general.  You know it, I know it, everyone knows it.  This is common 
> knowledge.  LCD monitors nowadays will cause those effects 
> *regardless* of the application running, so please don't make someone 
> else's illness as your point in voicing your opinions.
>
> Keep this in mind, your post accomplishes *nothing*.  Do you really 
> think Linden Labs wants to waste company money on replying to 
> complaints of your calibre?  They already know, trust me.  Linden Labs 
> is a small company and you can't expect them to reply to every single 
> Tom, Dick, and Harriet that wants to complain about this feature or 
> that feature.
>
> OpenSource-Dev is about fixing issues, not complaining about them.  
> This list is for developers to collaborate, not tech support for your 
> complaints.  If you want to vent, for heaven's sake do that in a 
> personal blog, twitter, facebook, etc.
>
> Please follow these SIMPLE STEPS before you waste our time in reading 
> yet another "I-hate-LL-viewer-2.0-and-they-should-fix-it-post."
>
>1. Has it been logged in JIRA?
>   * Yes, Comment on it there.
>   * No, Log it in JIRA.
>
> Linden Labs CAN view JIRA, so posting about specific articles becomes 
> redundancy at that point.  All you need to do is vote for the JIRA 
> topic.  Once you've logged your vote you can either get others to 
> vote, or sit quietly.
>
> Complaining about a feature and throwing around JIRA articles 
> accomplishes nothing except annoy those who have to hear that same 
> story, yet again.  And while the Lindens do monitor this, for the most 
> part, you are preaching to the choir. 
>
> So please, if you aren't going to pull up your sleeves and FIX IT, 
> then don't waste our time.  We know, the Linden's know.  Your post was 
> unnecessary.
>
> Jonathan Irvin
>
> P.S. Sorry for any one else who had to hear my rant.  Thanks.
>
>
> On Tue, Mar 23, 2010 at 14:51, Maya Remblai 
>  <mailto:snowfox...@dragonkeepcreations.com>> wrote:
>
> Ok, I was trying to be diplomatic, but now I'm going to be frank.
>
> It disturbs me that LL is ignoring how dangerous the shifting behavior
> of the sidebar and the blinking and winking of 2.0 is. Some people
> have
> already had or come close to having seizures because of it, and people
> without epilepsy are having motion sickness and vertigo. LL has been
> warned about it, especially on the JIRA, but the complaints
> haven't been
> acknowledged. If LL loves 2.0 so much, the very least they're going to
> have to do is include a video game style seizure warning on startup.
>
> Read the comments on this JIRA entry.
> http://jira.secondlife.com/browse/VWR-17249
>
> Here's the meta for all sidebar issues. The comments on most of these
> point out the photosensitivity issue.
> http://jira.secondlife.com/browse/VWR-17012
>
> Maya
>
> Maya Remblai wrote:
> > All interesting ideas, but it would be prudent to include a
> floater as
> > an option. Not only will it make things easier on experienced
> users and
> > those who don't like the sidebar, it will make things easier for the
> > devs making versions of Viewer 2.0 for photo-sensitive people to use
> > without issue.
> >
> > Maya
> >
> > Nyx Linden wrote:
> >
> >> Good que

Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Maya Remblai]

I thought the TPV policy went into effect on April 30?

Maya

Morgaine wrote:
> In this note I'll identify 3 simple scenarios in which TPV developers 
> can retain some confidence that the "NO WARRANTY" clauses of their 
> open licenses remain intact.  This is a technical reading of GPLv2 and 
> similar licenses which developers can verify for themselves, rather 
> than a legal reading of the TPV which Q Linden explained was beyond 
> our ability to understand 
> .
>
> The 1st of April is approaching rapidly, and April Fool aside, this is 
> also the date on which the Linden TPV policy comes into effect.
>
> That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 
> of GPLv2 *as they apply to TPV developers*, by imposing numerous 
> conditions and liabilities upon them.  It is important that developers 
> of TPVs realize the possible personal dangers to themselves that may 
> result from loss of "NO WARRANTY" protection, so that they can make a 
> personal decision about TPV development on 1st April and thereafter.  
> Boy Lane gave a well reasoned summary of the situation here 
> .
>
> To address a small part of the uncertainty created by TPV, I'll make 
> some simple technical observations on how to preserve the "NO 
> WARRANTY" protections of your open sources licenses if you are a TPV 
> developer whose viewers are used in SL by others.  No part of this 
> note is legal advice (obviously), but under the assumption that law 
> occasionally tries to be logical, it may help developers separate what 
> is relatively certain from what is highly uncertain.
>
> *The most important point to appreciate is that LL has no power to 
> void the "NO WARRANTY" clause on any open source license not issued by 
> them, or issued by them prior to 1st April 2010.*
>
> This means that the following 3 developer scenarios seem quite safe 
> from the standpoint of their "NO WARRANTY" clauses surviving any attack:
>
> * When a viewer project is licensed under BSD, Apache, MIT, GPLv3,
>   LGPL, or any other license other than GPLv2, this is clearly not
>   the license granted by LL and therefore its "NO WARRANTY"
>   protections cannot be overridden by LL.  LL is not the licensor
>   in this case.
>
> * When a viewer project is an independent project licensed by the
>   project's developers under GPLv2 but does not use any Linden
>   source code at all, then the license (together with its "NO
>   WARRANTY" freedom) is being offered and granted by those
>   developers, and it is clearly not being offered and granted by
>   LL.  Consequently LL has no say over the "NO WARRANTY"
>   protections provided in a GPLv2 license that is granted by
>   someone else in such an independent project.  LL is not the
>   licensor in this case.
>
> * When a project creates a TPV based on Linden sources released by
>   LL under GPLv2 prior to 1st April 2010, those sources are not
>   encumbered by LL's TPV document, but instead are licensed under
>   the normal terms of a valid GPLv2 *at the time that they were
>   released*.  This is because *GPL licenses are non-revocable*,
>   and therefore the entire GPLv2 license (including its "NO
>   WARRANTY" clauses) which was valid upon release remains valid
>   for all eternity.  As a result, TPV developers are protected by
>   their GPLv2 "NO WARRANTY" clauses, as long as they do not use
>   any LL sources released on or after 1st April 2010.  LL is the
>   licensor in this case, but the GPLv2 "NO WARRANTY" protection
>   was granted to you by Linden Lab themselves prior to the TPV
>   possibly affecting it, and that granted license cannot be
>   revoked, ever.
>
>
> In the above 3 cases, LL has no means of overriding the "NO WARRANTY" 
> protections in the respective licenses.  (Read GPLv2 clauses 11-12 
> carefully though, because they protect you only from *certain types* 
> of liability, not everything.)
>
> In contrast, any other TPV scenarios are highly dependent on 
> interpretation of the ambiguous TPV document, and hence developer 
> protection under those conditions is very uncertain.  It would have to 
> be decided in court, and I would not wish to second guess the outcome. 
>   Much caution is advised, and even these purely technical 
> observations should be examined carefully, and followed at your own 
> risk only if you think they are accurate.
>
> I reiterate that the above is not legal advice, but only a technical 
> analysis given the very well known terms of the major open source 
> licenses.  The GPL is particularly strong, and it has finally received 
> testing in court in recent years, so relying on its strength to 
> provide "NO WARRANTY" protection for open source developers is 
> probably a reasonable

Re: [opensource-dev] Can you legally agree to incomprehensible conditions

[Maya Remblai]

That all is true of pure OpenSim, but not necessarily true of 
OpenSim-compatible grids. ReactionGrid and InWorldz are 
OpenSim-compatible, meaning they use the same viewers and started with 
OpenSim code, but they've fixed many of the problems and are working to 
fix the others. Personally I favor InWorldz, and am now developing my 
avatars there before SL.

Maya

Carlo Wood wrote:

> I would move to opensim immediately, but:
>
> 1) It crashes non-stop
> 2) It can TOTALLY not deal with packetloss:
>2a) Avatar textures are extremely often corrupt.
>2b) Attachment won't attach/detach
>2c) I suffer from "rubber banding"
>2d) If I import stuff it literally ends up all over the sim.
> 3) Many other bugs have been there for years now
>and seem not to be fixed or addressed. For example,
>3a) Try sitting on a prim
>3b) Try standing on a slope
>3c) Try writing a script
>and so on.
>
> There simply is no alternative :(
>
> The opensim servers are very VERY buggy and bad quality,
> so much so that I seriously doubt the competence of it's
> developers to every deliver anything usable.
>
> What we need is to start over, write a new server from
> the ground up (in C++ if I'm to participate).
>
>   

___
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] Can you legally agree to incomprehensible conditions

[Maya Remblai]

Beats me, honestly. I'm not a coder, I'm just a content creator. My 
guess is the OpenSim project has its own plans and doesn't go looking 
for code elsewhere, they only take what's given to them. Which makes 
sense given the number of grids. But I really don't know the reason, I 
was just pointing out my own experiences.

Maya

Carlo Wood wrote:
> What is the reason that those fixes aren't incorporated in "pure" opensim?
>
>   

___
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] So you don't like the new TOS and wanna move to the OS grid?

[Maya Remblai]

You tried one grid out of...20? Maybe more? Not really a fair benchmark. :P

They're all different, and some are better than others. My personal new 
home is InWorldz. Reaction Grid performs well as well. OSGrid has the 
benefit of self-hosting, but that's a problem as well, as you saw. Many 
grids only run standard OpenSim software without any modifications, also 
a problem. There's a small discussion about OS grids here:

http://www.sluniverse.com/php/vb/opensim-discussion/42250-list-working-opensim-grids.html

Maya

Dale Mahalko wrote:
> I just tried using the SL 1.x client with OS grid for the first time
> this weekend. Overall the experience was plain awful, on a 10 megabit
> internet connection and GTX 285 1024meg
>
>
> Oddly, when giving the SL client the OSgrid URL from the command line,
> the client login page tells me that the Second Life grid is up, and
> the number of concurrent users in SL, etc. Why is the client not
> telling me the status of the OSgrid instead?
>
> On first login, the sim textures took forever to load. Like, after 5
> minutes I'm still standing in a sea of gray boxes.
>
> Simple physics only with the ground. All objects are phantom. I'd
> think the OSGrid default login would want to showcase the
> collision-resolving capabilities of the more advanced open physics
> engines, but oh well.
>
> When I search for sandboxes to try building stuff... odd, the search
> window shows me stuff from Second Life, not the OSGrid. Most teleports
> fail because it appears I'm getting links to SL sims that don't accept
> connections from OSGrid. Yep, I can find the Cordova Sandbox from the
> search page within OSGrid. (I don't think search should list sims that
> don't accept connections.)
>
> Searching for "osgrid" in the search window oddly turns up nothing.
> How am I to find sandbox sims in OSGrid? "Oh, just open the map and
> pick that way" someone tells me. Yeah that works well. the map shows
> about a 10x10 grid of sims nearby, but the rest of the map doesn't
> want to load. Timeout.
>
> I did actually manage to find another OSgrid sim to connect to, but on
> join it turned out to have a ping of 6000. (It would be useful for the
> search page to show a graph of the sim load for the last five minutes
> so we know if a sim is lagged out BEFORE we try teleporting.)
>
> And oh joy, I can't now "teleport home" to where I started. The OSgrid
> did something I've not seen happen on SL in a long time, where I seem
> to still be connected but all the traffic meters in the client debug
> (Ctrl-Shift-1) drop to 0 kbps.
>
> The inventory never loaded completely, even though as a new user it's empty.
>
> Relogin attempts attempting to login at the home location were just as
> slow and unresponsive.
>
>
> Yep, if you don't like the new SL client developer TOS, there is sure
> a great future to look forward to with the open source grid project.
> :-P
> ___
> 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] Stuff from my Lunch Bag

[Maya Remblai]

I agree with this outline, it makes far more sense. However I did want 
to point out this one minor detail:

Nicholaz Beresford wrote:
> - instruct that there is no end user support for problems arising when 
> using a TPV
>   
I assume you meant problems arising *because* of using a TPV. A user has 
every right to expect help when their sim crashes, or a greifer shows up 
on mainland, regardless of what viewer they're using. Saying "end-user" 
implies that, but I'd prefer more black and white wording. It's entirely 
possible for a Linden to say "Oh, I can't help you because you're on a 
TPV" if it's not completely clear.

Maya
___
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] Two Worlds

[Maya Remblai]

a...@skyhighway.com wrote:
> Oh, BTW, if you feel like answering this msg or making a comment or
> whatever, pls, pretty pls don't drag the TPVP argument into it?  'K?  i
> mean, yeah, it's important and all, but this isn't that conversation?
>
>   
Normally I'd agree, but actually the two issues *are* related. I 
wouldn't have said a thing about 2.0 if I were reasonably certain I 
wouldn't get banned for using a TPV. I haven't used LL viewers in a good 
year or so, and I don't plan to change that. But the TPVP makes users 
uneasy about using TPVs. That wouldn't be such a problem if 2.0 didn't 
cause so much trouble, people would just use that instead. But since 
we're potentially faced with "update or leave", it *is* a problem.

Just my two cents.

Maya
___
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] Viewer blacklist to replace the TPV directory ?

[Maya Remblai]

Not only that, but the only way the whitelist can work as a whitelist is 
if LL not only tests the viewers on the list, but compiles the list 
themselves. That means seeking out TPVs and accepting recommendations 
from users, not just sitting around waiting for the makers to send them in.

In my opinion, neither option will work all that well. LL doesn't have 
the staff necessary to compile and maintain either type of list, and the 
current TPV directory is nothing more than a misleading half-effort as a 
result. LL is trying, but they just don't have the manpower. Even a 
wiki-style page would be better.

Maya

Henri Beauchamp wrote:
> On Thu, 29 Apr 2010 14:04:21 -0400, Discrete Dreamscape wrote:
>
>   
>> A list of trusted entities is virtually always more robust and reliable than
>> a list of untrusted ones.
>> 
>
> This would be only true if LL was to *guarantee* that the listed viewer
> can *actually* be trusted, which is *not* the case with the current
> implementation of teh TPV directory.
>
>   

___
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

[Maya Remblai]

Glen Canaday wrote:
> [14:57] GC Continental: anything not on the TPV list as of yesterday 
> can't connect to the grid at all. This one does.
Just wanted to point out, that isn't true. The TPV list is merely for 
advertisement, and an unlisted viewer can still connect. Cool SL and 
Rainbow, for instance, are not listed but are TPV compliant and have no 
trouble connecting.

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

Re: [opensource-dev] Blocking viewers.

[Maya Remblai]

  Oh for crying out loud...Emerald DID cause a DDoS attack, which is a 
CRIME. It also collected information about users that it shouldn't have. 
Those are facts that LL is aware of. It's a dangerous piece of software 
and has no right to connect to the grid now. I used to use Emerald, and 
not many people advocated it more than me, but now I won't touch it 
because I know it's dangerous. LL did the right thing, and I'm impressed 
that they had the guts to do it at all. There was nothing personal or 
political about it. I do hope that LL will learn from the drama though, 
and get their act together with viewer work in general.

End of story. Go find another TPV and get on when your life. Most TPVs 
have the same feature set as Emerald now anyway, like temp uploads and 
useful radar.

Maya
___
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