[opensource-dev] Arrow Keys Always Move Me

[Glen Canaday]

Hey,

I'm a little curious - what's the expected behavior of "Arrow Keys Always Move 
Me"? I was under the impression that this was meant to cause the arrow keys to 
be the only movement keys, freeing up the rest of the keyboard for chat. I'm 
wrong, aren't I?

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

[opensource-dev] Arrow keys - nm

[Glen Canaday]

All,

My fault. Wrong checkbox! Please disregard.

--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] Almost certainly not your fault...

[Glen Canaday]

On Saturday, December 04, 2010 11:30:55 am Ponzu wrote:
> ...but I thought I should at least mention it.
> 
> I have been experimenting with compilers on OS X.  GCC 4.2  LLVM.  Clang.
>  Self educational OS X stuff.
> 
> Compile and link seems to work, but starting up Second Life leads to a
> kernel panic.  This is the only time I have ever seen OS X panic, so this
> is a pretty cool accomplishment.
> 
> FYI, LLVM is a very cool change to the compile-optimize-link chain.  it
> should lead to new and approved link-time optimizations.  Clang, on the
> other hand, is a new C++ parser front end.  It is supposed to be much
> faster than GCC.  We shall see.
> 
> regards,
> ponzu

You can get it to panic with faulty hardware, too. Happened to my powerbook G4 
way back, when the airport died.

Never ever saw it happen with software, so yeah that's a pretty crazy 
achievement.

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

[opensource-dev] User Story - Shared Media

[Glen Canaday]

Thought I'd post this here, since a few people might remember me trying this 
from a while back:

https://jira.secondlife.com/browse/VWR-24104

Got it wortking well enough, but can't right-click!

User Story (OK, a copy/paste from the Jira):

"When using a web-based VNC client to display a working desktop in SL, one 
would expect to be able to perform the same functions through VNC as through a 
standard desktop. There is no way to do that without being able to send mouse 
events other than the standard left click.

I've included a screenshot that shows what happens when you right-click.

To solve this, a key/click combo, such as "Alt+Shift+Click" or something, 
could be set up to send a standard right-click when the cursor is over a 
Shared Media-enable surface."

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

[opensource-dev] grid-wide banners

[Glen Canaday]

zFire Xue's device has now identified linden build 2.4.0 (216989) for Linux as 
a copybot client. I know this is not the correct forum, but I need a hotline 
to get rid of this guy and this product. It has seriously messed with my 
enjoyment of SL by banning me from EVERY one of his customer's sims. ALL of 
them. That includes normally quiet public places, such as the Shelman Sandbox. 
Now I have no idea where I can go and cannot go - and my partner is now 
similarly affected.

I simply want rid of this guy and his "product." Does anyone know the proper 
forum for this? Does anyone know if an AR will ever cut it in this situation?

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

[opensource-dev] svn compile failure on Ubuntu 9.10

[Glen Canaday]

Dead compile:

/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170: 
error: ‘LLInstanceTracker’ is an 
inaccessible base of ‘LLEventTimer’
make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2

I'm no good with templates - never use them. Anyone?

--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] svn compile failure on Ubuntu 9.10

[Glen Canaday]

Yup, that was it.

Next item, looks like SNOW-411 
(http://jira.secondlife.com/browse/SNOW-411) is the problem. Here's the 
output from gcc:

indra/viewer_components/login/lllogin.cpp:32:
/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/mpl/aux_/numeric_op.hpp:290:31:
 
error: missing binary operator before token "("

Here's the output of 'cat installed.xml | grep boost':

boost
boost
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-darwin-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux64-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-windows-20100119.tar.bz2
boost
http://www.boost.org/LICENSE_1_0.txt

The dates are out of whack with what Brad Linden posts - he's got a 
20100222a up there. I DLd and got this extracted into the source tree 
and now get:

/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/detail/coroutine_impl.hpp:59:
 
error: declaration of ‘typedef class 
boost::coroutines::detail::context_base 
boost::coroutines::detail::coroutine_impl::context_base’
/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/detail/context_base.hpp:55:
 
error: changes meaning of ‘context_base’ from ‘class 
boost::coroutines::detail::context_base’

*sigh*. Never ever once has any compile of any SL viewer worked. I'm 
even downgraded to 32-bit just to get this stuff to work because of 
issues with 64-bit linux last year.

Is there a version of boost and a way to get it in there that won't bust 
the build?

--GC

On 03/06/2010 06:13 PM, Thickbrick Sleaford wrote:
> On Sunday 07 March 2010 00:57:42 Glen Canaday wrote:
>
>> Dead compile:
>>
>> /home/glen/Programs/Second
>> Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170:
>> error: ‘LLInstanceTracker’ is an
>> inaccessible base of ‘LLEventTimer’
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> I'm no good with templates - never use them. Anyone?
>>
>> --GC
>>  
>
> This looks like SNOW-506:
> http://jira.secondlife.com/browse/SNOW-506
>
> IIRC there are two places where this happens (this and SNOW-514), and in both
> replacing the inheritance from protected to public seems to work.
>
>

___
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] svn compile failure on Ubuntu 9.10

[Glen Canaday]

My bad, SNOW-431: http://jira.secondlife.com/browse/SNOW-431

On 03/06/2010 06:13 PM, Thickbrick Sleaford wrote:
> On Sunday 07 March 2010 00:57:42 Glen Canaday wrote:
>
>> Dead compile:
>>
>> /home/glen/Programs/Second
>> Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170:
>> error: ‘LLInstanceTracker’ is an
>> inaccessible base of ‘LLEventTimer’
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> I'm no good with templates - never use them. Anyone?
>>
>> --GC
>>  
>
> This looks like SNOW-506:
> http://jira.secondlife.com/browse/SNOW-506
>
> IIRC there are two places where this happens (this and SNOW-514), and in both
> replacing the inheritance from protected to public seems to work.
>
>

___
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] svn compile failure on Ubuntu 9.10

[Glen Canaday]

Ah, cool. I'll give it a shot in a bit.

--GC

On 03/06/2010 07:47 PM, Thickbrick Sleaford wrote:
> On Sunday 07 March 2010 02:14:57 Glen Canaday wrote:
>
>> /home/glen/Programs/Second
>> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
>> etail/coroutine_impl.hpp:59: error: declaration of ‘typedef class
>> boost::coroutines::detail::context_base
>> boost::coroutines::detail::coroutine_impl> ContextImpl>::context_base’
>> /home/glen/Programs/Second
>> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
>> etail/context_base.hpp:55: error: changes meaning of ‘context_base’ from
>>   ‘class
>> boost::coroutines::detail::context_base’
>>
>>  
> What I did to get a non-standalone 32-bit build going with gcc4.4 was replace
> the boost in install.xml to the one from snowglobe 1.x trunk (REAL 1.39), then
> copy the libraries/include/boost/coroutine/ folder from the original boost
> package that came with 2.0 (1.34, but the file is named 1.39) into the
> unpacked new tree. Hopefully there will be proper 1.39 boost packages for 2.0
> soon.
>
> Other than this and the SNOW-506 problem you listed above, I also had copy my
> system's libuuid.so.1 into the build tree, because (I think) the supplied
> version didn't agree with my system's DBus.
>
>

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

[Glen Canaday]

On the bright side - anyone making tattoos and understanding the alpha 
mask isn't wearing system hair... 

--GC

On 03/10/2010 06:59 AM, Lance Corrimal wrote:
> Hmm...
>
>
> this won't help...
> I managed to adapt that patch for snowglobe 1.4, and editing an alpha layer
> corrupts skin and system hair, instead of skin and eyes.
>
>
> bye,
> LC
>
>
> Am Montag, 8. März 2010 22:23:32 schrieb Henri Beauchamp:
>
>> Greetings,
>>
>> I was wondering if Linden Lab was going to provide an updated v1.23
>> viewer with tattoo and alpha wearables support ?...
>> After all, and from LL's own admission, the v1.23 viewer is going to
>> be officially supported for quite a few more months even after v2.0
>> goes into production (a good thing, because patching v2.0 to make it
>> *acceptable* by power users and old timers will take a long while...),
>> and I think such a feature will be required pretty fast (I can see how
>> prim-shoes or prim-avatar makers could benefit of it)...
>>
>> I did some backport work on my side, based on the Snowglobe v2.0
>> sources: basically, things work (tattoo support is ok, alpha wearing
>> and rendering is ok), but I still got a problem with alpha editing (as
>> soon as I change a texture for the alpha in the customize appearance
>> floater, it corrupts the textures of the skin and eyes wearables).
>>
>> I'm attaching here the patch I came up so far for v1.23.5, but
>> I could use the help of one of the Lindens who coded this feature,
>> and/or of someone with a "new eye" on my patch in order to help me
>> spot what I missed or overlooked in v2.0 sources (the changes are
>> many, and it's kind of hard to spot all the related and required
>> changes among 24Mb of diff, not to mention the guess work around the
>> texture layering and baking algorithms in each v1.23 and v2.0)...
>>
>> Henri.
>>
>> PS: to use the patch, first apply
>>  slviewer-0-v12350-AlphaAndTattooSupport_v0.patch
>>  with 'patch -p1' from inside the linden/ source tree, then
>>  unzip slviewer-0-v12350-AlphaAndTattooSupport-patch.zip
>>  
> ___
> 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] Backport of Tattoo and Alpha support to v1.23 ?

[Glen Canaday]

The scripter's list has no sense of humor, either.

On 03/10/2010 09:54 AM, Lance Corrimal wrote:
> Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday:
>
>> On the bright side - anyone making tattoos and understanding the alpha
>> mask isn't wearing system hair...
>>  
> 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.
> ___
> 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] New topic: Snowglobe 2.0 way forward?

[Glen Canaday]

That's exactly the problem, really.

In order to more properly determine what has to be done, there first has 
to be a way of *defining* what helps immersion and what doesn't.

Popping out a sidebar that covers and shifts the world over definitely 
breaks it. In what ways will it be possible to keep the concept, since 
some in LL are obviously absolutely glued to it (Q that's you) while 
still removiing its detrimental effect on the user experience?

The chat bar's focus is also terrible. Only those who use wasdf to move 
can use it as it is... generally if my mouse focus in inworld, I want 
the keyboard focus (minus arrow keys) to be on the chat bar, as it has 
always been.

--GC

On 03/10/2010 03:14 PM, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The new interface breaks immersion, it places the world as just another
> small area of the screen with a bunch of other things outside of it.
>
> On 10/3/2010 15:13, Argent Stonecutter wrote:
>
>> On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
>>  
>>> IMO the 2.0 interface looks way more like a "developer's interface"
>>> than 1.*'s
>>>
>> Which brings this thread back onto topic for this list. :)
>>
>> I agree. The browser has become a familiar interface, but it was largely
>> developed by developers for developers, and for an application things
>> like the address bar and bookmarks and sidebars are distracting and
>> divert attention from the content (the page you're viewing, or the world
>> your avatar is in). Which is why web applications are allowed to remove
>> those decorations when creating a new window.
>>
>> The 2.0 interface looks like something a web developer would like to
>> use, not something someone IN SL needs. The address bar, toolbar, side
>> panel, and all the new highly decorated chat boxes and message boxes
>> should at the very least be made optional.
>>
>> Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
>> simplify the interface (or allow it to be simplified), restoring the sim
>> name and location to the title bar, cleaning up the chat and message
>> boxes, and so on?
>>
>>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuX/boACgkQ8ZFfSrFHsmWBbACeMaJR0Sd3PSQxvr+PFsSIuws5
> 19UAn2a5d5wIXJpdkQC0+wVHYz9V00Gi
> =aMlN
> -END PGP SIGNATURE-
> ___
> 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] oh give me a break

[Glen Canaday]

Then what are you doing in SL? Not making a living, I can assure you.

Nor are you putting food on the table RL except perhaps by manual labor, 
which cannot be copied. Ex: Ditches need to be dug. The ditch-digger can 
be changed out, but that doesn't change the fact that even if you get a 
new digger, you still have a ditch when you're done.

OSS/Free Software and Proprietary software are the diggers; they're not 
the ditch itself.

On 03/14/2010 06:18 PM, New Hax wrote:
> then what are you doing on an opensource list if you want your content
> wrapped in DRM.
>
> sl will die if its not open. and you can't compare rl doors to the
> internet. if you dont lock your rl door I can come in and take
> something of yours that isnt replaceable.
>
> 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.
>
>
> On 3/14/10, Marine Kelley  wrote:
>
>> well I am a content creator, content theft is a problem to me, it is tied to
>> IP rights which are a legal issue. And I am not one of those who say
>> "content theft is inevitable, let's not do anything about it". Doors can be
>> lock picked, that's not a reason for me to leave my door wide open.
>>
>>
>> On 14 March 2010 23:04, New Hax  wrote:
>>
>>  
>>> On 3/14/10, Marine Kelley  wrote:
>>>
 Err... Content theft has always been a problem, will always be a
 problem,
 and LL better be on the same page with developers, content makers and
 customers here.
  
>>> content theft isn't a problem, never has been a problem, and is the
>>> nature of the internet and digital things.  if content makers are
>>> worried about content "theft" then they shouldn't be on SL. because
>>> its inevitable and cant be stopped.
>>>
>>>
>>  
> ___
> 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] oh give me a break

[Glen Canaday]

Then what are you doing here?

On 03/14/2010 06:32 PM, New Hax wrote:
> I know better than to try to get rich off of selling ones and zeroes.
>
> On 3/14/10, Glen Canaday  wrote:
>
>> Then what are you doing in SL? Not making a living, I can assure you.
>>
>> Nor are you putting food on the table RL except perhaps by manual labor,
>> which cannot be copied. Ex: Ditches need to be dug. The ditch-digger can
>> be changed out, but that doesn't change the fact that even if you get a
>> new digger, you still have a ditch when you're done.
>>
>> OSS/Free Software and Proprietary software are the diggers; they're not
>> the ditch itself.
>>
>> On 03/14/2010 06:18 PM, New Hax wrote:
>>  
>>> then what are you doing on an opensource list if you want your content
>>> wrapped in DRM.
>>>
>>> sl will die if its not open. and you can't compare rl doors to the
>>> internet. if you dont lock your rl door I can come in and take
>>> something of yours that isnt replaceable.
>>>
>>> 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.
>>>
>>>
>>> On 3/14/10, Marine Kelley   wrote:
>>>
>>>
>>>> well I am a content creator, content theft is a problem to me, it is tied
>>>> to
>>>> IP rights which are a legal issue. And I am not one of those who say
>>>> "content theft is inevitable, let's not do anything about it". Doors can
>>>> be
>>>> lock picked, that's not a reason for me to leave my door wide open.
>>>>
>>>>
>>>> On 14 March 2010 23:04, New Hax   wrote:
>>>>
>>>>
>>>>  
>>>>> On 3/14/10, Marine Kelley   wrote:
>>>>>
>>>>>
>>>>>> Err... Content theft has always been a problem, will always be a
>>>>>> problem,
>>>>>> and LL better be on the same page with developers, content makers and
>>>>>> customers here.
>>>>>>
>>>>>>  
>>>>> content theft isn't a problem, never has been a problem, and is the
>>>>> nature of the internet and digital things.  if content makers are
>>>>> worried about content "theft" then they shouldn't be on SL. because
>>>>> its inevitable and cant be stopped.
>>>>>
>>>>>
>>>>>
>>>>  
>>> ___
>>> 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] oh give me a break

