Big News: The Foreground Layer Beta is Here!

Maldeth said: 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. Hi Maldeth! I'm not quite understanding the issue as described. Are there dynamic lighting blocking lines on the bridge? Screenshots might help. (If you haven't posted screen shots before, you need to actually upload them to the forum. Copy and paste from your desktop won't work)

It appears to work correctly when the players are using it, but when I spectate as the players token it gave me the error i indicated. So its not an actual problem but something you all may come across. Thank you Keith for a quick reply!

I'd have to see it in action to know exactly what's going on, but in general, Ctrl-L only gives you an approximation of a player's view. Its primary purpose is to reveal Line of Sight (hence the L). To truly test the players experience, testing with a  Dummy Account  is the best practice.

I definitely would like an option for just the door/window icons to always show up if a player can see any part of the door icon. It's partly a problem with Dynamic Lighting too, where the door icon is only partially visible if a player is only able to see one side of the door.

It would be great to have samples for weathers and daytimes and having an option to use the disabled conditional fading as standard.

Coldin said: I definitely would like an option for just the door/window icons to always show up if a player can see any part of the door icon. It's partly a problem with Dynamic Lighting too, where the door icon is only partially visible if a player is only able to see one side of the door. I believe all-or-nothing icon visibility is the behavior in Classic. I have also made a request for parity on this.

Currently, doors have a set of selectable toggles: open/closed, locked/unlocked, and visible/hidden. How about adding a "Visible in foreground" toggle? Lavi said It sounds like a blanked solution of putting doors/windows always above or always below Foreground objects wouldn't work here, so curious on more input from community on ideas, use cases and things to consider here!

I'm guessing this is already on the roadmap, but I haven't seen it anywhere else yet: please add an Advanced Keyboard Shortcut to move items to the Foreground layer. I would expect it to be "l ." (similiar to "l o", "l k", "l ," to move to the Objects Layer, GM layer, and Lighting layer respectively. I've also submitted a Help Center request. :) 

This seems like a good solution to me. This would allow the GM to identify which doors should be hidden and when, and which should be visible (and when).  Rick A. said: Currently, doors have a set of selectable toggles: open/closed, locked/unlocked, and visible/hidden. How about adding a "Visible in foreground" toggle? Lavi said It sounds like a blanked solution of putting doors/windows always above or always below Foreground objects wouldn't work here, so curious on more input from community on ideas, use cases and things to consider here!

I've been playing around with the Foreground layer on The Master's Vault  (great free beginner's module - hopefully it gets updated for 2024!). One great function for the Foreground layer is to move the Bone Cage trap to the Foreground layer instead of to the Objects or Map layer - it means that the Bone Cage will be seen  over  the player's tokens and is a really nice effect. (Bone cage on Map Layer on the left; Bone cage on Foreground layer on the right) I've started toying with using the Foreground layer as a replacement for Fog of War, but it does't  quite  do what I'm looking for.  What would still be incredible is to be able to  replace Fog of War with an image . But in the meantime, here's what I have been looking at. W ith standard Dynamic Lighting, when players arrive, they see the image on the left, but I'd rather them see the image on the right: And as they progress through the Lair, I would want it to look something like this: Again - this isn't exactly what I'm looking for. If Fog of War could replaced with an image, or if there was a Fog of War Layer, then it would allow for more customization and a better visualization on the player side.  I like Dynamic Lighting, but having a large black screen means that I often forgo using it. I want my players to be able to see the cool map images that I'm using. Thanks, Keith, for helping me understand this one better! Separately, anything on the Foreground layer blocks visibility of lines on the Lighting Layer, which makes adjusting DL lines impossible once foreground layer items have been placed.  (Foreground Layer on left with a large block that takes up the middle ⅓ of the screen; Lighting Layer on the right).

To make sure the lighting layer is not obscured, just dial down the opacity on the foreground layer:

keithcurtis said: To make sure the lighting layer is not obscured, just dial down the opacity on the foreground layer: Ah thank you! I was confusing the GM Foreground Opacity with the Base Opacity of the token image itself. I think as I play around with this a bit more some of these settings will start to make a bit more intuitive sense.

I really do like that they have moved all of the global opacity sliders to the same place.

Is there a way to opt out of this "beta" ? In 2023, Roll20 was simple and it worked. In 2025, it's not simple and it doesn't work. My good opinion once lost is lost forever.

At the risk of making a suggestion about something I know absolutely nothing about... would it be possible to simply have a toggle on the Door/Window pop out/set up that switches between "Above Foreground" and "Below Foreground"? I appreciate there would in all probability be nothing "simple" about it, but from a user perspective... I'm not sure how doors and windows work with the API in terms of unique settings, (maybe not having independent "GM Notes" to hold data like a Token would cause a problem...) but I'm sure the Modders would find a way to be able to link multiple doors and windows that could be toggled "Above/Below" via a button/macro making this transition easier.&nbsp; Lavi said: For awareness, we are in the process of solving partially obscured doors/windows with Darkness which we hope will be out soon as a fix to match Legacy, and is separate from Foreground Layer.&nbsp; As it relates to visibility of doors/windows with Foreground Layer,&nbsp;this one is very high on our list of feedback to review and address. Keith's previous post&nbsp;( <a href="https://app.roll20.net/forum/post/12296099/big-news-the-foreground-layer-beta-is-here/?pageforid=12296753#post-12296753" rel="nofollow">https://app.roll20.net/forum/post/12296099/big-news-the-foreground-layer-beta-is-here/?pageforid=12296753#post-12296753</a>), &nbsp;highlights some use cases for why foreground items should hide door markers, and repasting for discussion:&nbsp; "...Consider the application of using the layer for roofs. If the roof is covering the floorplan, it would be distracting (or spoiler-y) to reveal the location of interior doors." It sounds like a blanked solution of putting doors/windows always above or always below Foreground objects wouldn't work here, so curious on more input from community on ideas, use cases and things to consider here! keithcurtis said: Coldin said: I definitely would like an option for just the door/window icons to always show up if a player can see any part of the door icon. It's partly a problem with Dynamic Lighting too, where the door icon is only partially visible if a player is only able to see one side of the door. I believe all-or-nothing icon visibility is the behavior in Classic. I have also made a request for parity on this.

Tommy said: At the risk of making a suggestion about something I know absolutely nothing about... would it be possible to simply have a toggle on the Door/Window pop out/set up that switches between "Above Foreground" and "Below Foreground"? I appreciate there would in all probability be nothing "simple" about it, but from a user perspective... I'm not sure how doors and windows work with the API in terms of unique settings, (maybe not having independent "GM Notes" to hold data like a Token would cause a problem...) but I'm sure the Modders would find a way to be able to link multiple doors and windows that could be toggled "Above/Below" via a button/macro making this transition easier.&nbsp; GM Notes on Doors and Windows would be great. That could be leveraged by a lock-picking script, for instance. Or a riddle could be placed on a locked door.

I would LOVE that. I'm no API Master like some of you guys, but I'm pretty good at putting the MODS that are out there to creative uses.&nbsp; I just long figured that the set up of Doors and Windows was too different to standard "Tokens" to make that a viable thing. One thing I'm sure it would allow would be a means by which a Token would need to be within at least touching range for opening and closing them... keithcurtis said: Tommy said: At the risk of making a suggestion about something I know absolutely nothing about... would it be possible to simply have a toggle on the Door/Window pop out/set up that switches between "Above Foreground" and "Below Foreground"? I appreciate there would in all probability be nothing "simple" about it, but from a user perspective... I'm not sure how doors and windows work with the API in terms of unique settings, (maybe not having independent "GM Notes" to hold data like a Token would cause a problem...) but I'm sure the Modders would find a way to be able to link multiple doors and windows that could be toggled "Above/Below" via a button/macro making this transition easier.&nbsp; GM Notes on Doors and Windows would be great. That could be leveraged by a lock-picking script, for instance. Or a riddle could be placed on a locked door.

In terms of Doors / Windows rather than foreground layer.. simply having them selected along with other lines on the lighting layer in one go would be really useful..

A new layer that eats bandwidth and CPU power has negative appeal. I have players using second-hand budget laptops with UHD graphics on poor wifi. I can't even put text labels on the GM layer because it causes too much lag and load time. So why would I have an erg of enthusiasm for this new layer? I can never use it. I know you don't want this feedback - you prefer a world where everyone has an i9 on dedicated fiber and unlimited time to tinker. But that's not my reality. We have limited bandwidth, limited CPU power, and limited time. This layer will never be used in my games.

That would work fine for me. Rick A. said: Currently, doors have a set of selectable toggles: open/closed, locked/unlocked, and visible/hidden. How about adding a "Visible in foreground" toggle? Lavi said It sounds like a blanked solution of putting doors/windows always above or always below Foreground objects wouldn't work here, so curious on more input from community on ideas, use cases and things to consider here!

Plural said: A new layer that eats bandwidth and CPU power has negative appeal. I have players using second-hand budget laptops with UHD graphics on poor wifi. I can't even put text labels on the GM layer because it causes too much lag and load time. So why would I have an erg of enthusiasm for this new layer? I can never use it. I know you don't want this feedback - you prefer a world where everyone has an i9 on dedicated fiber and unlimited time to tinker. But that's not my reality. We have limited bandwidth, limited CPU power, and limited time. This layer will never be used in my games. then continue using legacy, nothing changes in that front for your players. For those who can run jumpgate and use this feature, this is a boon for us.&nbsp;

The foreground layer (as well as other features that are being included with Jumpgate) is something that's been requested by a lot of people for a long time. Roll20 is responding to user demand. You still have the&nbsp; option of using the legacy version of the VTT, which does not include any of these new features. Plural said: A new layer that eats bandwidth and CPU power has negative appeal. I have players using second-hand budget laptops with UHD graphics on poor wifi. I can't even put text labels on the GM layer because it causes too much lag and load time. So why would I have an erg of enthusiasm for this new layer? I can never use it. I know you don't want this feedback - you prefer a world where everyone has an i9 on dedicated fiber and unlimited time to tinker. But that's not my reality. We have limited bandwidth, limited CPU power, and limited time. This layer will never be used in my games.

Plural said: A new layer that eats bandwidth and CPU power has negative appeal. I have players using second-hand budget laptops with UHD graphics on poor wifi. I can't even put text labels on the GM layer because it causes too much lag and load time. So why would I have an erg of enthusiasm for this new layer? I can never use it. I know you don't want this feedback - you prefer a world where everyone has an i9 on dedicated fiber and unlimited time to tinker. But that's not my reality. We have limited bandwidth, limited CPU power, and limited time. This layer will never be used in my games. Hi Plural,&nbsp; Please file a Help Center request with Roll20 detailing the difficulties your group is having. Roll20 needs this feedback so that they can make improvements.&nbsp; While the other responses stating to continue to use Legacy is a viable solution for the moment there is a point someday where Legacy will be shut down (hopefully not for a long time) and thus detailing the problems your group has is very important to getting them resolved.&nbsp;

Tokens by default have the Hidden by Darkness setting toggled to off. There is a game default setting for this, but the Apply Default Settings button in the tabletop doesn't use it, so you can't apply the default setting to existing tokens. I honestly can't think of a use-case where I would want it off, and everything I've tried using the foreground for thus far I've definitely wanted it on. I just created a forest map with 260 tree canopy tokens on the foreground layer, before realizing that all of them were not being hidden by darkness. Default settings can't (currently) fix it after the fact, and the API doesn't appear to (currently) have foreground settings as available fields so I can't fix it with an ad-hoc script.

The use case would be if there are buildings or trees on the foreground layer under which are walls or tree trunks that include dynamic lighting barriers. The player can see the top-down view of the rooftop or tree canopy above the walls or tree trunks. As their token gets within the bounding box of the rooftop or canopy token, it disappears (or fades).

I love the foreground layer feature! Quick question: I use a lot of maps from Dungeon Alchemist in Roll20, and I'm using the Dungeon Alchemist Importer API to import maps. Right now, the importer will automatically place doors, windows, and even dynamic lighting on my maps. Will the importer ever account for the foreground layer? I noticed more DA maps with roofs over buildings and assumed this was in preparation for the new feature/layer.&nbsp;

Just been playing with a forest map, and am now encountering the problem with square boxes around&nbsp; "circular" tree tops on the Foreground layer. As it stands it's sorta workable, but not ideal by any means. Once again I'm throwing out a thought based on absolutely no understanding of the technology underlying the code/API etc, but what I'm thinking is... could there be an option of sorts to replace the box "4 Corner" frame with a polygonal frame that effectively cuts away the outside of the square frame, and leaves a user defined frame? So... you click on the image, open the polygon option and draw the polygon WITHIN the box frame by dragging the angles of the polygon around the image (within the boundaries of the square frame,) and the edges are removed. You won't have true "curves" as such but you could trim the frame to something where you aren't triggering a Foreground shift by crossing the corner of a square frame boxing in a round object... Again... NO idea what I'm talking about in terms of what that would require from a development point of view... just an idea from a user perspective.

I'm also loving the foreground layer, like a few others I'm finding that the bounding box can be a bit of an issue, especially with marketplace items where I have no way to edit the graphic to reduce the 'overhang', still it's workable with stuff that I can edit myself. Keep up the good work &amp; I look forward future tweaks/changes/improvements.

I've downloaded a few images that have a lot of empty transparent space around them,&nbsp; cropped them, then uploaded them to my personal art library. It would be cumbersome to do that with a large number of images, but it's a way to help get around a specific circumstance. Norman said: I'm also loving the foreground layer, like a few others I'm finding that the bounding box can be a bit of an issue, especially with marketplace items where I have no way to edit the graphic to reduce the 'overhang', still it's workable with stuff that I can edit myself. Keep up the good work &amp; I look forward future tweaks/changes/improvements.

Hi, Just wondered if I'm doing something wrong and someone has already figured this out. I've placed some roofs that match the footprint of the building so leaves half the door and window tokens visible. The roofs are acting as planned by disappearing when a token enters the building. I also have dynamic lighting working in that tokens can only enter the building through open doors and windows. The minor issue I have is a token can't look through a window as the roof remains in place until the token moves through the window. Is this expected behavior or do I need to adjust settings ?

That is working as intended.&nbsp; Roll20 can't know that you want the token to see inside the building from outside the footprint of the roof image.&nbsp; The workaround is to use a transparent .png image (likely just 1 square sized) and place that next to the roof where the window is, then select the .png and roof tile together on the Foreground layer and 'Group' them together.&nbsp; Then when a token moves next to the window, under the transparent .png image, the roof image will disappear at the same time because they are linked together.

Jarren, Thanks for the reply and good to know I wasn't doing anything wrong. Also thanks for you're clever solution

I couldn't find anything here about this, and maybe I missed it. However I am having difficulty with my lighting working on this page, where I've added some foreground items. The foreground items (roofs) disappear as they should, but the player view (not ctrl+L) is not obstructed by my lighting layer walls and doors. Is this a bug, or am I bugged and missing something? Here are some screenshots to ponder:

Zim Astrofal said: I couldn't find anything here about this, and maybe I missed it. However I am having difficulty with my lighting working on this page, where I've added some foreground items. The foreground items (roofs) disappear as they should, but the player view (not ctrl+L) is not obstructed by my lighting layer walls and doors. Is this a bug, or am I bugged and missing something? Here are some screenshots to ponder: Hi Zim! My first thought was to check and make sure Dynamic Lighting is actually turned on. I don't see indications of any light sources or sight blocking at all.

On the other hand, if there is a window, interior doors visible by line of sight, and not hidden by darkness SHOULD be visible. I'm currently dealing with a situation like that. I'm preparing a game to be played starting this summer (probably). On one map, I have a bar. The bar has windows and a door and I've placed a roof over the bar on the foreground layer. I've used Keith's door icon so that the door will be visible to the players so they know where it is. Once the door is open, and the players go through the door, the interior should be visible to them since the roof will fade away. The problem is dealing with the windows. As they move past the window, they should be able to "look in' and see inside the bar. I've accomplished this, at least temporarily, by placing a transparent icon near the windows and grouping them with the roof. The portion of the roof fades away and this does *almost* the right thing because of the way dynamic lighting, and line of sight works. It's close enough for them to get the effect. Since the window is "closed" and "locked", they can't get in that way and have to go over to the door. The problem is that the window icons are not visible. I've been trying to find a good window icon to use like the door icon that Keith posted, but haven't found anything i like. I may make one out of the standard window icon but that's more difficult (for me). Anyway, I wish there were a simpler way to accomplish the effect I want.&nbsp; One thing I was thinking about is that perhaps there could be some kind of "distance" parameter on tokens on the foreground layer. This could be used to have the foreground layer fade away if a token comes within X grid cells of the token. That would allow, for example, roof tokens to fade away if the players move within, say, 2 grid cells of the roof token. If the distance is 0, then the token behaves as it does now where you have to get into the same cell, but if it's non-zero, it fades away at that many cells away. Would something like this work? Or is it somehow already possible with the current settings and I just don't see how to do it? The problem with using a transparent token like I've done is that it's difficult to move around. It's part of a group so if I want to modify it (like increase the distance), I have to ungroup ALL the tokens, resize the one aI want, and then regroup ALL the tokens. So, if there are 6 windows, and I need to resize one, I have to ungroup 7 tokens (including the roof), resize the one, then regroup all of them. I can't just select a rectangular area around all the tokens because that would cause tokens inside the bar to be grouped along with the roof and windows... It really is troublesome to work with the foreground layer to get certain effects. I feel that a "distance" parameter might solve a lot of problems.&nbsp; Lavi said: Consider the application of using the layer for roofs. If the roof is covering the floorplan, it would be distracting (or spoiler-y) to reveal the location of interior doors." It sounds like a blanked solution of putting doors/windows always above or always below Foreground objects wouldn't work here, so curious on more input from community on ideas, use cases and things to consider here!

Here are updated copies of both the door and window icons. These are done at 512x512 (same as token markers), because I noticed the early ones were blurry at high zoom levels. These should be nice and crisp, just snap them to the grid for default sizing. I also changed the darkness of the circle. There was an update a few days ago that now allows the full icon to be seen if any part of them is visible (no more partial icons—it's no all-or-nothing). If this latest update passes muster, it should hopefully open the way for the dev team to address the issue with the same thing for foreground layer objects. And for comparison, side-by-side with the Roll20 actual objects. Slight differences, but not enough to be an issue:

No open door icon?

I don't want to derail the thread further, so here is a link to all door and window state icons , plus the sounds I uses for my DoorNoise script.

Thanks for that, Keith. But, I'm not sure it solves the complete problem.&nbsp; A person should be able to see through a window without walking up close to it, at least under certain circumstances. And, that leads back to having some kind of "distance" parameter on the foreground object to specify the distance away from it that it should fade away to reveal what's beyond or underneath it. You can specify the distance that light radiates, so I don't think it would be too hard to have a distance parameter on foreground objects. There are probably other applications for this. &nbsp; keithcurtis said: I don't want to derail the thread further, so here is a link to all door and window state icons , plus the sounds I uses for my DoorNoise script.

Thanks Saul, That image post was more in reference to Jim's post for filling out the set (also for others who commented such as JD, Gold, Rick, and Tommy). It wasn't intended to address window behavior in general. I have my own set of druthers regarding windows even before the foreground layer came into being. I can see where some users might like the setting you suggest, but to me it sounds computationally involved, and prone to "almost but not quite right" results. I'm not a real big fan of the windows feature, but the one I want (that increases distance of view or perhaps transparency the closer you get to it), is probably unworkable.