Animations and AFoW Offical Feedback Thread

I had to turn off dynamic lighting. Plot wise, I just had (as a prize for completing a mission) an an NPC 'show the PCs an accurate map' of level 2 of the dungeon. - I've had to move all monsters to the GM layer and the players can now see all secret rooms, which is a little disappointing.... but it's not the end of the world. I'll give roll20 another week or two before I downgrade my account to 'free' whilst we wait for some of the bugs to get resolved.

Hi, everyone. Thanks for your feedback and patience! We're close to a fix for some of these lighting/AFoW issues. I can't promise an exact time frame, but it is very high priority right now. We're hoping to get them into QA, and may put them out in a hotfix.

This issue with the dynamic lighting has plagued us for 2 months now. What am I paying for if the service I'm paying for is broken? Broken Auras, broken Dynamic Lighting, broken FoV rendering...  I've subbed to this site for something like 5 years. I've never had the service so unusable for so long.

Moving report here: Mike L.  said: I first noticed this issue on March 24. When I put my players on a map with global illumination, it doesn't let them see anything that they haven't already revealed with their own, character-based light radius (i.e. 60' for darkvision).  I have the same issue when I place an external light source on the map (I have made sure that all the players "have sight" and that the source is set to "all players see light").  Is this a known issue? If so, how can I fix it. That fixes the external light problem, but if I turn AFOW off, I can no longer keep the map layer revealed after the players move on. I would prefer to be able to continue to use that feature as well, but I understand if that is not currently possible.

No offence, but may I ask why didn't you considered to just cancel the patch that caused this AFoW issue, while you are working for a solution? 

Stephanie B. said: Hi, everyone. Thanks for your feedback and patience! We're close to a fix for some of these lighting/AFoW issues. I can't promise an exact time frame, but it is very high priority right now. We're hoping to get them into QA, and may put them out in a hotfix. I see some fixes have been implemented already? I tested it and it was working moderately well? Of course I was the DM using CTRL-L, not sure if the actual players have it the same. The only thing still not working is light-emitting NPC's or objects...  EDIT: Nevermind. I see that there are still issues with how AFoW is working. It reveals by square not by dynamic lighting lines - meaning a door that's diagonal is not shown as the square remains dark no matter what.

The Xyad said: EDIT: Nevermind. I see that there are still issues with how AFoW is working. It reveals by square not by dynamic lighting lines - meaning a door that's diagonal is not shown as the square remains dark no matter what. That part is how AFoW has always worked. It reveals cells by determining if the center point of that cell has been seen.

Since the most recent lighting/fog changes, I've noticed that the token light multiplier does not seem to work at all. All my player tokens had previously been set up for darkvision at 30/0/x2 as per a suggestion on the wiki. Until recently this had resulted in the expected behaviour of a 60ft light radius that would turn dark to dim and dim to full. Now however it merely provides the 30ft bright light in a square, indicating the multiplier isn't being applied at all.

Any timeline on fixing .webm files not working in rollable tables? There’s a bunch of monsters I can’t animate until this is fixed. Basically any monster that shapeshifts or has an alternative movement mode (like flight). That includes dragons. And anything that burrows, which is all the coolest monsters.

Hello, Are there any news regarding animation lag? Some people seem to be having trouble even with a single animation. File size is very small (<1mb), and running the animations on my computer I can run well over a dozen, ten times the size of those without a problem; add them to Roll20 and the platform explodes. Is there anything users can do to improve the experience while Roll20 works on a fix? Thanks you.

keithcurtis said: The Xyad said: EDIT: Nevermind. I see that there are still issues with how AFoW is working. It reveals by square not by dynamic lighting lines - meaning a door that's diagonal is not shown as the square remains dark no matter what. That part is how AFoW has always worked. It reveals cells by determining if the center point of that cell has been seen. Gotcha. Didn't know that.

No worries. Here's a link to a wiki section on how they are supposed to interact. They don't do that right now. :(

Imagine any other subscription service releasing a patch that breaks the current service for nearly all subscribers. I get that roll20 is probably a smaller dev team, but as has been suggested, why didn't you just recall the content patch until it was more QA'd or you had fixes for the problems it causes? At this point I'm close to just asking for a refund for the months I've been using a broken service that I've been paying for. 

Nick S. said: Hello, Are there any news regarding animation lag? Some people seem to be having trouble even with a single animation. File size is very small (<1mb), and running the animations on my computer I can run well over a dozen, ten times the size of those without a problem; add them to Roll20 and the platform explodes. Is there anything users can do to improve the experience while Roll20 works on a fix? Thanks you. During my game on Tuesday, I noticed that switching to a map that had animations on it (2x2 rain overlay tiles) caused the jukebox to start stuttering in a way that sounded a lot like a stream struggling to buffer.  This is pure speculation, but I'm guessing that R20 might be struggling with how it streams the data - rather than a ~1mb file, it's acting more like a constant video stream, for each animation, stacked on top of streaming the data and music. Each on my players has fairly powerful machines so I know it's not a bottleneck there, and only one of us got both smooth animations and audio. I noticed that it certainly seems to perform better for the players than the DM though.  As I said - pure speculation. I just know that there are these cool features that I want to use more of, so seeing them fixed is in my best interest. That, and things like dynamic line of sight and the advanced fog of war look nifty, but if the system can't handle animations on their own I'm not going to shell over money for a subscription when it's only going to hit the performance further. 

Performance with animations seems to be horrible. I testes it with my 2 of my players and it seems to consume a lot of cpu (~65% of my CPU: i5 3570k) and even 50% of more modern cpus. Also does not unload the animations properly: Even if I delete the animations, the high cpu usage does not disappear. 

Nico, If you view just the animation in your browser, what kind of performance do you get? Can you post a console log from while the animations are running and when you try to delete the animation?  Nico said: Performance with animations seems to be horrible. I testes it with my 2 of my players and it seems to consume a lot of cpu (~65% of my CPU: i5 3570k) and even 50% of more modern cpus. Also does not unload the animations properly: Even if I delete the animations, the high cpu usage does not disappear. 

Finally uploaded (processed!) a 1920x1080 10 second video but the bitrate was dropped down too much to be usable. Any way to clone the original format? Also the quality appears to shift, my second upload looks much better than my first but transitions from high bitrate (quality) to low bitrate. Like the first 2-3 seconds looks great but then the rest gets all fuzzy as it compressed the data more. This is so close to amazing, looking forward to longer and higher quality streams!   

Well, I still have problems with the animations bought in the market. I can not even upload most of them. These animations (the problematic and majority files of the packs) appear in my library but can not be inserted in the Pages of the game. Is there any solution for this? Thanks

Stephanie B. said: Nico, If you view just the animation in your browser, what kind of performance do you get? Can you post a console log from while the animations are running and when you try to delete the animation?  Nico said: Performance with animations seems to be horrible. I testes it with my 2 of my players and it seems to consume a lot of cpu (~65% of my CPU: i5 3570k) and even 50% of more modern cpus. Also does not unload the animations properly: Even if I delete the animations, the high cpu usage does not disappear.   I can also confirm that animations seem to have extremely poor performance in-game. Outside of the game I can have 50 tabs open with the large animations playing and looping at once without a problem, and in-game it seems to struggle even with one. It's not unplayable for me, but it is noticeable slower and stutter. I know there is a bug with audio + animations that causes that, but even without a single sound being played, animations seem to have trouble playing. Kefrem  said: not sure if a fix has been posted or not..i didn't see it but im tired from work all day but my animations still don't have transparency :( does roll20  need flash to be enabled to use these animated tokens? I have seen a few reports like this one both in this thread and out, and have encountered the problem myself (and sent logs to the devs weeks ago) but I haven't seen a single reply to the problem nor is it in the known bugs. At times animations seem to lose transparency and become a black square sometimes with the animation playing on top of it. Sometimes if fixes on its own after a while, other times not. No idea what is causing it yet. Alexandre M. said: Well, I still have problems with the animations bought in the market. I can not even upload most of them. These animations (the problematic and majority files of the packs) appear in my library but can not be inserted in the Pages of the game. Is there any solution for this? Thanks Alexandre, if you bought animations in the marketplace you're not supposed to re-upload them. You should be able to find them in-game in your Art Library > Premium Assets > Marketplace Purchases > "pack's name". You should be able to drag and drop the effects into the tabletop from there. Keep in mind that when you drop the image into the map it will probably occupy a single square/tile (and with weather effects it might be hard to see at such a small scale), so you'll need to select it and resize as needed.

Nick S. said: Stephanie B. said: Nico, If you view just the animation in your browser, what kind of performance do you get? Can you post a console log from while the animations are running and when you try to delete the animation?  Nico said: Performance with animations seems to be horrible. I testes it with my 2 of my players and it seems to consume a lot of cpu (~65% of my CPU: i5 3570k) and even 50% of more modern cpus. Also does not unload the animations properly: Even if I delete the animations, the high cpu usage does not disappear.   I can also confirm that animations seem to have extremely poor performance in-game. Outside of the game I can have 50 tabs open with the large animations playing and looping at once without a problem, and in-game it seems to struggle even with one. It's not unplayable for me, but it is noticeable slower and stutter. I know there is a bug with audio + animations that causes that, but even without a single sound being played, animations seem to have trouble playing. Kefrem  said: not sure if a fix has been posted or not..i didn't see it but im tired from work all day but my animations still don't have transparency :( does roll20  need flash to be enabled to use these animated tokens? I have seen a few reports like this one both in this thread and out, and have encountered the problem myself (and sent logs to the devs weeks ago) but I haven't seen a single reply to the problem nor is it in the known bugs. At times animations seem to lose transparency and become a black square sometimes with the animation playing on top of it. Sometimes if fixes on its own after a while, other times not. No idea what is causing it yet. Alexandre M. said: Well, I still have problems with the animations bought in the market. I can not even upload most of them. These animations (the problematic and majority files of the packs) appear in my library but can not be inserted in the Pages of the game. Is there any solution for this? Thanks Alexandre, if you bought animations in the marketplace you're not supposed to re-upload them. You should be able to find them in-game in your Art Library > Premium Assets > Marketplace Purchases > "pack's name". You should be able to drag and drop the effects into the tabletop from there. Keep in mind that when you drop the image into the map it will probably occupy a single square/tile (and with weather effects it might be hard to see at such a small scale), so you'll need to select it and resize as needed. Wow, this is really embarrassing. I had never selected the "Premium Material" option in my library until today. I swear, I tend to be better than this. Nick, thank you very much for your help!

It's been 2 months and my campaigns are still broken. I haven't been able to work at all since that day. All I could do is upload music, which is nice, but when I see that the "high priorities" are not what makes my campaigns unplayable, I'm getting a bit salty. My players are starting to complain and all I can answer them is those problems aren't "high priorities" and that I have no idea when I could prepare our next game. I don't like to complain, I'm usually patient, but the service have been unusable for so long now.

Hi, all. The devs have asked me to get a few game IDs from games where audio stops or jitters when animations are playing. If you're having this problem, can you please reply here with the game ID for a game where you know this has happened? The game ID is the number in your URL when you go to the game details page (not the invite link-- sharing the game ID doesn't invite everyone to your game, although one of the devs will likely join to take a look at what's going on.) Thanks!

Alexandre, When you download images from the marketplace and then upload them to your library, they take up some of your storage space because Roll20 doesn't have a way to know that what you uploaded was a purchase. When you use them directly from the premium material folder, they do not take storage space. They're available to download because many content creators allow you to use them outside of Roll20.  So, you might find this can help you recover some storage space, too! Alexandre M. said: Wow, this is really embarrassing. I had never selected the "Premium Material" option in my library until today. I swear, I tend to be better than this. Nick, thank you very much for your help!

Hi, all! This morning we pushed out a hotfix with the following bug fixes: AFoW does not reveal using DL vision radius multiplier Tokens with sight should have infinite-ranged AFoW vision when Global Illumination is on This should fix some of the issues with how dynamic lighting and AFoW interact. We're continuing to work on more fixes to these systems, and thank you for your patience. The next item we're focusing on is finishing the token bar fixes that are on the Dev server so they can be released.

Stephanie B. said: The devs have asked me to get a few game IDs from games where audio stops or jitters when animations are playing. If you're having this problem, can you please reply here with the game ID for a game where you know this has happened? Hey Stephanie! Here's the game ID number for my Experimental Testing Facility!!! 4233404 This campaign has an add-on pack of my Dynamic Dungeons pack with DL/AFoW set up, and on the 2nd Tab (titled "Cultist Lair 01" - Flagged) there are a few animations. That page will trigger the audio bug. I have noticed it is triggered when I place one of the larger sized animations from my weather set on the board - Specifically the 30x30 Smoke Overlay on the far right is the tile that triggered the bug on this page. I've noticed smaller animations do not seem to trigger the bug (at least not in my experience yet, and I have added several to any individual page and they have been fine). In addition to that The last two pages on this campaign are some other tests I ran with my newest tile set "Seamless Winter Forests". The page titled "Animated Winter Test" has 4 large 30x30 Animated maps (60x60 in total size). It hasn't triggered the audio bug to my knowledge, but you can clearly see the loss of quality on the art itself as well as the massive amount of CPU usage that tab will force my computer to use up (and I have a pretty decent computer rig). The next page in the campaign titled "Still Winter Test" shows those same 30x30 maps (60x60 in total page size) as JPEG and no loss of image quality and no drastic CPU usage on my end. The reason I bring those up is the loss of quality to larger animations make it difficult for us creators to produce a quality animation for everyone. I want to make full sized maps, and as of right now, that seems like a bad idea with the CPU usage and loss in quality from the conversion process. Dean and I chatted this past Monday evening about these larger sized (not file size as they are under 3mb each, but space of the animation takes up is 4200x4200 pixels) and it seems to clog up the upload when they upload them. Most of these take hours to upload. They also hog a lot of CPU in Roll20, but I can open the same images in my browser and have 40+ tabs open of that animation and have barely any CPU usage. I have an Audio Loop of some music I recorded and uploaded through My Audio, and there are several songs and jingles in the Jukebox that I have created and uploaded for testing purposes. Feel free to hop in there and move stuff around. If you or any of the DEVs need any other examples from my weather set (that is the one that seems to be triggering these audio bugs) I would be more than happy to drag a few more animations onto the various pages. Feel free to reach out to me. I'll have that page open so I should hear the "BLOOP" if one of the DEVs drop a line in the chat bar of that campaign. Also there is a little Tribal Goblin Monk Token (named Dogo) that has the permissions for All Players on several pages with Settings set up for Vision. You can see the lag that token generates when moving it around on the maps as it interacts with the DL/AFoW. Thanks for all of the hard work! I look forward to seeing the Dynamic Lighting, Advanced Fog of War, and the Animation/Audio bugs fixed, and hopefully the ability for us creators to be able to continue to produce top notch content that works without any loss of quality or drastic CPU usage on the end user's part!

Sam, Do the tokens which don't Emit Light and can't see have their AFoW View Distance set? If a token Emits Light and no AFoW View Distance, the AFoW will use that as its sight distance. If a token has nothing in Emits Light and it has an AFoW View Distance set, AFoW will reveal up to the view distance, based on any other light sources around. If a token has neither Emits Light now AFoW View Distance set, then the token cannot see at all. This is as designed; the AFoW Distance determines how far a token can see if it doesn't have a light source.   Sam T. said: Sam T. said: So I have an (apparently) related issue where the advanced fog of war is not being revealed for tokens which do not emit light themselves, despite being able to see due to other light sources.   We're using Advanced Fog of War and Dynamic Lighting.  We also have Enforce Line of Sight enabled so that players do not share vision.  The situation we're experiencing is as follows:  If a player controlled token emits light, then that token's vision reveals the advanced fog of war as expected.  However, for player controlled tokens that do not emit light, but can see in a region because of other light sources (e.g. light sources controlled by other players, ambient light emitting tokens on the dynamic lighting layer or map layer, or global illumination), then their vision does  not  reveal the advanced fog of war in that region for the controlling player. Note: Fog of War is not enabled.  All player tokens have "Has Sight" checked.  All light emitting tokens have the "All players see light" option checked.  I have tried both with and without "Dim Light Reveals" enabled.  I've been able to reproduce this behaviour in every different game I play in. By way of example: imagine two player controlled tokens (controlled by different players) are in a dark room.  One token emits light (with the "all players see light" option checked), meaning both players can see the whole room.  When the tokens leave the room, the advanced fog of war was only revealed in that room for the player controlling the token which was emitting the light. I'm still experiencing this behaviour after the hotfix.  I don't see this issue in the known issue list in the top level post.

We don't have a timeline, but it is coming up in the development cycle. I agree, it's a cool feature, and I look forward to it working as intended. Gargamond said: Any timeline on fixing .webm files not working in rollable tables? There’s a bunch of monsters I can’t animate until this is fixed. Basically any monster that shapeshifts or has an alternative movement mode (like flight). That includes dragons. And anything that burrows, which is all the coolest monsters.

This does not fix the primary problem with AFoW: a player cannot see an area that they should be able to see unless the fog of war has been cleared on that square. Clearing the AFoW out to an infinite distance on a global illumination map still means that any squares with the center on the wrong side of a DL line block the players vision. I turned Global Illumination on for an interior map to demonstrate the problem. Left is GM view. Right is player view. The DL lines follow the curved corridor, and the token has a 5-foot AFoW view distance in this example. There is no reason why the player should not be able to see down the curved corridor to the northeast and southeast. AFoW must not block a token's vision. Fog of war only works when what a unit can see clears the fog of war, and the area a player can see in color should not change based on whether AFoW is on or off. Before the January 29 update, the AFoW view distance seemed a bit odd, but I assumed it was to limit calculations. Now it blocks vision. Roll20 already did the DL calculations correctly. I am surprised the calculations were not also used to clear the fog of war rather than the square-based solution that has been used.. Persisting a 100 x 100 square map as a 1-bit indexed image would be under 30KB.

Brian, Can you post a screen shot of the dynamic lighting lines for this snippet? If AFoW can't "see" the center of the square, it doesn't reveal the square. That hasn't changed with this update. Brian C. said: This does not fix the primary problem with AFoW: a player cannot see an area that they should be able to see unless the fog of war has been cleared on that square. Clearing the AFoW out to an infinite distance on a global illumination map still means that any squares with the center on the wrong side of a DL line block the players vision. I turned Global Illumination on for an interior map to demonstrate the problem. Left is GM view. Right is player view. The DL lines follow the curved corridor, and the token has a 5-foot AFoW view distance in this example. There is no reason why the player should not be able to see down the curved corridor to the northeast and southeast. AFoW must not block a token's vision. Fog of war only works when what a unit can see clears the fog of war, and the area a player can see in color should not change based on whether AFoW is on or off. Before the January 29 update, the AFoW view distance seemed a bit odd, but I assumed it was to limit calculations. Now it blocks vision. Roll20 already did the DL calculations correctly. I am surprised the calculations were not also used to clear the fog of war rather than the square-based solution that has been used.. Persisting a 100 x 100 square map as a 1-bit indexed image would be under 30KB.

Stephanie B. said: We don't have a timeline, but it is coming up in the development cycle. I agree, it's a cool feature, and I look forward to it working as intended. Gargamond said: Any timeline on fixing .webm files not working in rollable tables? There’s a bunch of monsters I can’t animate until this is fixed. Basically any monster that shapeshifts or has an alternative movement mode (like flight). That includes dragons. And anything that burrows, which is all the coolest monsters. Ok. Thanks for your diligence, Stephanie.

My AFoW still does not work with dynamic lighting. I even tried making a new campaign. Here's a screenshot from a fresh Phandelver module with the Dwarf Cleric character. It's token should be emitting light and revealing fog of war, but still does not.

Robert, What are your dynamic lighting settings for that page?  Robert G. said: My AFoW still does not work with dynamic lighting. I even tried making a new campaign. Here's a screenshot from a fresh Phandelver module with the Dwarf Cleric character. It's token should be emitting light and revealing fog of war, but still does not.

Stephanie B. said: Robert, What are your dynamic lighting settings for that page?  Robert G. said: My AFoW still does not work with dynamic lighting. I even tried making a new campaign. Here's a screenshot from a fresh Phandelver module with the Dwarf Cleric character. It's token should be emitting light and revealing fog of war, but still does not. Dynamic Lighting is Enabled, and Enforce line of sight is enabled.

Stephanie B. said: Hi, all. The devs have asked me to get a few game IDs from games where audio stops or jitters when animations are playing. If you're having this problem, can you please reply here with the game ID for a game where you know this has happened? The game ID is the number in your URL when you go to the game details page (not the invite link-- sharing the game ID doesn't invite everyone to your game, although one of the devs will likely join to take a look at what's going on.) Thanks! My game is 4220139 - if i've got the right number. On mobile at the moment so I'm not navigating as well as possible. 

Robert, Does the lighting update if you move the token? (We just recreated this, but found that nothing was revealed until the token moved). And is the token assigned to anyone? Tokens need to be assigned in order to reveal AFoW. Robert G. said: Stephanie B. said: Robert, What are your dynamic lighting settings for that page?  Robert G. said: My AFoW still does not work with dynamic lighting. I even tried making a new campaign. Here's a screenshot from a fresh Phandelver module with the Dwarf Cleric character. It's token should be emitting light and revealing fog of war, but still does not. Dynamic Lighting is Enabled, and Enforce line of sight is enabled.

The AFoW "leak" still happens after the hot fix. Here's a screenshot showing a test that clearly reveals a square in the bottom right corner that should not be visible based on the DL lines on the walls: GM view: When will this be fixed? I've had to abandon some maps for this reason alone. It'd be nice to get the "token hidden by Has Sight limitations" bug fixed too...

Ben, Can you provide the game ID where this is happening?  Ben L. said: The AFoW "leak" still happens after the hot fix. Here's a screenshot showing a test that clearly reveals a square in the bottom right corner that should not be visible based on the DL lines on the walls: GM view: When will this be fixed? I've had to abandon some maps for this reason alone. It'd be nice to get the "token hidden by Has Sight limitations" bug fixed too...

Stephanie B. said: Robert, Does the lighting update if you move the token? (We just recreated this, but found that nothing was revealed until the token moved). And is the token assigned to anyone? Tokens need to be assigned in order to reveal AFoW. Robert G. said: Stephanie B. said: Robert, What are your dynamic lighting settings for that page?  Robert G. said: My AFoW still does not work with dynamic lighting. I even tried making a new campaign. Here's a screenshot from a fresh Phandelver module with the Dwarf Cleric character. It's token should be emitting light and revealing fog of war, but still does not. Dynamic Lighting is Enabled, and Enforce line of sight is enabled. Ok that may have done it! I assigned a player, and then moved the token and it appears to work now. Thank you!

Game ID is 4119730 Stephanie B. said: Ben, Can you provide the game ID where this is happening?  Ben L. said: The AFoW "leak" still happens after the hot fix. Here's a screenshot showing a test that clearly reveals a square in the bottom right corner that should not be visible based on the DL lines on the walls: GM view: When will this be fixed? I've had to abandon some maps for this reason alone. It'd be nice to get the "token hidden by Has Sight limitations" bug fixed too...

Stephanie B. said: Brian, Can you post a screen shot of the dynamic lighting lines for this snippet? If AFoW can't "see" the center of the square, it doesn't reveal the square. That hasn't changed with this update. Brian C. said: This does not fix the primary problem with AFoW: a player cannot see an area that they should be able to see unless the fog of war has been cleared on that square. Clearing the AFoW out to an infinite distance on a global illumination map still means that any squares with the center on the wrong side of a DL line block the players vision. I turned Global Illumination on for an interior map to demonstrate the problem. Left is GM view. Right is player view. The DL lines follow the curved corridor, and the token has a 5-foot AFoW view distance in this example. There is no reason why the player should not be able to see down the curved corridor to the northeast and southeast. AFoW must not block a token's vision. Fog of war only works when what a unit can see clears the fog of war, and the area a player can see in color should not change based on whether AFoW is on or off. Before the January 29 update, the AFoW view distance seemed a bit odd, but I assumed it was to limit calculations. Now it blocks vision. Roll20 already did the DL calculations correctly. I am surprised the calculations were not also used to clear the fog of war rather than the square-based solution that has been used.. Persisting a 100 x 100 square map as a 1-bit indexed image would be under 30KB. The DL lines are dead in the middle of the stone walls in the picture. While AFoW has historically revealed by square, what has become a problem in the last two months of updates and what has changed  is that AFoW now blocks what a token should see at that moment. It used to be that you could turn AFoW on or off, and there would be no difference in what you would see in color (only the cleared fog of war would change). Before January 29, AFoW did not block what a token was currently viewing . This has been brushed aside each time I have brought it up.  I am tired of being gaslighted about this. The products I have developed for the Roll20 marketplace are full of maps from products not originally designed for VTT. DL and AFoW have been used extensively. 80% or more of the DL lines do not line up with the grid. DL lines were set up in the middle of the walls on the map whether they were straight, curved, lined up with the grid or not. The player tokens could always see to the DL lines even if the center of squares was on the far side of the DL line. Once the token moved on, then the square would go dark again if the center of the square had not been revealed. Here are images from the previews showing DL taking precedence over AFoW for determining what a player could see. I am sorry I don't have better examples; I did not know half a year ago that I was going to have to provide evidence now. In each of these, the player can see the full extent of their vision, even if they cannot see the middle of a square. The first picture has no DL lines, but the squares on the leading edge have not yet been revealed. The upper right of this image has DL lines that the player can see all the way to, even though the DL lines are closer than some of the squares it cuts across. In the next image you can see a corner of an AFoW square being revealed on the upper-left of the token's field of vision, but the DL takes precedence. In the current system, large portions of the viewable area would be blocked. This next one is probably the most telling. The token can see to the DL lines, which are not aligned to the grid and are closer to the token than the center of the squares that they are in. Now what the token can see is limited by the grid. The walls used to be fully visible up to where the DL lines are. Now the vision is limited by the grid. Please stop telling me that the behavior in the quoted image at the top of this post is how the system has always worked. That is demonstrably false. The behavior has changed, and it is for the worse. The features need to go back to how they worked before regardless of how they are implemented.

OK, so the dev and I took a look at your game and think we know what's going on. There's a direct, unobstructed line between the center of your token's square and the center of the square being revealed. It pretty much slips right between the dynamic lighting lines you have set up: AFoW can be finicky like this; it's very strict about what counts as being revealed or not-revealed. I've logged a ticket to see what we can do to make this less of an issue, but ultimately, there's a point in the math where it has to say "yes" or "no." Some possible workarounds: You can add a little length to some of your dynamic lighting lines to get the square to not reveal. You can adjust the cell width a bit to make it so the center of the square isn't perfect (I found 69.75 pixels was enough to hide that square). Ben L. said: Game ID is 4119730

What Brian C said affects not just marketplace creators but anyone who creates maps for their own games.  Of course marketplace creators should get better response from Roll20 than seems to have been happening. Anyway Brian thanks for explaining, maybe the devs will understand what needs to be fixed now.

What on earth?!?! Why is the meaning of the user interface changing to be so convoluted? This change puts hidden meaning into the UI options. The pre-Jan 29 update implementation at least did what the user interface said. I want the token to provide vision for the player.  - Tick the "Has Sight" box. You can now see all illuminated areas not blocked by DL lines. I want the token to provide light.  - Set the "Emits Light" values. I want the other tokens to see this token's light.  - Also tick the "All Players See Light Box". I want the token to clear the fog of war (where the token can see) up to a certain radius.  - Set the AFoW "View Distance". Each UI element controlled 1 thing. AFoW View Distance has no business controlling what a token can see from light sources or how far it should be able to see; it should only control clearing the fog of war. Having an AFoW view distance of 30 feet should not stop a token from seeing a light source 40 feet away. Similarly, a token without the AFoW view distance set should be able to see an unobstructed light source 10 feet away (or 100 feet away). Making a breaking change is bad enough even if it had been for the better (which this isn't). Changing what the UI options do in ways not reflected in the UI makes for a bad user experience. Stephanie B. said: Sam, Do the tokens which don't Emit Light and can't see have their AFoW View Distance set? If a token Emits Light and no AFoW View Distance, the AFoW will use that as its sight distance. If a token has nothing in Emits Light and it has an AFoW View Distance set, AFoW will reveal up to the view distance, based on any other light sources around. If a token has neither Emits Light now AFoW View Distance set, then the token cannot see at all. This is as designed; the AFoW Distance determines how far a token can see if it doesn't have a light source.  

Okay, so the first problem I posted earlier today was lame but avoidable. However, here is an even bigger problem. This involves the AFoW View Distance that some have been complaining about. I have DL and AFoW set on this map with everything on but Global Illumination. My token emits light 40/20 in 360 degrees and has sight at 170 degrees. If I set the view distance to 5 ft., the area behind the token displays as expected, i.e. out 5 ft. However, the light being emitted is not revealing anything beyond this view distance as it should. That is, light isn't as important as the view distance when calculating what AFoW reveals. The opposite should be true, as light always reveals what normal darkness hides in the real world (and in most RPG games I would imagine). Ok, so let's compensate for this egregious bug. Let's get rid of the view distance number and let the light source do its thing. Oops! Now, although the fog was reset and the token has never been turned, the area behind the token has been revealed as far back as it could go when it should have been only 5 ft. out. This problem is arguably even worse because now AFoW is revealing areas the token hasn't discovered yet. I can't imagine any of this is "as designed" and it certainly isn't how it ought to work. Undiscovered areas of the map should never be revealed unless the token has moved into the area with light sufficient to allow it. P.S. Turning off Dim Light Reveals removed only one square from the furthest point in every direction, even where it should not have been revealed in the first place. This means it (or the dim light functionality itself) is broken in some fashion.

It still seems like its not working correctly as it did 3 weeks ago. I use to be able to set a tokens light setting sto 30ft bright -5 dim, and 2x multiplier to mimic dark vision. All it does now is makes it so the token can only see the 5 foot square its on, everything else is dark. Players can't see light source tokens unless its within their range as well? And fog of war is revealed blocky, compared to how it was. (Example of how it use to work:&nbsp; <a href="https://twitter.com/roll20app/status/912785141965164548?lang=en" rel="nofollow">https://twitter.com/roll20app/status/912785141965164548?lang=en</a> ) From DM view:&nbsp; From Player view:&nbsp; Also players can't see light sources anymore if its not in their view distance? From DM view:&nbsp; From player view:&nbsp;

Moving report here: J.D. &nbsp;said: Hi there, This issue may have already been brought up by others, but I couldn't readily find an existing post relevant to my issue. Anyways, I'm trying to use both the features mentioned in the subject line in tandem to help with revealing areas dynamically for player tokens as they explore a dungeon while keeping areas they've already explored revealed (in dim gray). &nbsp;At first I thought things were working as they should. I had all the dynamic lighting settings activated-(no global illumination; restrict movement, &amp; enforce line of sight. &nbsp;As for the AFOW feature, I have the page set to show grid and dim light reveals. &nbsp; What is happening is the players are able to see more than half the map in dim gray mind you, but it is revealing areas they haven't yet been too, thus giving away the layout of the dungeon ahead of them without the encounters of course. &nbsp; The screenshot below is from the Player Token's perspective. &nbsp;As you can see most of the dungeon is being revealed while some areas mainly the lower left corner are blacked out. &nbsp;That portion of the map appearing to be working as intended. The 2nd screen shot seen below is the GM layer showing the dynamic lighting boundary markings as well as the areas that have been explored by the players inside the red outline. &nbsp; As you can see much of the interior dungeon is being revealed and I can't seem to figure out what is causing this or better yet, how to fix it to where they can't see the unexplored areas. &nbsp;I thought the purpose of using these two features were to help reveal areas as they tokens move through while keeping areas hidden using the dynamic lighting feature. &nbsp;If I am wrong to assume this, someone please correct me. Any assistance with this would be greatly appreciated! Thanks!

Any word on when the Ctrl + L issue is going to be fixed? It's been the bane of trying to run my dynamic lighting heavy game, with players that all have darkvision. It's been months now. I'm starting to wonder why I even subscribe to this service...

Marek said: Any word on when the Ctrl + L issue is going to be fixed? It's been the bane of trying to run my dynamic lighting heavy game, with players that all have darkvision. It's been months now. I'm starting to wonder why I even subscribe to this service... Until it is fixed, you can run a free test account in whichever of Firefox or Chrome you do not currently use for Roll20. Give the test player a character with normal vision and one with darkvision. You can then run the GM account and the test account simultaneously from the two different browsers. This allows you to make changes on the fly and see them in the test account's browser. It works even better if you happen to have a two-monitor setup as you can see them at the same time.

@Berenice and Roll20 Mods-The title for the game is called Faerun’s Falling. &nbsp;I couldn’t see anything else to identify the page by. &nbsp;If there is a specific number for the Game ID, I do not know what that is. &nbsp;Thanks!