[Glen Canaday]

Agreed. Lack of a basic working knowledge of economics is a sad thing 
when combined with uninformed ideology. I was in the same boat as him 
about 15 years ago after reading The Cathedral and the Bazaar and not 
understanding what was really up.

Anyway, back to business. I'm actually glad for the diversion though - 
everyone suddenly stopped linden-bashing!

Suppose we could reaffirm the goals of the project, perhaps once a 
month? That would be helpful for those like myself who were on the 
viewer-dev list long ago and left it only to return recently hoping 
something would compile ;P And for total-newcomers, too.

I'm still holding on to my dream of a QT-based viewer running native on 
everything...

--GC

On 03/14/2010 07:03 PM, Soft Linden wrote:
> On Sun, Mar 14, 2010 at 3:47 PM, Kevin Woolley  wrote:
>
>> I own three Sims in SL, that's ~$600 a month or so to the Lindens, and
>> that's supported off DRM'ed content creation that I sell. If my income was
>> to vanish because of widespread content theft then I'd be out of SL.
>>
>> I find Hax's attitude extremely concerning.
>>  
> It's a good thing he's neither a contributor, nor - to the best of my
> knowledge - representative of anyone with code in our project. He's
> just a guy showing up with an opinion.
>
>
>
>> In fact I think we should now recognise that Open Sourcing the viewer has
>> been a mistake, and the Lindens should close it off again, possibly
>> replacing it with controlled licensed development.
>>  
> copybot and copying proxies existed before the viewer was made open
> source, and would continue to exist without the viewer being open
> source. Abandoning source publication wouldn't stop the problem. There
> are literally dozens of tools that don't use one line of our code.
>
> Keep in mind that open source projects also include clients and tools
> that help identify copy botters, added clothing layer protection even
> before Viewer 2, add automatic recognition of some copied content, and
> more. It's also meant some better building and scripting tools, free
> clothing texture upload previews and other things that help in
> creating content.
>
> On the balance, the open source viewer has improved the situation for
> content creators.
> ___
> 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] oh give me a break

[Glen Canaday]

I agree. This really doesn't belong on this list.
___
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

[Glen Canaday]

Linux build of Snowglobe-2.0 svn doesn't like spaces in the build path.

find: `/home/glen/Programs/Second': No such file or directory
find: 
`Life/Snowglobe-2.0-build/trunk/indra/viewer-linux-i686-relwithdebinfo/newview/packaged':
 
No such file or directory

Bright side - got thru my fist build! Least - compiling and linking 
worked lol

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

[opensource-dev] Yay! (was: Re: oh give me a break)

[Glen Canaday]

Screwed up the topic. All better now.


 >>

Linux build of Snowglobe-2.0 svn doesn't like spaces in the build path.

find: `/home/glen/Programs/Second': No such file or directory
find: 
`Life/Snowglobe-2.0-build/trunk/indra/viewer-linux-i686-relwithdebinfo/newview/packaged':
 
No such file or directory

Bright side - got thru my fist build! Least - compiling and linking 
worked lol

--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] Yay!

[Glen Canaday]

lol.. define 'proper' ;P

Release, non-standalone? If this worls properly I'll see if I can do a 
non-patched pure 2.0 build. If LL's interested, they can have it.


--GC

On 03/15/2010 11:14 PM, Tony Agudo wrote:


Congrats on the successful build, Glen. I hope this means a proper 
Snowglobe 2.0 binary for Linux isn't far behind anymore.


On Mar 15, 2010 10:08 PM, "Glen Canaday" <mailto:gcana...@gmail.com>> wrote:


Screwed up the topic. All better now.


>>>>>>

Linux build of Snowglobe-2.0 svn doesn't like spaces in the build path.

find: `/home/glen/Programs/Second': No such file or directory
find:
`Life/Snowglobe-2.0-build/trunk/indra/viewer-linux-i686-relwithdebinfo/newview/packaged':
No such file or directory

Bright side - got thru my fist build! Least - compiling and linking
worked lol

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


___
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] Yay!

[Glen Canaday]

Me too. It's part of why I wanted it to build so bad. Others can build 
it - this is actually my first successful build attempt.


--GC

On 03/15/2010 11:24 PM, Tony Agudo wrote:


Yup, that sort of proper(at least would run okay). I'm a bit tired of 
seeing "no Linux binary available" on the wiki page and I'd love to do 
performance comparisons of it against Viewer 2.0.


On Mar 15, 2010 10:16 PM, "Glen Canaday" <mailto:gcana...@gmail.com>> wrote:


lol.. define 'proper' ;P

Release, non-standalone? If this worls properly I'll see if I can do a 
non-patched pure 2.0 build. If LL's interested, they can have it.


--GC

On 03/15/2010 11:14 PM, Tony Agudo wrote:


Congrats on the successful build, Glen. I hope this means a proper 
Snowglobe 2.0 binary for Linux isn't far behind anymore.


On Mar 15, 2010 10:08 PM, "Glen Canaday" <mailto:gcana...@gmail.com>> wrote:


Screwed up the topic. All better now.


>>>>>>

Linux build of Snowglobe-2.0 svn doesn't like spaces in the build path.

find: `/home/glen/Programs/Second': No such file or directory
find:
`Life/Snowglobe-2.0-build/trunk/indra/viewer-linux-i686-relwithdebinfo/newview/packaged':
No such file or directory

Bright side - got thru my fist build! Least - compiling and linking
worked lol

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



___
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] Yay! (was: Re: oh give me a break)

[Glen Canaday]

I misbehaved. Changed the build dir from under "Second Life" (note the 
space in the name... i woulda though cmake would escape them), to 
SL_BUILD and all is almost beautiful. Runs great, considering it's 
terribly beta and hasn't been thru an iteration or two of performance 
patches. Runs (subjectively) the same as the 2.0 beta binary release.

The build didn't pack it up with tar & bzip2 though. I did that myself. 
Now I can at least start poking at it after my girlfriend turns me into 
a preppy elf.

--GC

On 03/16/2010 05:13 AM, til...@xp2.de wrote:
> Lilly  wrote ..
>
>
>>> Linux build of Snowglobe-2.0 svn doesn't like spaces in the build path.
>>>
>> Who puts spaces on unix pathes ? ;)
>>  
> Most installers do that for many OSes. Like Installer for Visual Studio on 
> windows. I had to reinstall Visual Studio to something like C:\vs\ or else 
> the build would break with a similar error. cmake pukes on that, apparently, 
> cause call parameters don't get surrounded with "" each.
>
> But sure, no one should use spaces in paths anywhere. But it's just a common 
> misbehaviour you will see all day.
>
> Tillie
>
>

___
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

[Glen Canaday]

That's part the point I've been hesitant to make. It's one thing to not 
be able to stop IP violations, but it's quite another to deliberately 
*enable* them and turn the other cheek when the theft is obvious. That's 
where the TPV policy comes in, and it's where Emerald's "project opal" 
(that what it's called?) comes in. It's also where viewer developers 
come in.

SL would be as empty of people and content as my standalone OpenSim home 
/ testing grid if it were permitted. In order to keep our own Second 
Lives worth having, viewer devs need to not deliberately enable copying. 
Can't predict the effects of every single little bug, but it still 
behooves the programmer to be vigilant about it.

The Gimp is free software but the pictures made with it aren't unless 
that right is given by the creator. Same as in SL. And that's the major 
point that brings the whole copyright / theft discussion back on topic 
for the list. Seems a few lurkers are thinking that they own the hole 
they've been digging themselves into. I'm all for free tools - the Mona 
Lisa could have been painted with free brushes or magic special 
Microsoft brushes - but that doesn't mean that because I gave DaVinci 
the brush, canvas, and paints that I'm free to take the art out of the 
Louvre.

Hopefully that kills this thread.

--GC

> I agree it can't be protected against, but that does not mean it
> should be encouraged by LL either - I believe that so long as
> copyright law exists, LL should enforce it on their platform.
>
> But, I heavily disagree on open source contributing more to SL than
> content creators - what use is an empty virtual world, even one that
> has killer technology?
>

___
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

[Glen Canaday]

Yeah, that's it. I forgot the name. I expect that list to grow a bit, 
but hopefully it won't grow much bigger than it already is.

On 03/16/2010 06:08 PM, Robert Martin wrote:
> On Tue, Mar 16, 2010 at 6:03 PM, Glen Canaday  wrote:
>
>> That's part the point I've been hesitant to make. It's one thing to not
>> be able to stop IP violations, but it's quite another to deliberately
>> *enable* them and turn the other cheek when the theft is obvious. That's
>> where the TPV policy comes in, and it's where Emerald's "project opal"
>> (that what it's called?) comes in. It's also where viewer developers
>> come in.
>>  
> ...
> are you talking about http://onyx.modularsystems.sl/??
>
>

___
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

[Glen Canaday]

Lol, yes, I think everyone except hax and a couple of others would agree.

The analogy still works, though...

DaVinci should've been able to export / backup the Mona Lisa. I'm still 
not allowed to take the original out of the museum though it's not mine 
even though I gave him the brushes.

--GC

On 03/16/2010 06:19 PM, Gareth Nelson wrote:
> On Tue, Mar 16, 2010 at 10:03 PM, Glen Canaday  wrote:
>
>> The Gimp is free software but the pictures made with it aren't unless
>> that right is given by the creator. Same as in SL. And that's the major
>> point that brings the whole copyright / theft discussion back on topic
>> for the list. Seems a few lurkers are thinking that they own the hole
>> they've been digging themselves into. I'm all for free tools - the Mona
>> Lisa could have been painted with free brushes or magic special
>> Microsoft brushes - but that doesn't mean that because I gave DaVinci
>> the brush, canvas, and paints that I'm free to take the art out of the
>> Louvre.
>>  
> I'd be inclined to say that this is a bad analogy - what's closer is
> whether you can paint your own mona lisa, or otherwise copy it -
> you'll not find support for actual theft from me :)
>
> But back on topic - regardless of all our unique individual political
> views on copyright, it's definitely a bad bad idea for LL to encourage
> copyright infringement on their platform - or anything illegal for
> that matter - this is something we can agree on, yes?
>
> I'd hope another thing to be agreed on is that it's not good to
> implement strong DRM measures and cripple legit users while at most
> slowing down temporarily those who want to break the rules - yay or
> nay?
>
>
>

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

[Glen Canaday]

That's an annoyance I'd like to specifically target in snowglobe 2. The 
majority of resis in SL were never gamers so never got used to wasd 
movement.

--GC

On 03/16/2010 03:42 PM, Argent Stonecutter wrote:
> OK, here's a design problem in the new viewer that maybe can be
> figured out here.
>
>   From the Jira, I missed this response to one of my comments, some
> time ago. Apologies, I forgot to "watch" the item:
>
>   From Q Linden:
>
>> Argent: the focus problem differs this time because the chat bar is
>> always present; we have no mechanism to make it go away, so if we
>> always gave it focus it would block normal keyboard use. Personally,
>> I'm an AWSD movement person, so I actually find this works really
>> well for me. It's not quite as obviously wrong as you seem to think.
>> However, I understand the use case and we'll talk about it internally.
>>  
> This is exactly the same problem that we had the last two times. This
> is exactly the same discussion we had the last two times. There are
> many many people who never use any of the keyboard accelerators in SL,
> and always have the chat bar up and in focus. The chat bar focus NEVER
> goes away. For us, normal keyboard use does not involve anything the
> chat bar blocks.
>
> So, how could this be fixed in the 2.0 viewer without causing
> discombobulation?
>
> An option "chat bar is the default focus"?
>
> What would that actually break?
> ___
> 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] Fixing the 2.0 chat bar focus problem?

[Glen Canaday]

Maybe it's *my* bias. I personally know of no gamers who'd use wasd who 
have stayed in SL longer than a couple of months at best.

Most of the people I have known in SL shop, go to clubs, create, RP, and 
hang out, most of which requires chatting without an extra step to 
switch focus. Leaving the chat bar with focus kills wasd movement, but I 
can name no one who doesn't use the arrow keys for that.

Survey?

On 03/16/2010 07:10 PM, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> that's new to me...
>
> perhaps my sample is biased due to me hanging around people with similar
> interests (i do like to play computer/video games)
>
> On 16/3/2010 19:41, Glen Canaday wrote:
>
>> That's an annoyance I'd like to specifically target in snowglobe 2. The
>> majority of resis in SL were never gamers so never got used to wasd
>> movement.
>>
>> --GC
>>
>> On 03/16/2010 03:42 PM, Argent Stonecutter wrote:
>>  
>>> OK, here's a design problem in the new viewer that maybe can be
>>> figured out here.
>>>
>>>From the Jira, I missed this response to one of my comments, some
>>> time ago. Apologies, I forgot to "watch" the item:
>>>
>>>From Q Linden:
>>>
>>>
>>>> Argent: the focus problem differs this time because the chat bar is
>>>> always present; we have no mechanism to make it go away, so if we
>>>> always gave it focus it would block normal keyboard use. Personally,
>>>> I'm an AWSD movement person, so I actually find this works really
>>>> well for me. It's not quite as obviously wrong as you seem to think.
>>>> However, I understand the use case and we'll talk about it internally.
>>>>
>>>>  
>>> This is exactly the same problem that we had the last two times. This
>>> is exactly the same discussion we had the last two times. There are
>>> many many people who never use any of the keyboard accelerators in SL,
>>> and always have the chat bar up and in focus. The chat bar focus NEVER
>>> goes away. For us, normal keyboard use does not involve anything the
>>> chat bar blocks.
>>>
>>> So, how could this be fixed in the 2.0 viewer without causing
>>> discombobulation?
>>>
>>> An option "chat bar is the default focus"?
>>>
>>> What would that actually break?
>>> ___
>>> 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
>>
>>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkugD9sACgkQ8ZFfSrFHsmWe2ACfWXcGjN7TjfQ1jDslHQa4Pav1
> kLsAn3I6rUdVhWj1hZaGQk7fzZ0dOE4V
> =0jWI
> -END PGP SIGNATURE-
> ___
> 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] Fixing the 2.0 chat bar focus problem?

