"Replace outfit" is basically broken now
Issue #86
resolved
I have just build a viewer from the current source as of today, and "replace outfit" doesn't work anymore. What happens is that it replaces the current outfit, but right after that all attachments are taken off again.
To reproduce: do a "replace outfit" with a folder that contains wearables and prim objects (or mesh, doesn't matter), and observe the "wearing" tab in the outfits floater.
Comments (47)
-
reporter
-
reporter
"Add to outfit" also detaches all newly worn prims again after a moment.
-
repo owner
Does it do this in the official viewer as well ? I couldn't test Replace Outfit seriously there, since it is greyed out after the first attempt. I noticed the behavior you describe in the RLV, but I'm not sure this is due to my code. At all. Considering the changes LL did to the appearance manager and how badly the official viewer behaves, it could very well be something that is completely out of my control.
-
reporter
Can't reproduce the bug on the official binary from the lab (Second Life 3.7.14 (292638) Aug 4 2014 20:09:12 (Second Life Release)), but I DO repro on a binary that I've built from a clean checkout of viewer-release at the same level of changes... what the eff is going on here?
-
repo owner
Ok, I think I have isolated the issues and fixed them :
"Add To Outfit" and "Replace Current Outfit" indeed empty the COF, then fill it up again with the old links along with the new ones, and then the viewer is supposed to wear them all again (without showing the user that the attachments and wearables were not worn for a little while). This convoluted way of handling it works like this in the official viewer, but my change in LLAgentWearables::userUpdateAttachments() broke the "wear new links automatically" part.
That fix was necessary for the case when you wear an outfit, then unwear it quickly before the links have all been registered, making parts of it re-attach. It was confusing as hell and clearly a bug that we didn't have before.
The fix to the side effect of that first fix is simple : check in the method LLAgentWearables::userUpdateAttachments() if it comes from a manual inventory action or from a RLV command, and branch accordingly.
-
repo owner
- changed status to resolved
-
repo owner
resolved in rev 85f4f1c3bbd9
-
repo owner
- changed status to open
I've noticed a little more stuff to fix that is related to the outfit handling (namely, when locked items are not part of the outfit we are removing, the objects are left on but their links are removed, which makes them detach automatically - and complain - after the next relog).
-
repo owner
- changed status to resolved
resolved in rev f18844a34188
-
reporter
- changed status to open
still does not work for me running the build that I've built on/for opensuse. Do you have a windows build for me to try?
-
reporter
basically, doing it with the outfits folder right now is not reliable at all. sometimes parts of the old outfit aren't taken off, sometimes parts of the new outfit aren't put on, sometimes a mix of both.
I'm also noticing that the "status" of the outfit i'm wearing flips between "Now wearing" and "unsaved changes" every second or so.
-
repo owner
All I have is the commits I've pushed, I did not release this viewer yet. It works for me but it's slooow to replace an outfit through the Appearance window. The links just take forever to appear, and that's a server-side issue it seems. But it looks reliable. The only real issue I've noticed was when you replace an outfit while wearing RLV-locked items. Their links seem to disappear, but the items are never detached by the viewer even after a relog, until they are unlocked. So that's acceptable to me for now, it's usable and not too frustrating.
-
reporter
well, it is not working here at all. replacing outfit through the outfits floater simply does not work. doing it by going into the inventory, navigating to the outfit in "My Outfits", and doing a "replace outfit" on the folder does work though.
-
reporter
I've built a viewer from your source on windows, no modifications at all on my end, fresh checkout from HG. I see the following bugs:
replacing outfit using the outfits floater takes quite some time
not all links for worn objects are properly created in COF, even though the original objects are properly worn
not all links in the outfit folder are properly bolded
outfit change only works once out of a few tries when you use the outfits floater
"replace outfit" using the actual folder in one's inventory works unreliably too
the whole misbehaviour only affects worn objects, not other wearables i.e. skin, system clothes, tattoos
all of this does not apply to the original viewer from LL, also changing outfits on the official viewer only takes a second or two (on my system), while the process on this RLV build takes way longer.
-
repo owner
I don't know what to say, except this is not at all how it behaves on my side, and all my commits have been pushed to the repo. I'll test more tomorrow if I have to, but I'm positive my fixes did good on this bug.
-
reporter
are you sure everything in your local build tree is committed and pushed?
-
repo owner
Yes, the files are all committed and pushed.
I do notice that sometimes, maybe once every five tries, doing a "Add to Outfit" or "Replace Current Outfit" fails with objects. The wearables are ok, but either the attachments are all worn, or none of them is worn, like the viewer fails a message or something. It happens whether I do it in the Appearance window or in the inventory itself. I'm still looking into it but I really have other things to do, and I'm getting late on them. I'm that close to declaring it a "known issue" and to release it and to look into it later, because the rest behaves well.
-
repo owner
Ok, I have made a few changes : I removed the "if (gAgent.mRRInterface.mUserUpdateAttachmentsUpdatesAll)" condition in LLAgentWearables::userUpdateAttachments(), which was an old trick to manage outfits better, but it seems SSA makes that trick no longer necessary, and even problematic. I've also made it so the 3 menu items in the outfit window are not greyed out while we're waiting for an outfit to load, because sometimes we simply do not receive the notification and then we're stuck. The result of these changes is that the loading of an outfit is much faster, but it still fails once in a while. I have no clue why, probably a race condition somewhere.
-
reporter
Getting there, now it properly replaces everything. It still does not recreate all required links in COF tho, leaving the outfit in "Unsaved changes" state which will break the saved outfit, should the user save it again.
-
repo owner
Well, when I switch between two outfits (a black dress and a pink dress) by right-clicking and selecting "Wear - Replace Current Outfit" for over 50 times, everything is working properly for me :
- The current outfit is removed, including attachments
- The new outfit is created, all the links appear in the COF
- Less than a second later, all the links in the COF switch to the state "worn"
- When clicking on the small drop down list on the right of "Save As", I see the "Save" menu item is greyed out, which means to me that the outfit is already in a clean state
I don't know how to make the viewer wear an outfit without creating its links in the COF. Do you have a repro ?
-
reporter
When I wear an outfit by opening the outfits floater, selecting one, and click the "wear" button, all outfit parts are properly worn, but not all links in COF are created. This reproduces not every time but in about 80% of tries. If the user would save the outfit again now it would be missing some pieces after.
-
reporter
To me it looks as if the "wear" options in the outfits floater and the wear options in the inventory context menu call different routines. With the inventory folder context menu all works ok now, from within the outfits floater it does not.
-
repo owner
That's what puzzles me, because they both call the same function : LLAppearanceMgr::wearInventoryCategory(). What I do is write "gAgent.mRRInterface.mUserUpdateAttachmentsCalledManually = TRUE;" just before the calls to distinguish what to do when LLAgentWearables::userUpdateAttachments() is called later (that's an asynchronous call). If the method has been called from an RLV function, the boolean will be FALSE, otherwise TRUE. Then set to FALSE afterwards to clean it up.
(note : that comment was supposed to be posted 2 days ago, but for some reason I forgot to validate it after typing, probably got interrupted by a cat or two)
-
reporter
Build from your latest source, still the same: not all items in an outfit in the outfits/appearance floater get properly marked as worn (bold) in there, and the outfit is in state "unsaved changes".
-
repo owner
The problem is that I can't reproduce this bug reliably. I have observed this a few times as well, but could never find the cause. I can't fix a bug that is so random. Any information is welcome.
-
reporter
ok, here's how to repro this bug on my end, as detailed as I can make it:
- login to SL using a recent RLV build
- Open the "Appearance" floater (from the menu. "Me" -> "Appearance")
- pick any of your saved outfits, click "wear"
- Observe how not all parts of your previously worn outfits get taken off, and/or how not all parts of the new outfit are put on, compare with the content of the respective folder under "My Outfits" in your inventory
I've taken a few screenshots that illustrate the problem and sent you a share to the google drive folder where I've put them.
-
reporter
one more detail: it happens exactly the same with RestrainedLove = false, so whatever the problem is, it's not inside a if(gRRenabled) {} block...
-
repo owner
Thank you for the very detailed repro for dummies :p
That's exactly what I was testing, and I'm sorry to say that on my end, it works perfectly. I'm switching between two outfits : black dress and pink dress. Some items are common to both (a RLV relay, my shape, skin, hair and eyes, a HUD, and a couple other things), most are unique to each. I have tested with both the context menu ("Wear - Replace Current Outift") and with the "Wear" button at the bottom of the floater. I must have done this 30 or 40 times, on both my work alt and my main each, never had one single bug, the outfits switched just fine.
The fact that it happens whether or not RestrainedLove = FALSE is interesting, but it could mean it is either a recent code of mine (in which case, putting it in a "if (gRRenabled)" block would be a good idea for testing, but not for release, since this code is basically a fix for LL's code, so it shouldn't be deactivated on my viewer), or a bug in the original code base. Either case, I can't repro it here so I'm not sure what I can do.
On a side note, to me, the "My Outfits" tab of the Appearance window is rather useless. You can't make a hierarchy of outfits, it's always "wear all", "unwear all" or "replace all", and you can't even manage your links from there, you have to do it in your inventory anyway. I personally never use it.
-
repo owner
I have just removed an old piece of code, which purpose was to force the COF version when a mismatch was detected. It used to work well before SSA, but I think it does more harm than good in SSA. Now, I don't think it really has anything to do with this particular bug (that I still cannot reproduce, except once, but that was while the COF was mismatched, hence my change), but I noticed there was a problem sometimes, that would make the viewer give up requesting a bake of the outfit, most often when an alpha layer was involved (could never reproduce it without an alpha layer in the outfit when changing it). As a result, it would look OK locally, but other people would see a mess of textures on the avatar's body, and it would never re-bake out right, even when forcibly re-baking with Ctrl Alt R. It would not let the avatar height offset be updated either, only a relog would set things straight.
It seems to work much better after that piece of code has been removed. Can you build a viewer with this latest commit and tell me if it changes anything please ? Since it used to manipulate the COF version, maybe it has something to do with the attachments not being worn correctly.
-
reporter
"I personally never use it" explains why you didn't see the bug yourself... :) I can definitely understand your feelings about not being able to have a proper folder hierarchy in there, I'd love to have one too. But putting that aside, it is a main feature of the original LL viewer. so I think it should work the same way in RLV... or at least not be broken :)
That being said, the bug still reproduces with a build from your latest source code. now even links pointing at non-prim wearables (shape, to be precise) are affected...
-
reporter
...and from the looks of it, now the viewer is stuck in "changing appearance", can't change into another outfit...
-
repo owner
Well I don't see the bug EVEN when using the Appearance window :p
I'm puzzled when you say it is stuck in "changing appearance" (I presume that means the "tool" icon turned into a rotating circle and is not coming back). I specifically added code to make the three context menu items always available, changing appearance or not.
And in my point of view, it is not broken, since I can't manage to reproduce that bug, even when changing outfits dozens of times. Really, it looks like we are not testing the same viewer, although you are building from the same code, which is up-to-date. I'm stumped.
The only issue I see, sometimes, is when I change outfits fast, there seems to be some kind of throttle in the sim, which ends up answering "service unavailable". And my avatar skin would stop being baked until I wait a few seconds, and request a change to the appearance again (even a simple change in the Z offset will help). But I never ever saw the attachments links, let alone the tape links, to show on my body and in the COF without showing as worn in the Outfit tab. I saw it only once, and that was during a COF version mismatch, before I removed my hack.
-
reporter
i can reproduce the error 100%... so i really do not know what is going on. The only visible difference here that I can think of is that you're testing on windows, i'm on linux...
-
repo owner
Or it could be the sim (although I have tested in several, mainland and private alike), or a debug setting that differs in our viewers. I really have no idea. If you have time, maybe you could remove one portion of my code (that is not contained in a "if (gRRenabled)", as you pointed out) at a time, and test. Maybe that could help.
-
reporter
That's what I have planned to do, but I'm going to actually compare RLV and V-D side by side. Thanks to linux I have tools to do that... :)
Bad news is, not until some weeks from now.. next week and the week after I'll be AWOB (away on business) and my laptop just has too small a screen for this kind of stuff (and not enough juice to build a viewer fast enough).
-
repo owner
No problem, and thank you. This is probably something silly, but since I can't reproduce it on my side, I can't fix it myself. In the meantime, I'm going to release this viewer with all its other fixes and enhancements (after the fix I added yesterday about locked items that were disappearing from the COF when replacing outfits), and I'll be able to move on to something else.
-
repo owner
So, I have removed two pieces of code that, to me, could potentially be problematic. One that would force updating the shape after an outfit change (it looked necessary at first... now it seems to be totally unnecessary), and another that would add a link to the current shape before removing it right away... although we do an enforceCOFRestrictions right after that. It's like begging for a race condition. Yes, both pieces of code were mine so I have no shame butchering them away. Hehe. I'm told by a friend that it helps with the missing links issue, can you test on your side and confirm please ?
-
reporter
Can do, but not until the weekend...
-
repo owner
So I've got new information ! I discovered that the bugs you mentioned (and others experienced) happen ONLY when "Http Inventory" is checked in the Develop menu. When it is checked, the "IncrementCofVersion" capability is used, in fact, a whole lot of things are handled differently. But when it is unchecked, it works like a charm.
I also discovered that when "Http Inventory" is checked, the outfit problems happen only when an attachment is locked. They don't happen when nothing is locked, so that's a good lead.
However, still when that bit is checked, even when nothing is locked, changing the Z offset will force the shape to be unworn, turning into Ruth (for everybody except the user).
So, for now, unchecking that "Http Inventory" menu item (and then relog) fixes the issue. I will try to find out exactly what happens when it is checked and something is locked.
-
reporter
hmm... I am not wearing anything locked when I have that bug hitting me... but I do have HTTP inv checked on. Lemme verify that behaviour with my latest linux build that just finished.
-
reporter
...you know what, with your latest sources and not wearing anything locked I can't reproduce the bug anymore... changing outfits through the appearance list works fine now, and it doen't matter if I have HTTP Inventory on or off... I do sometimes get "changed" status on outfits that haven't been modified since I last used them, so it's not 100% perfect yet.
-
repo owner
Yes, it works fine as long as nothing is locked, but the Z offset feature is problematic : it won't register the change until we rebake (with my addition that cleans up the COF when doing so), and sometimes the shape will even be unworn, switching the avatar shape back to Ruth.
And when something is locked, some of the bugs you described occur at times.
-
reporter
like i said, i wasnt wearing anything locked wjen I was fighting with this... anyway with your latest changes changing outfits works fine now but there is still the issue of the outfit being stuck in state "unsaved changes" which will confuse people who are actually using the outfits system... like me, my wife and pretty much anyone I know, except you... :)
-
repo owner
I know, but I don't know how to fix that yet.
-
repo owner
Today I'm looking at that "outfit being stuck in unsaved changes" bug... It appears to me that it is in fact working exactly as designed (by LL) : you wear an outfit through the appearance window, it displays "Now wearing...". If you later remove or add some items from the inventory, the outfit switches to "Unsaved changes". But if you remove them afterwards, or make it so (still from the inventory) that what you are wearing is exactly like your initial outfit, then it switches back to "Now wearing...". Same thing even when the shape changes due to a modified Z offset. As soon as the new value is committed and comes back to the viewer, the outfit is updated as well.
Which means the viewer correctly checks the status of the current outfit every time something changes in it.
This works both with "Http Inventory" on and off.
If there is a bug on your side, can you explain how I can reproduce it please ? I don't think there is an open issue on this problem.
-
Is this fixed? I have a ticket that reports a similar problem. https://sourceforge.net/p/team-purple/kokua/tickets/336/
-
repo owner
- changed status to resolved
It is fixed when HTTP Inventory is unticked in the Advanced menu, but I think there are still issues when it is ticked, namely the shape being unworn and not worn again, turning the avatar into Ruth. But I have not tested this in months and haven't heard about this bug in months either, so I will mark it as Resolved (for the third time) now.
- Log in to comment
Another effect: not all previously worn attachments are taken off properly either.