[opensource-dev] Fwd: [MediaAPI] Plugin folders and what plugins

[Opensource Obscure]

Is MediaAPI mailing list supposed to be working?

Maybe the list should be closed - or instead its existence
should be advertised again in order to promote activity.

There were no replies to the following questions, that were
the only message in the last months.

Opensource Obscure

 Original Message 
Subject: [MediaAPI] Plugin folders and what plugins
Date: Wed, 18 Aug 2010 19:39:02 -0500
From: SuezanneC Baskerville 
To: media...@lists.secondlife.com

Apparently the viewer looks for such plugins as Flash and Quicktime.

What all plugins does the viewer look for?

What folders does the viewer look in?

-- 
for   v i r t u a l   w o r l d s   try these sites:
h i p i h i . c o m  - s  e c o n d l i f e . c o m -
-- http://www.google.com/profiles/s u e z a n n e --
Apparently the viewer looks for such plugins as Flash and Quicktime.  What all plugins does the viewer look for?What folders does the viewer look in?-- for   v i r t u a l   w o r l d s   try these sites:
h i p i h i . c o m  - s  e c o n d l i f e . c o m - -- http://www.google.com/profiles/s u e z a n n e --
___
Policies 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] Avatar animation control using gestures and augmented reality visualization.

[Kantonen Tuomas]

Hi.

Earlier  this year I presented our work on using Snowglobe as a platform for 
mixed reality meetings.
This includes controlling avatars by natural gestures and to be able to view 
avatars as if they would
be located in the same room as the user.

I opened two "new feature" issues into SL Jira (SNOW-820, SNOW-821) to discuss 
if some of this work could
be included into Snowglobe. The gesture recognition part might be easiest to 
integrate, since it does not require
changes in the viewer source, except to be able to initialize and execute the 
processing thread. However, since all
this image processing requires a lot of processing, and the implementation uses 
3rd party libraries, such as
OpenCV, I'm not sure what would be the method of integration that the Snowglobe 
community would like to
use. Augmented reality visualization needs to touch the rendering pipeline so 
I'd like to know how eager you
are to include this kind of work.

I have created a couple of web-pages describing how the system works:
 http://virtual.vtt.fi/virtual/proj2/multimedia/MWI/mwi.html.

Currently the system is implemented as a separate DLL + a small set of patches 
to initialize the DLL and transfer
calls between the viewer and the DLL. I can figure out at least two other 
possibilities: including all the DLL sources
(and adding all its dependencies) directly into the viewer source, or running 
the DLL as a separate executable using
some simple IPC interface to communicate with the viewer (not too unlike how 
the SLVoice works).

You can see all the sources and patches at the project web page. Since the 
project contains multiple different parts,
I tried to separate the patches into sensible sets. The patches are so small 
that I think that I could quite easily port
them to the latest viewer trunk but I'd rather not do it until I have a better 
idea what's the correct integration mechanism.

As a side note, we are currently working on face gestures that was proposed 
already on 2007
(https://jira.secondlife.com/browse/VWR-2122). If we can figure out a way to 
include all this client
side video processing, then this work would also be integrated.

--
- Tuomas Kantonen

___
Policies 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] SL 2.1.1: Menu entry not working

[Tillie Ariantho]

Hello,

1. I can't get the advanced sky window into the World dropdown. Something like 
this I thought should work:






but doesn't. Any ideas?

2. And is there a way to get the 'East Angle' slider into the bottom bar? That 
would really help me for taking photos, as I don't need to have open the 
Advanced Sky window all the time.

3. Oh and I tried to move the Upload entries from inventory to a FILE entry in 
top bar again. But it doesnt translate the [COST] strings.

4. And I got 2 crashes by now:

2010-08-26T09:56:25Z newview/llappviewer.cpp(1247) : error
2010-08-26T09:56:25Z ERROR: LLAppViewer::mainLoop: Bad memory 
allocation in LLAppViewer::mainLoop()!

No idea what the cause was, once I was wearing an outfitfolder, the other time 
I only opened a menu dropdown.

Second Life 2.1.1 (208043) Aug 12 2010 14:14:07 (Second Life Beta Viewer)

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

[opensource-dev] Heads-up - pretty big viewer-public merge to viewer-development landed

[Tofu Linden]

Hello!

Probably no surprise to folks who've seen my last few days of
branch-juggling on hg.secondlife.com, but I finally got LL's
retired viewer-public branch converted to the new repo and merged into
viewer-development.

It's a fair amount of churn, but it should be the last of the big
merges needed to synchronize viewer-development's trunk and LL's
formerly internal ~viewer2.2 trunk (hooray for a public trunk now).

What's new (the details are in the hg log):
* Assorted world and UI rendering optimizations
* Assorted rendering fixes
** including fix for longstanding 'glow visible through alpha faces'
problem (VWR-4214 and pals)
* Assorted fixes all over the place
* Pretty complete support for multi-attachments (add a bunch of
attachments on the same attachment point)

These are changes that haven't been in a released viewer before (though
most of it was in snowglobe2.1, and most of it has been QA-tested), so
please be vigilant. :)

Cheers!
-Tofu
___
Policies 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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

  User Story

As a Funtoo Linux (a Gentoo variant) 64bit user and volunteer viewer
developer, I want to build Snowstorm with the same build mode I already
use(d) for Snowglobe:

* native (i.e. 64bit)
* standalone
* out-of-source

