MantisBT - opensim
View Issue Details
0008623opensim[REGION] OpenSim Corepublic2019-11-02 13:542020-03-19 08:52
tampa 
tampa 
highmajorrandom
resolvedfixed 
0.9.1.0 
master (dev code) 
Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
ubODE
XEngine
Mono / Linux64
6.x
Firestorm, Dayturn, Singu
0008623: llSetLinkPrimitiveParamsFast inside for loop not updating
As visible here https://youtu.be/cQp_pFHcpG8 [^]

when llSetLinkPrimitiveParamsFast is put inside a for loop to change a prims size to make a rolling effect the new size information is not transmitted to the viewer. Before recent master builds this worked flawlessly each time, now the shown behavior happens 70% of the time and only very rarely does the expected behavior(smooth scaling of the prim) occur.

As shown the only way to actively get the effect is by right clicking the prim in question, then updates about the prim size are sent.

I have tried different viewers and different network settings, three more people are reporting seeing the same thing.

This is on XEngine with ubODE on master
Create a prim and place a script inside that within a for loop changes the prim size: llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE... based on the loop integer
No tags attached.
? blinds.lsl (2,328) 2019-11-02 14:47
http://opensimulator.org/mantis/file_download.php?file_id=4903&type=bug
? controller.lsl (310) 2019-11-02 14:48
http://opensimulator.org/mantis/file_download.php?file_id=4904&type=bug
Issue History
2019-11-02 13:54tampaNew Issue
2019-11-02 14:45BillBlightNote Added: 0035816
2019-11-02 14:47tampaFile Added: blinds.lsl
2019-11-02 14:48tampaFile Added: controller.lsl
2019-11-02 14:50tampaNote Added: 0035818
2019-11-02 14:57UbitUmarovNote Added: 0035819
2019-11-02 14:59BillBlightNote Added: 0035820
2019-11-02 15:31tampaNote Added: 0035821
2019-11-02 15:51tampaNote Added: 0035822
2019-11-02 19:17djphilNote Added: 0035823
2019-11-02 20:01djphilNote Added: 0035824
2019-11-02 20:21djphilNote Edited: 0035824bug_revision_view_page.php?bugnote_id=35824#r8542
2019-11-02 20:32djphilNote Edited: 0035824bug_revision_view_page.php?bugnote_id=35824#r8543
2019-11-02 21:03djphilNote Edited: 0035824bug_revision_view_page.php?bugnote_id=35824#r8544
2019-11-02 21:03djphilNote Edited: 0035824bug_revision_view_page.php?bugnote_id=35824#r8545
2019-11-02 22:04djphilNote Edited: 0035824bug_revision_view_page.php?bugnote_id=35824#r8546
2019-11-05 21:08tampaNote Added: 0035829
2019-11-05 21:51djphilNote Added: 0035833
2019-11-13 06:33tampaNote Added: 0035856
2019-11-13 11:17tampaNote Edited: 0035856bug_revision_view_page.php?bugnote_id=35856#r8573
2020-03-19 08:51tampaStatusnew => resolved
2020-03-19 08:51tampaFixed in Version => master (dev code)
2020-03-19 08:51tampaResolutionopen => fixed
2020-03-19 08:51tampaAssigned To => tampa

Notes
(0035816)
BillBlight   
2019-11-02 14:45   
Tried to replicate this ...

Couldn't on osGrid ..

https://i.gyazo.com/988fa546864f8d8dab89b1bc8bd3a388.gif [^]
(0035818)
tampa   
2019-11-02 14:50   
Uploaded both scripts, Prim should have 100 as description and Path Cut set to: 0.1250 and 0.6250

I tested this on master code with Firestorm, Dayturn and Singularity, all showing the same, stock configs and all, so not many variables left that could be the reason. I suspect it is something with scene update throttles, but hard to say, wouldn't mantis this if I wasn't sure there was something being weird :)
(0035819)
UbitUmarov   
2019-11-02 14:57   
just test that on Y
amasing how you expected that to work on X with stock settings..
(0035820)
BillBlight   
2019-11-02 14:59   
Using your script, https://www.dropbox.com/s/mhj6p0frk3xhehi/2019-11-02%2017-58-40.mp4?dl=0 [^]

