Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

API Z-order with newly created objects, toFront(), and toBack() is broken

1432337040

Edited 1432394287
I'm writing a pretty complex script (that I'm going to share with the community) that simply won't reliably draw without toFront() and toBack() working properly. I have a mix of graphics and paths where I need to be able to control the Z-order, and I find toFront() and toBack() to have no effect. Thanks to The Aaron for pointing out a workaround: run toBack() against objects in series with a delay of 50ms between each operation. (The same process for toFront() failed even with delays up to 1000ms). Successes: Natural insertion of paths (if no graphics are involved). toBack() of mixed graphics and paths if delayed in series. Failures: Natural insertion of graphics. Natural insertion of mixed graphics and paths. toFront(). toBack() without delays. I have a thread in the API forum about this as well, as it's API-related, but I haven't gotten a response there: API forum thread I also wrote a script that illustrates the error (and can be used for debugging) - the pic above was generated by this script: tester script
This has been updated with more detailed findings.
There is only one property on an entire page currently that controls the z-order internally. Call it "zorder". So when you do toFront() and toBack(), we update the whole zorder to move that object to the front/back. So if you call it a bunch of times in a row, it's entirely possible/probably that a race condition is occurring where the zorder is getting overwritten a lot and it's getting old data, etc. The solution to this is probably to put in some code on the API server that only updates the actual zorder after no toFront/toBack calls have occurred for like 100ms or something. I will look into adding that, thanks for pointing it out.
Awesome - thanks!
Any luck with this? :)
We are busy with the current push on the next update but it is still on our radar. Sorry for no fix yet.
Thanks for the update... I hope the push is going well.
Bumping this thread so it doesn't get locked. This is still the bug that haunts me the most. :)
1438647704
Stephen Koontz
Forum Champion
Marketplace Creator
Sheet Author
API Scripter
Compendium Curator
Rand, did putting in a time out like Riley suggested or other asychronous to syncronous tricks solve the issue?
Steve K. said: Rand, did putting in a time out like Riley suggested or other asychronous to syncronous tricks solve the issue? I can't believe I missed this message... sorry! If you look at the image at the top, you'll see that the only thing that works (most of the time) is ToBack() with delays and run in series - no other tricks worked for me or Aaron. Even that doesn't work perfectly, and if you have a lot of images on the page, they'd ALL have to be cycled through since the Z-order would be altered at the page level. I'm using this currently in a hefty script, and the redrawing can take a long time if there are a lot of objects.