Big News: The Foreground Layer Beta is Here!

Saul J. said: Shows how different people use things differently, and different tastes and all. I'd actually prefer the list in the order in which I'm likely to access them during game play: Tokens->GM->Lighting->Foreground->Map. Yeah, it is a very personal preference thing for sure. My order was based on what I've seen as the general rendering order of the assets/text/etc placed on each layer, from a very "this renders above that" in art progams perspective. I'm also generally fine with an "all the token stuff" (Tokens & GM Layer) > "all the map stuff" (Foreground, Lighting, Map) order since that's a bit more suited to facilitating gameplay needs, as long as Map ends up on the bottom and FG above it. But Tokens, GM, Map (strange little divider bar!) Fore, Lighting as it is right now just irks me. Heh

One thing I'm sure we can all agree on about the layer tool order is that we will never agree on the layer tool order. It wasn't my preferred order either, but in a week, I'll likely have forgotten it was any other way.

I just want to say "thank you" to the developers for thinking beyond a simple "weather layer". I'd always thought that was a good idea, but when it was announced my first thought was "well that's nice, not sure I have a use for it".  Then I saw the "remove when token bumps into it" part of the video, and got a whole lot more interested, as roofs on buildings are something I have to do manually on the map layer today. And less than a day later I have a cave entrance for my next game that will use this to reveal the first part of the cave the moment someone moves into the cave mouth.  I can't wait to see how it goes with my players.

 I have been following for awhile now, well as early as I can remember your product release in our region. I really like your layout, very functional and has learned me a lot. I had a subscription for awhile and enjoyed the macro and dynamic upgrades. I like the mapping and layers, as well as the compatibility your product offers. The integrated communication adds to a more personal preference as well which is great in my opinion, say a group decides for a more long term campaign or what not.   Briefing through the latest layer release, the idea further affirms your market in my opinion. The modelling does not detract from the tangible, which is the most dynamic part of this niche. Thanks for many great times!

Small issue I've noticed.  When putting uploaded assets onto the Foreground layer, they are all dropping at 1x1 squares.  For odd sized roofs and such, this then means I need to go edit the size manually (also turn off grid snapping for each item).  It's just a bit of extra steps that feels like it should be there. Edit: Did find out how to drop items with keeping dimensions, though they still drop relatively tiny and have to be resized back.

Maybe I just need more practice, but an issue I am running into is that I was trying to use this new feature to have traps and triggers for them auto-appear to players as they advanced if they missed the perception checks. It works when I set the opacity for the layer to 0, and conditional fade on at 100%. Just like in the video. However... This then made my other things on that same layer not function as I wanted. For example, the structural support arches they can pass under. If I set it up for traps, they do not appear until they are directly beneath them. Unless I missed something like an individual item opacity other than conditional fade?

KatValkyrie said: The 'bounding box' test used for obsuring assets can be very clunky if the asset is not generally rectangular. I ran into this problem with overhead assets authored on the diagonal, and assets that have odd protrusions or cut outs, and thus a lot of space where you can walk into the bounding box and not the asset. As someone that works in 3D art, I might suggest the possibility of looking into an alpha-test based solution (ie. checking the transparency values (alpha chanel) of the pixels) for a more accurate bounding box. For non-rectangular items (alpha channel has been determined to be a potential performance inhibitor) you can slice up irregular shapes into chunks and upload them separately. Re-assemble them on the foreground layer, and group them. The group will follow whatever behavior you set for it, with any member of the group triggering the behavior. Thus an L-shaped roof could be assembled from two pieces and grouped. Either leg of the group members will trigger the behavior, but not the negative space formed by the L. It's a lot easier to show than to tell, so let me know if a diagram would be of service.

Krunok said: Maybe I just need more practice, but an issue I am running into is that I was trying to use this new feature to have traps and triggers for them auto-appear to players as they advanced if they missed the perception checks. It works when I set the opacity for the layer to 0, and conditional fade on at 100%. Just like in the video. However... This then made my other things on that same layer not function as I wanted. For example, the structural support arches they can pass under. If I set it up for traps, they do not appear until they are directly beneath them. Unless I missed something like an individual item opacity other than conditional fade? The individual item opacity is on the token editor panel, first tab, where you configure the token's name, bars or auras, etc.

