Orphaned records in inventoryitems for Current Outfit folder content

[Vinhold]

When an avatar creates an outfit, a linked record is created in the Current Outfit folder with assetType=25 and the AssetID is the folderID folder placed in the My Outfits folder in the inventoryfolders table. When the Outfit is removed from the Appearance or the Outfits in the Inventory window, the linked record in the Current Outfit folder is not removed. Over time an accumulation of a lot of orphaned records build up in the inventoryitems table. I recommend that the process called to remove an outfit, also include removing the inventoryitem record where assetID=inventoryitem.folderID and assetType=25.

-- List of orphan records in inventoryitems
Select *
From inventoryitems
Where assetType=25 and assetID not in
(Select folderID From inventoryfolders)

[kf6kjg]

Is this removing the currently worn outfit or removing an outfit that is not currently being worn?

[kf6kjg]

Doing detailed testing with an instrumented Halcyon instance, a duplicate is made when the user logs in and does a SaveAs of the currently worn outfit. For some reason the viewer does not know that the previously worn outfit was being worn and does not send a request to remove it.

I can confirm that upon login the viewer (Firestorm 4.7.5 (47975)) marks the avatar as having "No outfit".

I think this is the real bug here: either the viewer is not handling correctly what the avatar is currently wearing at login or Halcyon isn't sending it right. Going to test with IW3.

[kf6kjg]

Cannot replicate in IW3 3.0.2 - the viewer sees what's being worn without a problem.

However, it still might be prudent to have Halcyon clean up any old links when a new outfit link is created without waiting for the viewer to send the remove command.

[ddaeschler]

I think this issue can be closed once the changes to remove the extra links have been tested.

[Vinhold]

Just for the record, here is a test I did on several viewers and done in Gospel World, InWorldz and Second Life: http://www.gospellearningcenter.com/resources/viewer%20-%20grid%20tests/default.html
I also did a follow up test and report:

---

Viewer Active Outfit Test:
I used IW V3 to clean and set the active outfit. Ran all test viewers to see who got the active outfit.
Firestorm, Alchemy, Kokua could not detect the Active Outfit, but correctly set all the options and displayed the content in COF. Singularity appeared to have it correct.

Clearing the cache in all viewers had minor change in the results.
Only Alchemy got the correct Active Outfit as a result of cache change.

I used Firestorm to set the Active Outfit. Manually cleared the extra folder link from the DB. Re tested all the viewers again. FireStorm, IW V3, Alchemy and Kokua could not display the correct active outfit. Singularity seemed to have it correct.
I remembered that my DB edit did not flag the change in the COF version so manually updated that and re ran the tests. FireStorm, Alchemy, Kokua still could not get it. IW V3 got it perfectly. No change in Singularity.

Summary:
Only IW V3 could correctly identify the Active Outfit when the COF version was changed if there was any server side outfit change regardless of the cause of change. If the viewer does not keep the COF outfit folder links cleaned up when setting an outfit active, it will not display it on a relog. Regardless of any server side cleaning done, viewers that are not getting it correct still will not figure it out.

If any changes are made to the COF content on the server to enforce the "rules", it will not matter as that is the same as it being changed by any other viewer. This may be one of a few cases where that is true.

Singularity was not really helpful in the tests I have done as it was not doing the My Outfit floater (same as Appearance in the other viewers) to show the active outfit. I will not be using it again.

---