[Glen Canaday]

Autoplay media has got to go, too.

On 03/16/2010 07:10 PM, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> that's new to me...
>
> perhaps my sample is biased due to me hanging around people with similar
> interests (i do like to play computer/video games)
>
> On 16/3/2010 19:41, Glen Canaday wrote:
>
>> That's an annoyance I'd like to specifically target in snowglobe 2. The
>> majority of resis in SL were never gamers so never got used to wasd
>> movement.
>>
>> --GC
>>
>> On 03/16/2010 03:42 PM, Argent Stonecutter wrote:
>>  
>>> OK, here's a design problem in the new viewer that maybe can be
>>> figured out here.
>>>
>>>From the Jira, I missed this response to one of my comments, some
>>> time ago. Apologies, I forgot to "watch" the item:
>>>
>>>From Q Linden:
>>>
>>>
>>>> Argent: the focus problem differs this time because the chat bar is
>>>> always present; we have no mechanism to make it go away, so if we
>>>> always gave it focus it would block normal keyboard use. Personally,
>>>> I'm an AWSD movement person, so I actually find this works really
>>>> well for me. It's not quite as obviously wrong as you seem to think.
>>>> However, I understand the use case and we'll talk about it internally.
>>>>
>>>>  
>>> This is exactly the same problem that we had the last two times. This
>>> is exactly the same discussion we had the last two times. There are
>>> many many people who never use any of the keyboard accelerators in SL,
>>> and always have the chat bar up and in focus. The chat bar focus NEVER
>>> goes away. For us, normal keyboard use does not involve anything the
>>> chat bar blocks.
>>>
>>> So, how could this be fixed in the 2.0 viewer without causing
>>> discombobulation?
>>>
>>> An option "chat bar is the default focus"?
>>>
>>> What would that actually break?
>>> ___
>>> 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
>>
>>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkugD9sACgkQ8ZFfSrFHsmWe2ACfWXcGjN7TjfQ1jDslHQa4Pav1
> kLsAn3I6rUdVhWj1hZaGQk7fzZ0dOE4V
> =0jWI
> -END PGP SIGNATURE-
> ___
> 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] Fixing the 2.0 chat bar focus problem?

[Glen Canaday]

That is the current 2.0 behavior to a tee. The only difference is that 
it never becomes invisible.

That's 4 on the list including Q so far, 1 (me) otherwise.

--GC

On 03/16/2010 07:31 PM, Michael Schlenker wrote:
> Am 17.03.2010 um 00:29 schrieb Zi Ree:
>
>
>> Am Mittwoch 17 März 2010 00:21:42 schrieb Glen Canaday:
>>
>>  
>>> Most of the people I have known in SL shop, go to clubs, create, RP, and
>>> hang out, most of which requires chatting without an extra step to
>>> switch focus. Leaving the chat bar with focus kills wasd movement, but I
>>> can name no one who doesn't use the arrow keys for that.
>>>
>> What I usually do is having the chat bar hidden, walk around with WASD or
>> cursor keys, whatever is appropriate at that moment, and call the chat bar up
>> by pressing Enter when I need it. That's one thing I would lve to see coming
>> back in 2.0. Autohide chat bar.
>>  
> +1 Was the first thing i missed from 2.0.
>
> 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
>

___
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] SL2 font problem on linux

[Glen Canaday]

Which distro?

On 03/16/2010 02:08 PM, Tayra Dagostino wrote:

Every time i try to login SL2 crash due some font trouble, all font
listed are present and readable by all users in the system...

somebody else seen this? (if yes i'll opena  JIRA, otherwise i look for
a local trouble of my linuxbox...)
   



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

[Glen Canaday]

Has anyone else noticed a 10 fps drop between snow 2.0 and snow 1.3?

Seriously, 10fps difference standing by myself in my own house. I go 
from 22 since i have everything turned on to 12 with the same settings, 
and all i did was relog and wait for rez. That's nearly a 50% frame rate 
drop.

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

[Glen Canaday]

I'm still opting to eyeball the code and put it back the way it was, at 
least on my end, and I'll try to include an option for it in prefs 
(therefore obvious and not hidden) so that others can have a worthwhile 
patch. It will take time though because I only just got it to compile in 
the past couple of days. It will take a bit to grok this ginormous 
beast. I'm such a n00b to the viewer code it's insane - a patch to fix 
ATI memory detection that doesn't make it into the main viewer kinda 
doesn't count.

I've never thought of SL as a game; never will.

--GC

On 03/17/2010 08:17 PM, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> like i said before, hitting a key to call the chatting functionality is
> quite common in games
>
> On 17/3/2010 06:55, Kitty wrote:
>
>>  Having the chatbar always taking focus would be just as much a
>>  disaster for me as it seems it is for you to have it releasing focus
>>  so much...  Although, for me it seems to be perfect the way it is,
>>  as I haven't been fighting it in 2.0: it seems to work the way my
>>  mind expects it to.
>>
>>  If there seems to be an issue, then it sounds like a debug setting
>>  is in order.  If enough people seem interested, that can be later
>>  exposed in the UI somewhere.
>>
>> Going by the last "by country" statistics that were released 9% of the
>> SL population lives in a country where "WASD" is meaningless (AZERTY
>> keyboard layout).
>>
>> So regardless of how the other 90% is laid out that particular change in
>> 2.0 is going to annoy at least the 1 in 10 for who WASD never worked in
>> the first place which seems more than enough to make it a clearly
>> visible option and not something that's hidden away in an obscure debug
>> setting noone will ever know about.
>>
>> As an aside, hitting  to get focus to the chat bar just isn't
>> intuitive because it's tied to the "send what I've typed" action. If I'm
>> halfway through typing something and something else in the UI needs
>> attention it feels like a terribly unnatural thing to hit  to go
>> back to typing because you'd expect  to instead send what you
>> were busy typing before. Or if you finished typing it now takes 2
>> 's all of a sudden to actually send it.
>>
>> The UI also doesn't give any hints for those who don't know: instead of
>> "Click here to chat" it should say "Press return to start chatting".
>> People do realize that you click in a text box before typing in it while
>> having to hit  to give it focus is non-standard.
>>
>> Kitty
>>
>>
>>
>> ___
>> 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
>>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuhcQYACgkQ8ZFfSrFHsmXr7wCeNb7EQxLloj5YGVFGmBvf41oA
> 5dUAn30NvH55CFVnHnavQ/DuawK2P2ka
> =aUAJ
> -END PGP SIGNATURE-
> ___
> 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] "vendor" branch and Snowglobe 2.0

[Glen Canaday]

What are we checking out with snowglobe/trunk currently?

--GC

On 03/17/2010 08:52 PM, Philippe (Merov) Bossut wrote:

Hi,

For those following the commit messages, you certainly noticed quite a 
bit of commits from that "Merov Linden" bloke recently. What's this 
all about?


*Short Story
*We have now a "vendor" branch (export of official viewer source code) 
and tagged branches. I'm going to continue testing of the commit 
scripts and, when done, will flip the switch and drop beta 4.


*Long Story
*I'm pretty much done with all the export script writing now and I'm 
moving to make all that live so that updates from the viewer trunk 
come in more regularly and automatically. For this though, I needed to 
create the first repo "manually" and that's what I did yesterday and 
today (among other things), cleaning stuff up and finding a couple of 
more bugs in my scripts while at it :/


The result is a "vendor" branch, i.e. a clean export from the viewer 2 
0 trunk that we can use to sync Snowglobe 2.0 with whenever we 
need/want. This branch is:

https://svn.secondlife.com/svn/linden/branches/2010/oss-viewer

This will be the "live" vendor branch holding the exported copy of the 
internal viewer development trunk.


Since I populated it with the beta 3 bundle, I also created a "tag" 
for good measure:

https://svn.secondlife.com/svn/linden/branches/2010/viewer_2-0_beta3

*Next Step
*I'm going to turn on the commit script before the end of the week (I 
need to do some more tests) so expect beta 4 to drop on oss-viewer soon.


Thanks for your patience.

Cheers,
- 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


___
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] left and right arrows change to strafing in mouselook

[Glen Canaday]

It seems to me that the 2.0 prefs box can add a lot of extra tabs - one 
page might get full, but there looks to be room for twice as many tabs. 
One separate for input and one for camera, for example.

--GC

> I don't use mouselook very often, so I wouldn't be a good person to
> weigh the benefit of this particular proposed option versus the added
> complexity. But I will point out that the "Input&  Camera" preference
> panel (in the SL 1.x UI) is not overly crowded, so the cost of putting
> a new option there would not be very high. For the SL 2.0 UI, it could
> potentially be squeezed in to the "Setup" preference panel, although
> it would be a tighter fit.
>
> So, to summarize: I think it's a good idea and you (or someone) should
> go for it. :-)
>
> - Jacek
> ___
> 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 Development project: extending avatar wearables

[Glen Canaday]

I'm a little unsure what the tiny robot means about the appearance 
floater being all yucky

We'll still need it for the shape sliders, will we not? After all, it's 
incredibly convenient to just put it where you want it in order to 
reduce the mouse-miles involved. Sticking it ALL on the right... yuck. I 
would need an extension to my desk to keep going that far to the right.

I know they put a lot of effort into it, but 2.0's UI already has too 
much tossed into the sidebar junkbox - could we at least keep the 
floater for shape editing? I find it very useful as it is. Wearables, 
since new functionality is being added, sure... but the community is 
going to tear the sidebar up, anyway.

--GC


On 03/23/2010 12:58 PM, Nyx Linden wrote:
>The current iteration of the appearance floater needs to go away. The
> current implementation has been held together with chicken wire, bubble
> gum, and duct tape. It works for now, but it won't hold up to the
> addition of multiple wearables of a given type. The currently designed
> plan is to extend the appearance sidebar to pick up the extra
> functionality of editing a saved outfit and editing of individual
> wearables. I think the flow between the different stages (selecting your
> outfit, editing your outfit, editing a wearable item) should be pretty
> useful and intuitive. I'll be posting our initial design thoughts once
> we get the appropriate channels set up (forums most likely).
>
> I will remind you, however, that this project is specifically about
> extending the avatar functionality. Yes there is a UI element here, and
> I'm open to discussion of various ways of presenting the UI for these
> specific features, given that the ideas are 1) easy to use and intuitive
> and 2) still able to be done within the given timeframe.
>
> It sounds, however that you're asking for the ability to "tear off" any
> of the sidepanels into independent floaters. This is good feedback, and
> a perspective that a number of residents share, but this project is not
> the one that is capable of doing that. We have a design team and a
> "Viewer interactive" team that is in charge of the overall design and
> GUI implementation of the major elements of the viewer. I'm pretty sure
> that they're already aware of this feedback, but I'll send it their way
> again.
>
> Let's keep discussion of the multi-wearables functionality on-target,
> please :)
>
> -Nyx
>
> Bryon Ruxton wrote:
>
>> 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 inven

Re: [opensource-dev] Open Development project: extending avatar wearables

[Glen Canaday]

Nyx,

Oh, I actually do have one functionality idea / request: rather than 
allowing the creator to dictate the clothing layer of a wearable, can we 
allow the wearer themselves choose where it goes? I can't tell you how 
many times I've had to not wear something because the original creator 
did not have the foresight to put it on a layer that makes sense for 
that wearable, nor include a copy that goes onto the desired layer.


We might have a tattoo layer now, but most places are not offering that, 
nor are very many people using 2.0. It would be nice to be able to 
choose that a tattoo goes *under* the underpants since most people sell 
tats on the unders layer and will until 2.1 or 2.2 is widely used. If we 
get to choose which of which multiple-wearable goes on top at /wear/ 
time and not /creation/ time, it allows for far more flexibility in 
customizing an avatar's look.


Just my $0.02, but it's hard to justify having multiple layers in my 
mind without doing it this way.


--GC

On 03/23/2010 12:58 PM, Nyx Linden wrote:

   The current iteration of the appearance floater needs to go away. The
current implementation has been held together with chicken wire, bubble
gum, and duct tape. It works for now, but it won't hold up to the
addition of multiple wearables of a given type. The currently designed
plan is to extend the appearance sidebar to pick up the extra
functionality of editing a saved outfit and editing of individual
wearables. I think the flow between the different stages (selecting your
outfit, editing your outfit, editing a wearable item) should be pretty
useful and intuitive. I'll be posting our initial design thoughts once
we get the appropriate channels set up (forums most likely).

I will remind you, however, that this project is specifically about
extending the avatar functionality. Yes there is a UI element here, and
I'm open to discussion of various ways of presenting the UI for these
specific features, given that the ideas are 1) easy to use and intuitive
and 2) still able to be done within the given timeframe.

It sounds, however that you're asking for the ability to "tear off" any
of the sidepanels into independent floaters. This is good feedback, and
a perspective that a number of residents share, but this project is not
the one that is capable of doing that. We have a design team and a
"Viewer interactive" team that is in charge of the overall design and
GUI implementation of the major elements of the viewer. I'm pretty sure
that they're already aware of this feedback, but I'll send it their way
again.

Let's keep discussion of the multi-wearables functionality on-target,
please :)

-Nyx

Bryon Ruxton wrote:
   

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
 

Re: [opensource-dev] Open Development project: extending avatar wearables

[Glen Canaday]

Actually, I don't mind "undies, shirt, and jacket." What I'm really 
referring to is maybe 3 undies layers numbered 1,2,3. Creators can still 
specify which of those three as they do now, but the user would choose 
the 1, 2, 3 bit. The creator doesn't lose the ability to choose which of 
the three upper layers (or two lower), so they can still specify on 
which layer the items would look as intended... but the user doesn't 
have to stick to "gee, do I wear the garter, the undies, or the tattoos? 
But I still want to wear the glitchpants that came with the skirt..."


I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. There 
should be a limit to keep the code simple, it's just a way bigger limit!


