First off, kudos to all the folks who have brought the foreground layer to life. I will admit that I was skeptical at first. I really never thought a foreground layer would be something I would ever use. Then I got to give it a test drive. (If you've never responded to those "would you like to give feedback on a new feature" survey links, do it! You get to help guide brand new features and certainly will have ideas that the dev team hadn't considered.) Anyway, I got to take a test spin of this and tried out all sorts of tricks and variations to simulate traps, roofs that disappear when you go inside a building, objects that can't be seen until you get close enough (like seeing over a cliff edge) and a lot more. This is truly cool! However... There are some improvements that can be made that will help to handle elevation. I.e. it's still pretty cumbersome to have a token cross under a bridge, climb some stairs and then go over a bridge. It currently requires moving the foreground bridge to a different layer or mucking about with its settings. There needs to be an easier way to handle token elevation. (Note that I am not talking about Altitude, the height of a flying token, for instance.) As a matter of fact, it might be better to use a different term altogether to avoid confusion. Let's call it " Multi-level Play ". The knee-jerk reaction would be to add an additional layer, one that is on top of the Foreground layer. I think this is a bad idea, first, because this has no end (add more layers, more layers...), and second, it would probably be detrimental to performance and get cumbersome pretty quickly. I propose a condition that can be applied to a token called something like " superposition ", or " overhead ". This is a status you could add to a token that says, "Ignore foreground layer, ignore light, visions and permissions, just render it on top of everything. This should be added to the right-click menu. Ideally, there should be something that marks the token as being an overhead token. (I think that " overhead " is a good word here, easy to grasp, and describes the state well. Some questions still arise. Should an overhead token be affected by dynamic lighting? There are plusses and minuses. On the one hand, a token on a rooftop should have a clear view of other roof tops. If the map has dynamic lighting that outlines buildings, you wouldn't want an overhead token to have it's view of these blocked. On the other hand, GMs often do not want part of a map revealed. There are some solutions. An overhead token might be affected by masking, but not dynamic lighting, for instance. Although this suggestion proposes a token state to solve the problem of multi-level play, I think this is a good place to hammer out what the community wants. And this suggestion thread might be best served by listing out use cases that other folks want to achieve and how this cool new thing might be used (or what pieces are missing) to make them happen. While a new feature is fresh and in development is the absolute best time for this sort of community communication.