I'd like to be able to do this for all three, Release, RelWithDebug and
Debug mode.


Rationale

This specific choice of build mode might require some explanations. (If
you don't think so, just skip this section. ;-) )


  Why native (64bit)?

* Why not? (OK, that might not be a too good argument.)
* 64bit builds will also have a 64bit |bin/SLPlugin|, which, other
  than the 32bit version, will be able to use my already installed
  (64bit) GStreamer
  o Gentoo (and thus also Funtoo) allows a "multilib" setup that
installs some important libraries in both 64bit and 32bit
versions, so that most 32bit applications can be run.
However, GStreamer isn't one of these libraries, so one
would probably need a 32bit chroot with 32bit GStreamer to
be able to use it from a 32bit |bin/SLPlugin|. That or I
could dual boot or use a VM.
* So I see when changes in the source break 64bit.
  o If those can be corrected right away, whenever LL decides to
also provide 64bit binaries, the source will be ready to
build them.


  Why standalone?

For those who don't know what the (confusingly named) 'standalone' build
mode implies, see Compiling the viewer (Linux) > What does 'Standalone'
mean?

on our wiki. So why use it?

* LL provides no 64bit version of the prebuilt libraries, so when
  wanting to build 64bit, I don't have much of a choice here, anyway.
* So I see whether version changes of the used libraries will break
  something. Often, the code can be prepared to work well with
  various versions of a library, see e.g. SNOW-737
  .
* So I see whether changes in the source break standalone.
  o Most packagers of the Viewer for Linux distributions will
base their packages on standalone builds. So keeping
standalone flawless means making their task a bit easier.


  Why out-of-source?

What is it and how do I do it? See What is an "out-of-source" build?
 at
the FAQ on the CMake wiki. As for the why:

* A pristine source tree makes it easy to see your own
  modifications, especially addition of yet untracked files (which
  will show up in |hg status| but not |hg diff|).
* Maintain builds with different settings from a single source tree
  in separate directories.
* Easy to do clean rebuilds by just deleting and re-creating the
  build dir.
* Once again, to see when it is/gets broken.

Of course, I don't want to imply that everyone should build like I do.
To the contrary, the more different combinations of build settings,
operation system setup etc. are used (and thus tested and hopefully
fixed if broken), the more robust and flexible our build system and
source will become in the end.


  What's already done

As some of you might know, I've been working on collecting patches and
changesets on pJIRA and SVN that allow me to build
lindenlab/viewer-development
 with the settings
above. I've applied them to my repository at
http://bitbucket.org/boroondas/snowstorm-development , ported/modified
them where necessary. I also had Techwolf port some of his own patches.
(Available on his repo
. Thanks Techwolf!)

The final result, merged with the many changes that came from upstream
meanwhile, can be found at the current tip (i.e. rev a0292ef8)

of my repository.


Remaining issues

* SNOW-508  (missing
  |glh/glh_linear.h|)
  o Can be worked around manually by just copying the file into
the right place.
  o Has a proper solution (for standalone) for this been
established yet and I just missed an additional step needed
for it? If so, please let me know.
* Tests fail because the test binaries can't load the required
  shared libraries
  o Work around this by disabling the tests: Set |LL_TESTS| to
|FALSE|.
* When building for the first time or after cleaning the build dir,
  make fails like this near the end:
>   [100%] Building CXX object
>   newview/CMakeFiles/secondlife-bin.dir/llappviewerlinux_api_dbus.o
>   Linking CXX executable secondlife-bin
>   [100%] Built target secondlife-bin
>   Scanning depend

[opensource-dev] Kdu

[Francesco Rabbi]

I see in latest 2.1.2 builds kdu libs, but in "about second life" i
see openjpeg is used, is a bug or a feature?

-- 
Sent by iPhone
___
Policies 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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 On 08/26/2010 02:37 PM, Boroondas Gupte wrote:
> PS: Looks like upstream got some more changesets this morning, I'll
> provide a merge ASAP.
Here you go:
http://bitbucket.org/boroondas/snowstorm-development/changeset/5f58bebfb4ce

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

Re: [opensource-dev] Encrypted chat & third-party servers

[Carlo Wood]

On Wed, Aug 25, 2010 at 10:16:22PM -0700, Erik Anderson wrote:
> " at the end (this is 
> ).  I'm guessing that it 
> is
> thought that no one would notice these unless they were looking for them.

Surely you mean



?

Because after a quick look it's clear that  is the '0'
and  a '1', so that my version spells

01000101010001010010 = 4F 54 52 = ascii for "OTR"
   

-- 
Carlo Wood 
___
Policies 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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Aleric Inglewood]

Hey Boroondas,

not withstanding testing-- I'd like to urge you to get this checked in
ONE related SNOW-* jira at a time (except when they are totally related
of course).

Just wanted to express my "concerns" that all of these changes would
end up as a single commit.

I'd prefer to see them committed per corresponding jira patch, and if the
final commit is not near-100% the same as the original SNOW patch then
that should be detailed clearly in the commit comment.

Thanks!
Aleric

On Thu, Aug 26, 2010 at 4:02 PM, Boroondas Gupte
 wrote:
>  On 08/26/2010 02:37 PM, Boroondas Gupte wrote:
>> PS: Looks like upstream got some more changesets this morning, I'll
>> provide a merge ASAP.
> Here you go:
> http://bitbucket.org/boroondas/snowstorm-development/changeset/5f58bebfb4ce
>
> happy testing
> 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] Kdu