I just noticed that foreground objects appear above the grid (ie grid lines aren't drawn on the foreground object).  This was visible in the video with the crow's nest on the ship, but I'd overlooked it. While I can see the value in that, as a way to visually distinguish "above" from "below", it would be very useful if you could set an option on the object to show or hide the grid over it. One example: I have a floor with a pit trap, and a foreground object of a normal floor.  When someone steps onto the trap, the floor disappears and they're standing above the pit.  However, with no grid lines visible, the existance of the trap (if not what it is) is immediately visible to anyone looking at the map, as they see a section of flooring without a grid. A similar problem occurs with others objects you want to place on the foreground to hide something, which fade to reveal the hidden token/object when you get close. The lack of a grid instantly tells the observant that "there's something there".

Awesome! Maybe have a new tick box - See Nameplate for GM only on foreground Lavi said: Novercalis - thank you for highlighting. This seems like unideal behavior so taking it back to our team to discuss next steps to avoid losing tokens. Novercalis said: However there seems to be an issue: Grab a npc token set it to the foreground double click token to open token setting Set Base Opacity to 0 Turn on Nameplate go to Foreground tab Set conditional fade to 100% Save token setting Now DM move back to token layer - even the DM can't see the token. That should be expected, but I was hoping the DM can see the NAME. There will be times we forgot we set a monster up and then in-game, someone walks into it and things just got ackward.......... There should be some form for the DM to see tokens hidden in the foreground. 

Excellent work. It was well worth the wait. ;D

I agree with the door thing, I've just put a roof as a test and the door is hidden for both me and the players.  As they move their tokens closer it might change for them.  The other aspect is for the GM.  Is there away to make the object always opaque for us?  If you click a token it becomes opaque, but only then.  (this might be there and I've just missed it).

