So if object A and B are both floating with some offset, and object A is overlayed onto object B, and B is overlayed on C (who has a non floating plane), things look like this.
At least as far as I can gather.
C = 10 // No additions, since it's not overlayed inside anything
B = 10 + 1 // parent's plane plus its own
A = 10 + 1 + -4 // parent's plane + its own
This is useful for cases where you want to mirror "depth" nicely, and even for what I'm trying to do it's quality.
But it would be very powerful to be able to use things like vis_contents as a "lens", while retaining actual plane ordering and relative values.
Something like this
plane_master B = 10
plane_master C = 11
plane_master B_lower = -10
plane_master C_lower = -9
// The actual plane is unimportant, it's simply being used to "offset"
// The planes of the below. Kinda like a lens
A.plane = -20
// A turf here
B.plane = 10 + FLOAT_PLANE
// A generic overlay
C.plane = 11 + FLOAT_PLANE
B.overlays += C
A.vis_contents += B
// What we would want the planes to look like at the end
A.plane = -20
B.plane = 10 + -20 (our plane + the plane of the first non floating plane above us
C.plane = 11 + -20 (ditto)
// How things actually end up
A.plane = -20
B.plane = 10 + -20
C.plane = 11 + 10 + -20
The current behavior is useful, and even sometimes preferable.
For instance, using this pattern to apply multiz would only be possible if the "lens" took the plane of other lenses above it.
That said it makes keeping plane on the same plane masters (or mirrored plane masters) almost impossible
I'm working on multiz right now, and I do not want to have to manage the plane offsets between overlays and their owners just to accomplish the effect.
It's an insane amount of work and it's fragile as heck. Almost as bad as manually assigning planes based off z level.
What would be amazing would be a way to pull an object out of this cascading plane shifting, at least partially.
So rather then always taking an offset from its "parent", it would only take from objects without X flag set, and those objects would also only take from parents without X flag set.
So the same concept could be done something like this
plane_master B = 10
plane_master C = 11
plane_master B_lower = -10
plane_master C_lower = -9
plane_master B_even_lower = -30
plane_master C_even_lower = -29
// First "mutliz effect applier"
Z.plane = -20 + FLOAT_PLANE
// The second
A.plane = -20 + FLOAT_PLANE
// A turf here
B.plane = 10 + FLOAT_PLANE
B.appearance_flags |= FLOAT_APART
// A generic overlay
C.plane = 11 + FLOAT_PLANE
C.appearance_flags |= FLOAT_APART
B.overlays += C
A.vis_contents += B
Z.vis_contents += A
//Outputs
// We found an object without FLOAT_PLANE, or without
// the FLOAT_APART flag
// So we stick it in a variable, and move on
Z.plane = -20
lemons_overactive_imagination = Z.plane // -20
// We see we have a parent, so we take its value,
// and since we don't have FLOAT_APART we replace it in the "store"
A.plane = -20 + -20
lemons_overactive_imagination = A.plane // -40
// We have a parent, and we're floating, so we take its value
// But since we have FLOAT_APART, we don't "count" as parent, and don't get inserted into the store
B.plane = 10 + -40
// Same as above, and since B didn't insert itself into the store
// We use the last plane that did, or A's
C.plane = 11 + -40
The uh "Implementation details" here are honestly just kinda me spitballing. Perhaps a bit improperly. You could do the same thing with a priority variable, but that gets messy, and is kinda hacky.
I'm asking about this because I've been trying to make multiz not bad on mainline ss13. What we have now essentially throws away planes, which is really crummy and breaks a lot of effects, including lighting.
What I'd like to be able to do is apply a "lens" to planes below some turf without needing to manually manage their plane value.
This is kinda in the same vein as https://www.byond.com/forum/post/2784126 honestly, except the overhead here is manually managing the offset of every object overlayed in every object, rather then a few extra plane masters.
I'm doing crap like relying on /image being a datum so I can treat it generically and stick it in an "event list" whenever I set a plane's value, and that pattern of directly managing offsets even just breaks down as soon as you display the same thing in two places, which pretty much dooms my implementation from the start.
It would be so nice to have good multiz, and a nice way to shift planes without needing to manage it manually.