There are content creators that give transfer on items.. and I like it 
that way. There are some (ok, one that I can name) that doesn't give 
multiple layers because she gives them xfer, which I can understand. It 
all comes down to smart permissions for the next person. But that's a 
key issue for the creators I think.


However, they'd still get to choose that their pants go on the pants 
layer - just not choose WHICH pants layer. The user would get that, and 
that might curb some people's bitching at the creators! Kind of a 
win-win imo...


--GC

On 03/24/2010 09:48 PM, Brent Tubbs wrote:
I like this idea a lot.  While we're talking about about increasing 
flexibility though, why have a low hardcoded limit to the number of 
layers?  The new tattoo and alpha layers are great, but what comes 
next, and how long do we keep hardcoding more specific layers?  If 
someone wants to layer on ten tattoos at once, let's let them!  At 
some point it makes sense to throw away the pre-defined layers and 
just call them 1 through n.


On the other hand, some content creators sell items in separate 
under-layer and tattoo friendly over-layer packs.  I imagine some of 
them would be pretty upset if the layer restrictions on all the 
products they've sold were suddenly removed.


Brent

On Wed, Mar 24, 2010 at 6:21 PM, Glen Canaday <mailto:gcana...@gmail.com>> wrote:


Nyx,

Oh, I actually do have one functionality idea / request: rather
than allowing the creator to dictate the clothing layer of a
wearable, can we allow the wearer themselves choose where it goes?
I can't tell you how many times I've had to not wear something
because the original creator did not have the foresight to put it
on a layer that makes sense for that wearable, nor include a copy
that goes onto the desired layer.

We might have a tattoo layer now, but most places are not offering
that, nor are very many people using 2.0. It would be nice to be
able to choose that a tattoo goes *under* the underpants since
most people sell tats on the unders layer and will until 2.1 or
2.2 is widely used. If we get to choose which of which
multiple-wearable goes on top at /wear/ time and not /creation/
time, it allows for far more flexibility in customizing an
avatar's look.

Just my $0.02, but it's hard to justify having multiple layers in
my mind without doing it this way.


--GC

On 03/23/2010 12:58 PM, Nyx Linden wrote:

   The current iteration of the appearance floater needs to go away. The
current implementation has been held together with chicken wire, bubble
gum, and duct tape. It works for now, but it won't hold up to the
addition of multiple wearables of a given type. The currently designed
plan is to extend the appearance sidebar to pick up the extra
functionality of editing a saved outfit and editing of individual
wearables. I think the flow between the different stages (selecting your
outfit, editing your outfit, editing a wearable item) should be pretty
useful and intuitive. I'll be posting our initial design thoughts once
we get the appropriate channels set up (forums most likely).

I will remind you, however, that this project is specifically about
extending the avatar functionality. Yes there is a UI element here, and
I'm open to discussion of various ways of presenting the UI for these
specific features, given that the ideas are 1) easy to use and intuitive
and 2) still able to be done within the given timeframe.

It sounds, however that you're asking for the ability to "tear off" any
of the sidepanels into independent floaters. This is good feedback, and
a perspective that a number of residents share, but this project is not
the one that is capable of doing that. We have a design team and a
"Viewer interactive" team that is in charge of the overall design and
GUI implementation of the major elements of the viewer. I'm pretty sure
that they're already aware of this feedback, but I'll send it their way
a

Re: [opensource-dev] Open Development project: extending avatar wearables

[Glen Canaday]

That's actually what I would like to avoid, specifically. That forces 
the creator to continue to dictate whether your underwear goes on top of 
your pants or not. There's no added flexibility for the resident in that.

Here's why I'll be an advocate of just a few extra numbered layers on 
top of the existing system (until someone blows me away with a simpler 
to implement, more flexible solution):

Creator: no change. "Hmm... undie, pants, undershirt, shirt, jacket."
Creator A: "... it puts the pants on pants layer"

Wearer: "I got a pants layer from Creator A! ... but my tights are 
pants, too... Oh, ok. Tights on Pants1, pants from Creator A on Pants 2. 
That'll do it.."

No change for the creator - none. Not a thing. The user gets a "bump up" 
or "bump down" item in the current "wear" submenu.. that's all. Max 3 or 
so, and they act like layers in Photoshop or Gimp, which is essentially 
what they are now.

Totally minimal UI change, no change in permissions, and just a few 
extra layers to bake - half of which will usually be empty anyway until 
people discover the coolness of wearing 3 pairs of pants at once. (last 
part's a joke, but you get my meaning.)

lower layer list:
*skin
*alpha
*tattoo
*underwear 1
*underwear 2
*underwear 3
*pants 1
*pants 2
*pants 3
(*jacket 1 lower)
(*jacket 2 lower)
(*jacket 3 lower)

uppers:
*skin
*alpha
*tattoo
*undershirt 1
*undershirt 2
*undershirt 3
*shirt 1
*shirt 2
*shirt 3
*jacket 1 upper
*jacket 2 upper
*jacket 3 upper

Would also be nice to have a few facial layers, too. The current tattoo 
layer in 2.0 is full-body, one layer only. That doesn't work for people 
who like to mix-n-match, but that in combination with the above list does.

I'm still open to be convinced - I'm just starting the discussion off!

--GC

On 03/24/2010 10:58 PM, Dzonatas Sol wrote:
> An easier way may just to have  list without ordinals. Example:
>
> Outfit:
> * Upper-body
> ** Jacket
> ** Shirt
> ** Undershirt
> ** upper-tattoos
> ** custom-upper-body-skin
> ** another-custom-upper-body-skin
> * Lower-body
> ** Pants
> ** Underpants
> ** lower-tattoos
> ** custom-lower-body-skin
> ** another-custom-lower-body-skin
>
> etc
>
> We can just use a hierarchal like list when any number of subelements. 
> The items near the top of the list appear above the other layers. This 
> way specific layer numbers aren't needed (or the viewer can 
> automatically compute them for you).
>
> Just insert an item into the list and move it up and down in layer 
> appearance priority.
>
> Glen Canaday wrote:
>> Actually, I don't mind "undies, shirt, and jacket." What I'm really 
>> referring to is maybe 3 undies layers numbered 1,2,3. Creators can 
>> still specify which of those three as they do now, but the user would 
>> choose the 1, 2, 3 bit. The creator doesn't lose the ability to 
>> choose which of the three upper layers (or two lower), so they can 
>> still specify on which layer the items would look as intended... but 
>> the user doesn't have to stick to "gee, do I wear the garter, the 
>> undies, or the tattoos? But I still want to wear the glitchpants that 
>> came with the skirt..."
>>
>> I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. 
>> There should be a limit to keep the code simple, it's just a way 
>> bigger limit!
>>
>> There are content creators that give transfer on items.. and I like 
>> it that way. There are some (ok, one that I can name) that doesn't 
>> give multiple layers because she gives them xfer, which I can 
>> understand. It all comes down to smart permissions for the next 
>> person. But that's a key issue for the creators I think.
>>
>> However, they'd still get to choose that their pants go on the pants 
>> layer - just not choose WHICH pants layer. The user would get that, 
>> and that might curb some people's bitching at the creators! Kind of a 
>> win-win imo...
>>
>> --GC
>>
>> On 03/24/2010 09:48 PM, Brent Tubbs wrote:
>>> I like this idea a lot. �While we're talking about about increasing 
>>> flexibility though, why have a low hardcoded limit to the number of 
>>> layers? �The new tattoo and alpha layers are great, but what comes 
>>> next, and how long do we keep hardcoding more specific layers? �If 
>>> someone wants to layer on ten tattoos at once, let's let them! �At 
>>> some point it makes sense to throw away the pre-defined layers and 
>>> just call them 1 through n.
>>>
>>> On the other hand, some content creators sel

Re: [opensource-dev] Open Development project: extendingavatar wearables

[Glen Canaday]

All,

If layers are to be truly arbitrary, then we would need to go all the 
way with it so that items can be sold as only 1 item and not on multiple 
layers w/ xfer. Argent's got the idea partly in one of his posts.

Of course, multiple wearables of the same type at once kind of wrecks 
the argument and it looks like everyone's got the same idea but just 
phrased it differently.

;P

--GC

On 03/25/2010 02:55 PM, Nyx Linden wrote:
> Specifying an arbitrary order in inventory that is unrelated to wearable
> type is absolutely trivial.
> The difficult part comes when you go to render your baked textures.
>
> Currently each baked texture is specified by a "layerset" which is a
> vector of texture layers in rendering order. So the upper body layerset
> is a list of layers somewhat along the lines of:
> "skin color, upper skin texture, upper tattoo, undershirt texture,
> gloves texture, shirt texture, jacket texture, upper alpha mask texture"
> which are rendered in order on top of one another to result in the baked
> texture you see on screen. Note: there are actually a *lot* more layers
> than I've listed, if you look at avatar_lad.xml for examples. Many
> texture layers have shadow layers, etc.
>
>  This gets more complicated when you allow someone to wear multiple
> shirts. I did a rather large chunk of the required refactoring last
> year, but the feature was too complicated to ship with viewer 2.0, given
> all of our other needs. The "straightforward" way to re-architect this
> layer system is to allow the "shirt" texture layer to be a meta-layer
> that contains references to all the shirt textures, in order of their
> drawing. Layer order right now is completely data-driven by the contents
> of avatar_lad.xml. The resulting code changes you can see in the
> released viewer-2 source code - look for the classes
> LLTexLayerInterface, LLTexLayerTemplate, and LLTexLayer. Each
> user-modifyable layer is replaced with a LLTexLayerTemplate which
> contains a list of LLTexLayer objects for that layer. Currently its
> limited to one LLTexLayer per LLTexLayerTemplate, but this is what the
> multiwearables project will extend.
>
>  In order to allow you to arbitrarily re-order layers, this structure
> completely breaks. Layers would need to be grouped by wearable that they
> effect, rather than what actual layer order is sepcified in
> avatar_lad.xml. The user interface also gets significantly more
> complicated, or at the very least, less intuitive.
>
>  As I stated previously, I'm not completely stuck on the current
> structure, its just one that I know I can finish and ship in the given
> timeframe. I can think of ways to re-re-architect the structure yet
> again to enable this requested functionality, but I'm not convinced to
> do so because:
>
> 1) The ultimate user interface becomes less intuitive (I'll go into more
> depth on this later)
> 2) We simply do not currently have the time to re-architect and test the
> new structure yet again.
>
> Again, if any open source developer wants to look at the code
> architecture and draw up a plan for how this can be done in a reasonable
> amount of time, I'm all ears. My current ideas on how to implement this
> would push us well out of the timeframe that we were hoping to ship this
> set of features.
>
>   -Nyx
>
>
> Carlo Wood wrote:
>
>> On Thu, Mar 25, 2010 at 01:48:39PM -0400, Nyx Linden wrote:
>>
>>  
>>> My initial answer to that request is "we don't have time to implement
>>> that right now", but I'd be happy to have a more in-depth technical
>>> discussion as to how that could be implemented in the future. If the
>>> community is able to come up with a proposed implementation where layer
>>> order is truly arbitrary, regardless of wearable type, without damaging
>>> the intuitiveness of the user interface or expanding required
>>> development time too far, I'd love to go over such a proposal.
>>>
>>>
>> This seems rather trivial... just allow one to explicitely
>> drop a wearable in any folder (ie, a shirt in a jacket folder),
>> after which you can move it up and down "as usual" (what you
>> implement right now).
>>
>> How have a new problem however: Why not allow to tuck jackets in?
>> That means: a jacket having an abitrary order related to shirts
>> and other jackets is fine, but even if it goes over all other
>> jackets, you might still want to put it below the pants.
>>
>> Since a jacket is currently the only wearable that extends over
>> two textures (apart from the new "tatoo" containing three textures,
>> and the skin, both of which kinda make sense to always be on
>> the bottom), it make sense to have, or NEED, an ordering relative
>> to pants too! After all, both pants and jackets have a lower-texture!
>>
>> For example (top layer on top):
>>
>> * jacket Y (not tucked in)
>> * jacket X (tucked in)
>>
>> Just means for the LOWER texture, this ordering:
>>
>> * jacket Y (not tucked in)
>> * pants
>> * jacket X (tucked in)

Re: [opensource-dev] Open Developmentproject: extendingavatar wearables

[Glen Canaday]

Avatar cloth doesn't just make clothing wave in the breeze. Just turning 
it on and flying. It makes your butt wave in the breeze, too.

--GC

On 03/25/2010 01:55 PM, Nyx Linden wrote:
>  There is the "avatar cloth" graphics setting in preferences (if you
> enable advanced preferences). Though the effect appears to be subtle and
> not used for terribly much. There is certainly the possibility to extend
> this functionality to be more explicit and improve it to be better, but
> I believe its primarily making "loose" clothing flutter in the wind a
> bit. Causing clothing to react to objects outside the avatar itself
> (attachments, ground, objects in the world) is a *much* more complex
> problem however.
>
>  This is a good feature request, and directly related to avatars, but
> my todo list is quickly growing beyond what I think I can reasonably
> accomplish. If any open source devs want to take this on as a project,
> I'd be happy to provide what support I can, but this will go on my "nice
> to have someday" list for now.
>
>   -Nyx
>
> Carlo Wood wrote:
>
>> OMG yes! Especially if THAT flexi doesn't "pass through" the avatar!
>>
>> How great wouldn't it be to have flexies (which are client side)
>> that respect other things around them, like avatars, ground,
>> and even other prims, and won't pass through them but rather
>> fold around them! (You could make this a custom Graphics settings
>> that is only on in "Ultra" for all I care, it would just be
>> great if it existed!)
>>
>> On Fri, Mar 26, 2010 at 04:47:47AM +1100, Jonathan Bishop wrote:
>>
>>  
>>> If its extra awesome we are after...any chance of eliminating the need for
>>> half the prim skirts and capes by adding a flexi-layer mode to the
>>> layer...So the clothes can flutter and maybe stretch in the wind?
>>>
>>>
>>
>>  
> ___
> 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] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?

[Glen Canaday]

zOmg ty. I know have my first wearable html prim object project. I 
couldn't think of a *use* for that!!

--GC

On 03/26/2010 04:29 AM, Lance Corrimal wrote:
> Am Mittwoch, 24. März 2010 23:58:39 schrieb Tayra Dagostino:
>
>> On Mon, 8 Mar 2010 09:39:00 +0100
>>
>> Lance Corrimal  wrote:
>>  
>>> Anyways, shouldn't SLPlugin exit when it is done doing what it
>>> thought it should be doing?
>>>
>> installed and configured Pulseaudio
>> now only ONE SLPlugin thread executed, with very low processor
>> usage.
>>  
> ok, switched to pulse audio here...
>
>
> ...after some serious KDE related headache it works now, and with way less
> trouble in SL tan last time i tried, at least as far as sound quality goes.
> except that it didn't really help with the SLPlugin issues. Still more than
> one running at times, eating CPU like crazy, and loads of errors...
>
> sometimes i get "no plugin for the mimetype none/none", sometimes i get popups
> _outside_ sl from flashplayer complaining about a "script is slowing down
> adobe flash player"...
>
>
> I'm still not convinced about any benefits of that slplugin architecture.
>
> besides... fully interactive HTML on a worn prim?
>
> ... any of you guys still remember those sandwichboard advertizing guys in the
> streets? When will we see the first one in SL,  offering you to play mafia
> wars in-world?
>
> ... or how about a prim that for all intentions seems to present the login
> page on the SL website, but of course it is not hosted on secondlife.com at
> all, instead it's from somewhere in asia? how many newbies will fall for that
> &  end up with an emptied credit card?
>
>
> bye,
> LC
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

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

Re: [opensource-dev] SL2 font problem on linux

[Glen Canaday]

Oh, wow. I guess I'll be remembering this one. I had no idea on it.

--GC

On 03/29/2010 02:44 PM, Tayra Dagostino wrote:
> On Mon, 29 Mar 2010 16:58:30 +0100
> Tofu Linden  wrote:
>
>
>> On your system it's trying to load 103 system fonts for full unicode
>> coverage (on my system it's 43 fonts, which also seems huge so I
>> never dreamed of testing with 100+).
>> Not a huge problem in itself, but the current font system is hugely
>> wasteful of resources and Linux's font autoprobing can return
>> arbitrarily long lists of fonts.
>> In the longer term I'd like to make the font system more efficient
>> (it's currently loading each of these fonts... multiple times each,
>> for various sizes and styles :( ) but in the short term for Viewer2
>> I'll limit the fallback font list to something like the top 20 most
>> useful system fonts.
>> Thanks for the report!
>>  
> removed quite all fonts, now i have less than 64 fonts... SL2 works
> (58 font installed)
> ___
> 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] SnowGlobe 2.0 Linux build status?

[Glen Canaday]

I can build it on ubuntu 9.10, but I don't know why it's not up. There 
are a couple of crazy things in the build (build type release... uh... 
relwithdebinfo you mean? haha), but it works.


--GC

On 03/31/2010 06:02 PM, Ricky wrote:

What is the current status of the Linux binaries for SnowGlobe?

I've been checking the wiki page ( 
http://wiki.secondlife.com/wiki/Snowglobe ) regularly, but nothing has 
shown up. The main Viewer 2.0 has Linux binaries, but SnowGlobe 2.0 
(apparently the same code at the moment,) doesn't...


Just pinging...

Ricky
Cron Stardust


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

[Glen Canaday]

They won't accept viewer developers because the viewer is GPL and they 
want to be absolutely sure that only BSD code gets in. If the viewer 
code weren't virally licensed (as the GPL is), they'd probably be more 
than happy to accept viewer-developer patches. Geeked as all get-out, 
I'd imagine. It's the same reason why they will not accept patches from 
anyone who is known to have seen the LL server code. They can't be sure 
there's no LL-proprietary licensing stuff going on. See this: 
http://opensimulator.org/wiki/Contributions_Policy

... all of which I can completely understand.

It's a good thing I haven't had time to view the code itself so I'm 
still open to choose a project. Though I *HAVE* decided that I will not 
work on a TPV... it's Snowglobe if it's going to be anything viewer 
related. I'm actually rather surprised no one's said anything about the 
merges of GPL code into viewer-internal. That bugged me more than the 
TPV stuff.

I dunno about mono, though. I'm not too keen on learning yet another 
language. My brain's kinda full as it is and I would LOVE to branch the 
viewer into UI, rendering, network, and DB modules so that any one 
module can be upgraded at any time without any significant impact on any 
other.

--GC

On 04/02/2010 11:49 AM, Gareth Nelson wrote:
> It's a lot of work to maintain, trust me - anyway, it'd be better to
> convince the opensim team to allow viewer developers in.
>
> On Fri, Apr 2, 2010 at 4:38 PM, Argent Stonecutter
>   wrote:
>
>> Sounds like an "impure opensim" fork is needed.
>>
>> On 2010-04-02, at 08:19, Gareth Nelson wrote:
>>
>>  
>>> If these people also work on the viewer, they're banned from
>>> contributing patches to opensim
>>>
>>> On Fri, Apr 2, 2010 at 1:40 PM, 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?

[Glen Canaday]

Mmm. There are many grids, all running different server versions. All of 
the web-related stuff like the concurrency, etc., is all client-side and 
has nothing at all to do with OpenSim. It's web data and your client 
wasn't configured to look at any other web page with that data.

In short, it looks like what you saw was something akin to a very, very 
bad wireless connection. I used to have the same things in SL (ping 
times near 20 sec) before I replaced my wireless card. Physics engines 
don't work when you can't participate in the server frames! The 
particular grid you were on could have been served from crap hardware 
and connection. The upshot is that they could serve it at all, and that 
you could connect... but people (like me) often tend to bite off more 
than they can chew at times. You need a good machine and good 
connectivity in order to serve regions - which LL has invested *oodles* 
into.

--GC

On 04/04/2010 02:49 AM, 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

[opensource-dev] Soft body physics

[Glen Canaday]

Soft body physics are best implemented in a local viewer, leaving the 
rigid-body collision detection to the server, am I right in this?

--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] Soft body physics

[Glen Canaday]

I came to the same conclusion, with the exception that a lookahead for a 
collision would be helpful in the client. If they use the same physics 
engine and the client does no more than implement a collision check, I 
think it could be a good thing. I'm looking at several free physics 
engines atm and thought I would clear my thinking up some. Collisions 
with soft bodies deform the collision mesh itself so yeah it gets a 
little tricky when you split them.


--GC

On 04/07/2010 11:14 AM, Moriz Gupte wrote:
I feel you are right. Makes more sense to have it implemented client 
side for many soft body dynamic behaviors... eg cloth, hair etc...
but I think in areas where rigid body behaviors impact local soft body 
dynamics, there will be lots of timing and synch problems to deal with.
So there's where I think that perhaps all physics need to be done at 
the same site.

R

On Wed, Apr 7, 2010 at 9:03 AM, Glen Canaday <mailto:gcana...@gmail.com>> wrote:




Soft body physics are best implemented in a local viewer, leaving the
rigid-body collision detection to the server, am I right in this?

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




--
'Consider how the lilies grow. They do not labor or spin.'
Rameshsharma Ramloll PhD Research Assistant Professor Idaho State 
University, PocatelloTel: 208-282-5333

More info at http://tr.im/RRamloll



___
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] Soft body physics

[Glen Canaday]

I'm only playing with the idea. Soft-body would have to be client-side 
only. if you think your SL is laggy NOW, imagine if it were also sending 
the vertex data back and forth to the sim. That would make SL unusable. 
It's a fun idea, though... I can imagine fields of waving grass, rubber 
couches and trampolines, and well as a little bit o' jiggle when ya 
walk, ya know, jes for fun :) Prim clothes and flexi hair that actually 
drapes, etc.

I'm only dreaming it up. The client would have to anticipate collisions 
a few frames before they occur to keep it more realistic, and then the 
server would have a few server frames to report that the collision 
actually happened like it already does. No server changes in mind.

It would require that changes be made to the avatar meshes.

--GC


On 04/07/2010 07:39 PM, Jacek Antonelli wrote:
> Personally, I would keep soft body effects as purely client-side eye
> candy, without any impact on the world, like flexi prims and particles
> are today. Sending the deformation data from the server to the client,
> or vice versa, would be very bandwidth intensive, and a huge headache
> to keep in sync. And some users would need to disable the feature
> altogether, because it would also be costly to process the effect.
>
> - Jacek
>
> On Wed, Apr 7, 2010 at 2:48 PM, Glen Canaday  wrote:
>
>> I came to the same conclusion, with the exception that a lookahead for a
>> collision would be helpful in the client. If they use the same physics
>> engine and the client does no more than implement a collision check, I think
>> it could be a good thing. I'm looking at several free physics engines atm
>> and thought I would clear my thinking up some. Collisions with soft bodies
>> deform the collision mesh itself so yeah it gets a little tricky when you
>> split them.
>>
>> --GC
>>
>> On 04/07/2010 11:14 AM, Moriz Gupte wrote:
>>
>> I feel you are right. Makes more sense to have it implemented client side
>> for many soft body dynamic behaviors... eg cloth, hair etc...
>> but I think in areas where rigid body behaviors impact local soft body
>> dynamics, there will be lots of timing and synch problems to deal with.
>> So there's where I think that perhaps all physics need to be done at the
>> same site.
>> R
>>
>> On Wed, Apr 7, 2010 at 9:03 AM, Glen Canaday  wrote:
>>  
>>>
>>> Soft body physics are best implemented in a local viewer, leaving the
>>> rigid-body collision detection to the server, am I right in this?
>>>
>>> --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
>>>
>>
>>
>> --
>> 'Consider how the lilies grow. They do not labor or spin.'
>> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State
>> University, PocatelloTel: 208-282-5333
>> More info at http://tr.im/RRamloll
>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>  

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

[opensource-dev] Another crazy idea... what list for this one?

[Glen Canaday]

What would the appropriate list for this be? I'm pretty sure it's not 
this one,

Anyone know of a flash desktop exporter? For two-way web interaction 
with your own desktop? Killer app for shared media... using your own 
computer! ;)

I've thought of perhaps a web-based desktop environment to render / 
export my X display to my web server with which I can then interact and 
work while logged into SL. Perhaps a buffer program that captures the X 
drawables and hands them to a flash app for web-based display. Imagine 
remote server admin possibilities, etc... not having to minimize SL to 
check job progress; share the desktop as if you were in the same room. 
Devs could literally be looking at a desktop thousands of miles away 
like gotomeeting, watching the same compile messages fly by, using the 
same primary display from inworld without the hassle of the software 
incompatibilities that gotomeeting and ultravnc have beyond running the 
exporter itself. Export a second desktop or stretch it across two 
shared-media prims like dual monitor setups in RL. The virtual workplace 
redefined. Office in your underwear, 'cept your av is wearing the ugly, 
ill-fitting business suit your boss likes.

--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] Soft body physics

[Glen Canaday]

Soft-body would have to be client-side only. There's no way I'd want 
that much data going across my net connection for every single frame. 
Neither I nor LL has that kind of collective bandwidth. I don't know if 
the server just reports a rigid-body collision or if it warns of 
impending collisions... though now that I think about it, it probably 
doesn't matter.

Vac-forming can be done in Maya I know. Unsure about anything else. I'm 
pretty confident Blender can do it.

On 04/08/2010 07:04 PM, Dale Mahalko wrote:
> Can you point to anything in 3D animation that already does this sort
> of thing? I don't think it exists.
>
> The idea sounds reminiscent of an idea I posted on this list a few
> years ago, wrapping a sculptie mesh around a collection of prims and
> "deflating" the mesh until its vertices form-fit the prims within,
> sort of like vacuum-forming with plastic, to quickly make a multiprim
> object into a single sculptie.
>
> ,
>
> Sending raw soft-mesh vertex points to the client to accurately show
> the soft mesh shape would likely be far too slow. A simple mesh can
> contain a few hundred points, each with X/Y/Z coordinates, and these
> must all be adjusted for each new "frame" of the 3D renderer.
>
> You would probably have to simplify and generalize the soft body
> modeling to make it fast enough for a slow network connection, and
> leave the actual modeling up to the local computer. Define general
> static forces that pin the mesh around its edge and on its surface,
> such as the flattening buttons like on chair cushions. To "inflate"
> the mesh into a bun or balloon, assign a general direction of billow.
> And if desired, also adjust the elasticity of the rays linking
> vertices together to tighten up or loosen the overall shape, such as
> along seams on pillows..
>
> To deform the mesh the server only sends a force and a 3D impression
> shape to the client, such as a sphere X meters in diameter pressing
> into the mesh surface with Y newtons of force. The client then uses
> that simple data in combination with the defined static forces to
> dynamically deform the soft mesh vertices, such as representing your
> avatar's feet pushing down on surface of a trampoline.
>
> Just don't ask me to program that. :-)
>
> - Dale Mahalko / Scalar Tardis
>
>
> On Wed, Apr 7, 2010 at 7:25 PM, Glen Canaday  wrote:
>
>> I can imagine fields of waving grass, rubber couches and trampolines
>>  

___
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] Semi-transparent UI, other modifications to viewer 2 UI

[Glen Canaday]

The XML file edits are good. I've used them and they work pretty well. 
But the one with the textures doesn't work so well. Half the UI (window 
frames, etc) goes completely transparent with the new texture files so 
is for the most part unusable.


--GC

On 04/11/2010 05:39 PM, Boroondas Gupte wrote:

On 04/11/2010 11:13 PM, Stickman wrote:

Nyx Linden said there was an xml file you could edit to fix this. I
don't remember getting the details on it, though. Anyone know how to
do this?
   
Looking at the wiki 
, 
it takes some different textures, too, not just an xml modification. 
But maybe Nyx knows another way?


Btw., should anything from 
https://wiki.secondlife.com/wiki/Viewer_2_Tweaks be incorporated into 
Snowglobe 2? If so, as changes to the default skin or as separate skins?


cheers
Boroondas


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


___
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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Glen Canaday]

> deal with the law enforcement people
>
Chuckle @ wording ;)

--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] Quiet amendments of TPV (again)

[Glen Canaday]

On 04/20/2010 03:41 PM, Jonathan Irvin wrote:
"4. You assume all risks, expenses, and defects of any Third-Party 
Viewers that you use. Linden Lab shall not be responsible or liable 
for any Third-Party Viewers."


That sure sounds like what you all have been wanting.  The risk is on 
the user, not so much the developer.


That sounds to me like exactly the change people wanted in the first 
place. This also means I can dive into the viewer source. I spose I 
should be gettin' on it now...


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

[opensource-dev] build errors in template classes in svn with alternative set to gcc 4.3

[Glen Canaday]