On what they call the "Hamburger" menu on the left hand bar, (its three horizontal bars at the top...) where it used to just show GM Layer opacity, you've now also got sliders for Darkness/Daylight mode opacity AND Foreground Opacity that you can set between having the foreground completely invisible to 100% solid.  Jonathan K. said: I agree with the door thing, I've just put a roof as a test and the door is hidden for both me and the players.  As they move their tokens closer it might change for them.  The other aspect is for the GM.  Is there away to make the object always opaque for us?  If you click a token it becomes opaque, but only then.  (this might be there and I've just missed it).

I had the same behaviour, however not when deleting a token. If you select a token that is UNDER the foreground layer and then click another token, it works fine. However if you don't click on another token, but on map somewhere, it stays revealed. It seems that the conditions under which that token is "unselected" seems to be the problem here. Terry McGinn said: This is fantastic!! One thing I noticed is that if a token is delete while it's "under" a foreground layer item the foreground layer item remains revealed, it doesn't reappear. It will reappear if you close the map and open it again, but it seems that the transparent to opaque toggle requires token interaction both ways. Deleting tokens while they're under a foreground object is a pretty minor fringe case to be an actual problem, but just thought I would mention it.

Fran said: Hello, Roll20 VTT team member here! Thanks so much for your in-depth response! (And thanks to everyone here!!) To #1: Alpha channel - We DID look into this - but still worry about big performance hits. Alpha channel checking would probably have to be an option on a per-asset basis&nbsp; &nbsp; - don't quote me on that - &nbsp; and used judiciously. We felt that it was a bit much to come roaring out of the gate with a performance concern. Regardless, its something we can look into if others are interested. To #2: Noted! Are you - the GM - Clicking on doors and windows during map set up, or is it difficult for players to click on them during game time?&nbsp; To #3: You can adjust your Campaign Settings (Game Details Page &gt; Settings Dropdown &gt; Game Settings &gt; Game Default Settings &gt;&nbsp; Foreground Tab.) One thing that quickly emerged in our research was that we needed to be able to adjust defaults, as we worried that this new feature would add too much prep time!&nbsp; To #4: Specifically for&nbsp; elevation , Ill point you&nbsp; here: &nbsp; <a href="https://app.roll20.net/forum/post/12296098/add-multi-level-slash-elevation-support-to-the-foreground-layer#post-12297566" rel="nofollow">https://app.roll20.net/forum/post/12296098/add-multi-level-slash-elevation-support-to-the-foreground-layer#post-12297566</a> .&nbsp; To #5: We've noted peoples comments about the &nbsp;layer order&nbsp; thus far and have seen what we found through research - which is that no one order appears to make&nbsp; everyone&nbsp; happy. The team chose to prioritize the following: 1. Keeping "Token" up top, as the "Main" layer. 2.&nbsp; Grouping Token, GM and Map, as it has the strongest shared mental model. 3. Grouping "Foreground" and "Light" together, as they appear "locked" for free users. I hope this sheds light on our thought process. :)&nbsp; Hey there! I would love it as a "use at your own risk" type option, though I absolutely understand performance concerns. Having made a lot of maps, I know that a lot of times there are weird edge cases with shapes and bounding boxes of overhead layers that will otherwise cause oddities with the bounding box version of the test. I have struggled with this both as a DM and as a player. In my Bazaar test scene, in order to click on doors to use or adjust them as a DM, I have to physically move the overhead layer assets out of the way. Link to a video of that. As a player, I ran into this issue on Wednesday, as my DM had just added an overhead layer to the dungeon we were exploring (top level cave walls, beams, sconces, etc that we could walk under), but these obscured and paritally hid doors that we encountered, and I and other players kept clicking and closing/opening doors we forgot were there accidentally, as we couldn't see the icons. Oh excellent, I missed that! Glad you've already got that handled. Already commented on/upvoted :) I continue to disagree with that grouping, especially the idea of Map as a "mental model" not being grouped with the map-related layers (Foreground, Lighting), but I seem unlikely to change the design team's opinion. My only comment is that it seems odd that you're designing the UI experience for the users of the actual paid Plus/Pro features in a way that makes the most sense to free users (as the stuff they can't use gets grouped together). I know that you do have to design for both, it just is a bit backwards from common UI design principles. Thank you very much for responding to my feedback though! keithcurtis said: KatValkyrie said: The 'bounding box' test used for obsuring assets can be very clunky if the asset is not generally rectangular. I ran into this problem with overhead assets authored on the diagonal, and assets that have odd protrusions or cut outs, and thus a lot of space where you can walk into the bounding box and not the asset. As someone that works in 3D art, I might suggest the possibility of looking into an alpha-test based solution (ie. checking the transparency values (alpha chanel) of the pixels) for a more accurate bounding box. For non-rectangular items (alpha channel has been determined to be a potential performance inhibitor) you can slice up irregular shapes into chunks and upload them separately. Re-assemble them on the foreground layer, and group them. The group will follow whatever behavior you set for it, with any member of the group triggering the behavior. Thus an L-shaped roof could be assembled from two pieces and grouped. Either leg of the group members will trigger the behavior, but not the negative space formed by the L. It's a lot easier to show than to tell, so let me know if a diagram would be of service. Oh I'm fully aware that further slicing up and grouping overhead assets is an option, but as someone that made and released 150+ maps for a specific module I was running just for fun, the onus really shouldn't be on map makers to have to slice assets that should cover one building, up into many smaller pieces specifically for weird issues with Roll20's specific use case. It's confusing for less technically savvy end map users/DMs to set up and understand, and I've found from comments people have left on my work that people already have issues utilizing overhead pieces sometimes without extremely specific guidance, and "XYZ goes here" type diagrams, extrapolating that to say 3x the number of pieces to help solve issues like that is not a reasonable ask.&nbsp; Many other mapmakers I've seen also don't split their overhead tiles up if there are some smaller individual sections on a map, and instead export them as an image the full size of the base map. This was something a DM friend of mine encountered, when she was experimenting with the Foreground layer herself, and so many others will probably run into this issue also.

I've tried this and it works quite well! Also, I have a situation where I have a building that is open on one side, meaning that player tokens should be able o "see" what is under the roof from some distance away. What I did was in addition to placing a "roof" token above the building on the foreground layer, I also placed an in invisible token on the side with the opening and grouped it with the "roof" token. I made the invisible token wider than the building so that a player token approaching the open wall from one side could begin to see the interior. keithcurtis said: For non-rectangular items (alpha channel has been determined to be a potential performance inhibitor) you can slice up irregular shapes into chunks and upload them separately. Re-assemble them on the foreground layer, and group them. The group will follow whatever behavior you set for it, with any member of the group triggering the behavior. Thus an L-shaped roof could be assembled from two pieces and grouped. Either leg of the group members will trigger the behavior, but not the negative space formed by the L. It's a lot easier to show than to tell, so let me know if a diagram would be of service.

Something I noticed playing around.&nbsp; Would it be possible when selecting and moving a token using the "Q" key or "right click" that the foreground opacity is not triggered until the release of the movement rather than while maneuvering of the token, in order to keep from spoiling a reveal.&nbsp; It gives the player a way to "cheat" the system if they can see what might be under a tree before they commit to the action. &nbsp; And my players will take every advantage they can get. ; )