[Oz Linden (Scott Lawrence)]

  On 2010-08-26 9:00, Francesco Rabbi wrote:
> I see in latest 2.1.2 builds kdu libs, but in "about second life" i
> see openjpeg is used, is a bug or a feature

In the process of splitting the public from non-public stuff that was in 
the old private repository, the llkdu build was temporarily left behind 
(on some platforms, attempting to use what's built caused crashes).  It 
should reappear shortly.


___
Policies 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] Product Backlog addition request: Build fixes for 64bit out-of-source

[Boroondas Gupte]

 Hi Aleric

On 08/26/2010 06:20 PM, Aleric Inglewood wrote:
> not withstanding testing-- I'd like to urge you to get this checked in
> ONE related SNOW-* jira at a time (except when they are totally related
> of course).
>
> Just wanted to express my "concerns" that all of these changes would
> end up as a single commit.
I'm not quite sure what you mean by "a single commit" ... "a single
pull", maybe? I /have/ created a separate changeset (a.k.a. "commit")
for almost each patch or SVN changeset I've used. (Everything else would
probably be impossible to review.) The relevant pJIRA issue IDs should
be listed in the commit messages, as well as the SVN commits (if any).

After CG mentioned Daggy Fixes
 on IRC, I used that
technique, so apart from my first few sequential commits (and the
sequential commits I pulled from Techwolf) everything should be easy to
cherry-pick and/or backport.

Or did you mean I should have merged the single commits individually
into upstream instead of merging them together and merging the result
into upstream? If so, why? (It shouldn't matter, as far as I know.)

> I'd prefer to see them committed per corresponding jira patch,
(see above)

> and if the
> final commit is not near-100% the same as the original SNOW patch then
> that should be detailed clearly in the commit comment.
I think I've used "Boroondas Gupte (original patch by )
" as 'author' for stuff I had to modify and "Boroondas Gupte
(patch by ) " (i.e. without 'original') for
patches I could apply essentially as-is. I don't know how consistent I
was at that, so I'd have to check that.

If required, I can re-do the commits with better indication of the
differences from the original patches, but with hg not allowing any
history rewriting, that would take me quite some time. (Though, much
less then I needed up to now, as I now know where to find all the needed
changes.)

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

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

[Marine Kelley]

Hello all,

I am currently working at integrating the RLV code into the latest 2.1.2
viewer in "viewer-development". Some users might have noticed that the
"MultipleAttachments" debug setting was set to FALSE by default in order to
stay compatible with 1.x, because 1.x users cannot see attachments worn on
slots 1 and beyond, only slot 0 is rendered. So the feature is still rather
useless because since most of the users are still using 1.x, multiple
attachments are to be avoided. However having the option to choose whether
to activate it or not was a good idea. I even added a checkbox in the navbar
to set it to TRUE or FALSE in one click without having to open the debug
settings (but that version is not released).

And now what I'm seeing in the latest version worries me. The
MultipleAttachments debug setting is gone ! The viewer behaves as if it were
always TRUE. On the paper it makes sense, since 2.x is supposed to handle
multiple attachments natively and the sims have been updated to 1.40 (and
now 1.42) almost only for this reason. But... this is actually
counter-productive because now someone who tries 2.1 will soon discover that
most of their attachments are not showing to their friends. And that they
require more steps to change an outfit than before, because they now have to
explicitely remove attachments before wearing new ones.

For a viewer that has a lot of difficulties being adopted by the user base,
isn't this move a little backwards ? Why not set MultipleAttachments to TRUE
by default and let the user choose in the preferences or in the navbar as I
did ?

I for one would very much like to see the MultipleAttachments debug setting
come back and stay !

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

[Sythos]

On Thu, 26 Aug 2010 21:45:14 +0200
Marine Kelley  wrote:


> I for one would very much like to see the MultipleAttachments debug
> setting come back and stay !

i use multiple attachments, quite all users (but not emerald neither
imprudence) see them correctly, all kirsten viewers (on kirsten is
enabled by default on last 2 builds) rezz them fine, both SL2 users (if
they don't turn TRUE the debug options too, they say...)

I think is nice hold it as options in preferences, without hide it in
debug setting or turn it always on/off
___
Policies 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 ?

[Aidan Thornton]

On Thu, Aug 26, 2010 at 8:53 PM, Altair Sythos  wrote:
> On Thu, 26 Aug 2010 21:45:14 +0200
> Marine Kelley  wrote:
>
>
>> I for one would very much like to see the MultipleAttachments debug
>> setting come back and stay !
>
> i use multiple attachments, quite all users (but not emerald neither
> imprudence) see them correctly, all kirsten viewers (on kirsten is
> enabled by default on last 2 builds) rezz them fine, both SL2 users (if
> they don't turn TRUE the debug options too, they say...)

So in other words, exactly what Marine Kelley said - they only show up
properly for users of Viewer 2 or a third-party viewer based on it.
That's quite a lot of Second Life users who won't be able to see some
attachments you're wearing in an unpredictable fashion.
___
Policies 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 ?

[Sythos]

On Thu, 26 Aug 2010 21:06:53 +0100
Aidan Thornton  wrote:


> >> I for one would very much like to see the MultipleAttachments debug
> >> setting come back and stay !
> >
> > i use multiple attachments, quite all users (but not emerald neither
> > imprudence) see them correctly, all kirsten viewers (on kirsten is
> > enabled by default on last 2 builds) rezz them fine, both SL2 users
> > (if they don't turn TRUE the debug options too, they say...)
> 
> So in other words, exactly what Marine Kelley said - they only show up
> properly for users of Viewer 2 or a third-party viewer based on it.
> That's quite a lot of Second Life users who won't be able to see some
> attachments you're wearing in an unpredictable fashion.

with my bad eng i was trying to confirm... 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

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

[Trilo Byte]

Trying to confirm the change (and how attachments look/don't look to 1.x 
clients), and am finding that in 2.1.2 (298569) multiple attachments just 
appears to be broken.  I don't see a debug setting, I'm not finding a 
preference option, and the feature is definitely not working in-world.  Putting 
on a belt is taking off coat-tails, and vice-versa.

TriloByte Zanzibar

On Aug 26, 2010, at 12:45 PM, Marine Kelley wrote:

> Hello all,
> 
> I am currently working at integrating the RLV code into the latest 2.1.2 
> viewer in "viewer-development". Some users might have noticed that the 
> "MultipleAttachments" debug setting was set to FALSE by default in order to 
> stay compatible with 1.x, because 1.x users cannot see attachments worn on 
> slots 1 and beyond, only slot 0 is rendered. So the feature is still rather 
> useless because since most of the users are still using 1.x, multiple 
> attachments are to be avoided. However having the option to choose whether to 
> activate it or not was a good idea. I even added a checkbox in the navbar to 
> set it to TRUE or FALSE in one click without having to open the debug 
> settings (but that version is not released).
> 
> And now what I'm seeing in the latest version worries me. The 
> MultipleAttachments debug setting is gone ! The viewer behaves as if it were 
> always TRUE. On the paper it makes sense, since 2.x is supposed to handle 
> multiple attachments natively and the sims have been updated to 1.40 (and now 
> 1.42) almost only for this reason. But... this is actually counter-productive 
> because now someone who tries 2.1 will soon discover that most of their 
> attachments are not showing to their friends. And that they require more 
> steps to change an outfit than before, because they now have to explicitely 
> remove attachments before wearing new ones.
> 
> For a viewer that has a lot of difficulties being adopted by the user base, 
> isn't this move a little backwards ? Why not set MultipleAttachments to TRUE 
> by default and let the user choose in the preferences or in the navbar as I 
> did ?
> 
> I for one would very much like to see the MultipleAttachments debug setting 
> come back and stay !
> 
> Marine
> ___
> Policies 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] Removal of the "MultipleAttachments" debug settings ?

[Nyx Linden]

"MultipleAttachments" was a debug setting we were using for testing 
multi-attachments internally because we didn't have sufficient UI for 
specifying what happened when you went to wear an item on your avatar. 
To be clear, the setting "MultipleAttachments" affected the "wear" 
option for attachments as follows:

FALSE:
When set to false, any time you "wear" an attachment, it would 
replace all attachments at that point. If you're wearing three things on 
your head, and you "wear" something on your head, all three will be 
replaced with the new attachment. Result: you're wearing a single 
attachment on your head.

TRUE:
When set to true, any time you "wear" an attachment, it would ignore 
whatever attachments were at that point and "add" the attachment onto 
that point. For example, if you're wearing three attachments on your 
head and you "wear" something new, you will end up with four things on 
your head.

We've removed the debug setting as we've implemented this 
functionality directly in the user interface, making the debug setting 
completely unnecessary. With the latest code if you "wear" an attachment 
on your head, it will act as if MultipleAttachments was set to FALSE - 
it will replace everything else on your head.

We have a new option in the UI which we've labeled "add" - which 
will act as if MultipleAttachments is TRUE - that is it will "add" the 
attachment to the attachment point, without removing the existing 
attachments.

With both of these options being available through the UI, there is 
no need for the debug option anymore. If you don't want to use 
multi-attachments, all you need to do is make sure you use the "wear" 
option instead of the "add" option. If this is not working as I've 
described, then let us know as we have some bugs to fix :)

Let me know if this clarifies things.

 -Nyx


Marine Kelley wrote:
> Hello all,
>
> I am currently working at integrating the RLV code into the latest 
> 2.1.2 viewer in "viewer-development". Some users might have noticed 
> that the "MultipleAttachments" debug setting was set to FALSE by 
> default in order to stay compatible with 1.x, because 1.x users cannot 
> see attachments worn on slots 1 and beyond, only slot 0 is rendered. 
> So the feature is still rather useless because since most of the users 
> are still using 1.x, multiple attachments are to be avoided. However 
> having the option to choose whether to activate it or not was a good 
> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE 
> in one click without having to open the debug settings (but that 
> version is not released).
>
> And now what I'm seeing in the latest version worries me. The 
> MultipleAttachments debug setting is gone ! The viewer behaves as if 
> it were always TRUE. On the paper it makes sense, since 2.x is 
> supposed to handle multiple attachments natively and the sims have 
> been updated to 1.40 (and now 1.42) almost only for this reason. 
> But... this is actually counter-productive because now someone who 
> tries 2.1 will soon discover that most of their attachments are not 
> showing to their friends. And that they require more steps to change 
> an outfit than before, because they now have to explicitely remove 
> attachments before wearing new ones.
>
> For a viewer that has a lot of difficulties being adopted by the user 
> base, isn't this move a little backwards ? Why not set 
> MultipleAttachments to TRUE by default and let the user choose in the 
> preferences or in the navbar as I did ?
>
> I for one would very much like to see the MultipleAttachments debug 
> setting come back and stay !
>
> Marine
> 
>
> ___
> Policies 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] Removal of the "MultipleAttachments" debug settings ?

[Sythos]

On Thu, 26 Aug 2010 16:24:08 -0400
Nyx Linden  wrote:


> Let me know if this clarifies things.

yeah
i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life
Development) now, it work as you said, just noticed something weird and
tryiong to reproduce:
if i crash when relog all attachments are weared double time, like the
dirty logoff don't detach items.