Still getting svn build errors in Ubuntu 9.10 with my gcc alternative 
set to g++4.3.

Output:

[ 4%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llcoros.o
In file included from 
/home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boost/coroutine/coroutine.hpp:44,
from 
/home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.h:39,
from 
/home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.cpp:39:
/home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boost/coroutine/detail/coroutine_impl.hpp:59:
 
error: declaration of ‘typedef class 
boost::coroutines::detail::context_base 
boost::coroutines::detail::coroutine_impl::context_base’
/home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boost/coroutine/detail/context_base.hpp:55:
 
error: changes meaning of ‘context_base’ from ‘class 
boost::coroutines::detail::context_base’
make[2]: *** [llcommon/CMakeFiles/llcommon.dir/llcoros.o] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2
g...@glen-desktop:~/Programs/SL_BUILD/snowglobe/trunk/indra/viewer-linux-i686-relwithdebinfo$
 


Any idea y'all? This is from a straight svn co. This works in the 
tarball, but hasn't yet with svn. I was hoping for all the 2.0.1 stuff.. 
I assumed it would have been checked in here as well.

--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] build errors in template classes in svn with alternative set to gcc 4.3

[Glen Canaday]

Thanks, Thickbrick. Patch applied and compilation gets past that now. 
Lynx's patch should get applied to svn.

--GC

On 04/24/2010 07:50 AM, Thickbrick Sleaford wrote:
> On Saturday 24 April 2010 04:03:24 Glen Canaday wrote:
>
>> Still getting svn build errors in Ubuntu 9.10 with my gcc alternative
>> set to g++4.3.
>>
>> Output:
>>
>> [ 4%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llcoros.o
>> In file included from
>> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
>> st/coroutine/coroutine.hpp:44, from
>> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.h:39,
>> from
>> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.cpp:39:
>> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
>> st/coroutine/detail/coroutine_impl.hpp:59: error: declaration of ‘typedef
>>   class
>> boost::coroutines::detail::context_base
>> boost::coroutines::detail::coroutine_impl> ContextImpl>::context_base’
>> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
>> st/coroutine/detail/context_base.hpp:55: error: changes meaning of
>>   ‘context_base’ from ‘class
>> boost::coroutines::detail::context_base’
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/llcoros.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>> g...@glen-desktop:~/Programs/SL_BUILD/snowglobe/trunk/indra/viewer-linux-i6
>> 86-relwithdebinfo$
>>
>>  
> This looks like SNOW-505. There is a small patch for this in JIRA that was
> posted to this list a few weeks ago by Lynx Linden. I think this is only a
> problem in gcc>=4.3, but not sure. We can't commit this to svn, since this is
> in the prepackaged boost library.
>
> http://jira.secondlife.com/browse/SNOW-505
>
>

___
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] A little OT, but not *entirely*

[Glen Canaday]

Here's an odd thing - in 2.0, I'm trying to add an LM to a notice. How 
do I do that when I have to drag an item from inventory to do it, which 
is in the same sidebar?

Def need an inventory floater.

/perplexed

--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] A little OT, but not *entirely*

[Glen Canaday]

AHH hidden. Really need that more obvious. Never saw it before.

*/me puts it on his list

--GC


On 04/26/2010 12:33 PM, Kuraiko Yoshikawa wrote:
> Am 26.04.2010 18:26, schrieb Glen Canaday:
>> Here's an odd thing - in 2.0, I'm trying to add an LM to a notice. How
>> do I do that when I have to drag an item from inventory to do it, which
>> is in the same sidebar?
>>
>> Def need an inventory floater.
> Uhm... open an inventory floater?  Press on the bottom left gear in 
> the inventory sidebar and select "New Inventory Window" ?
>

___
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] Banning by client

[Glen Canaday]

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] Banning by client

[Glen Canaday]

That's me on the list. You go in Snowglobe V2? My partner was also there 
in Emerald and did not get banned - that's why I was asking about 
client-based ban (and hence why I even brought it up on this list, even 
though it's only on topic in a very cursory way).

--GC

On 05/01/2010 12:45 AM, 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] Banning by client

[Glen Canaday]

Well OSS devs, be prepared to be banned by anyone using the redzone 
thing even when using unpatched LL svn. Sorry to spam, but this type of 
attitude is spreading, and I thought that *EVERYONE* on this list best know.

[14:54] zFire Xue: Your comming up as Community Developer
[14:55] zFire Xue: which is an open source viewer that someone has made 
into a copybot viewer.  Yours might not have been, but it reads just 
like one that is
[14:55] GC Continental: which is a false positive
[14:56] zFire Xue: It isnt snowglobe
[14:56] zFire Xue: and its a known copybot
[14:56] zFire Xue: So Im confused about the falseness part
[14:56] GC Continental: it is snowglobe. This is unpatched source.
[14:57] GC Continental: anything not on the TPV list as of yesterday 
can't connect to the grid at all. This one does.
[14:58] GC Continental: someone may have altered the sources on their 
personal viewers, but the svn of anowglobe isn't a copying viewer
[15:00] zFire Xue: Ok, I have 3 people with your same signature.
[15:00] zFire Xue: I have 2884 with snowglobe signatures
[15:01] GC Continental: 'd suggest you hop onto the opensource-dev 
mailing list... there has to be a better way of detecting.
[15:03] GC Continental: If there is, that's going to be the best place 
to has it out. There are a few people on there you'd want to be in 
contact with, such as Marine and most of the  Emerald crew.
[15:03] GC Continental: as well as meroiv, rob, and Q linden
[15:04] GC Continental: (I can't type today)
[15:04] zFire Xue: I have no interest in being in contact with any of them.
[15:05] zFire Xue: I will get a copy of Linux snowglob and test.
[15:05] GC Continental: Compile it yourself - use the svn sources
[15:05] zFire Xue: but being that I have IDed Snowglobe over 2800 times 
with the system, and then there is you, and 2 others... it doesnt look 
good that you are such a rare exception.
[15:06] GC Continental: You'll have the same viewer I have.
[15:06] zFire Xue: That explains how someone may have made a copybot out 
of it.
[15:07] GC Continental: Copybot came out before the sources were 
released. Nov 2006.
[15:08] GC Continental: I'll forward it to the dev list. Thank you for 
your time.

--GC

On 05/01/2010 04:35 PM, Thickbrick Sleaford wrote:
> I don't know if this store is (badly) detecting client versions/channels
> through the media plugins' user agent strings, or if it's just that I didn't
> move enough for their taste after teleporting. I went there with my test alt,
> using Snowglobe 2.0.0 () Apr 22 2010 00:11:09 (CommunityDeveloper) on
> linux, and was banned and ejected after a couple of minutes:
>
> [13:14] Second Life: You have been teleported home by the object 'zF RedZone
> v3.2.3' on the parcel 'Furniture and Prefabs @ The Loft II'.
> [13:14] zF RedZone v3.2.3: You have been removed for using copybot.
>
>
> On Saturday 01 May 2010 22:20:26 Glen Canaday wrote:
>
>> That's me on the list. You go in Snowglobe V2? My partner was also there
>> in Emerald and did not get banned - that's why I was asking about
>> client-based ban (and hence why I even brought it up on this list, even
>> though it's only on topic in a very cursory way).
>>
>> --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] Banning by client

[Glen Canaday]

EDIT:

The rest of the conversation was actually very gracious. I do expect his 
product not to be the only one to provide false positives.

He is checking into it to see how it could be changed to properly detect 
unchanged clients - after now, it's likely going to be th beta grid for 
any testing.

--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] Banning by client

[Glen Canaday]

Me too, but I don't think it's against TOS. A sim owner can do what a 
sim owner wants, and if it's to trust client/copybot detection to an 
inworld device they didn't make themselves, that's not against the rules 
afaik. Of course, I'm completely unaware of any method that's not going 
to result in false positives.

I'm just posting this because I have the feeling that it's going to 
become far more commonplace, and this is the group of people that it's 
going to affect the most.

So it's Emerald in the main grid for me, with my own clients on OpenSim 
or the beta grid from here on out.

Though WHY anyone wouldn't want to come HERE to talk about client 
detection is far beyond my grasp. That's like AVG not wanting to talk to 
Microsoft.

--GC

On 05/01/2010 06:42 PM, Robert Martin wrote:
> On Sat, May 1, 2010 at 6:09 PM, Glen Canaday  wrote:
>
>> [15:05] GC Continental: Compile it yourself - use the svn sources
>> [15:05] zFire Xue: but being that I have IDed Snowglobe over 2800 times
>> with the system, and then there is you, and 2 others... it doesnt look
>> good that you are such a rare exception.
>> [15:06] GC Continental: You'll have the same viewer I have.
>> [15:06] zFire Xue: That explains how someone may have made a copybot out
>> of it.
>>  
> and most of the reason for the rarity is that most folks can't seem to
> get a from source compile to actually work much less getting a SVN
> copy to work.
> Personally i think that any kind of ban by viewer signature device
> should be banned (outside of a Linden Lab built item).
>
>

___
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

[Glen Canaday]

My mistake. I was under the impression that anything not on the list 
wasn't supposed to be able to get on agni. I must have read it wrong.

--GC

On 05/01/2010 09:50 PM, Maya Remblai wrote:
> 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
>

___
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] Introduction

[Glen Canaday]

Mornin, east-coaster!

--GC

On 05/18/2010 04:46 PM, Oz Linden (Scott Lawrence) wrote:
> This is just a quick note to introduce myself - I'm Scott Lawrence, and
> this week I've become Oz Linden.  I've just started at Linden Lab as the
> Director of Open Development.
>
> I'm a long time open source user and developer - for the last ~7 years
> I've been leading the sipXecs SIP PBX project
> 
>
> My new role here is to expand and improve the open source viewer
> program.  I hope to get to know most of you well, and to hear your
> thoughts on how Linden Lab and the open source community can work better
> together.
>
> I'm also heading up the Applied Engineering team with the mission of
> making our sustaining activities for the viewer even more responsive to
> the needs of our Residents, and I hope that part of that will be
> achieved by accelerating the incorporation of the good work of open
> source contributors.
>
> I'm based in the Boston office, which will give you some idea of when
> I'm most likely to be awake.
>
> I am very much aware that I've taken on a big job, and that there's much
> to do - I'm going to be looking to you to help me set my agenda.  Please
> understand that I'm sending this note on my second day as an employee -
> I have not yet finished all my new-hire paperwork, and it will take me
> some time to get up to speed; please bear with me.
>
> Outside work, I play billiards in the APA,
> and ride my electric skateboard (if you've got a Facebook account, you
> can see a very short ride
> ). (I rode it
> today from the train station to the office).
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

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

[opensource-dev] icesphere

[Glen Canaday]

icesphere looks really interesting... anyone try it? looks like a pain 
to get started.

--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] Migrating open development focus to 2.x

[Glen Canaday]

Basically, I think the group as a whole likes much of what was done, but 
that making the real changes to the UI itself don't exactly seem a 
less-than-herculean task. So, if we were to remove the sidebar, will LL 
keep it gone? If themability gets added, and people spend the time it 
takes to make a set of really good themes, will LL keep it, or will that 
viewer be kept on the sidelines as a 3rd party viewer? I don't know 
about anyone else, but I'm not personally interested in working on a TPV 
that guarantees I'll be banned and ejected by people checking the 
channel my viewer uses.

--GC


On 05/27/2010 05:50 PM, Oz Linden (Scott Lawrence) wrote:
> I opened this in the 27 May IW open source meeting, and would like to
> invite wider and more specific feedback.
>
> It's fairly clear that Linden Lab doesn't have the resources to devote
> to active work on both Snowglobe 1.x and 2.x, and it's not efficient for
> the community as a whole to be splitting effort.
>
> I'd like to fairly quickly get to the point where all our new work is
> happening on the 2.x branch.  That said, I understand that might leave
> behind things that the Snowglobe user/dev base wants and that some
> people are not happy with some elements of 2.x.  What I'd like to know
> is... what needs to happen to make that choice that most people can be
> happy with?
>
> One of my goals is to increase the rate and volume at which Linden Lab
> can (and _does_) take changes from the open source base into the
> internal code, but unless we can keep everyone on the same branch, that
> will be much more difficult.
>
> Please respond to this thread with your favorite reasons not to move
> development to 2.x.   We will review the list at the 6 June open source
> meeting with the goal of setting some priorities.
>
>
>
> To be clear... I don't object to anyone else working on 1.x at all; I'd
> just like to know why so that we can tempt them to join us on 2.x
>
> ___
> 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

[Glen Canaday]

This does sound much better than the previous way of doing things - more
open and closer to the Bazaar, etc., but I want to ask how it came
about. What was the impetus? Is this a direct result of Phil's return to
more active involvement with LL in general? Is it simply the desire of
the devs added to opportunity and freedom thus made into reality?

--GC

