Descriptive Problem Summary:
Layering in regards to z level position is not respected, tested in isometric mode.
Adding an atom from a lower z to an atom's vis_contents on a higher level z results in the lower level atom appearing still as an overlay, regardless of layering.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
It has never worked in any earlier versions.
Workarounds:
You can manually work around this by using plane, but it isn't effective as it limits what is possible with vis_contents.
I've attached an example project to highlight the issue.
https://www.dropbox.com/s/uh24d0zmp9ieo0i/ IsometricVisContents_src.zip?dl=0
ID:2328818
 Dec 19 2017, 5:30 pm (Edited on Dec 19 2017, 5:52 pm)
|
|||||||||||||
| |||||||||||||
|
Dec 19 2017, 5:40 pm
|
|
Crazah
 |
Had a talk with Ter13, evidently this isn't a bug. It should be moved to feature requests, because having vis_contents respect an atom's position in the world would be invaluable.
|
I agree with this sentiment.
If an object in vis_contents has a map location, it should layer: 1) according to plane 2) according to loc (if on map, otherwise skip) 3) according to layer 4) according to precedence Otherwise, this leaves developers to use separate planes for each stacked map layer, which bloats the number of unique appearances well above and beyond what you'd expect to have simple map stacking. | |
Ya, this at the very least warrants an appearance flag to bring on this behavior, if not making it the default.
| |
I'll take a look at this.
I suspect an earlier change that used transforms in place of pixel offsets for the visual contents caused this to happen, and I've been wondering all along if that would have to be changed back. Likely that's the case here. | |
Hrm, it seems I misunderstood the issue, but the thing I was thinking of doing is probably still a necessity in isometric.
I took a look at the demo, and you're not actually doing anything to alter the layer of the z=2 turfs. The z=1 and z=2 turfs are in the same position and have the same layer. Theoretically the blue one ought to be on top of the red one, in at least the smaller case (the big case maybe not so much, because big icons are tricky beasts in isometric), but any time you have two icons with the exact same layer interfering with one another you have a potential issue. The old microlayering behavior might potentially be getting in the way here. | |
What Ter13 mentioned is exactly what I had in mind for the feature request. It would give vis_contents extendability, as right now having to predefine planes for different z levels can turn into a development nightmare.
| |
Would this be better suited as a feature request for tracking details?
| |