Thanks, I love it!

This is resolved by going into your map settings &gt; Dynamic Lighting &gt; Turn on "Update Vision on Token Drop". This will prevent spoilers and lighting changes when deciding which tile they want to move.&nbsp; Talequin Silverstrings said: Something I noticed playing around.&nbsp; Would it be possible when selecting and moving a token using the "Q" key or "right click" that the foreground opacity is not triggered until the release of the movement rather than while maneuvering of the token, in order to keep from spoiling a reveal.&nbsp; It gives the player a way to "cheat" the system if they can see what might be under a tree before they commit to the action. &nbsp; And my players will take every advantage they can get. ; )

For bounding boxes of irregularly shaped foreground objects, could you implement something like walls on the lighting layer, where you can define the area that you want to trigger the foreground object behavior? Would that be better performance-wise than transparency/alpha channel? You could possibly group it to the foreground object to create a user-defined bounding box for an individual foreground object.&nbsp;Or have it interact with all objects on the foreground layer but only the portion of the objects within the walled area that you define. (This option might let you easily use map sets that have a single "inside" and "outside" map image, and have the inside of a single building become visible once a token enters that building's wall area.)

Tommy said: On what they call the "Hamburger" menu on the left hand bar, (its three horizontal bars at the top...) where it used to just show GM Layer opacity, you've now also got sliders for Darkness/Daylight mode opacity AND Foreground Opacity that you can set between having the foreground completely invisible to 100% solid.&nbsp; Jonathan K. said: I agree with the door thing, I've just put a roof as a test and the door is hidden for both me and the players.&nbsp; As they move their tokens closer it might change for them.&nbsp; The other aspect is for the GM.&nbsp; Is there away to make the object always opaque for us?&nbsp; If you click a token it becomes opaque, but only then.&nbsp; (this might be there and I've just missed it). Thanks, I'd not twigged about the hamburger thing despite reading it :)

A bit buggy at the moment. For instance, I created a treeline around a map I'm using for a siege.&nbsp; Clicking a token on the left side of the map hides the trees and reveals the tokens.&nbsp; Clicking a token on the right side of the map does not. This seems to be a theme,&nbsp; lots of cool, mostly working features that are a slog during game play because they don't quite work as expected, or don't work for all the players, and so you end up trying to turn them off in the middle of a session.

I've encountered this a lot with map assets like furniture, trees, and other smaller map items. Examples of this in the free art objects that we all get in our library. Many of the items have a lot of dead transparent space around them. I don't see what Roll20 can do about that though. I plan on downloading such items, editing out the excess dead space, then uploading the new versions to my library. KatValkyrie said: Many other mapmakers I've seen also don't split their overhead tiles up if there are some smaller individual sections on a map, and instead export them as an image the full size of the base map. This was something a DM friend of mine encountered, when she was experimenting with the Foreground layer herself, and so many others will probably run into this issue also.

Things on my GM layer need to be seen through everything else, including the foreground layer. I have room numbers and other important information here.&nbsp;

Sam H. said: Things on my GM layer need to be seen through everything else, including the foreground layer. I have room numbers and other important information here.&nbsp; Does reducing the GM opacity of the foreground layer help with this? I think it might be a good idea to have the GM layer render on top of evreything.

I was thinking the same. Is there any drawbacks if we moved the GM Layer to the top? I couldn't think of any. If at all, it helps us more when using mods like Bump on some use case scenario that doesn't utilize the foreground conditional fade trick.&nbsp; IE: Dig site under the Mushroom Tree after an investigation. So I still need the treasure box to be hidden from view.&nbsp; keithcurtis said: Sam H. said: Things on my GM layer need to be seen through everything else, including the foreground layer. I have room numbers and other important information here.&nbsp; Does reducing the GM opacity of the foreground layer help with this? I think it might be a good idea to have the GM layer render on top of evreything.

Issue from Reddit - how to replicate - Drop a House map or create a square home with 4 rooms. Set that to the Map Layer. - Add some furniture in each room in the map layer. - Create a Dynamic Lighting walls to the home in the light layer - add 4 roof times for each room in the foreground layer - go to page setting &gt; dynamic lighting and turn on: Dynamic Lighting, Explorer Mode, Daylight Mode - Drop a PC token in the token layer outside the home, 50 ft away from the house. - PC token can't see house interior yet.&nbsp; &nbsp;Move PC Token 10 ft in any direction. You will begin to see underneath the foreground roof and see a faded out interior of the house. The Foreground roof turns transparent, even when you're not near it or under it, revealing the interior, even though you haven't entered the home and explored the area.

Just to add my view on what has been mentioned already, but with a visual.&nbsp; Please fix so none square art can be used correctly!&nbsp; Was excited to use this but cannot as is.&nbsp; One image shows the image on the foreground (dome roof) and the "selection box", the other image shows something outside the image, but within that selection box and able to see inside the circle. I put a one way wall in the short term around the roof, and a transparent line so the players can't enter those spaces and need to go in the front door for now as a fix.

I have my map set up this way, but the foreground opacity is still triggered when a player token moves into the foreground area, not upon release.&nbsp; Can anyone else check and see if this works for them?&nbsp; Or maybe I have something else wrong? Novercalis said: This is resolved by going into your map settings &gt; Dynamic Lighting &gt; Turn on "Update Vision on Token Drop". This will prevent spoilers and lighting changes when deciding which tile they want to move.&nbsp; Talequin Silverstrings said: Something I noticed playing around.&nbsp; Would it be possible when selecting and moving a token using the "Q" key or "right click" that the foreground opacity is not triggered until the release of the movement rather than while maneuvering of the token, in order to keep from spoiling a reveal.&nbsp; It gives the player a way to "cheat" the system if they can see what might be under a tree before they commit to the action. &nbsp; And my players will take every advantage they can get. ; )