It is still setup , hg.osgrid.org:80:Dev Outreach Test
(0035821)
tampa   
2019-11-02 15:31   
Like I said, this works 1/3 of the time, then results are as the video I posted, then it fails again, works, fails, works. It's strange.

I also tried on different regions, empty ones, and can get it to work more reliably, which leads me to suspect throttles of some kind introduced in the last 6 months to be causing scene update pauses because too many are sent. Problem is nothing is reported by the region itself, neither in stats nor elsewhere.

So if there is overload how would I even determine where that comes from then? It's the symptom of something else.
(0035822)
tampa   
2019-11-02 15:51   
So I changed the sleep from 0.05 to 0.1 and now it works on the loaded region, set it lower again, fails. Empty region has no change.

Loaded region has 80k prims, 1700 scripts, 600 eps, stable sim fps, no packet loss no overloads or errors, nothing out of the ordinary.
(0035823)
djphil   
2019-11-02 19:17   
I confirm, there is a problem, I managed to reproduce the problem.
For me it happens if the object is not used for a moment (I do not know exactly after how long).
It also occurs if the simulator is restarted.

The problem disappears if I recompile the script.
Reset script has no effect, you must recompile.

Video demo:https://www.youtube.com/watch?v=onuq7Pe8lRs [^]
Script used: https://pastebin.com/JHJztDau [^]

PS: no tested with osSetPrimitiveParams, tested only with llSetLinkPrimitiveParamsFast

I hope that can help a little.
(0035824)
djphil   
2019-11-02 20:01   
(edited on: 2019-11-02 22:04)
Restarting the simulator systematically causes the bug.
Add llResetScript() on change event "CHANGED_REGION_START" DO NOT avoid the problem.

(0035829)
tampa   
2019-11-05 21:08   
Interesting. Frankly under X the changed states have not been reliable at all so I am not surprised. The specific one of region_start indeed far as I know never actually worked.

I did test this initially just after a binary upgrade and reboot so assumed the script cache was empty and it would recompile anyways. I still think it may be partially related to some scene update throttle, but that it started working after I forced the recompile changing the sleep time might hint to your experience with it.

Either way I will have to test how Y behaves with the same script and maybe make it default now as Ubit suggests anyways. I merely reported it out of fear some recent new throttle may be set lower than it should have been :)
(0035833)
djphil   
2019-11-05 21:51   
I have not yet tested with YEngine because I thought I heard that he had some limitations ...
After some research on Google and OpenSim wiki, I could not find a descent documentation for YEngine.
Maybe you know a good reference?

I also tested with CHANGED_REGION_RESTART but it does not improve anything.
Decreasing the number of loops or significantly increasing the increment does not improve the behavior of the script either.
The only thing that seems to work a little efficiently is to use touch_start in the main script and thus remove the button and listen. In this way, the script continues to work, even after restarting the region.
(0035856)
tampa   
2019-11-13 06:33   
(edited on: 2019-11-13 11:17)
Got around to test the original script on YEngine today, both 0.05 and 0.1 for the sleep seem to work, but only after I recompiled the script, upon first compile aka region startup it did not update properly, however it was running.

On a possible related note. I been seeing prims rescale themselves when edited, say I made a prim and scaled it from 1x1x1 to 10x10x10 it would reset to 1x10x10 or 10x1x10. This normally hints to packet loss or overload, but not this time. I run "force update" on the region console and the prim scaled itself to the scale I set aka 10x10x10 and stuck there.

This is a recent observation that could hint at what I originally suspected the cause for this bug to be and that is something with how the viewer receives or handles updates or how the region sends them now. It leads me to think beyond this being potentially just a bug with how region start handles running up scripts it could also be affected by what amounts to a loss of sync between region and viewer.

There is something wrong with how updates are handled now whether this be server or client side I cannot say, but the relation to the "force update" command being the way to resolve it may hint at what's wrong. I can make a new ticket to track that part, but I think it is still related to this one.

Small update: Able to reproduce original reported behavior in both X and Y, prim not updating until right clicked on.