Maestro Linden commented at 2013-02-25T21:35:18Z

Hi Whirly, thanks for the report. It looks like the delay in full object updates in objects which are behind the avatar is affecting Meeroos; this bug was reported in a similar case in an internal issue:

Steps to Reproduce

1. Log 2 users into affected region on Aditi such Product Engine Apollo2
2. Have User A face west
3. Have User B stand 20 m behind User A
4. Have User B build an object
5. Have User B edit the object and change the color to green
6. Have User A turn around 180 degrees so the object comes into view
7. Observe that User A first sees the object as the default wood color and then the green color updates
   Note this could also apply to other object updates such as position, etc..

Maestro Linden commented at 2013-02-25T21:36:35Z

A server-side change to mitigate this issue is in the works, by the way.

Whirly Fizzle commented at 2013-02-25T22:29:12Z

Ahh great! Thank you :)

Whirly Fizzle commented at 2013-04-03T00:49:41Z, updated at 2013-04-03T00:53:28Z

Heya Maestro,

Todays roll of main channel to 13.03.22.272563 is supposed to include a fix for this issue: Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779[c]) (http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/13#13.03.22.272563)

I am seeing no improvement at all and this bug still reproduces.

http://maps.secondlife.com/secondlife/Ruiz/159/80/1502
You are at 256,927.0, 287,568.0, 1,501.7 in Ruiz located at sim10324.agni.lindenlab.com (216.82.50.46:13004)
Second Life Server 13.03.22.272563

Whirly Fizzle commented at 2013-04-03T01:07:30Z

Your above repro however seems fixed.

Andrew Linden commented at 2013-04-15T21:05:27Z

I'm reopening this bug. Linked objects that move many of their child prims at once may have their various ObjectUpdates arrive over several seconds, which makes the linked object appear disconnected for a long time – the object updates piecemeal. This is especially noticeable when the viewer has a low bandwidth setting.

The above problem was not solved by the earlier work for getting non-visible updates to sent to the viewer after a maximum delay expiry.

Whirly Fizzle commented at 2013-04-15T21:21:22Z

Thanks Andrew.

I have a message that the Meeroo creator wanted added to this issue:

It might help if you updated that ticket and let Andrew know that each animation "frame" is created by a single llSetLinkPrimitiveParamsFast() with commands to move/scale/rotate every prim for that frame in one giant call. Previously, clients would get the update for all child prims in one single update/at the same time, and now it seems they come in multiple seperate updates from the server in random order
I can give him a "robo roo" that will let him click for a menu to play specific animations on command if that would help him repro/fix it.

Whirly Fizzle commented at 2013-04-15T21:43:14Z

The Meeroo creator passed you the robo Roo inworld named "BUG-1779 repro object"

He asked me to also add this info - please let me know if you wish a seperate issue filed for it:

The Robo Roo I passed Andrew is also good at demonstrating another long standing bug with the client cache I dont know if has ever been reported.
I think this has been probably a huge network sink for them since the dawn of SL and they don't even know it.
I know its true for sculpt maps, but i'm not sure if its true for all textures
The bug is, the instant a sculpt map has all references removed to it, the client deletes it out of its local cache and it has to refetch it from the server the next time it encounters it. This is not healthy cache behavior. It should only purge unreferenced items when the cache is full.
Some of the legs use different sculpts when it animates, so you see the sculpts disappear/reload in every time you play the walk anim. But if you replay it again, those sculpts should be in a local cache a second later, but instead, you see them disappear and reload every time it plays the walk anim.
The client should at the very least have the file cached on disk locally and not hit the server. That or it just takes an excessive amount of time to reload it from disk. I dont have enough insight into the client workings to know if its really hitting the server, but obviously something is broken in the caching of sculpt maps.
If you have enough roos walking around at least one of them is using the alternate sculpt maps and you dont notice the bug
And actually, every meeroos eye prim has an invisible particle poofer that poofs out every sculpt map used by the eyelids, so if you just have a single roo in frame, you dont see the eyelid sculpts pop in/out over and over with each blink frame which i would LOVE to remove in a later update if they ever fix this issue

Henri Beauchamp commented at 2015-07-13T17:27:47Z

I just noticed this JIRA...

I fixed this issue while backporting the Interest List code to the Cool VL Viewer, 2+ years ago. It's because of missing code in LL's implementation of LLViewerRegion::eCacheUpdateResult LLViewerRegion::cacheFullUpdate(LLDataPackerBinaryBuffer& dp, flags)
In this function, LL's code fails to also update the flags (with loadFlags()) on the existing objects in the objects list.

TPV developers can see (and freely reuse in their viewer) the fix in the Cool VL Viewer sources, llviewerregion.cpp, lines 2237 to 2254. Lindens will have to find the fix by themselves, since they refuse to reuse my code...