[opensource-dev] Cannot wear two different bodyparts at the same time

[Marine Kelley]

Hello all,

I have just filed a JIRA under Viewer 2.0.1 (although it shows for 2.0.0 as
well) at https://jira.secondlife.com/browse/VWR-19425

In short, when you wear a new skin and a new hair at the same time (by
selecting both and pressing Wear), one of them is worn then removed, leaving
you with the default version and an error message. I have discovered this
when testing RLV 2.0 (and pulling my hair for days over it) which uses
outfits very extensively and that ability is crippled. But since it is also
present in the vanilla SL viewer 2.0, I don't see what I can do.

Have anyone encountered this problem ?

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] build instructions overhaul

[Boroondas Gupte]

On 05/01/2010 08:39 PM, Boroondas Gupte wrote:
> I noticed that we already have Category:Compiling_viewer
> ,
> containing a lot of pages that might be relevant.
Oops, looks like I linked to the same page twice. As you might have
guessed, this one should have pointed to
https://wiki.secondlife.com/wiki/Category:Compiling_viewer

No reasons have been brought up not to use this category (instead of
another/a new one) for this, so let's start adding relevant articles to
it: If you find an article that should be in this category but isn't,
please add

[[Category:Compiling viewer]]
  

to it's source, preferably near the end after the actual content. Please
note that category names are case sensitive.

If someone feels like documenting the current build process, by all
means go for it! (And if you create a new article, add it to the
category, too!) It can't hurt to have these things written down, even if
they might get edited heavily during the documentation reorganization.

cheers
and thanks in advance for your help with this

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] Cannot wear two different bodyparts at the sametime

[Kitty]

  _  

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Marine
Kelley
Sent: Monday, May 10 2010 09:24
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] Cannot wear two different bodyparts at the
sametime



Hello all,

I have just filed a JIRA under Viewer 2.0.1 (although it shows for 2.0.0 as
well) at  
https://jira.secondlife.com/browse/VWR-19425

In short, when you wear a new skin and a new hair at the same time (by
selecting both and pressing Wear), one of them is worn then removed, leaving
you with the default version and an error message. I have discovered this
when testing RLV 2.0 (and pulling my hair for days over it) which uses
outfits very extensively and that ability is crippled. But since it is also
present in the vanilla SL viewer 2.0, I don't see what I can do.

Have anyone encountered this problem ?

Marine


 
*waves*
 
There's a few JIRAs on it already I think (not all of them that exact same
issue but all having to do with a broken COF) and all the "fun" bugs that
come from that.
 
What happens in your specific case:
  1) I'd guess you're calling LLAppearanceMgr::addCOFItemLink twice in a row