I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff
"acvatar destructor" take "current outfit" and store somewhere on
asset, during login last saved "current outfit" is worn.

maybe is better if saved "current outfit" replace what worn during
login, so if crashed nothing boudle is worn...

somebody who know better and deeper the code can hint me about?
___
Policies 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 ?

[Trilo Byte]

My mistake, then.  When I performed the same action to wear an item as
I had in previous builds and got the unexpected/unwanted result, and 
saw that the debug option was gone, I thought it had broken (like 
anti-aliasing did in the latest build).

When this viewer gets released. it would be helpful if this change in 
behavior was blogged and documented.  I think it makes a lot of sense,
but double-clicking on an item or right-clicking and choosing 'wear' is 
what I imagine most people would do.

Trilo

On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote:

>"MultipleAttachments" was a debug setting we were using for testing 
> multi-attachments internally because we didn't have sufficient UI for 
> specifying what happened when you went to wear an item on your avatar. 
> To be clear, the setting "MultipleAttachments" affected the "wear" 
> option for attachments as follows:
> 
> FALSE:
>When set to false, any time you "wear" an attachment, it would 
> replace all attachments at that point. If you're wearing three things on 
> your head, and you "wear" something on your head, all three will be 
> replaced with the new attachment. Result: you're wearing a single 
> attachment on your head.
> 
> TRUE:
>When set to true, any time you "wear" an attachment, it would ignore 
> whatever attachments were at that point and "add" the attachment onto 
> that point. For example, if you're wearing three attachments on your 
> head and you "wear" something new, you will end up with four things on 
> your head.
> 
>We've removed the debug setting as we've implemented this 
> functionality directly in the user interface, making the debug setting 
> completely unnecessary. With the latest code if you "wear" an attachment 
> on your head, it will act as if MultipleAttachments was set to FALSE - 
> it will replace everything else on your head.
> 
>We have a new option in the UI which we've labeled "add" - which 
> will act as if MultipleAttachments is TRUE - that is it will "add" the 
> attachment to the attachment point, without removing the existing 
> attachments.
> 
>With both of these options being available through the UI, there is 
> no need for the debug option anymore. If you don't want to use 
> multi-attachments, all you need to do is make sure you use the "wear" 
> option instead of the "add" option. If this is not working as I've 
> described, then let us know as we have some bugs to fix :)
> 
> Let me know if this clarifies things.
> 
> -Nyx
> 
> 
> Marine Kelley wrote:
>> Hello all,
>> 
>> I am currently working at integrating the RLV code into the latest 
>> 2.1.2 viewer in "viewer-development". Some users might have noticed 
>> that the "MultipleAttachments" debug setting was set to FALSE by 
>> default in order to stay compatible with 1.x, because 1.x users cannot 
>> see attachments worn on slots 1 and beyond, only slot 0 is rendered. 
>> So the feature is still rather useless because since most of the users 
>> are still using 1.x, multiple attachments are to be avoided. However 
>> having the option to choose whether to activate it or not was a good 
>> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE 
>> in one click without having to open the debug settings (but that 
>> version is not released).
>> 
>> And now what I'm seeing in the latest version worries me. The 
>> MultipleAttachments debug setting is gone ! The viewer behaves as if 
>> it were always TRUE. On the paper it makes sense, since 2.x is 
>> supposed to handle multiple attachments natively and the sims have 
>> been updated to 1.40 (and now 1.42) almost only for this reason. 
>> But... this is actually counter-productive because now someone who 
>> tries 2.1 will soon discover that most of their attachments are not 
>> showing to their friends. And that they require more steps to change 
>> an outfit than before, because they now have to explicitely remove 
>> attachments before wearing new ones.
>> 
>> For a viewer that has a lot of difficulties being adopted by the user 
>> base, isn't this move a little backwards ? Why not set 
>> MultipleAttachments to TRUE by default and let the user choose in the 
>> preferences or in the navbar as I did ?
>> 
>> I for one would very much like to see the MultipleAttachments debug 
>> setting come back and stay !
>> 
>> Marine
>> 
>> 
>> ___
>> Policies 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 inform

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

[Nyx Linden]

Correct, that is what most people will do, and that's why we wanted to 
keep the behavior of double click / "wear" to be consistent with how the 
functionality worked in 1.23.X, as that's what most people are used to 
those functions doing.

Since multi-wearables is a new feature, using the new functionality 
warranted using a new right click menu option.

We'd like to keep things consistent for old users and offer new 
functionality for those who would like to take advantage of it. Its a 
fairly simple implementation for the UI for controlling multiwearables, 
however, so if you have suggestions for better ways of exposing the 
functionality, please do let us know!

 -Nyx