Is there a trick for making door and window icons visible to players despite a roof foreground layer? If the foreground layer roof is large enough to actually look like a roof, i.e. slightly overhang the outer walls of the building, the icons are obscured, and the player token has to get right up against the wall to see there's a window or a door at all. If I make the roof small enough that icons aren't obscured, then there's a sliver of visible interior around the edge.

Ari said: Is there a trick for making door and window icons visible to players despite a roof foreground layer? If the foreground layer roof is large enough to actually look like a roof, i.e. slightly overhang the outer walls of the building, the icons are obscured, and the player token has to get right up against the wall to see there's a window or a door at all. If I make the roof small enough that icons aren't obscured, then there's a sliver of visible interior around the edge. That's been raised.. currently no, hopefully soon :)

For now, I add an invisible token to the door side of the roof token and group them together. That way if a player token crosses the outline of the invisible&nbsp; token the door becomes visible. Ari said: Is there a trick for making door and window icons visible to players despite a roof foreground layer? If the foreground layer roof is large enough to actually look like a roof, i.e. slightly overhang the outer walls of the building, the icons are obscured, and the player token has to get right up against the wall to see there's a window or a door at all. If I make the roof small enough that icons aren't obscured, then there's a sliver of visible interior around the edge.

It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

firstly, roll20 you're awesome thanks! secondly, omg Keith ! you have half-solved my issue(s) with that damn door icon: I can put a foreground icon/image of my chosing over the top of the stupid door icon, and have it only reveal the actual default roll20 door or window icon when in proximity (for clicking etc.). Ima try this right now. yay. keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

I don't understand how to use it - a lot of this Foreground Layer stuff is confusing. keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

Copy that Door image, convert it to a PNG and remove the edges if necessary, and add it to the foreground layer in a position above the door on the lighting layer, but make sure it is on top of the Roof token (Use "Bring to Front" on the Token menu if it somehow appears below). Then group any such door Tokens to be part of the larger roof image on the Foreground layer. So that will mean that the door can be seen from a distance, and will vanish when the player token gets close enough to the door, at which point the Lighting level Door will become active and when the player opens and goes through the door it will remain looking open to anyone under the Foreground roof. It won't make an open door that someone has gone through appear open to anyone outside the Foreground trigger area, or allow them to see through an open door into the area under a foreground layer but it's a pretty good work-around for now. Saul J. said: I don't understand how to use it - a lot of this Foreground Layer stuff is confusing. keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

if you right-click on the page and download it, it should be a PNG with transparency. It may not appear that way in the browser, but the lightbox function doesn't seem to handle transparency for forum preview.