On Sun, 2010-08-15 at 12:25 -0400, Oz Linden (Scott Lawrence) wrote:
> 
> 
> What’s Next For The Second Life Viewer?
> Linden Lab spent the better part of the last two years revamping the
> Second Life Viewer to create Viewer 2. Some of the changes were
> important new features, and some were controversial - some were both.
> The bulk of the design and engineering work was done with only
> limited, indirect participation from the open source and resident
> communities, which has left many in those communities feeling
> alienated and disenfranchised. 
> In recent months we have released both Viewer 2 and a 2.1 update;
> Linden Lab has also been through a major reorganization. We are now
> evaluating the results of all of this work, and we are making
> significant changes to the way we design and build the viewer.
> 
> Introducing Snowstorm 
> Linden Lab has created a new team whose goal is to develop the Second
> Life Viewer in the open and in response to the needs of our Residents.
> Here are our goals:
>   * Show Residents continuous visible progress
>   * Work in the open by sharing not only our code, but our
> process publicly -- this includes our backlog and our
> discussion about it.
>   * Engage with the open source community and aggressively
> accept good work the community does into our product.
>   * Release new ‘Development’ Viewers frequently -- our
> initial target is bi-weekly.  All builds from the
> ‘Development’ branch are visible and available for
> testing. 
>   * Improve the user experience
>   * Make continuous improvements to the design and
> implementation of the Viewer’s user interface.
>   * Import desirable patches and features from Snowglobe
> and other Third Party Viewers.
>   * Add small features and fixes that have high value and
> low cost, while still remaining consistent with an
> overall product vision.
>   * Renew and deepen our relationship with the community
>   * Integrate community work directly into our main line
> Viewer rather than routing it through Snowglobe
> first. 
>   * Demonstrate rapid responsiveness to feedback and
> patches from community.
>   * Engage continuously with the community to develop new
> project proposals and provide resources that open
> source developers need to be effective.
> 
> 
> How Snowstorm Works
>   * Viewer development has moved to a single open source model
>   * There are no longer internal ‘private’ and external
> ‘public’ versions. Viewer source (with the exception
> of one wrapper library we cannot legally release), is
> now in public Mercurial source repositories. All
> viewer integration is happening in the Development
> repository at
> ‘http://hg.secondlife.com/viewer-development’. It is
> used by all Linden Lab viewer development teams, and
> open source developers are encouraged to pull from
> that repository and submit changes for integration to
> it.
>   * Code in the Development repository is now released under
> version 2 of the GNU LGPL
> 
> This allows community developers greater freedom to use the viewer
> code, including incorporating it into products that also include
> closed source.
> 
>   * Accepted contributions go directly into the official Second
> Life Viewer
> 
> There is no longer a two-step process of contributing to Snowglobe and
> then hoping that the contribution is imported to the Linden viewer.
> Viewer development efforts within Linden Lab go through the same
> integration queue and into the same repository that open source
> contributions use.
> 
>   * Innovations from Snowglobe are being imported to this new
> viewer
>   * Some changes may be left behind or modified in order
> to fit into Viewer 2; Linden Lab will work with open
> source contributors to harmonize contributions with
> the product goals of the Linden viewer. The plan is to
> import as much as possible of the excellent work that
> has been done in Snowglobe as quickly as possible
> (this rate does depend on help fro

Re: [opensource-dev] Removal of the "MultipleAttachments" debug settings ?

[Glen Canaday]

Been over that and over that on the list. The only way to get that taken
care of is to fix it ourselves and have LL merge it in. I'd do it if I
were 'up to the task' but anyone who does do it just needs to remember
to have it set up as a pref setting.

Gamers like it broken like it is now, people who SOCIALIZE here (since
SL is, in fact, *not* a game... ahem) like it broken the way it's
historically been.

Either way, it's broken for someone. Just need the check box for "b0rken
other way".

--GC

On Tue, 2010-08-31 at 12:24 +0200, Francesco Rabbi wrote:
> Il giorno 31/ago/2010, alle ore 12:11, Argent Stonecutter
>  ha scritto:
> 
> > On 2010-08-30, at 15:39, Suz Dollar wrote:
> >> *cough* If the point of this is to make people *want* 2.x a lot of
> >> nice tags that say 'to see me properly, use viewer 2.x... I have more
> >> attachments than you do' might be a good way to go.
> >
> > If I can't talk without jumping I'm not going to go to V2 no matter how 
> > many attachment points it has.
> 
> 
> Yes Focus should be fixed...
> 
> 
> 


___
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] Removal of the "MultipleAttachments" debug settings ?

[Glen Canaday]

People on this list got pretty vitriolic about it only a few months ago
- I was under the impression the gamers wanted it the way it is.

Where was this ever a pref setting? I don't recall ever seeing it.

--GC

On Wed, 2010-09-01 at 06:09 -0500, Argent Stonecutter wrote:
> On 2010-08-31, at 22:40, Glen Canaday wrote:
> > Gamers like it broken like it is now, people who SOCIALIZE here (since
> > SL is, in fact, *not* a game... ahem) like it broken the way it's
> > historically been.
> 
> It wasn't broken historically: it was a prefs setting.
> 
> Also, gamers don't like it the way it is, seems like they want to completely 
> lose the chat bar on hitting enter:
> 
> http://jira.secondlife.com/browse/VWR-18323
> 
> The current behavior doesn't work well for either camp.


___
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] Plugins/Modular architecture

[Glen Canaday]

This is the project I've started 50 times and never got further than
"YES! It compiles on all platforms! ...just.. need... everything. else."

Since it's LGPL now, we can make a modular plugin-based viewer that uses
LL's code as a starting point, and even incorporate BSD-licensed bits...
just convert all of the relevant sections of code into loadable libs
with a built-in that manages all of the plugin data centrally. That way
you can load and unload things like UIs and renderers on the fly without
ever logging out, and you can also include cool new things like "local
data" on your own computer, thus, if desired, having an integrated
desktop<->inworld presence.

Like I said... 50 times, never got further than the first sentence. Too
much work and not enough single geek. I had even named it "GROND" after
Sauron's battering ram.

Had trouble turning it into an acronym, though... "Generic Reusable
Omnipotent Networking Disaster," anyone?

--GC

On Fri, 2010-09-03 at 09:32 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-09-03 9:14, Lawson English wrote:
> >On 9/2/10 8:13 AM, Talia Tokugawa wrote:
> >> [...]
> >> I know this has been suggested before as friends have suggested it.
> >> Why not make the viewer more Modular? Introduce a plugin architecture.
> >> Allow any user to "build" their own client that fits their needs and
> >> requirements.
> >>
> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue
> > directly years ago and they probably don't have the resources to do it
> > now. It would have to be a community-lead effort and I'm not sure that
> > developers are willing to invest the time to refactor the viewer at that
> > level unless LL will be willing to seriously consider using the
> > resulting re-architectured viewer.
> 
> Try us...
> 
> ___
> 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] Plugins/Modular architecture

[Glen Canaday]

> 
> this is why now all code is public and following few step you can
> contribute all code you want... a optional switchable theme/UI/XUI can
> be merged giving to all residents the freedom to choose the aspect on
> monitor (viewer 1.x style too).
> 
> Is hard take LL base code, patch it, merge a LL-next-version to fit
> newfeatures and patch again everything, i think this way to work is
> great why all can fit a features (a single click in setup panel
> enable/disable it maybe...) without care to merge everytime a new
> features will be implemented by LL

Like I said... lots of ideas, but not enough geek nor enough singlehood
to commit as much time to this kind of thing as it would need. It's like
looking through the window at some Shiny Animal you might be able to buy
and dearly want, but you could never afford to feed and you know it. It
makes me sad, heh.

The base idea for the GROND project was only a plugin manager,
memory/data manager, and these basic plugins:

1. A UI plugin. Allows for hot-loading a UI and handles all human I/O
that isn't related to rendering or audio.

2. A viewer plugin. Allows for hot-loading renderers since all scene
information is maintained by the data manager and not the renderer
library.

3. A protocol plugin. Would allow for protocol upgrades to occur on a
per-grid basis.Each grid could provide a plugin or just a protocol spec
to handle their own grid's communications needs, so that things like SL
2's incompatibility with OpenSim doesn't have to happen again. That was
a HUGE pain trying to get used to 2.0 on my own grid... it just didn't
work.

Some extras I came up with were:

1. An audio plugin. This plugin could handle all audio input and output
to and from the viewer. This would permit the use of voice (VOIP)
technology as well as play inworld sounds and streaming. Doesn't have to
only be audio, could be a "direct gstreamer" plugin. If it ate too much
bandwidth, it could be unloaded by the user or just self-throttled.

2. A client-side physics plugin. This plugin would handle all soft-body
physics to be displayed by the viewer. Note that all rigid-body physics
must be simulated on the server, with the collisions only reported to
the client. If it ate too much processor, it could be disabled.

3. A local filesystem plugin. This one's cool. Upload / download from
within an inworld object or from your own inventory - which could
display your own local filesystem as well as your inworld inventory.

This kind of thing could easily evolve into the first viable 3D desktop
that could also integrate emerging web technologies and do it completely
transparently.

But like has been said, it's HUGE. There's no WAY I could devote enough
time to it. It's the next Mosaic, and LL's already written the first
versions of all of the most important parts.

--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] Plugins/Modular architecture

[Glen Canaday]

On Sat, 2010-09-04 at 13:28 +0100, Talia Tokugawa wrote:
> Well this is taking things quite a bit further than I envisioned for
> this. What Glen is suggesting here seems more like having stuff like
> java and flash installed for a browser.

Actually, nowhere near that! That's what people on the list seem to be
thinking of. What I've been thinking of for months is far more radical.
A browser can't change out its rendering engine or parser while still
connected to the website. This could and that's the idea.

What you're talking about seems much like how Maya was set up (at least
in 7.0 when I last saw it), or at least the concept. You switched entire
menu groups depending on the task (modeling, animating, etc.). You mean
switching UI styles according to skill level. Understandable... is one
of the things I was going for.

--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] Plugins/Modular architecture

[Glen Canaday]

On Sat, 2010-09-04 at 17:39 +0100, Talia Tokugawa wrote:
> Okay so this plugin talk has got me thinking.. I tend to think
> visually and wasn't sure on if this mailing list dealt with images or
> not so I just blogged the idea instead.
> http://www.talia-tokugawa.co.uk/snowstorm-plugin-concepts-calendar/
> I intend to write a series of ideas (thinking twitter plugin is next)
> 
> 
> And yes Glen.. Something like Maya, maybe not changing the entire
> interface dependant on what your working on, But the ability to bolt
> bits on so to speak and for the parts to integrate with each other. I
> guess more like plugins and scripts worked in Maya rather than the
> task dependant views. 
> As you say with the renderer. It might be cool to have the main window
> display SL as we know it now but be able to get something like an
> advanced minimap in 2d that you could plugin as a replacement for the
> default graphics engine. Something to enable people with lesser
> machines to still be able to interact with the work. As the text based
> viewer have shown in the past it's perfectly feasible for people to
> interact with SL with minimal graphical fluff. 
> Tal

lol... ASCII-art renderer plugin, anyone? ;P

http://aa-project.sourceforge.net/
http://www.jfedor.org/aaquake2/
http://n00n.free.fr/aatv/


These SO make my day. Oh hey - this also solves the alpha z sorting
problems too, doesn't 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] Chat issues

[Glen Canaday]

Try editing a notecard and type past the edge. I've only seen it once
and im not in a position where I can report it atm, but it could be
related to what you're seeing.

In the notecard I get screwed up text.

--GC

On Wed, 2010-09-08 at 20:15 +0100, Talia Tokugawa wrote:
> Hey, is this just me?
> In Snowstorm every so often in chat the last character on a line of
> text is replaced by a space.
> Specific example here..
> 
> 
> What I see is
> [12:06]  Nerd: got my vot
> 
> 
> everyone else sees
> [12:06]  Nerd: got my vote
> 
> 
> I can also copy the line of text and paste it and it will be "vote"
> not "vot". It's literally just what I see that's wrong.
> Tal
> ___
> 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] The Plan for Snowglobe

[Glen Canaday]

On Sat, 2010-09-11 at 17:39 +0200, Michael Schlenker wrote:
> Am 11.09.2010 um 17:31 schrieb Zi Ree:
> 
> > Am Samstag 11 September 2010 17:22:33 schrieb dilly dobbs:
> > 
> >> it more like a game with a limited number of opening/learning the interface
> >> 'quests' so to speak.  There has to be some way to keep all of the sign
> >> ups.
> > 
> > The old orientation islands had all this. It never really worked out.

I'll bite, lol.

How about - bringing a REWARD to the end of the quest! Say, L$10 bonus?
If an account is not logged into more than once in the first 30 days,
delete it and reclaim any of the awarded bonus cash?

> > 
> And they failed miserably. I was stuck on one of those for a few hours till i 
> found out how to TP away
> from orientation island. And it took the help of Torleys Videos to find out 
> how to open
> the freebie boxes.
> 
> In fact, the orientation island nearly succeeded in keeping me from ever 
> logging in again. 
> I was just determined enough to get past it.
> 
> Michael

I'd heard "you can make real money doing this." It was stories of Anshe
Chung in the press and SL coverage on slashdot that got me to try it out
in the first place. I'd wanted to make something like SL years ago when
I was still in school (early 90's) but didn't have the power or the
knowledge to go after it.

What KEPT me in it was the ability to create and to script. I wonder
what the percentage of REAL n00bs trying this out is now? And for that
matter, does the far higher quality of inworld merchandise and builds
compared to 4 years ago have anything to do with the discouragement?
Back then, EVERYTHING kind of sucked, even the things that were cool,
compared to how they are now. We might have too many professionals and
the bar may be set far higher than it used to be.

We'll never get the "gamers." SL's UI and rendering engine aren't
specific enough to any given look and feel so it can never match the
inworld content, and other than its superficial resemblance, it's just
not a game. There used to be a very high geek and DIY quotient in the
resident pool. I get the feeling there just aren't that many left.

--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] User Story: Improved Cache

[Glen Canaday]

> > * Let the local operating system deal with the file caching. If you
> > have 4+ gig of system memory, let the OS manage it for caching
> > frequently accessed world data.
> 
> if i have 4+GB i use a ramdisk as cache... XD
> 

Wow. I am getting VERY old and senile. WHY oh why I didn't think of
this, I don't know - I used to use them all the time for other things
that needed fast file access.

--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] Lindens way ahead of us

[Glen Canaday]

I disagree - it's not that great. Full client-side softbody with Bullet
would be better to do. Add a few sliders for "softness" in the av
appearance dialog (while upgrading the base mesh to support this) and
there we really are... the whole shebang with a lot less real effort.
>From there all would be needed is to supply new meshes and that's it.

Speaking of meshes... stick me on the test0r list? I suck at sculpties
and I'll be real good and promise not tell peepul about it...? ;) lol

--GC

