ID:2029810
Feb 4 2016, 1:26 am
|
|||||||
Not Feasible
| |||||||
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! |
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. 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: 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!
|
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.