Trilo Byte wrote:
> My mistake, then.  When I performed the same action to wear an item as
> I had in previous builds and got the unexpected/unwanted result, and 
> saw that the debug option was gone, I thought it had broken (like 
> anti-aliasing did in the latest build).
>
> When this viewer gets released. it would be helpful if this change in 
> behavior was blogged and documented.  I think it makes a lot of sense,
> but double-clicking on an item or right-clicking and choosing 'wear' is 
> what I imagine most people would do.
>
> Trilo
>
> On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote:
>
>   
>>"MultipleAttachments" was a debug setting we were using for testing 
>> multi-attachments internally because we didn't have sufficient UI for 
>> specifying what happened when you went to wear an item on your avatar. 
>> To be clear, the setting "MultipleAttachments" affected the "wear" 
>> option for attachments as follows:
>>
>> FALSE:
>>When set to false, any time you "wear" an attachment, it would 
>> replace all attachments at that point. If you're wearing three things on 
>> your head, and you "wear" something on your head, all three will be 
>> replaced with the new attachment. Result: you're wearing a single 
>> attachment on your head.
>>
>> TRUE:
>>When set to true, any time you "wear" an attachment, it would ignore 
>> whatever attachments were at that point and "add" the attachment onto 
>> that point. For example, if you're wearing three attachments on your 
>> head and you "wear" something new, you will end up with four things on 
>> your head.
>>
>>We've removed the debug setting as we've implemented this 
>> functionality directly in the user interface, making the debug setting 
>> completely unnecessary. With the latest code if you "wear" an attachment 
>> on your head, it will act as if MultipleAttachments was set to FALSE - 
>> it will replace everything else on your head.
>>
>>We have a new option in the UI which we've labeled "add" - which 
>> will act as if MultipleAttachments is TRUE - that is it will "add" the 
>> attachment to the attachment point, without removing the existing 
>> attachments.
>>
>>With both of these options being available through the UI, there is 
>> no need for the debug option anymore. If you don't want to use 
>> multi-attachments, all you need to do is make sure you use the "wear" 
>> option instead of the "add" option. If this is not working as I've 
>> described, then let us know as we have some bugs to fix :)
>>
>> Let me know if this clarifies things.
>>
>> -Nyx
>>
>>
>> Marine Kelley wrote:
>> 
>>> Hello all,
>>>
>>> I am currently working at integrating the RLV code into the latest 
>>> 2.1.2 viewer in "viewer-development". Some users might have noticed 
>>> that the "MultipleAttachments" debug setting was set to FALSE by 
>>> default in order to stay compatible with 1.x, because 1.x users cannot 
>>> see attachments worn on slots 1 and beyond, only slot 0 is rendered. 
>>> So the feature is still rather useless because since most of the users 
>>> are still using 1.x, multiple attachments are to be avoided. However 
>>> having the option to choose whether to activate it or not was a good 
>>> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE 
>>> in one click without having to open the debug settings (but that 
>>> version is not released).
>>>
>>> And now what I'm seeing in the latest version worries me. The 
>>> MultipleAttachments debug setting is gone ! The viewer behaves as if 
>>> it were always TRUE. On the paper it makes sense, since 2.x is 
>>> supposed to handle multiple attachments natively and the sims have 
>>> been updated to 1.40 (and now 1.42) almost only for this reason. 
>>> But... this is actually counter-productive because now someone who 
>>> tries 2.1 will soon discover that most of their attachments are not 
>>> showing to their friends. And that they require more steps to change 
>>> an outfit than before, because they now have to explicitely remove 
>>> attachments before wearing new ones.
>>>
>>> For a viewer that has a lot of difficulties being adopted by the user 
>>> base, isn't this move a little backwards ? Why not set 
>>> MultipleAttachments to TRUE by default and let the user choose in the 
>>> preferences

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

[Marine Kelley]

I understand, it makes sense, thanks for your reply Nyx. I did see the Add
option on 2.1.0 along with MultipleAttachments there too so I assumed both
were needed for some reason (this debug setting was used in a few places in
the code).


On 26 August 2010 22:43, Nyx Linden  wrote:

> Correct, that is what most people will do, and that's why we wanted to
> keep the behavior of double click / "wear" to be consistent with how the
> functionality worked in 1.23.X, as that's what most people are used to
> those functions doing.
>
> Since multi-wearables is a new feature, using the new functionality
> warranted using a new right click menu option.
>
> We'd like to keep things consistent for old users and offer new
> functionality for those who would like to take advantage of it. Its a
> fairly simple implementation for the UI for controlling multiwearables,
> however, so if you have suggestions for better ways of exposing the
> functionality, please do let us know!
>
>  -Nyx
>
> Trilo Byte wrote:
> > My mistake, then.  When I performed the same action to wear an item as
> > I had in previous builds and got the unexpected/unwanted result, and
> > saw that the debug option was gone, I thought it had broken (like
> > anti-aliasing did in the latest build).
> >
> > When this viewer gets released. it would be helpful if this change in
> > behavior was blogged and documented.  I think it makes a lot of sense,
> > but double-clicking on an item or right-clicking and choosing 'wear' is
> > what I imagine most people would do.
> >
> > Trilo
> >
> > On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote:
> >
> >
> >>"MultipleAttachments" was a debug setting we were using for testing
> >> multi-attachments internally because we didn't have sufficient UI for
> >> specifying what happened when you went to wear an item on your avatar.
> >> To be clear, the setting "MultipleAttachments" affected the "wear"
> >> option for attachments as follows:
> >>
> >> FALSE:
> >>When set to false, any time you "wear" an attachment, it would
> >> replace all attachments at that point. If you're wearing three things on
> >> your head, and you "wear" something on your head, all three will be
> >> replaced with the new attachment. Result: you're wearing a single
> >> attachment on your head.
> >>
> >> TRUE:
> >>When set to true, any time you "wear" an attachment, it would ignore
> >> whatever attachments were at that point and "add" the attachment onto
> >> that point. For example, if you're wearing three attachments on your
> >> head and you "wear" something new, you will end up with four things on
> >> your head.
> >>
> >>We've removed the debug setting as we've implemented this
> >> functionality directly in the user interface, making the debug setting
> >> completely unnecessary. With the latest code if you "wear" an attachment
> >> on your head, it will act as if MultipleAttachments was set to FALSE -
> >> it will replace everything else on your head.
> >>
> >>We have a new option in the UI which we've labeled "add" - which
> >> will act as if MultipleAttachments is TRUE - that is it will "add" the
> >> attachment to the attachment point, without removing the existing
> >> attachments.
> >>
> >>With both of these options being available through the UI, there is
> >> no need for the debug option anymore. If you don't want to use
> >> multi-attachments, all you need to do is make sure you use the "wear"
> >> option instead of the "add" option. If this is not working as I've
> >> described, then let us know as we have some bugs to fix :)
> >>
> >> Let me know if this clarifies things.
> >>
> >> -Nyx
> >>
> >>
> >> Marine Kelley wrote:
> >>
> >>> Hello all,
> >>>
> >>> I am currently working at integrating the RLV code into the latest
> >>> 2.1.2 viewer in "viewer-development". Some users might have noticed
> >>> that the "MultipleAttachments" debug setting was set to FALSE by
> >>> default in order to stay compatible with 1.x, because 1.x users cannot
> >>> see attachments worn on slots 1 and beyond, only slot 0 is rendered.
> >>> So the feature is still rather useless because since most of the users
> >>> are still using 1.x, multiple attachments are to be avoided. However
> >>> having the option to choose whether to activate it or not was a good
> >>> idea. I even added a checkbox in the navbar to set it to TRUE or FALSE
> >>> in one click without having to open the debug settings (but that
> >>> version is not released).
> >>>
> >>> And now what I'm seeing in the latest version worries me. The
> >>> MultipleAttachments debug setting is gone ! The viewer behaves as if
> >>> it were always TRUE. On the paper it makes sense, since 2.x is
> >>> supposed to handle multiple attachments natively and the sims have
> >>> been updated to 1.40 (and now 1.42) almost only for this reason.
> >>> But... this is actually counter-productive because now someone who
> >>> tries 2.1 will soon discover that most of their attachments are not
> 

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

[Marine Kelley]

I'd like to chime in and say that this happens to me often as well.
Attachments are worn twice on relog, approx. once a day. Since the
attachments I'm wearing usually say things with llOwnerSay and I see them
say their messages twice, I do know this is not only a viewer-side problem.
I have never observed this with 1.23, only with 2.1.

Soft is aware of this issue, and confirmed seeing the double-rezzing in the
logs of my sim at the time I indicated.


On 26 August 2010 22:30, Altair Sythos  wrote:

> On Thu, 26 Aug 2010 16:24:08 -0400
> Nyx Linden  wrote:
>
>
> > Let me know if this clarifies things.
>
> yeah
> i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life
> Development) now, it work as you said, just noticed something weird and
> tryiong to reproduce:
> if i crash when relog all attachments are weared double time, like the
> dirty logoff don't detach items.
>
> I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff
> "acvatar destructor" take "current outfit" and store somewhere on
> asset, during login last saved "current outfit" is worn.
>
> maybe is better if saved "current outfit" replace what worn during
> login, so if crashed nothing boudle is worn...
>
> somebody who know better and deeper the code can hint me about?
>
___
Policies 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 ?

[Dave Booth]

  On 8/26/2010 15:54, Marine Kelley wrote:
> I understand, it makes sense, thanks for your reply Nyx. I did see the 
> Add option on 2.1.0 along with MultipleAttachments there too so I 
> assumed both were needed for some reason (this debug setting was used 
> in a few places in the code).
>

So, Marine, I'm guessing theres going to be a new UI element in the next 
RLV release  - a checkbox that toggles the behaviour of the force-attach 
option between "wear" and "add". Either that or you've got the pain of 
revising the API yet again and having @attach:folder=force do a "wear" 
and @attach:folder=forceadd do an "add" - along with a note that for 
backwards compatibility, any viewer that doesnt implement add must treat 
forceadd as equivalent to force, just to spread the pain down to the 
other folks that implement it  :)
___
Policies 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 ?

[Brian McGroarty]

There were some fixes in 1.42 that dealt with a related MultipleAttachments
issue, and should have addressed the more general case.

If anyone encounters this while logging in with an account where you've
crashed or logged out today or later, would you please follow up with me in
direct email? If you include the time and location at which you logged in,
as well as what the item names were, and which attachment point they were
on, it will help tremendously. Also, let me know if you flipped between 2.x
and 1.x viewers in those sessions - anything out of the ordinary could be
relevant.