- both the currently worn hair and skin link are removed from
"Current Outfit"
- you'll have two calls to link_inventory_item() with two different
ModifiedCOFCallback callbacks
  2) (let's say the skin link callback fires first)
- it fires off LLAppearanceMgr::updateAppearanceFromCOF() which does
the whole LLWearableHoldingPattern dance
- the old skin link was removed but there's a new one so you're set
for skin
- the old hair link was removed but the new hair link hasn't been
created yet (or the viewer hasn't been notified of it yet)
- when it gets to LLWearableHoldingPattern::checkMissingWearables()
it decides that since there is no hair link in COF it should just create one
from scratch and wear that
 
You probably got lucky too since there's another bug in wearing more than
one body part at the same time:
  - when the wearable gets recovered it creates a new item link for it in
"Current Outfit"
  - when both the original and the recovered wearable link complete you now
have two body parts of the same type listed under COF and you may get lucky
and end up with the one you want, or you may get the one you don't want the
next time you try to wear something
 
The easiest solution there was to simply change "checkMissingWearable()" to
first call a new "recoverExistingWearable()" which checks what's currently
worn and reuses that instead of creating a new default wearable.
 
So it goes:
  - if wearable type either should be always be present (=body part) or was
requested (=clothing) but wasn't resolved then:
  - iterate over what's currently worn on that wearable type and compare
the asset UUID
  - if it matches then you just grab the existing LLWearable* and put
that in mFoundList instead
  - or do nothing if a clothing layer was requested but isn't currently
worn
 
Which goes back to the far less annoying 1.23 behaviour (if you wear
something that can't have its asset fetched (or that times out) then you do
*not* change what's currently worn).
 
It still won't work perfect though because you'll still have two independent
callbacks firing and two LLWearableHoldingPattern instances:
  - extend LLAppearanceMgr::addCOFItemLink to take a callback as an extra
parameter
  - instead of creating its own callback have it use the one passed to it if
it's not null
 
That way you can go:
  LLPointer cb = new LLUpdateAppearanceOnDestroy();
  LLAppearanceMgr::instance().addCOFItemLink(..., true, cb);
  LLAppearanceMgr::instance().addCOFItemLink(..., true, cb);
  LLAppearanceMgr::instance().addCOFItemLink(..., true, cb);
 
And you'll just have one single call to
LLAppearanceMgr::updateAppearanceFromCOF() no matter how many you add. One
thing to note is that there's code in addCOFItemLink that will make sure
that if you already have an item of that wearable type in COF then it'll
remove the old link to make sure that you don't end up with 2 body parts and
4 shirts listed so you'll need to do that filtering yourself because since
the new links don't exist yet that code doesn't end up actually doing
anything (and in 2.0.2 it needs fixing to still filter out body parts).
 
So for me it looks like (items is an array of LLViewerInventoryItem* to body
parts and clothing items):
  LLAppearanceMgr::filterWearableItems(items, X); // <- this one isn't
public by default so you'll have to change that
 
  LLPointer cb = new LLUpdateAppearanceOnDestroy();
  for (LLInventoryModel::item_array_t::const_iterator itItem =
items.begin(); itItem != items.end(); ++itItem)
LLAppearanceMgr::instance().addCOFItemLink(*itItem, true, cb);

(X will be 1 on 2.0.1 but 5 - probably subject to change but that seems to
be the current limit - on 2.0.2 s

[opensource-dev] SnowGlobe Libraries still MIA

[Malachi]

everything below 2.0 gives the following...


This XML file does not appear to have any style information associated  
with it. The document tree is shown below.

−

AccessDenied
Access Denied
C29F96F3FA9104C6
−

DkVyYn+VGIwuSq7QFGeEl5MmbO/UtqIMp9rFTzmIDfiLjBYgZ8tTAmiaogteCMMZ





i take it we are being forced to use 2.0 code? or does someone happen to  
have the 1.3.2 libraries stored somewhere other than at the SL wiki... if  
so please send me a link id love to be able to download them
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Problems porting VWR-12984 to snowglobe 2.0

[lists . secondlife . com]

When porting over VWR-12984, I hit a snag. Turns out an enum was added to from 
1.x to 2.x that put it at 32 bits. The port added one more causing to go over 
to 33 bits. From the comments section of the jira.

==
These warnings are indeed sign of a serious problem: The enum's values are 
used to shift a 1 (a set bit) around within (32-bit) ints, to produce flags 
and masks. Other than in Snowglobe 1.x, the enum already had 32 values before 
the patch. The patch added a 33rd, pushing the shifted-around 1 off the type 
size boundary.

This results in some objects staying blurry and and others disappearing 
seemingly at random or not showing at all. Most of the values of the enum are 
being assigned values from other enums, so either this was very, very 
carefully crafted or we were extremely "lucky" that the bit-shifting didn't 
push the 32bit limit already before this patch.

The warnings can be avoided by doing the shifting within long ints instead of 
ints. This of course doesn't solve the problem, as the types of the variables 
to which the resulting masks get assigned are still too small and would have 
to be changed, too. (Which could lead to other variables and constants having 
to be changed. Didn't check that, yet.)

If (at least) one of the values of the enum isn't used to shift bits around (I 
haven't looked yet whether that's the case), that one could be put at the end 
of the enum, thus keeping the others below 32. However, that solution would be 
even hackier than than the current code and would cause major maintenance 
headaches. (E.g., what happens when that value has later to be used to define 
a mask, too?)


My question for the group is how is the best way to fix this? Can 
RENDER_TYPE_PASS_* be moved into its own enum?

--Techwolf Lupindo
___
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 Libraries still MIA

[Philippe (Merov) Bossut]

Hi Malachi,

Rebuilding the 1.23.4 bundles used by all versions of Snowglobe from 1.1.2
was the subject of https://jira.secondlife.com/browse/SNOW-604

I recreated bundles for 1.23.4 and update the asset_urls.doc file for 1.4
(aka the Snowglobe 1.x trunk). Those should be usable to compile 1.3.2  and
all versions of Snowglobe till 1.1.2.

Here are the links in case you don't get your source from svn:

SLASSET_LIBS_WIN32=
http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/slviewer-win32-libs-oss-viewer-1.23.4.0.zip
SLASSET_MD5=
http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/md5sums-oss-viewer-1.23.4.0.txt
SLASSET_LIBS_DARWIN=
http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/slviewer-darwin-libs-oss-viewer-1.23.4.0.tar.gz
SLASSET_ART=
http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/slviewer-artwork-oss-viewer-1.23.4.0.zip
SLASSET_LIBS_LINUXI386=
http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/slviewer-linux-libs-oss-viewer-1.23.4.0.tar.gz

I have however not fixed the bundles in the download page and some need to
be rebuilt from whichever branch. I should certainly add 1.23.4 in there,
redo 1.23.5 (as Henri signaled to me that the Linux libs is incorrect) but,
what about others? Should we go back all the way to 1.22.11?

I'll clean up that page and provide downloadable links for all.

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