Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008934opensim[REGION] OpenSim Corepublic2021-10-10 06:222022-01-17 00:15
Assigned To 
PlatformOperating SystemOperating System Version
Product Version 
Target VersionFixed in Version 
Summary0008934: Cachable prims do not scale without position change
DescriptionThis has been an ongoing thing for years now and I keep running into it so many times. Unfortunately the nature of this is that you often times do not see them resetting without relog or as the video in the reproduction steps shows, forcing a prim redraw.

It seems that prims that have sat on a region for a long time become "stuck" in their scale and position. When you attempt to edit them specifically with the scale tool they "snap" back into their previous scale and position, which doesn't show in the viewer until the prim is forcefully redrawn.

Changing the position by a single step in different direction to the scale seems to cause an update to the prim that makes the newly set scale and position stick properly.

Strangely this only seems to happen on regions that have been running for a few weeks and with prims that have been on the region for a long time. Newly created prims within the last 24 hours don't experience this issue.

I'm not one to complain about such somewhat minor things given there is a workaround for this, but it catches me so many times when re-visiting older builds and it ends up just getting to a consistency that can't just be shrugged off as the usual OpenSim lludp voodoo.
Steps To Reproduce [^]

- Create prim.
- Let sit for a couple weeks.
- Change scale using the shift + ctrl scale tool.
- Zoom out or relog to force prim redraw.
Additional InformationThis could potentially be a viewer bug of not properly communicating the changes and only reflecting them locally. It is entirely possible this isn't just a fix that is needed in OpenSim, but also one viewers need to carry along with.
TagsNo tags attached.
Git Revision or version numbermaster
Run ModeStandalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineubODE
Script EngineYEngine
EnvironmentMono / Linux64, Mono / Windows
Mono Version6.x
Attached Files

- Relationships

-  Notes
tampa (reporter)
2021-10-13 07:48

I attempted some of the suggestions made regarding this.

Making the objectcache folder not writable to any user and in the debug settings setting objectcache use to false.

The results are interesting. A lot of the prims I suspected to be stuck are locked now, or at least, when I lock and unlock them I can edit them, but selecting them for edit causes the build menu to behave as if they are locked even if that option isn't set.

Not sure how they could get, let's call it softlocked, like this.

Enabling object cache again and resetting the folder permissions the softlocked prims become editable again. Once again the prims reset after being edited.

Question is now, is this an issue with OpenSim sending the wrong flags about the prims to the viewer causing it to cache them poorly or is the viewer object cache not properly storing the prims and thus won't transmit changes because to it the prims are "locked"?
tampa (reporter)
2021-10-14 11:20 [^]

This is fairly interesting. Not sure whether the relog or the disabling of the ObjectCache caused the prim to appear properly. [^]

Was also able to record the "softlocking" issue when a suspect prim is selected with the ObjectCache disabled in the viewer.

Both of this suggests the viewer messing up. The odd part is that it seems after some time the viewer pushes the prim back to the region as well. I don't see how that should work given the ObjectCache should be a dead end.

What it does clearly show is something wrong with the system of ObjectCache. I will try to disable the ObjectCache in the ClientStack on the region to see what effect that has next.
UbitUmarov (administrator)
2021-10-14 12:07

do not change viewer options about object cache. Some will just do odd things because they are not tested in ages. Viewers are supposed to run with defaults on many of the options, specially low level ones like this
tampa (reporter)
2021-10-14 13:07

As requested I also added

SupportViewerObjectsCache = false

to see if that had any effects. Leaving viewer with ObjectCache enabled.

Trying some suspect prims from what I can tell any changes now properly stick. Will keep my eyes out with that option enabled to see if it returns.

This still doesn't really get to the root of the problem. Is this a communication issue between OpenSim and viewer, a bug or the viewer misinterpreting the data.
tampa (reporter)
2021-12-07 18:45

It seems pretty clear at this point that this is primarily a viewer issue. I had a look at the caching code on OpenSim end and can't see how there would be a bug in that unless the information was somehow malformed on the way out. Turning off object caching on either end seems to resolve this so the culprit is definitely found.

Hopefully this is just some missing handling on the viewer end. Curious as to this not being more widely reported given it seems to be reproducible and quite aggressive when it does occur. I feel a bit singled out not gonna lie :)
tampa (reporter)
2021-12-13 01:57

Made Firestorm aware of the issue now, Dayturn knows about it since last os meeting as well, let's just hope this is easy to fix. [^]
UbitUmarov (administrator)
2021-12-16 09:07

as reported on that jira, that is a viewer BUG
in fact same happens at SL and with original viewer if the scale change is made by a script.

On manual change al SL, ll made regions send a, otherwise useless, TERSE UPDATE, when the prim is selected.
They of course seem to had forgotten the scripts changes.

wonder how many where unjustly accused of not putting toilet cover down..
tampa (reporter)
2021-12-16 11:15

I'm surprised no one seems to have noticed all the years this has been like this given how easy it is to reproduce this even at SL. Hopefully can be resolved as easily as it is reproducible, will close this out when the jira has been resolved. Don't think more changes are needed on our end, but who knows.
tampa (reporter)
2022-01-17 00:15

According to LL and Firestorm the bug has been resolved on the viewer end and now prims are once again behaving themselves. If all goes well the next release of FS at least will have that fix, I'll close this when that has happened. Lovely to see such a quick fix to this, thanks everyone!

- Issue History
Date Modified Username Field Change
2021-10-10 06:22 tampa New Issue
2021-10-13 07:48 tampa Note Added: 0038004
2021-10-14 11:20 tampa Note Added: 0038010
2021-10-14 12:07 UbitUmarov Note Added: 0038012
2021-10-14 13:07 tampa Note Added: 0038013
2021-10-14 15:31 tampa Git Revision or version number => master
2021-10-14 15:31 tampa Environment Mono / Linux64 => Mono / Linux64, Mono / Windows
2021-10-14 15:31 tampa Summary Old prims do not scale without position change => Cachable prims do not scale without position change
2021-12-07 18:45 tampa Note Added: 0038286
2021-12-13 01:57 tampa Note Added: 0038293
2021-12-16 09:07 UbitUmarov Note Added: 0038295
2021-12-16 11:15 tampa Note Added: 0038296
2022-01-17 00:15 tampa Note Added: 0038343

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker