ID:2029810
 
Not Feasible
Applies to:DM Language
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future


The new plane stuff is great, but one issue I'm having is that NO_CLIENT_COLOR doesn't get applied to planes that change its contents' color. To remedy this, I would like to propose NO_PLANE_COLOR.

This would have the same function as NO_CLIENT_COLOR does with client.color, just with the atom's master plane color setting. I can explain a little more in depth if what I'm describing doesn't make sense, but thanks for reading!
Yeah, I don't follow.

Planes will apply the client color to the final plane itself, unless you tell them not to. There was a bug in 1320 that didn't do that, but that's been fixed.
In response to Lummox JR
I assume Kumo means something like the PLANE_MASTER's atom.color not effecting objects with NO_PLANE_COLOR as an appearance flag personally, which I could see uses for tbh.
If a plane has a color, or is impacted by client.color, it isn't possible to shield the plane's contents from that.
In response to Lummox JR
What Pokemonred200 said.

Lummox JR wrote:
If a plane has a color, or is impacted by client.color, it isn't possible to shield the plane's contents from that.

.. which is exactly what I'm trying to get around. If this isn't possible, then I'm going to be pretty bummed.


So to try and explain a little better just incase it's still being misunderstood, NO_PLANE_COLOR would stop an atom from having color changes applied to the plane master.

I can see many uses for this, unified effects in a plane but having unique key elements of the plane stick out for some reason or another, for example.
NO_PLANE_COLOR would stop an atom from having color changes applied by the plane master.

This exactly.
In response to Kumorii
Kumorii wrote:
NO_PLANE_COLOR would stop an atom from having color changes applied by the plane master.

This exactly.

Why do you need this, if you can just place the atom on a different plane.
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
Kumorii wrote:
NO_PLANE_COLOR would stop an atom from having color changes applied by the plane master.

This exactly.

Why do you need this, if you can just place the atom on a different plane.

He said this in the skype group, but the issue here is he'd have to place it above the plane master and that would look ugly in some scenarios because it'd be above the rest of the objects on the map.
Here's the thing: PLANE_MASTER is basically KEEP_TOGETHER but grouping all icons on the same plane. There's no way for an atom to opt out of the color of a KEEP_TOGETHER parent without using KEEP_APART, and the same principle applies here--except that there's no plane equivalent to KEEP_APART.
Fair enough. I'll just use client.color instead. Thank you for taking the time to read this though!
Lummox JR resolved issue (Not Feasible)