On Thu, Aug 26, 2010 at 2:37 PM, Marine Kelley wrote:

> I'd like to chime in and say that this happens to me often as well.
> Attachments are worn twice on relog, approx. once a day. Since the
> attachments I'm wearing usually say things with llOwnerSay and I see them
> say their messages twice, I do know this is not only a viewer-side problem.
> I have never observed this with 1.23, only with 2.1.
>
> Soft is aware of this issue, and confirmed seeing the double-rezzing in the
> logs of my sim at the time I indicated.
>
>
>
> On 26 August 2010 22:30, Altair Sythos  wrote:
>
>> On Thu, 26 Aug 2010 16:24:08 -0400
>> Nyx Linden  wrote:
>>
>>
>> > Let me know if this clarifies things.
>>
>> yeah
>> i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life
>> Development) now, it work as you said, just noticed something weird and
>> tryiong to reproduce:
>> if i crash when relog all attachments are weared double time, like the
>> dirty logoff don't detach items.
>>
>> I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff
>> "acvatar destructor" take "current outfit" and store somewhere on
>> asset, during login last saved "current outfit" is worn.
>>
>> maybe is better if saved "current outfit" replace what worn during
>> login, so if crashed nothing boudle is worn...
>>
>> somebody who know better and deeper the code can hint me about?
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 
Brian McGroarty | Linden Lab
Sent from my Newton MP2100 via acoustic coupler
___
Policies 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 ?

[Francesco Rabbi]

I think may be more usefull add all you asked in the jira opened about
multiattachments double worn :)

-- 
Sent by iPhone

Il giorno 27/ago/2010, alle ore 00:50, Brian McGroarty 
ha scritto:

There were some fixes in 1.42 that dealt with a related MultipleAttachments
issue, and should have addressed the more general case.

If anyone encounters this while logging in with an account where you've
crashed or logged out today or later, would you please follow up with me in
direct email? If you include the time and location at which you logged in,
as well as what the item names were, and which attachment point they were
on, it will help tremendously. Also, let me know if you flipped between 2.x
and 1.x viewers in those sessions - anything out of the ordinary could be
relevant.

On Thu, Aug 26, 2010 at 2:37 PM, Marine Kelley wrote:

> I'd like to chime in and say that this happens to me often as well.
> Attachments are worn twice on relog, approx. once a day. Since the
> attachments I'm wearing usually say things with llOwnerSay and I see them
> say their messages twice, I do know this is not only a viewer-side problem.
> I have never observed this with 1.23, only with 2.1.
>
> Soft is aware of this issue, and confirmed seeing the double-rezzing in the
> logs of my sim at the time I indicated.
>
>
>
> On 26 August 2010 22:30, Altair Sythos  wrote:
>
>> On Thu, 26 Aug 2010 16:24:08 -0400
>> Nyx Linden  wrote:
>>
>>
>> > Let me know if this clarifies things.
>>
>> yeah
>> i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life
>> Development) now, it work as you said, just noticed something weird and
>> tryiong to reproduce:
>> if i crash when relog all attachments are weared double time, like the
>> dirty logoff don't detach items.
>>
>> I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff
>> "acvatar destructor" take "current outfit" and store somewhere on
>> asset, during login last saved "current outfit" is worn.
>>
>> maybe is better if saved "current outfit" replace what worn during
>> login, so if crashed nothing boudle is worn...
>>
>> somebody who know better and deeper the code can hint me about?
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 
Brian McGroarty | Linden Lab
Sent from my Newton MP2100 via acoustic coupler
___
Policies 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] Updated Snowstorm submission procedure

[Oz Linden (Scott Lawrence)]

  I've just updated the procedure for how to submit a changeset for 
Snowstorm integration.  There's now an explicit mechanism in Jira to 
queue a change to be integrated.   See

https://wiki.secondlife.com/wiki/How_To_Submit_A_Viewer_Change#Submission

This is a temporary procedure - it will be replaced by a better one 
using Jira workflow when Jira is upgraded (the new workflow is in place 
and ready to be used post-upgrade, which is currently on track for 
September 7).


___
Policies 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] Anti-Aliasing

[Trilo Byte]

Is it just me, or is anti-aliasing broken in the last couple builds?
2.1.2 (208569) and 2.1.2 (208581)

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

TriloByte Zanzibar
___
Policies 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] Requiring user stories for bug fix jiras?

[Latif Khalifa]

Hi Oz,

Looking through VWR-19505 I see the comment by the dev who made a fix
that you have requested a user story. Do we really need user stories
for bugs? There is effects setting in the main preferences floater,
there is a menu that enables to turn on and off the selection beam.
Why do you need a user story and justification for those sort of bug
fixes?

Should the devs have to write "As a user I expect that this bug is not
present", or "As a user I expect effect color and 'show selection
beam' menu items to do something"?

Could we please get the procedure for including bug fixes clarified?

Thanks!

Latif
___
Policies 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] Anti-Aliasing

[Kadah Coba]

  Yeah, me too. AA is buggy in 2, but its not working at all now.


On 8/26/2010 6:06 PM, Trilo Byte wrote:
> Is it just me, or is anti-aliasing broken in the last couple builds?
> 2.1.2 (208569) and 2.1.2 (208581)
>
> https://jira.secondlife.com/browse/VWR-20969
>
> TriloByte Zanzibar
> ___
> Policies 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