Use attachment info to prevent accidental nudity

[vir-linden]

Server work in https://github.com/secondlife/server/issues/679 includes list of attachment asset ids in the appearance message. We should be able to use this information to help prevent accidental nudity, by keeping the avatar clouded until all expected attachments have rezzed fully.

[vir-linden]

This work should go in Maint A or later, since Maint A is the first viewer that contains support for the new message payload.

[vir-linden]

Related work: https://github.com/secondlife/viewer/issues/676

[nat-goodspeed]

Prevent "wardrobe malfunction"

[beqjanus]

I hope that this is made optional. We will almost certainly make it so. We get far more complaints about the time it takes to "de-cloud" than we ever get about accidental nudity. If people are really that concerned then they need to wear BOM undies.

[akleshchev]

I hope that this is made optional. We will almost certainly make it so. We get far more complaints about the time it takes to "de-cloud" than we ever get about accidental nudity.

The right solution is probably to add load priorities (ex: sort mSkinRequests by priority or avatar or just postpone request creation, the same for whatever requests attachments). So that avatars would load one at a time instead of all at once.

[vir-linden]

Grouping requests by avatar and requesting info for nearby avatars first should improve the declouding experience for everyone.

How much people care about accidental nudity is certainly going to vary based on the person and the context, so if this check substantial slows down loading it might make sense to have a preference setting

[akleshchev]

so if this check substantial slows down loading it might make sense to have a preference setting

It appears to speed up loading process. Since viewer is now certain no more attachments will arrive it doesn't need to wait as long just in case something is missing.

Frustatingly there are still issues of 'accidental nudity' but this time caused by lods being low (like a dress that consists of a single triangle at a low LOD).

P.S. changed that 'just in case' delay from 45s to 15s, probably can make it 5s, but decided to keep at 15s because of bad content.

[vldevel]

I hope that this is made optional.

I, for one, will not even bother implementing this in the Cool VL Viewer... :-D

[ChorazinAllen]

I'm echoing Beq's and Henri's feedback for Kokua - time spent de-clouding is a major source of pain already. Even if this is believed to actually improve things, there should be a debug setting to override the behaviour.

[akleshchev]

I'm echoing Beq's and Henri's feedback for Kokua - time spent de-clouding is a major source of pain already

The whole point of getting attachment count was to reduce 'wait for unknown attachments' decloud time. Because now we know that no more attachments are pending thus no need to wait. It does help with 'accidental nudity', but the whole point of the decloud delay was to fight that, attachment count is just more reliable.

I can add a debug setting that would return those extra 30s wait time instead of checking attachment count, but it isn't practical. When I visited 'new london', only 1 of ~20 avatars failed an attachment count check and took usual amount of time to load, everyone else loaded faster. But I will ask QA to make sure declouding is now faster.

[vir-linden]

Let's establish what effect this has on loading time before getting into preferences.

[akleshchev]

For QA:

1. Please record avatar decloud time on an agent heavy region prior and after this change.
2. Confirm all agents decloud and don't get stuck as cloud indefinetely

[georgebproductengine]

Failed QA. Verified on the Second Life Release 7.1.7.8993168213 (64bit) on Win10/OSX in the scope of https://github.com/secondlife/iqa/issues/226. After clearing the cache, the decloud time of some avatars is 120-150 seconds in the test build versus 20-40 seconds in the production .

[akleshchev]

Looks like I missed some cases where attachments have null id.

Commented in server ticket, response: null attachments are attachments server is aware of but aren't inwold yet.

[valeriiaaproductengine]

Failed QA.

On average, on Win10 all avatars load correctly in a busy location after 50 seconds.

On OSX, all avatars in the busy (http://maps.secondlife.com/secondlife/London%20City/90/192/23) location did not load completely. The check was carried out several times during an average of 10-20 minutes of stay at this place.

Verified on the Second Life Release 7.1.9.9473057952 (64bit) on Win10/OSX in the scope of https://github.com/secondlife/iqa/issues/260.

[akleshchev]

On OSX, all avatars in the busy (http://maps.secondlife.com/secondlife/London%20City/90/192/23) location did not load completely. The check was carried out several times during an average of 10-20 minutes of stay at this place.

Did you check on default Relase? Code added in scope of this task is platform idnependent and I wasn't able to repro, all avatars loaded under a minute.

[valeriiaaproductengine]

Hi @akleshchev ! I checked the busy (http://maps.secondlife.com/secondlife/London%20City/90/192/23) location on the Release 7.1.8.9375512768 build on OSX. Within about 2 minutes, all avatars were loaded. Thank you.

[AtlasLinden]

Let's review the decloud time in a DeltaFPS build. Moving milestone and sending to testing again.

[dmytrohproductengine]

Passed QA. Verified on the Second Life Release 7.1.10.10582490681 (64bit) on Win10/OSX in the scope of https://github.com/secondlife/iqa/issues/316.

The (http://maps.secondlife.com/secondlife/London%20City/90/192/23) location was used. Win10: The user is declouded in 5 seconds, nearby avatars are declouded in 1 minute. OSX: The user is declouded in 10 seconds, nearby avatars are declouded in 1 minute 30 seconds.