On Mon, 2010-09-27 at 05:29 -0300, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> If we indeed are getting individual breast jiggle settings, that is a
> great move by LL, i had already proposed a way for Emerald users to have
> individual settings some time ago (embedding the parameters in the baked
> texture or one of the unused clothing layers, apparently it ended up
> being a similar approach to the infamous encrypted installation folder
> string that they turned out to leaking), but at the time they didn't
> seem much interested in the idea (and lots of people were making drama
> over not being able to make everyone go Baywatch run or wear a concrete
> bra anymore)
> 
> The icing on the cake will be if LL also adds butt jiggle (and even
> better if also we get gut, arm flabs, face cheeks etc jiggle settings as
> well)
> 
> On 27/9/2010 04:55, Harold Brown wrote:
> > I doubt this is a personal build as this implements a new wearable
> > "physics" item.  From the cursory glance through the source changes this
> > appears to allow for each Avatar to have their own personal breast
> > physics setting.
> > 
> > On Sun, Sep 26, 2010 at 11:11 PM, miss c  > > wrote:
> > 
> > yep that's why I said this 
> > 
> > 
> > 
> > Before it turns into an even bigger debate.  First, I assumed that
> > viewcontrol meant rlv since it was directly under breastphysics, I
> > do not know what the viewercontrol code is for.  Secondly this could
> > be Oz's personal build for himself XD.  It does say it was merged
> > with the latest viewer, but its not here in the code, no breast
> > physics period.
> > 
> > 
> > ...I am just combing the code and changes to work on UI
> > customization.  I was trying to  locate change notes for the dev
> > release when I ran across it.
> > 
> > 
> > *From:* Zabb65 mailto:zab...@gmail.com>>
> > *To:* miss c mailto:miss_c...@yahoo.com>>
> > *Cc:* opensource-dev@lists.secondlife.com
> > 
> > *Sent:* Mon, September 27, 2010 1:00:48 AM
> > 
> > *Subject:* Re: [opensource-dev] Lindens way ahead of us
> > 
> > llviewercontrol.h is the header that allows access to saved settings
> > values within the viewer, and has nothing to do with RLV or any
> > other form of control over the viewer. They are simply a set of
> > saved control values in llsd xml format.
> > 
> > On Sun, Sep 26, 2010 at 22:37, miss c  > > wrote:
> > 
> > All this talk about adding these plug ins RLV and breast
> > physics plug ins were added to viewer 2 already.
> > 
> > They were just going to surprise us I suppose -.-
> > 
> > I found it here
> > http://bitbucket.org/oz_linden/test1/changeset/bbecf41db5c8
> > 
> > Quote:
> > merge avatar physics up to latest viewer-development
> > 
> > 49 
> > 
> > 
> > 
> > 
> > #include "llbreastmotion.h"
> > 
> > 49 
> > 
> > 
> > 
> > 
> > 50 
> > 
> > 
> > 
> > 
> > #include "llviewercontrol.h"
> > 
> > 
> > 
> > 
> > YAY
> > 
> > Miss
> > 
> > 
> > ___
> > 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 unmoder

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

[Glen Canaday]

On Sat, 2010-10-02 at 05:45 +1000, Tateru Nino wrote:
> 
> 
> On 2/10/2010 5:22 AM, Brian McGroarty wrote: 
> > On Fri, Oct 1, 2010 at 11:41 AM, Ponzu  wrote:
> > On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw
> >  wrote:
> >  On 01/10/2010 18:04, Ponzu wrote:
> > Nobody has crappier internet than I
> > (satellite).
> > 
> > 
> > Well, we're really talking about transfer caps,
> > here, rather than available bandwidth.
> > 
> > Available bandwidth can be appeased by the network
> > slider.  But transfer caps are the biggest problem,
> > and pretty much everyone in Australia is affected,
> > and a lot of people on the less decent ISP's in the
> > UK.
> > 
> > 
> > and me.  17GB per 30 day period, in a sliding window.
> >  
> > Point is still that caps will be increased as time goes on
> > (or decreased, as international economic system collapses,
> > but taht is a differnt sim).
> > 
> > 
> > Devs concerned about crazy-limited connections shouldn't worry about
> > the small changes that may someday come with a different image
> > CODEC. They can cut texture transfers in half -today- at the expense
> > of texture blurriness. 
> > 
> > 
> > A test should be straightforward, if anyone feels strongly enough to
> > take a whack at it. Add a "texture fidelity" slider that scales the
> > measure the viewer uses to decide what discard level it wants. See
> > where you still find it tolerable.
> > 
> I read that three times, with different reactions. After a little
> thought, though, yes. I'd _totally_ use that if it were an option.
> Right on the main UI next to a draw-distance slider.
> -- 
> Tateru Nino
> http://dwellonit.taterunino.net/

Totally seconded. That's very nice - it's almost like using fog to hide
a draw distance limit. As the human eye sees things blurrier as they get
further away, it seems like a healthy method of bandwidth capping to me.
That way they only fully load those textures that are in view and within
the slider's distance.

--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] Unity 3D as possible base for future (maybe even official) SL Viewers

[Glen Canaday]

No Linux support is a total deal-breaker for me. I really don't care how
many platforms are supported, and that includes gaming consoles, if mine
isn't. Gaming consoles are irrelevant, as SL is not a game and would not
sell at Best Buy even if it were, making that support a completely moot
point.

I don't pay for the "privilege" of using an operating system on my
hardware. Just because someone else does does not mean I (and the rest
of the Linux users in SL, including a pretty good percentage of Lindens)
should be shut out. If a commercial piece of software does not support
the entire user base and is not GPL or LGPL, then it should be off the
table completely.

If you really want to do something like this, look to Ogre instead.

--GC

On Sun, 2010-10-03 at 13:44 -0700, Daniel Smith wrote:
> 
> 
> On Sun, Oct 3, 2010 at 1:26 PM, Boroondas Gupte
>  wrote:
>  On 10/03/2010 08:57 PM, Daniel Smith wrote:
> > Consider what it would take to have a Unity foundation,
> layered with
> > the SL-specific experience on top.
> What it would take? At least Linux support for Unity.
> 
> Yep, that came up as a point on my blog, and I answered: 
> 
> Now, let’s look at the deployment platforms in Unity 3.0,
> which just came out on Monday — all of these will be available
> soon:
> 
> Mac, Windows, Web, iPhone, Android, Wii, PS3, and Xbox 360
> 
> I think that’s amazing. Don’t you? Yes, it sucks a little that
> Linux isn’t in there. … But… if there is that potential to get
> a better experience for 95% of the current users, and to open
> up a bunch of new platforms to them and new users, then my gut
> says that is the right way to go.
> 
> Also.. I would think that the current Linux viewer could maintain
> compatibility. 
> 
> -- 
> Daniel Smith - Sonoma County, California
> http://daniel.org/resume
> 
> ___
> 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] Unity 3D as possible base for future (maybe even official) SL Viewers

[Glen Canaday]

On Sun, 2010-10-03 at 15:09 -0700, Daniel Smith wrote:
> 
> 
> On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday 
> wrote:
> No Linux support is a total deal-breaker for me.
> 
> I never said anything about the Linux viewer going away.
> I note that we have Pocket Metaverse now, and have had AjaxLife in the
> past.
> If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;)
> 
> As is the case with web browsers, a VR client to the same server could
> take many forms.
> 
> Ultimately, it's about what the community wants, and if a critical
> mass of developers decides to give them that.  It doesn't have to be
> an official Linden effort at all.
> 
> All I am saying is, in 2 years time, I cant see the current codebases
> even getting to the point where Unity 3.0 is today, in terms of
> graphics, physics, animation, terrain, and sound.
> But, I could see a pretty decent SL app done in Unity within that
> amount of time.
> 
> And, of course, I am just an interested observer.  I dont speak for
> LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :)
> 
> Daniel 

It's hard to see exactly where the rendering engine will go, really, in
2 years. For a plugin-based client, as some (including myself) are
rather nudging towards, the renderer is just a part of the whole and
could in theory be hot-swapped if desired to A/B different engines. Even
if those renderers swapped between opengl and directx, it could still
fly. But to suggest that the main client perhaps go to something that
does not work across the board doesn't really include the whole of the
population - something which LL would be keen to retain.

That's why I suggested Ogre instead. I personally think it would be a
better fit and more productive to look at. Others may have different
opinions.

--GC

> -- 
> Daniel Smith - Sonoma County, California
> http://daniel.org/resume
> 


___
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] Unity 3D as possible base for future (maybe even official) SL Viewers

[Glen Canaday]

  Its rigging and control system is designed for rapid
> prototyping and higher level designig.
> 
> I would put unity as an equivilant to making a mod for
> a fps with "good" tools unlike most mod systems. 
> 
> But as a complete engine from a graphics and other
> standpoints The hero engine blows that away. Actually
> there are quite a few game engines that surpass unity.
> And if we take thoes its like compairing writing with
> QT vs flash. (not quick time... but QT).
> 
> Flash is great as a packaged thing but its limited.
> Now unity can me modified and such to some extent but
> no where whats needed for a SL type of thing. 
> 
> And for the record I am not a fan boi of any engine or
> system. But i have developed a mmo from the ground up
> in 2001 to playable alpha 2 on the cusp of beta before
> the project was shelved due to funding.
> Having written a majority of the Engine and most of
> the server code. I would thing these are subjects i am
> quite capable of assessing.
> 
> 
> 
> 
> On Sun, Oct 3, 2010 at 7:41 PM,
>  wrote:
> 
> Alright, this is the most incorrect post I have ever
> seen so I would guess you have used Unity for maybe a
> total of an one hour.
> 
>  
> 
> First of all you can use any network technology you
> like.  It does come with a very basic P2P network, but
> you can use many game server that you like included
> some that support fail over and fault tolerance
> configurations.  In fact there are those using SL’s
> server and rendering prims and sculpties in Unity.
> 
>  
> 
> The scripting language can also use C# and supports a
> way more complete set of functions then is available
> in SL.  This list is so long I don’t know where to
> start on functionality it supports that LSL doesn’t
> support.
> 
>  
> 
> Not sure your point about FPS, it has Ambers Occlusion
> culling, beast lighting and deferred lighting which
> lets it create FPS you can’t do in SL for the same
> amount of content.
> 
>  
> 
> So if you are going to comment on Unity please do your
> homework and don’t mislead people.
> 
>  
> 
> M.
> 
>  
> 
>  
>     
>  
> 
>
> __
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com]
> On Behalf Of Brandon Husbands
> Sent: Sunday, October 03, 2010 8:20 PM
> To: Robert Exile In Paradise Murphey
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Unity 3D as possible
> base for future (maybe even official) SL Viewers
> 
> 
>  
> 
> Unity is the biggest POS i have ever used 
> Not well designed. IMHO. Its like trying to do SL in
> javascript.
> Not literally but you know what i mean. 
> 
> It was never designed for a heavy network transport
> now multi player / mmo style.
> 
> A FPS maybe but nothing on a grand scale.
> 
> On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In
> Paradise" Murphey  wrote:
> 
> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote:
> > That's why I suggested Ogre instead. I pers

Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?

[Glen Canaday]

On Mon, 2010-10-04 at 13:15 -0700, Daniel Smith wrote:
> 
> Am happy to see some input on the idea of Unity.  It makes me smile.
> 
> My intent, of course, was to jolt a bit out of idea of a monolithic
> 2.x codebase.  A lot of folks want the viewer to do quite a bit (mesh
> editor, anyone?).  Fulfilling the wishlist without going to a plugin
> strategy will result in a bloated client that will run on fewer and
> fewer machines.
> 
> So if Unity is relegated to a cool TPV project somewhere, that's
> fine ;)
> Proposing something radical like that will hopefully get people to
> think more about what it would take to do a very plugin oriented
> client (can the 2.x codebase do it?  or does it call for a reset of
> sorts?)  Where do people want to see an SL client, 2 years from now?
> 
Hey, when it gets all-around support, it can come right back out of TPV
and be an option..
> 
That's where I was going with my own project. Sounds like there are
quite a few people thinking in the same direction - I like that. My
first run through, should I ever be able to get it off the ground, was
to just split up the current code base so that it would be simpler to
implement things just like this. If Unity worked better on a given
machine, then by all means use it, and the same with Ogre or Irrlicht or
the Linden engine or OSG or etc.

> I dont think much of possible approaches that dont handle the
> physics / animation / terrain / sound angles.   It's just asking to
> reinvent too many wheels.  Oh, and as for the objection to Unity
> outputting to game consoles: snap out of it.  The mere existence of
> code on a console doesn't make it a game.  The overall idea is to make
> SL / OS ubiquitous (Linux client doesnt go away, other approaches open
> up the Web, phones, and consoles.. all good moves).
> 
Oh, don't misunderstand, I've got nothing against putting it on a
console. The more platforms, the merrier. I don't know how useful the
XBox controller would be in a heavy chat environment, but to each his
own, I suppose!

--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] Enhanced Script Editor Request

[Glen Canaday]

On Wed, 2010-10-20 at 19:40 -0400, Ponzu wrote:
> Alas, so many generations of coder who learned vi from someone who
> already didn't know vi.
> 
> 
> You will note that Google's new keyboard commands are vi commands.
>  There is a reason for this.
> 

Google... has keyboard commands?

:wq , :i, :q! <---?

(loved the vi & emacs graphics! the other editors just didn't exist yet
when I started with Linux...)

--GC


> On Wed, Oct 20, 2010 at 7:23 PM, Altair Sythos 
> wrote:
> On Wed, 20 Oct 2010 16:07:31 -0700
> Ricky  wrote:
> 
> 
> > lol... That comment reminds me of this (tongue-in-cheek,)
> graphic
> > representing the learning curves for a variety of common
> editors:
> >
> 
> http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx
> 
> 
> damn awaked my wife laughing... XD
> 
> 
> ___
> 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] Enhanced Script Editor Request

[Glen Canaday]

I do sometimes wonder what happened to i, ii, iii, iv, and v, though.
Must be like that "Leonard Part 6" movie Bill Cosby did in the early
80's.

--GC

On Wed, 2010-10-20 at 19:45 -0500, Dave Booth wrote:
> On 10/20/2010 18:40, Ponzu wrote:
> > Alas, so many generations of coder who learned vi from someone who 
> > already didn't know vi.
> >
> > You will note that Google's new keyboard commands are vi commands. 
> >  There is a reason for this.
> >
> 
> same reason that most chat apps commands are IRC commands :) /me does 
> something in SL for example ...
> ___
> 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] Dynamic shadows and ATI

[Glen Canaday]

They used to be so much better... on Linux, anyway. I wonder what happened.

--GC

On Saturday, November 13, 2010 10:17:15 am Dave Booth wrote:
> On 11/13/2010 06:04, Laurent Bechir wrote:
> > Is it a hardware problem of ATI or just a software problem that can be
> > solved by SL developers ?
> 
> ATIs drivers have bugs - ATI + OpenGL FBOs = crash or render artifacts
> or both.
> ___
> 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] Dynamic shadows and ATI

[Glen Canaday]

Oh, for the record - I did have dynamic shadows working on an ATI HD2600 on 
Ubuntu 9.10. It was slow and horrible, but it worked.

I have screenshots, somewhere.

--GC

On Saturday, November 13, 2010 10:17:15 am Dave Booth wrote:
> On 11/13/2010 06:04, Laurent Bechir wrote:
> > Is it a hardware problem of ATI or just a software problem that can be
> > solved by SL developers ?
> 
> ATIs drivers have bugs - ATI + OpenGL FBOs = crash or render artifacts
> or both.
> ___
> 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