You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
Found some big chunks of possibly-dead code in object update in llobjectupdate.cpp. Just want to know if that's ever used.
Object updates come in various specific lengths, each of which indicates a different format. For uncompressed updates, sizes 76 (for avatars) and size 60 (for other objects) are the sizes usually seen. Sizes 48 and 32, for "terse 16" updates, never seem to be used. Nor is size 16, the "terse 8" update, used. I put in debug print to print a WARNING if they are, and cursory testing isn't hitting those warnings. "Terse 16" and "Terse 8" updates seem to be an early form of data compression. If that was used, some object positioning would be rather inaccurate.
There's code for "compressed updates", and that's regularly used. Did "compressed updates" replace the "Terse 16" and "Terse 8" updates? From logging, it looks like it.
What were you doing when it happened?
Testing a version of Firestorm with extra logging.
What were you expecting to happen instead?
What's happening is fine.
Other information
There's some cleanup in progress, with UDP asset serving support going away. If these legacy object update formats are also unused, that code could come out as well. If those "Terse 16" and "Terse 8" update formats are ever used, I'd like to know how to get a sim to generate some, for testing.
If someone can answer this question quickly, thanks. If not, so be it.
The object update code, LLViewerObject::processUpdateMessage, is one huge function about 1500 lines long, and has some problems which produce visual artifacts at region crossings. I've been chasing those down, which is why I'm looking too hard at that function. (This isn't why region crossings fail; it's just why they sometimes have big bogus moves on screen that snap back.) Not having to maintain untestable code would help a bit here.
Original Jira Fields
Field
Value
Issue
BUG-225654
Summary
Obsolete object update formats?
Type
Bug
Priority
Unset
Status
Accepted
Resolution
Accepted
Reporter
animats (animats)
Created at
2018-10-18T03:10:36Z
Updated at
2018-10-24T16:25:57Z
{
'Build Id': 'unset',
'Business Unit': ['Platform'],
'Date of First Response': '2018-10-24T11:25:57.946-0500',
"Is there anything you'd like to add?": 'There\'s some cleanup in progress, with UDP asset serving support going away. If these legacy object update formats are also unused, that code could come out as well. If those "Terse 16" and "Terse 8" update formats are ever used, I\'d like to know how to get a sim to generate some, for testing.\r\n\r\nIf someone can answer this question quickly, thanks. If not, so be it.\r\n\r\nThe object update code, LLViewerObject::processUpdateMessage, is one huge function about 1500 lines long, and has some problems which produce visual artifacts at region crossings. I\'ve been chasing those down, which is why I\'m looking too hard at that function. (This isn\'t why region crossings fail; it\'s just why they sometimes have big bogus moves on screen that snap back.) Not having to maintain untestable code would help a bit here.',
'ReOpened Count': 0.0,
'Severity': 'Unset',
'System': 'SL Viewer',
'Target Viewer Version': 'viewer-development',
'What just happened?': 'Found some big chunks of possibly-dead code in object update in llobjectupdate.cpp. Just want to know if that\'s ever used.\r\n\r\nObject updates come in various specific lengths, each of which indicates a different format. For uncompressed updates, sizes 76 (for avatars) and size 60 (for other objects) are the sizes usually seen. Sizes 48 and 32, for "terse 16" updates, never seem to be used. Nor is size 16, the "terse 8" update, used. I put in debug print to print a WARNING if they are, and cursory testing isn\'t hitting those warnings. "Terse 16" and "Terse 8" updates seem to be an early form of data compression. If that was used, some object positioning would be rather inaccurate.\r\n\r\nThere\'s code for "compressed updates", and that\'s regularly used. Did "compressed updates" replace the "Terse 16" and "Terse 8" updates? From logging, it looks like it. ',
'What were you doing when it happened?': 'Testing a version of Firestorm with extra logging. ',
'What were you expecting to happen instead?': "What's happening is fine. ",
'Where': 'Linux 16.04 LTS, modified Firestorm 5.1.9.',
}
The text was updated successfully, but these errors were encountered:
I asked one of the devs to have a look and they said this was a valid code clean up request. I've imported it based on that feedback. No ETA on when this could be worked on though.
Thanks
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What just happened?
Found some big chunks of possibly-dead code in object update in llobjectupdate.cpp. Just want to know if that's ever used.
Object updates come in various specific lengths, each of which indicates a different format. For uncompressed updates, sizes 76 (for avatars) and size 60 (for other objects) are the sizes usually seen. Sizes 48 and 32, for "terse 16" updates, never seem to be used. Nor is size 16, the "terse 8" update, used. I put in debug print to print a WARNING if they are, and cursory testing isn't hitting those warnings. "Terse 16" and "Terse 8" updates seem to be an early form of data compression. If that was used, some object positioning would be rather inaccurate.
There's code for "compressed updates", and that's regularly used. Did "compressed updates" replace the "Terse 16" and "Terse 8" updates? From logging, it looks like it.
What were you doing when it happened?
Testing a version of Firestorm with extra logging.
What were you expecting to happen instead?
What's happening is fine.
Other information
There's some cleanup in progress, with UDP asset serving support going away. If these legacy object update formats are also unused, that code could come out as well. If those "Terse 16" and "Terse 8" update formats are ever used, I'd like to know how to get a sim to generate some, for testing.
If someone can answer this question quickly, thanks. If not, so be it.
The object update code, LLViewerObject::processUpdateMessage, is one huge function about 1500 lines long, and has some problems which produce visual artifacts at region crossings. I've been chasing those down, which is why I'm looking too hard at that function. (This isn't why region crossings fail; it's just why they sometimes have big bogus moves on screen that snap back.) Not having to maintain untestable code would help a bit here.
Original Jira Fields
The text was updated successfully, but these errors were encountered: