|Anonymous | Login | Signup for a new account||2021-10-20 03:43 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008623||opensim||[REGION] OpenSim Core||public||2019-11-02 13:54||2020-03-19 08:52|
|Platform||Operating System||Operating System Version|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0008623: llSetLinkPrimitiveParamsFast inside for loop not updating|
|Description||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
|Steps To Reproduce||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|
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux64|
|Viewer||Firestorm, Dayturn, Singu|
|Attached Files|| blinds.lsl [^] (2,328 bytes) 2019-11-02 14:47|
controller.lsl [^] (310 bytes) 2019-11-02 14:48
Tried to replicate this ...
Couldn't on osGrid ..
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 :)
just test that on Y
amasing how you expected that to work on X with stock settings..
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
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.
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.
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.
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.
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 :)
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.
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.
|2019-11-02 13:54||tampa||New Issue|
|2019-11-02 14:45||BillBlight||Note Added: 0035816|
|2019-11-02 14:47||tampa||File Added: blinds.lsl|
|2019-11-02 14:48||tampa||File Added: controller.lsl|
|2019-11-02 14:50||tampa||Note Added: 0035818|
|2019-11-02 14:57||UbitUmarov||Note Added: 0035819|
|2019-11-02 14:59||BillBlight||Note Added: 0035820|
|2019-11-02 15:31||tampa||Note Added: 0035821|
|2019-11-02 15:51||tampa||Note Added: 0035822|
|2019-11-02 19:17||djphil||Note Added: 0035823|
|2019-11-02 20:01||djphil||Note Added: 0035824|
|2019-11-02 20:21||djphil||Note Edited: 0035824||View Revisions|
|2019-11-02 20:32||djphil||Note Edited: 0035824||View Revisions|
|2019-11-02 21:03||djphil||Note Edited: 0035824||View Revisions|
|2019-11-02 21:03||djphil||Note Edited: 0035824||View Revisions|
|2019-11-02 22:04||djphil||Note Edited: 0035824||View Revisions|
|2019-11-05 21:08||tampa||Note Added: 0035829|
|2019-11-05 21:51||djphil||Note Added: 0035833|
|2019-11-13 06:33||tampa||Note Added: 0035856|
|2019-11-13 11:17||tampa||Note Edited: 0035856||View Revisions|
|2020-03-19 08:51||tampa||Status||new => resolved|
|2020-03-19 08:51||tampa||Fixed in Version||=> master (dev code)|
|2020-03-19 08:51||tampa||Resolution||open => fixed|
|2020-03-19 08:51||tampa||Assigned To||=> tampa|
|Copyright © 2000 - 2012 MantisBT Group|