Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008668opensim[REGION] Scripting Enginepublic2020-03-02 09:092020-03-18 08:01
Reportertampa 
Assigned Totampa 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version0.9.1.0 
Target VersionFixed in Versionmaster (dev code) 
Summary0008668: Objects fail to send updates until selected
DescriptionThis started happening a few months ago I must assume, because I do recall this not being an issue sometime in fall last year. Since then at some point objects that change their scale or other properties that have been sitting idle on a region for some time, when triggered to then change the viewer does not display this change until the object is selected with a right click.

The only way to fix this is to re-compile the script it seems, which is odd. Not even a script reset helps. I recorded this in FS, Singu and Dayturn so far, here is an example from Dayturn:

http://two66.com/2020-02-24_22-33-00.mp4 [^]

I wonder if some changes to scene update handling or anything remotely to this could have caused it, as mentioned it only started happening in recent months and I have kept this region on master code on a weekly basis.

This is really starting to manifest itself quite badly since I started creating more objects that rely on PrimitiveParams functions, specifically those that also use DetectedGrab and other user-interaction functions as they simply don't update their "state" until right clicked.

I worry that this could become a larger issue affecting other scene updates hence why I opened this ticket. I have regions on ZetaWorlds that can somewhat reliably reproduce this issue if anyone wants to see for themselves.
Steps To ReproduceCreate a script with llSetLinkPrimitiveParamsFast for PRIM_SIZE triggered via a listener and wait a certain amount of time before triggering it, could be up to 48 hours. Logging out and clearing cache does not seem to trigger this.

Try to engage the prim size change script via the listener and observe the prim not changing scale, when that is the case, right click on the prim and watch it change size as normal while selected.

I have been somewhat reliable in reproducing this by placing the script on a region with YEngine and ubode, rebooting the region, then observing the script only updating prim scale when selected.
Additional InformationI initially thought this was something in regards to timers, but that does not seem the case as the video shows even reducing the timer, potentially running into function overrun does not cause the issue.

I do recall some changes to certain throttles and other stuff happening in recent months after which I received some concerns from various people and grid owners asking what the impact of those were as they recorded a performance drop specifically loading avatars and dealing with a lot of scene updates. I am not sure if that is related.

It seems if the loop for changing the prim size finishes and the prim was not selected during the change the final scale seen in the viewer does not match the scale it is supposed to be e.g. prim is supposed to be 3 meters tall, but the viewer only shows 2 meters even when right clicked. When the loop is triggered again while the prim is selected though the prim quickly snaps to 3 meters before scaling down again as per the script loop.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineubODE
Script EngineXEngine
EnvironmentMono / Linux64
Mono Version6.x
ViewerFirestorm, Dayturn, Singu
Attached Files

- Relationships

-  Notes
(0036246)
tampa (reporter)
2020-03-03 04:49

Changes on master seem to solve this issue in regards to reboots no longer breaking prim scale updates. Will monitor if this breaks down again over time, but I suspect this is all it was.
(0036290)
tampa (reporter)
2020-03-18 08:01

Did just try again and no problems anymore using master, 99% sure this is fixed so resolving for now, thanks for the fix :)

- Issue History
Date Modified Username Field Change
2020-03-02 09:09 tampa New Issue
2020-03-03 02:42 tampa Steps to Reproduce Updated View Revisions
2020-03-03 04:49 tampa Note Added: 0036246
2020-03-18 08:01 tampa Note Added: 0036290
2020-03-18 08:01 tampa Status new => resolved
2020-03-18 08:01 tampa Fixed in Version => master (dev code)
2020-03-18 08:01 tampa Resolution open => fixed
2020-03-18 08:01 tampa Assigned To => tampa


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker