[Request?] Intelligent z-ordering script

When making complex maps out of tiles, the limitations of the current z-ordering system are the bane of my life. What I'm looking for is a script by someone good at graphics math that will let me do "send 1 step backwards" on a given graphic object. It will find all the other graphics that the selected graphic overlaps with, calculate a new z-order that puts the selection immediately behind the next one back, and then put this into action using toFront() and toBack(). I guess naively it could just calculate the complete new z-order for the page and then make it so by calling toFront() on each one starting from the back... but someone better at maths than me can probably work out a more optimised approach to changing the z-order using just those two operations... Any takers? Surely someone like Stephen S. or TheAaron has already written this code somewhere?

Yeah... that's a hard problem... &nbsp; <a href="https://app.roll20.net/forum/post/1986741/slug%7D" rel="nofollow">https://app.roll20.net/forum/post/1986741/slug%7D</a> We could probably work that out though...

Yeah, I'm aware of that limitation. I guess that just means it has to be slow :-(

~50ms per image, probably. &nbsp;But if you can minimize the set of images that need to be changed, that could be reasonable.

There's been multiple suggestions made over the years, even before the current craptastic iteration of a suggestion forum, for better control of z-order, &nbsp;include move forward one and move back one. Would be nice if some of these really old suggestions like this would be worked on instead of relying on user-created api solutions.

Letting the page's zorder property be editable might be sufficient, depending on how the ordering is handled. At least then it would be a single property update the system sees, instead of a toFront or toBack call on every object on the page in order to switch the order of two objects. It would also let the api move objects by more than one hop at a time, although it introduces the possibility of dropping an element from the zorder list, which could cause some problems.

Brian said: Letting the page's zorder property be editable might be sufficient, depending on how the ordering is handled. At least then it would be a single property update the system sees, instead of a toFront or toBack call on every object on the page in order to switch the order of two objects. It would also let the api move objects by more than one hop at a time, although it introduces the possibility of dropping an element from the zorder list, which could cause some problems. Yeah, that would certainly be easier, but I suspect if it was easy to implement they would have done it by now. It would be fairly trivial to check that an element hadn't been dropped. At worst it's basically just assert(_.difference(prev.split(','), updated.split(',')).length === 0) , which isn't *that* expensive even for a pages with a few thousand graphics on them.