&nbsp;For completeness, there's a couple of steps missing from the process that Tommy has given - some people may not be aware of these intermediate steps If you right-click on the image of the door within Keith's forum post, you should get a menu that includes a choice to "save image as ...". Click that selection and it will allow you to download the image to a folder on your computer. The default file name will probably by "original.png". Once your have that copy on your computer, rename it to something useful, like "Roll20 Door Icon.png". Open one of your games, go to your art library, select "My Library", then "Upload" then drag-and-drop that file from your computer to your art library. It will now appear in your "Uploaded Assets" (If you've set up folders in your art library, now is a good time to move that image into one. I know that if I don't do this right away, I'll forget.) Now you can drag the image from your library to a map to create the token that the others are referring to. Tommy said: Copy that Door image, convert it to a PNG and remove the edges if necessary, and add it to the foreground layer in a position above the door on the lighting layer, but make sure it is on top of the Roof token (Use "Bring to Front" on the Token menu if it somehow appears below). Then group any such door Tokens to be part of the larger roof image on the Foreground layer. So that will mean that the door can be seen from a distance, and will vanish when the player token gets close enough to the door, at which point the Lighting level Door will become active and when the player opens and goes through the door it will remain looking open to anyone under the Foreground roof. It won't make an open door that someone has gone through appear open to anyone outside the Foreground trigger area, or allow them to see through an open door into the area under a foreground layer but it's a pretty good work-around for now. Saul J. said: I don't understand how to use it - a lot of this Foreground Layer stuff is confusing. keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

Roll20 should add such an icon into the &nbsp; sampler pack &nbsp;of foreground objects available. <a href="https://marketplace.roll20.net/browse/set/36564/roll20-foreground-sampler" rel="nofollow">https://marketplace.roll20.net/browse/set/36564/roll20-foreground-sampler</a> Along with a Tip Sheet on how to use it keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

I don't know what agreements were made with the creators of the assets, but since I pretty much just duplicated the existing graphic design (even using the original SVG data for the door icon), I've no objection to Roll20 using it for whatever they want.

.. and if the image was double-sided... you could flip to open/close the door?&nbsp; Though not sure if this would work with grouped?

To the steps given, I'll add (after experimentation): make sure you resize the door image to the size you want, before &nbsp;you group it with the roof. Rick A. said: &nbsp;For completeness, there's a couple of steps missing from the process that Tommy has given - some people may not be aware of these intermediate steps If you right-click on the image of the door within Keith's forum post, you should get a menu that includes a choice to "save image as ...". Click that selection and it will allow you to download the image to a folder on your computer. The default file name will probably by "original.png". Once your have that copy on your computer, rename it to something useful, like "Roll20 Door Icon.png". Open one of your games, go to your art library, select "My Library", then "Upload" then drag-and-drop that file from your computer to your art library. It will now appear in your "Uploaded Assets" (If you've set up folders in your art library, now is a good time to move that image into one. I know that if I don't do this right away, I'll forget.) Now you can drag the image from your library to a map to create the token that the others are referring to. Tommy said: Copy that Door image, convert it to a PNG and remove the edges if necessary, and add it to the foreground layer in a position above the door on the lighting layer, but make sure it is on top of the Roof token (Use "Bring to Front" on the Token menu if it somehow appears below). Then group any such door Tokens to be part of the larger roof image on the Foreground layer. So that will mean that the door can be seen from a distance, and will vanish when the player token gets close enough to the door, at which point the Lighting level Door will become active and when the player opens and goes through the door it will remain looking open to anyone under the Foreground roof. It won't make an open door that someone has gone through appear open to anyone outside the Foreground trigger area, or allow them to see through an open door into the area under a foreground layer but it's a pretty good work-around for now. Saul J. said: I don't understand how to use it - a lot of this Foreground Layer stuff is confusing. keithcurtis said: It's definitely a conundrum. Perhaps if doors became visible regardless, depending on their proximity to a token? This would at least reveal nearby doors. Also, you could mark exterior doors with a foreground layer token that doesn't react to token overlap (i.e. doesn't adjust it's opacity). Here is a Roll20 style door icon for such use. This is probably the best solution for folks who need a quick fix.

Great to see this get implemented. Just following along here.

I hope this is the right place for help. Conundrum. I have a token ( no dark vision ) on the token layer, trying to walk under a bridge on foreground layer. There are two torches on the light layer at opposite ends of the map. So, I am unable to walk the token under the bridge with Dynamic Lighting on the map. The bridge is set to Condition Fade OFF and Hidden By Darkness ON. Can someone please help me.